Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout
This is a discussion on Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout within the pgsql Hackers forums, part of the PostgreSQL category; --> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 11 Mar 2008 10:46:23 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote: And ...
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-15-2008, 10:46 PM
| ||||
| ||||
 Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 11 Mar 2008 10:46:23 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote: And the -c version  (thanks bruce)Joshua D. Drake - -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL political pundit | Mocker of Dolphins -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFH1spfATb/zqfZUUQRAv2EAJ92/8EBxBbqLDlOX5wUYdN3ElG5OQCghZ2Z tUIrN/MYVgP6rc4QXONDrFg= =2oJ5 -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers      |
|
04-17-2008, 04:11 PM
| |||
| |||
| Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout On Tue, 11 Mar 2008 11:07:27 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tue, 11 Mar 2008 10:46:23 -0700 > "Joshua D. Drake" <jd@commandprompt.com> wrote: > > And the -c version (thanks bruce)> > Joshua D. Drake > What is the feedback on this patch? Is there anything I need to do to get it into the next commit fest? Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-17-2008, 04:11 PM
| |||
| |||
| Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout Joshua D. Drake wrote: > What is the feedback on this patch? Is there anything I need to do to > get it into the next commit fest? Please add it to the commitfest wiki page. http://wiki.postgresql.org/wiki/CommitFest:May -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-17-2008, 04:11 PM
| |||
| |||
| Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout On Wed, 16 Apr 2008 13:36:50 -0400 Alvaro Herrera <alvherre@commandprompt.com> wrote: > Joshua D. Drake wrote: > > > What is the feedback on this patch? Is there anything I need to do > > to get it into the next commit fest? > > Please add it to the commitfest wiki page. > > http://wiki.postgresql.org/wiki/CommitFest:May > Done: http://wiki.postgresql.org/wiki/Comm...ending_patches Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-17-2008, 04:11 PM
| |||
| |||
| Re: Patch for Prevent pg_dump/pg_restore from being affectedby statement_timeout Joshua D. Drake wrote: > What is the feedback on this patch? Is there anything I need to do to > get it into the next commit fest? Yes, go add it to the wiki page ;-): http://wiki.postgresql.org/wiki/CommitFest:May I agree that we should do that, but the thread on -hackers ("Autovacuum vs statement_timeout") wasn't totally conclusive. Greg Sabine Mullane and Peter Eisentraut argued that we shouldn't, but neither provided a plausible use case where a statement_timeout on restoring a dump would be useful. I'm thinking we should apply the patch unless someone comes up with one. To quote Tom: > I think we need to be careful to distinguish three situations: > > * statement_timeout during pg_dump > * statement_timeout during pg_restore > * statement_timeout during psql reading a pg_dump script file This patch addresses the third situation, but leaves open the 1st and the 2nd. IMO, we should set statement_timeout = 0 in them as well, unless someone comes up with plausible use case for using a non-zero statement_timeout. Ps. If you want to save the committer a couple of minutes of valuable time, you can fix the indentation to use tabs instead of spaces, and remove the spurious whitespace change on the empty line. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-17-2008, 04:11 PM
| |||
| |||
| Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout On Wed, 16 Apr 2008 21:04:17 +0300 Heikki Linnakangas <heikki@enterprisedb.com> wrote: > To quote Tom: > > I think we need to be careful to distinguish three situations: > > > > * statement_timeout during pg_dump > > * statement_timeout during pg_restore > > * statement_timeout during psql reading a pg_dump script file > > This patch addresses the third situation, but leaves open the 1st and > the 2nd. IMO, we should set statement_timeout = 0 in them as well, > unless someone comes up with plausible use case for using a non-zero > statement_timeout. My patch addresses all three, unless I am misunderstanding your meaning. The patch does the following: After connection with pg_dump it executes set statement_timeout = 0; This fixed the pg_dump timeout issue. It also writes set statement_timeout = 0 into the archive file, which fixed pg_restore and psql. > > Ps. If you want to save the committer a couple of minutes of valuable > time, you can fix the indentation to use tabs instead of spaces, and > remove the spurious whitespace change on the empty line. > I can do that. Thanks for the feedback. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-17-2008, 04:11 PM
| |||
| |||
| Re: Patch for Prevent pg_dump/pg_restore from being affectedby statement_timeout Joshua D. Drake wrote: > On Wed, 16 Apr 2008 21:04:17 +0300 > Heikki Linnakangas <heikki@enterprisedb.com> wrote: >> To quote Tom: >>> I think we need to be careful to distinguish three situations: >>> >>> * statement_timeout during pg_dump >>> * statement_timeout during pg_restore >>> * statement_timeout during psql reading a pg_dump script file >> This patch addresses the third situation, but leaves open the 1st and >> the 2nd. IMO, we should set statement_timeout = 0 in them as well, >> unless someone comes up with plausible use case for using a non-zero >> statement_timeout. > > My patch addresses all three, unless I am misunderstanding your > meaning. The patch does the following: > > After connection with pg_dump it executes set statement_timeout = 0; > This fixed the pg_dump timeout issue. > > It also writes set statement_timeout = 0 into the archive file, which > fixed pg_restore and psql. Oh, ok, I misread the patch. Sorry for the noise. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-17-2008, 04:11 PM
| |||
| |||
| Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout On Wed, 16 Apr 2008 21:20:17 +0300 Heikki Linnakangas <heikki@enterprisedb.com> wrote: > > My patch addresses all three, unless I am misunderstanding your > > meaning. The patch does the following: > > > > After connection with pg_dump it executes set statement_timeout = 0; > > This fixed the pg_dump timeout issue. > > > > It also writes set statement_timeout = 0 into the archive file, > > which fixed pg_restore and psql. > > Oh, ok, I misread the patch. Sorry for the noise. > Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-17-2008, 04:11 PM
| |||
| |||
| Re: Patch for Prevent pg_dump/pg_restore from being affected by statement_timeout -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 > I agree that we should do that, but the thread on -hackers ("Autovacuum > vs statement_timeout") wasn't totally conclusive. Greg Sabine Mullane > and Peter Eisentraut argued that we shouldn't, but neither provided a > plausible use case where a statement_timeout on restoring a dump would > be useful. I'm thinking we should apply the patch unless someone comes > up with one. I don't think it's fair to simply discard the use cases provided as "implausible" and demand one more to your liking. I strongly dislike having a giant dump file written that has non-vital configuration variables embedded in the top of it, precluding any user choice whatsoever[1]. As before, where are the reports of all the people having their manual restorations interrupted by a statement_timeout? [1] Short of editing a potentially GB-size file, or using some sed/shell shenanigans to strip out the suspect setting. - -- Greg Sabino Mullane greg@turnstep.com End Point Corporation PGP Key: 0x14964AC8 200804161814 http://biglumber.com/x/web?pk=2529DF...9B906714964AC8 -----BEGIN PGP SIGNATURE----- iEYEAREDAAYFAkgGetEACgkQvJuQZxSWSsg+4ACghvlBkIth1a BiGpFPFPj+HWgf iyEAnj+WK9MQL+ZQqKoTcLOe/lvoNkkV =Nlyg -----END PGP SIGNATURE----- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
04-17-2008, 04:11 PM
| ||||
| ||||
| Re: Patch for Prevent pg_dump/pg_restore from beingaffected by statement_timeout On Wed, 16 Apr 2008 22:17:30 -0000 "Greg Sabino Mullane" <greg@turnstep.com> wrote: > I don't think it's fair to simply discard the use cases provided as > "implausible" and demand one more to your liking. I strongly dislike > having a giant dump file written that has non-vital configuration > variables embedded in the top of it, precluding any user choice > whatsoever[1]. As before, where are the reports of all the people > having their manual restorations interrupted by a statement_timeout? Calling me, wondering why in the world it is happening. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
Linear Mode
