Tom Lane wrote:
To me, the killer reason for statement_timeout = 0 during pg_dump
is that without it, routine cron-driven dumps could fail, and the
user might not notice until he really really needed that dump.
This concrete case if of course valid, but if you take a step back, there are
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
To me, the killer reason for statement_timeout = 0 during pg_dump
is that without it, routine cron-driven dumps could fail, and the
user might not notice until he really really needed that dump.
This concrete case if of course valid,
I have added a TODO:
o Set up autovacuum to ignore statement_timeout set in
postgresql.conf
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php
and documented this behavior with the attached patch; backpatched to 8.3.X.
Bruce Momjian wrote:
I have added a TODO:
o Set up autovacuum to ignore statement_timeout set in
postgresql.conf
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php
and documented this behavior with the attached patch; backpatched to 8.3.X.
Alvaro Herrera wrote:
Hmm, AFAIR subsequent investigation led to the discovery that autovacuum
is not affected by statement_timeout.
Right -- see
http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/80044/focus=93847
So your documentation changes are incorrect.
--
Alvaro Herrera
Alvaro Herrera wrote:
Bruce Momjian wrote:
I have added a TODO:
o Set up autovacuum to ignore statement_timeout set in
postgresql.conf
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php
and documented this behavior with the attached
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Hmm, AFAIR subsequent investigation led to the discovery that autovacuum
is not affected by statement_timeout.
Right -- see
http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/80044/focus=93847
Or even more to the
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Alvaro Herrera wrote:
Hmm, AFAIR subsequent investigation led to the discovery that autovacuum
is not affected by statement_timeout.
Right -- see
http://thread.gmane.org/gmane.comp.db.postgresql.devel.general/80044/focus=93847
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Particularly consider using psql to restore a pg_dump
dump --- are we going to add SET statement_timeout=0
to the pg_dump file?
I hope not. That should be the user's choice.
- --
Greg Sabino Mullane [EMAIL PROTECTED]
PGP Key: 0x14964AC8
Greg Sabino Mullane wrote:
Particularly consider using psql to restore a pg_dump
dump --- are we going to add SET statement_timeout=0
to the pg_dump file?
I hope not. That should be the user's choice.
Would anyone want to limit the load time for pg_dump? I can hardly see
why.
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 11 Mar 2008 16:17:53 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Greg Sabino Mullane wrote:
Particularly consider using psql to restore a pg_dump
dump --- are we going to add SET statement_timeout=0
to the pg_dump file?
Joshua D. Drake wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 11 Mar 2008 16:17:53 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Greg Sabino Mullane wrote:
Particularly consider using psql to restore a pg_dump
dump --- are we going to add SET
Bruce Momjian [EMAIL PROTECTED] writes:
Greg Sabino Mullane wrote:
Particularly consider using psql to restore a pg_dump
dump --- are we going to add SET statement_timeout=0
to the pg_dump file?
I hope not. That should be the user's choice.
Would anyone want to limit the load time for
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Bruce asks:
Particularly consider using psql to restore a pg_dump
dump --- are we going to add SET statement_timeout=0
to the pg_dump file?
I hope not. That should be the user's choice.
Would anyone want to limit the load time for
On Tue, Apr 17, 2007 at 10:33:21PM -0400, Bruce Momjian wrote:
Alvaro Herrera wrote:
I think that is too strong an assumption, which is why I'm planning to
back-patch the change to reset statement_timeout to 0 on autovacuum till
8.0, as discussed. I think I should also backpatch the change
On Tuesday 17 April 2007 21:25, Alvaro Herrera wrote:
I think that is too strong an assumption, which is why I'm planning to
back-patch the change to reset statement_timeout to 0 on autovacuum till
8.0, as discussed. I think I should also backpatch the change to set
zero_damaged_pages as well
On Tuesday 17 April 2007 20:54, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm with Joshua on this one. Statement_timeout is often used as a means
for protection from long running statements due to server load and
locking and all of the above commands can certainly fall into
Robert Treat wrote:
On Tuesday 17 April 2007 21:25, Alvaro Herrera wrote:
I think that is too strong an assumption, which is why I'm planning to
back-patch the change to reset statement_timeout to 0 on autovacuum till
8.0, as discussed. I think I should also backpatch the change to set
Robert Treat wrote:
On Tuesday 17 April 2007 20:54, Tom Lane wrote:
I'm not excited about the other ones but I can see the argument for
making pg_dump force the timeout to 0.
Allowing pg_dump to run un-checked could also lead to problems such as
exceeding maintenence windows causing
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from being vacuumed.
FWIW in testing, I just noticed that autovacuum does not pay
Alvaro Herrera wrote:
Robert Treat wrote:
On Tuesday 17 April 2007 20:54, Tom Lane wrote:
I'm not excited about the other ones but I can see the argument for
making pg_dump force the timeout to 0.
Allowing pg_dump to run un-checked could also lead to problems such as
exceeding maintenence
On Wednesday 18 April 2007 11:30, Alvaro Herrera wrote:
Robert Treat wrote:
On Tuesday 17 April 2007 20:54, Tom Lane wrote:
I'm not excited about the other ones but I can see the argument for
making pg_dump force the timeout to 0.
Allowing pg_dump to run un-checked could also lead to
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from being vacuumed.
Jim C. Nasby wrote:
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from
On Tue, Apr 17, 2007 at 12:51:51PM -0700, Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a
On Tuesday 17 April 2007 18:38, Jim C. Nasby wrote:
On Tue, Apr 17, 2007 at 12:51:51PM -0700, Joshua D. Drake wrote:
Jim C. Nasby wrote:
On Sun, Apr 01, 2007 at 12:36:01AM +0200, Peter Eisentraut wrote:
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
Robert Treat [EMAIL PROTECTED] writes:
I'm with Joshua on this one. Statement_timeout is often used as a means for
protection from long running statements due to server load and locking and
all of the above commands can certainly fall into that area. If people feel
strongly that the command
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm with Joshua on this one. Statement_timeout is often used as a means for
protection from long running statements due to server load and locking and
all of the above commands can certainly fall into that area. If people feel
strongly
Joshua D. Drake wrote:
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'm with Joshua on this one. Statement_timeout is often used as a means
for protection from long running statements due to server load and
locking and all of the above commands can certainly fall into that area.
Alvaro Herrera wrote:
I think that is too strong an assumption, which is why I'm planning to
back-patch the change to reset statement_timeout to 0 on autovacuum till
8.0, as discussed. I think I should also backpatch the change to set
zero_damaged_pages as well (which is not on 8.0 AFAIR).
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from being vacuumed.
On a vaguely related matter, should programs such as pg_dump, vacuumdb,
Tom Lane wrote:
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from being vacuumed.
But I do not see anything in autovacuum.c that resets the variable.
Am I
Heikki Linnakangas [EMAIL PROTECTED] writes:
statement_timeout interrupts seem to go through the PG_CATCH-block and
clean up the entry from the vacuum cycle array as they should. But a
SIGINT leading to a terminating connection due to administrator
command error does not.
Hm, that's an
I wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
statement_timeout interrupts seem to go through the PG_CATCH-block and
clean up the entry from the vacuum cycle array as they should. But a
SIGINT leading to a terminating connection due to administrator
command error does not.
Hm,
Tom Lane wrote:
I wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
statement_timeout interrupts seem to go through the PG_CATCH-block and
clean up the entry from the vacuum cycle array as they should. But a
SIGINT leading to a terminating connection due to administrator
command
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmmm, remember that DatabaseCancelAutovacuumActivity is called on CREATE
DATABASE; but what it does is send SIGINT, not SIGTERM. Also, it's not
in 8.2. SIGINT does terminate the autovac process however.
I haven't read the whole problem report
I seem to remember that we'd agreed that autovacuum should ignore any
globally set statement_timeout, on the grounds that a poorly chosen
setting could indefinitely prevent large tables from being vacuumed.
But I do not see anything in autovacuum.c that resets the variable.
Am I just being blind?
37 matches
Mail list logo
