Keepalive for max_standby_delay
in [PgSql]
|
Prev: [HACKERS] Keepalive for max_standby_delay
Next: Unexpected page allocation behavior on insert-only tables
From: Simon Riggs on 3 Jun 2010 03:56 On Wed, 2010-06-02 at 16:00 -0400, Tom Lane wrote: > the current situation that query grace periods go to zero Possibly a better way to handle this concern is to make the second parameter: min_standby_grace_period - the minimum time a query will be given in which to execute, even if max_standby_delay has been reached or exceeded. Would that more directly address you concerns? min_standby_grace_period (ms) SIGHUP -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 3 Jun 2010 04:56 On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > I don't understand why you want to use a different delay when you're > restoring from archive vs. when you're streaming (what about existing WAL > files found in pg_xlog, BTW?). The source of WAL shouldn't make a > difference. Yes. The pace of a recovery has nothing to do with that of log shipping. So to hurry up a recovery when restoring from archive seems to be useless. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 3 Jun 2010 05:07 On Thu, 2010-06-03 at 17:56 +0900, Fujii Masao wrote: > On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: > > I don't understand why you want to use a different delay when you're > > restoring from archive vs. when you're streaming (what about existing WAL > > files found in pg_xlog, BTW?). The source of WAL shouldn't make a > > difference. > > Yes. The pace of a recovery has nothing to do with that of log shipping. > So to hurry up a recovery when restoring from archive seems to be useless. When streaming drops for some reason we revert to scanning the archive for files. There is clearly two modes of operation. So it makes sense that you might want to set different times for the parameter in each case. We might think of those modes as "connected" and "degraded" modes rather than streaming and file shipping. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 3 Jun 2010 05:39 On Thu, Jun 3, 2010 at 6:07 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Thu, 2010-06-03 at 17:56 +0900, Fujii Masao wrote: >> On Thu, Jun 3, 2010 at 4:41 AM, Heikki Linnakangas >> <heikki.linnakangas(a)enterprisedb.com> wrote: >> > I don't understand why you want to use a different delay when you're >> > restoring from archive vs. when you're streaming (what about existing WAL >> > files found in pg_xlog, BTW?). The source of WAL shouldn't make a >> > difference. >> >> Yes. The pace of a recovery has nothing to do with that of log shipping. >> So to hurry up a recovery when restoring from archive seems to be useless. > > When streaming drops for some reason we revert to scanning the archive > for files. There is clearly two modes of operation. Yes. > So it makes sense > that you might want to set different times for the parameter in each > case. What purpose would that serve? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 3 Jun 2010 06:57
On Thu, 2010-06-03 at 18:39 +0900, Fujii Masao wrote: > What purpose would that serve? Tom has already explained this and it makes sense for me. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |