Обсуждение: statement timeout vs dump/restore
I'm a bit confused about where the consensus is on this issue ( http://archives.postgresql.org/message-id/20080311110727.62605f5f@commandprompt.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
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
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 >
> > 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
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
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
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
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