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

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

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