SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
05-05-2008, 05:52 AM
| ||||
| ||||
 statement timeout vs dump/restore I'm a bit confused about where the consensus is on this issue ( http://archives.postgresql.org/messa...mandprompt.com et al) Do we want the following: 1. pg_dump issues "set statement_timeout = 0;" to the database prior to taking its copy of data (yes/no/default-but-switchable) 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in text mode output (yes/no/default-but-switchable) 3. pg_restore issues "set statement_timeout = 0;" to the database in restore mode (yes/no/default-but-switchable) I would tend to say default-but-switchable for all 3, but maybe that's too complicated. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers      |
|
05-05-2008, 05:52 AM
| |||
| |||
| Re: statement timeout vs dump/restore Andrew Dunstan <andrew@dunslane.net> writes: > Do we want the following: > 1. pg_dump issues "set statement_timeout = 0;" to the database prior to > taking its copy of data (yes/no/default-but-switchable) > 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in text mode > output (yes/no/default-but-switchable) > 3. pg_restore issues "set statement_timeout = 0;" to the database in > restore mode (yes/no/default-but-switchable) I think "yes" for all three. There was some handwaving about someone maybe not wanting it, but an utter lack of convincing use-cases; so I see no point in going to the effort of providing a switch. Note that 2 and 3 are actually the same thing (if you think they are not, then you are putting the behavior in the wrong place). regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
05-05-2008, 05:52 AM
| |||
| |||
| Re: statement timeout vs dump/restore Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> Do we want the following: > >> 1. pg_dump issues "set statement_timeout = 0;" to the database prior to >> taking its copy of data (yes/no/default-but-switchable) >> 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in text mode >> output (yes/no/default-but-switchable) >> 3. pg_restore issues "set statement_timeout = 0;" to the database in >> restore mode (yes/no/default-but-switchable) > > I think "yes" for all three. There was some handwaving about someone > maybe not wanting it, but an utter lack of convincing use-cases; so > I see no point in going to the effort of providing a switch. > > Note that 2 and 3 are actually the same thing (if you think they are > not, then you are putting the behavior in the wrong place). Right, pg_restore just using the output from pg_dump. The dump has the statement_timeout. That way it works regardless of output (e.g; for psql text based restores). Sincerely, Joshua D. Drake > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
05-07-2008, 10:17 AM
| |||
| |||
| Re: statement timeout vs dump/restore > > Do we want the following: > > > 1. pg_dump issues "set statement_timeout = 0;" to the > database prior to > > taking its copy of data (yes/no/default-but-switchable) > > 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in > text mode > > output (yes/no/default-but-switchable) > > 3. pg_restore issues "set statement_timeout = 0;" to the > database in > > restore mode (yes/no/default-but-switchable) > > I think "yes" for all three. There was some handwaving about someone > maybe not wanting it, but an utter lack of convincing use-cases; so > I see no point in going to the effort of providing a switch. > > Note that 2 and 3 are actually the same thing (if you think they are > not, then you are putting the behavior in the wrong place). I thought a proper fix for 3 would not depend on 2 ? Andreas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
05-07-2008, 10:17 AM
| |||
| |||
| Re: statement timeout vs dump/restore Zeugswetter Andreas OSB sIT wrote: >>> Do we want the following: >>> >>> 1. pg_dump issues "set statement_timeout = 0;" to the >>> >> database prior to >> >>> taking its copy of data (yes/no/default-but-switchable) >>> 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in >>> >> text mode >> >>> output (yes/no/default-but-switchable) >>> 3. pg_restore issues "set statement_timeout = 0;" to the >>> >> database in >> >>> restore mode (yes/no/default-but-switchable) >>> >> I think "yes" for all three. There was some handwaving about someone >> maybe not wanting it, but an utter lack of convincing use-cases; so >> I see no point in going to the effort of providing a switch. >> >> Note that 2 and 3 are actually the same thing (if you think they are >> not, then you are putting the behavior in the wrong place). >> > > I thought a proper fix for 3 would not depend on 2 ? > > > I'm sure we could separate the two if we wanted to. Since we don't it's been put in the most natural spot, which does both. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
05-07-2008, 10:18 AM
| |||
| |||
| Re: statement timeout vs dump/restore On Monday 05 May 2008 09:01:25 Andrew Dunstan wrote: > Zeugswetter Andreas OSB sIT wrote: > >>> Do we want the following: > >>> > >>> 1. pg_dump issues "set statement_timeout = 0;" to the > >> > >> database prior to > >> > >>> taking its copy of data (yes/no/default-but-switchable) > >>> 2. pg_dump/pg_restore issue "set statement_timeout = 0;" in > >> > >> text mode > >> > >>> output (yes/no/default-but-switchable) > >>> 3. pg_restore issues "set statement_timeout = 0;" to the > >> > >> database in > >> > >>> restore mode (yes/no/default-but-switchable) > >> > >> I think "yes" for all three. There was some handwaving about someone > >> maybe not wanting it, but an utter lack of convincing use-cases; so > >> I see no point in going to the effort of providing a switch. > >> ISTR being unconvinced by the pg_restore arguments, but as I think about it some more, for someone to set statement_timeout on a production system, and then have that be blindly overridden by any random pg_dump user seems a bit unfair. pg_dump is not only used as a backup tool, it is also used as a general user tool (for example, pgadmin calls pg_dump if you want to see a tables schema). imho pg_dump should not set it by default, but have an option to set it, specifically for the backup scenario. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
05-07-2008, 10:18 AM
| |||
| |||
| Re: statement timeout vs dump/restore Robert Treat <xzilla@users.sourceforge.net> writes: > ISTR being unconvinced by the pg_restore arguments, but as I think about it > some more, for someone to set statement_timeout on a production system, and > then have that be blindly overridden by any random pg_dump user seems a bit > unfair. pg_dump is not only used as a backup tool, it is also used as a > general user tool (for example, pgadmin calls pg_dump if you want to see a > tables schema). So? In those usages, it's not going to run long enough to have a statement_timeout problem anyway. When there is a data dump involved, you still have to defend the proposition that it's okay for pg_dump to deliver a bad dump if statement_timeout hits it. I can't accept that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |
|
05-07-2008, 10:18 AM
| ||||
| ||||
| Re: statement timeout vs dump/restore Tom Lane wrote: > Robert Treat <xzilla@users.sourceforge.net> writes: > >> ISTR being unconvinced by the pg_restore arguments, but as I think about it >> some more, for someone to set statement_timeout on a production system, and >> then have that be blindly overridden by any random pg_dump user seems a bit >> unfair. pg_dump is not only used as a backup tool, it is also used as a >> general user tool (for example, pgadmin calls pg_dump if you want to see a >> tables schema). >> > > So? In those usages, it's not going to run long enough to have a > statement_timeout problem anyway. > > When there is a data dump involved, you still have to defend the > proposition that it's okay for pg_dump to deliver a bad dump if > statement_timeout hits it. I can't accept that. > > > I agree. What is more, the solution to the non-dump uses of pg_dump is to put that functionality in a library where clients can call it directly rather than using pg_dump. cheers andrew -- 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
