Обсуждение: Question about concurrent synchronous and asynchronous commits
I notice on the documentation page about Asynchronous Commit (http://www.postgresql.org/docs/8.3/static/wal-async-commit.html), it says the follow "The user can select the commit mode of each transaction, so that it is possible to have both synchronous and asynchronous commit transactions running concurrently". Now out of curiously, I have a couple questions about the details of this.
If I commit asynchronously and then follow that with a synchronous commit, does that flush the asynchronous commit as well?
Is the WAL strictly linear in that commit order must always replay back in the order that transactions return on the server, regardless of whether they are asynchronous or synchronous?
Thanks,
Dan
On Wed, Jan 12, 2011 at 12:03 AM, Dan Birken <birken@gmail.com> wrote: > If I commit asynchronously and then follow that with a synchronous commit, > does that flush the asynchronous commit as well? I'm pretty sure it does, because it has to flush the write-ahead log to disk, and there's only one. You can think of it as getting the flush for free from the first transaction, since the single flush covered the requirements of both transactions.
Ok given your response, this is my understanding of how the WAL works:
When you begin a transaction, all your changes write to the in-memory WAL buffer, and that buffer flushes to disk when:
a) Somebody commits a synchronous transaction
b) The WAL buffer runs out of space
Please correct me if I'm wrong.
-Dan
On Wed, Jan 12, 2011 at 12:32 PM, Vick Khera <vivek@khera.org> wrote:
On Wed, Jan 12, 2011 at 12:03 AM, Dan Birken <birken@gmail.com> wrote:I'm pretty sure it does, because it has to flush the write-ahead log
> If I commit asynchronously and then follow that with a synchronous commit,
> does that flush the asynchronous commit as well?
to disk, and there's only one. You can think of it as getting the
flush for free from the first transaction, since the single flush
covered the requirements of both transactions.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
On Thu, Jan 13, 2011 at 6:55 PM, Dan Birken <birken@gmail.com> wrote: > When you begin a transaction, all your changes write to the in-memory WAL > buffer, and that buffer flushes to disk when: > a) Somebody commits a synchronous transaction > b) The WAL buffer runs out of space > Please correct me if I'm wrong. I don't think there is an explicit in-memory WAL -- it is just the file's I/O buffer. What the commit causes is that disk file to be flushed to disk using the sync file system call, ensuring the durability of the transaction. The call to sync() is very expensive and is what is optimized out for the asynchronous transaction mode. This is my understanding as a user. I do not write the code that does this.