Does Tx.WriteTo need to have Tx open for entire duration of io.CopyN?

[andreyvit]

Tx.WriteTo is fundamentally a long-running operation, it needs to read and write the entire size of the database. If, meanwhile, a write transaction needs the database to grow, everything gets stuck until the backup (WriteTo) completes. This is unfortunate.

After writing the meta pages, why does Tx.WriteTo need to keep holding the transaction open? Can we make a different method that simply returns the open file and size, and allows the caller to proceed with io.CopyN, while releasing the read transaction?

Any pitfalls here? I guess there's a concern about some required pages being overwritten, resulting in an inconsistent state? If yes, is there another way to avoid WriteTo blocking mmap resizing, perhaps (again, in a new method) by taking over the Tx entirely, and marking it as not blocking mmaps?

[ahrtr]

Since it's just a question, so I converted it into a discussion topic.

After writing the meta pages, why does Tx.WriteTo need to keep holding the transaction open?

It guarantees repeatable read. If you close the readonly transaction, then there will be no guarantee on repeatable read. No transaction, no guarantees.

Tx.WriteTo is fundamentally a long-running operation, it needs to read and write the entire size of the database. If, meanwhile, a write transaction needs the database to grow, everything gets stuck until the backup (WriteTo) completes. This is unfortunate.

Yes, it's correct based on current design & implementation. Let me know if you have any thoughts to improve this.