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


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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


---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)

iD8DBQFGl7iNdO30qud8SkgRAqUWAKDkC7eVhzba/ZKZrBRRQtM3bvmOAQCaAjKp
9uFvLGzS7VXlFCUKv1sp1u0=
=3Myz
-----END PGP SIGNATURE-----

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


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)

iD8DBQFGl8vYdO30qud8SkgRApmjAJ0WLOw9JndqYHLgRN2OT/qlETaF5ACgvCjw
vuhtgDEAow8TsAG1BN4iqSk=
=dUpX
-----END PGP SIGNATURE-----

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/pgdo...ance-tips.html


> > Thanks for reading.
>
> Thanks for writing.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com


---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

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. +

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

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. +

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

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. +

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate