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 cour
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
ab
-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 t
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
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
-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_dum
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: 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: 0x14964AC
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/8004
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
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 behavio
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
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
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.
--
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 a
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 wi
> > 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
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 caus
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 s
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
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 w
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
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).
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
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 t
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 co
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 shou
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 grou
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 be
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 vacuum
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, vacuumd
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 com
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
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 n
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
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 j
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
