Remaining Streaming Replication Open Items
in [PgSql]
|
Prev: [HACKERS] Hot Standby: Startup at shutdown checkpoint
Next: SELECT constant; takes 15x longer on 9.0?
From: Fujii Masao on 8 Apr 2010 02:54 On Thu, Apr 8, 2010 at 10:41 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Wed, Apr 7, 2010 at 8:17 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> OK, that looks a lot less risky than I had understood from discussions. >> The main thing for me is it doesn't interfere with Startup or >> WalReceiver, so assuming it works I've got no objections. Thanks for >> chasing this down, good addition. > > Thanks. Committed. Thanks. The following TODO item should be removed? "Redefine smart shutdown in standby mode to exist as soon as all read-only connections are gone." http://wiki.postgresql.org/wiki/Todo#Standby_server_mode Or change it to something like? "Change smart shutdown in standby mode so that it kills the startup and walreceiver process before waiting for the regular backends to die off" 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: Robert Haas on 8 Apr 2010 06:58 On Thu, Apr 8, 2010 at 2:54 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Thu, Apr 8, 2010 at 10:41 AM, Robert Haas <robertmhaas(a)gmail.com> wrote: >> On Wed, Apr 7, 2010 at 8:17 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >>> OK, that looks a lot less risky than I had understood from discussions. >>> The main thing for me is it doesn't interfere with Startup or >>> WalReceiver, so assuming it works I've got no objections. Thanks for >>> chasing this down, good addition. >> >> Thanks. Committed. > > Thanks. The following TODO item should be removed? > > "Redefine smart shutdown in standby mode to exist as soon as all > read-only connections are gone." > http://wiki.postgresql.org/wiki/Todo#Standby_server_mode > > Or change it to something like? > > "Change smart shutdown in standby mode so that it kills the startup > and walreceiver process before waiting for the regular backends to die off" Yeah, we should do one of those two things, but I don't much care which. ....Robert -- 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 8 Apr 2010 07:37 On Thu, 2010-04-08 at 06:58 -0400, Robert Haas wrote: > >> Thanks. Committed. > > > > Thanks. The following TODO item should be removed? > > > > "Redefine smart shutdown in standby mode to exist as soon as all > > read-only connections are gone." > > http://wiki.postgresql.org/wiki/Todo#Standby_server_mode > > Or change it to something like? > > > > "Change smart shutdown in standby mode so that it kills the startup > > and walreceiver process before waiting for the regular backends to die off" > > Yeah, we should do one of those two things, but I don't much care which. I do. I see no reason to do the latter, ever, so should not be added to any TODO. -- 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: Robert Haas on 8 Apr 2010 07:53 On Thu, Apr 8, 2010 at 7:37 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Thu, 2010-04-08 at 06:58 -0400, Robert Haas wrote: > >> >> Thanks. Committed. >> > >> > Thanks. The following TODO item should be removed? >> > >> > "Redefine smart shutdown in standby mode to exist as soon as all >> > read-only connections are gone." >> > http://wiki.postgresql.org/wiki/Todo#Standby_server_mode > >> > Or change it to something like? >> > >> > "Change smart shutdown in standby mode so that it kills the startup >> > and walreceiver process before waiting for the regular backends to die off" >> >> Yeah, we should do one of those two things, but I don't much care which. > > I do. I see no reason to do the latter, ever, so should not be added to > any TODO. Well, stopping recovery earlier would mean fewer locks, which would mean a better chance for the read-only backends to finish their work and exit quickly. But I'm not sure how much it's worth worrying about. ....Robert -- 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 8 Apr 2010 08:00
On Thu, 2010-04-08 at 07:53 -0400, Robert Haas wrote: > > I do. I see no reason to do the latter, ever, so should not be added to > > any TODO. > > Well, stopping recovery earlier would mean fewer locks, which would > mean a better chance for the read-only backends to finish their work > and exit quickly. But I'm not sure how much it's worth worrying > about. The purpose of the lock is to prevent access to objects when they are in inappropriate states for access. If we stopped startup and allowed access, how do we know that things are in sufficiently good state to allow access? We don't. If the Startup process is holding a lock then that is the only safe thing to do. Otherwise we might allow access to a table with a partially built index or other screw ups. -- 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 |