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:
Show quoted text
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.--
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.