Thread: Synchronous Commit Doc Patch
Doc patch only... To aid with the understanding of the synchronous commit technique, I've completed the docs prior to the completion of the final version of the patch. Any review comments, final doubts etc.., please say them now... Applies cleanly to CVS HEAD, sgml make OK. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Attachment
On Fri, 2007-07-13 at 15:01 +0200, Reviewer wrote: > I just read your patch in order to understand a little bit what will > happen in the next release. Thanks for the review. v2 attached. > About the guc variable wal_writer_delay, you say at the end: > "This parameter can only > + be set in the postgresql.conf file or on the server command line." > > Well, I don't really understand if this parameter is set only at server > startup or if it is possible to modify the postgresql.conf file and then > reload the conf-files. A common confusion. I'm not personally in favour of using that phrase in the docs, though it is the standard description of when to set this type of parameter, so I have followed the convention. > Also, in the part about synchronous commit and fsync=off, there's just a > missing verb, I think you should insist between the two possibilities : > system or database server crash, maybe by using some bold. I've reworded that part. Thanks for spotting this. > From a user point of view, I think the documentation is clear enough, > but I admit beeing a bit lost in the real end of the explanation, the > part about the transaction status hint bits but I think it's not that > important. I think I understood synchronous and asynchronous commits. I've added to and reworked that a bit also. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Attachment
On Fri, 2007-07-13 at 14:59 +0100, Simon Riggs wrote: > On Fri, 2007-07-13 at 15:01 +0200, Reviewer wrote: ...A few more minor changes... thanks very much. I'll wrap these into a final submission with the main patch. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
One question... can operations that shortcut the WAL by fsyncing direct to disk also use async commit? I suspect the answer is an implicit "no" because the only examples I can think of all involve DDL, but it's probably worth spelling that out... -- Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment
On Fri, 2007-07-13 at 12:38 -0500, Jim C. Nasby wrote: > One question... can operations that shortcut the WAL by fsyncing direct > to disk also use async commit? I suspect the answer is an implicit "no" > because the only examples I can think of all involve DDL, but it's > probably worth spelling that out... They can, but the WAL-avoiding ops are all designed for bulk ops, so you'll get something like 0.0001% benefit by using async commit for them. They are just as safe/unsafe as other async commits. Thanks for reading. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
On Fri, Jul 13, 2007 at 07:11:54PM +0100, Simon Riggs wrote: > On Fri, 2007-07-13 at 12:38 -0500, Jim C. Nasby wrote: > > One question... can operations that shortcut the WAL by fsyncing direct > > to disk also use async commit? I suspect the answer is an implicit "no" > > because the only examples I can think of all involve DDL, but it's > > probably worth spelling that out... > > They can, but the WAL-avoiding ops are all designed for bulk ops, so > you'll get something like 0.0001% benefit by using async commit for > them. Yeah, I knew it wouldn't help much, I just wasn't clear on what the effect would be. I guess I'm also a bit confused... the only shortcut I know of (COPY into a table created in the same transaction) involves creating files, so it would be ineligible for async commit, or are there other shortcuts? Do we list the shortcuts anywhere in the docs? > Thanks for reading. Thanks for writing. :) -- Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Attachment
On Fri, 2007-07-13 at 14:00 -0500, Jim C. Nasby wrote: > On Fri, Jul 13, 2007 at 07:11:54PM +0100, Simon Riggs wrote: > > On Fri, 2007-07-13 at 12:38 -0500, Jim C. Nasby wrote: > > > One question... can operations that shortcut the WAL by fsyncing direct > > > to disk also use async commit? I suspect the answer is an implicit "no" > > > because the only examples I can think of all involve DDL, but it's > > > probably worth spelling that out... > > > > They can, but the WAL-avoiding ops are all designed for bulk ops, so > > you'll get something like 0.0001% benefit by using async commit for > > them. > > Yeah, I knew it wouldn't help much, I just wasn't clear on what the > effect would be. I guess I'm also a bit confused... the only shortcut I > know of (COPY into a table created in the same transaction) involves > creating files, so it would be ineligible for async commit, or are there > other shortcuts? Do we list the shortcuts anywhere in the docs? Wrote that too... http://developer.postgresql.org/pgdocs/postgres/performance-tips.html > > Thanks for reading. > > Thanks for writing. :) -- Simon Riggs EnterpriseDB http://www.enterprisedb.com
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Simon Riggs wrote:
> Doc patch only...
>
> To aid with the understanding of the synchronous commit technique, I've
> completed the docs prior to the completion of the final version of the
> patch.
>
> Any review comments, final doubts etc.., please say them now...
>
> Applies cleanly to CVS HEAD, sgml make OK.
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Simon Riggs wrote:
> On Fri, 2007-07-13 at 15:01 +0200, Reviewer wrote:
>
> > I just read your patch in order to understand a little bit what will
> > happen in the next release.
>
> Thanks for the review. v2 attached.
>
> > About the guc variable wal_writer_delay, you say at the end:
> > "This parameter can only
> > + be set in the postgresql.conf file or on the server command line."
> >
> > Well, I don't really understand if this parameter is set only at server
> > startup or if it is possible to modify the postgresql.conf file and then
> > reload the conf-files.
>
> A common confusion. I'm not personally in favour of using that phrase in
> the docs, though it is the standard description of when to set this type
> of parameter, so I have followed the convention.
>
> > Also, in the part about synchronous commit and fsync=off, there's just a
> > missing verb, I think you should insist between the two possibilities :
> > system or database server crash, maybe by using some bold.
>
> I've reworded that part. Thanks for spotting this.
>
> > From a user point of view, I think the documentation is clear enough,
> > but I admit beeing a bit lost in the real end of the explanation, the
> > part about the transaction status hint bits but I think it's not that
> > important. I think I understood synchronous and asynchronous commits.
>
> I've added to and reworked that a bit also.
>
> --
> Simon Riggs
> EnterpriseDB http://www.enterprisedb.com
[ Attachment, skipping... ]
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Uh, we need a context diff for this. --------------------------------------------------------------------------- Simon Riggs wrote: > On Fri, 2007-07-13 at 15:01 +0200, Reviewer wrote: > > > I just read your patch in order to understand a little bit what will > > happen in the next release. > > Thanks for the review. v2 attached. > > > About the guc variable wal_writer_delay, you say at the end: > > "This parameter can only > > + be set in the postgresql.conf file or on the server command line." > > > > Well, I don't really understand if this parameter is set only at server > > startup or if it is possible to modify the postgresql.conf file and then > > reload the conf-files. > > A common confusion. I'm not personally in favour of using that phrase in > the docs, though it is the standard description of when to set this type > of parameter, so I have followed the convention. > > > Also, in the part about synchronous commit and fsync=off, there's just a > > missing verb, I think you should insist between the two possibilities : > > system or database server crash, maybe by using some bold. > > I've reworded that part. Thanks for spotting this. > > > From a user point of view, I think the documentation is clear enough, > > but I admit beeing a bit lost in the real end of the explanation, the > > part about the transaction status hint bits but I think it's not that > > important. I think I understood synchronous and asynchronous commits. > > I've added to and reworked that a bit also. > > -- > Simon Riggs > EnterpriseDB http://www.enterprisedb.com [ Attachment, skipping... ] > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
bruce wrote: > > Uh, we need a context diff for this. Uh, never mind. The final version has a context diff. --------------------------------------------------------------------------- > > --------------------------------------------------------------------------- > > Simon Riggs wrote: > > On Fri, 2007-07-13 at 15:01 +0200, Reviewer wrote: > > > > > I just read your patch in order to understand a little bit what will > > > happen in the next release. > > > > Thanks for the review. v2 attached. > > > > > About the guc variable wal_writer_delay, you say at the end: > > > "This parameter can only > > > + be set in the postgresql.conf file or on the server command line." > > > > > > Well, I don't really understand if this parameter is set only at server > > > startup or if it is possible to modify the postgresql.conf file and then > > > reload the conf-files. > > > > A common confusion. I'm not personally in favour of using that phrase in > > the docs, though it is the standard description of when to set this type > > of parameter, so I have followed the convention. > > > > > Also, in the part about synchronous commit and fsync=off, there's just a > > > missing verb, I think you should insist between the two possibilities : > > > system or database server crash, maybe by using some bold. > > > > I've reworded that part. Thanks for spotting this. > > > > > From a user point of view, I think the documentation is clear enough, > > > but I admit beeing a bit lost in the real end of the explanation, the > > > part about the transaction status hint bits but I think it's not that > > > important. I think I understood synchronous and asynchronous commits. > > > > I've added to and reworked that a bit also. > > > > -- > > Simon Riggs > > EnterpriseDB http://www.enterprisedb.com > > [ Attachment, skipping... ] > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 2: Don't 'kill -9' the postmaster > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +