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: Robert Haas on 8 Apr 2010 09:40 On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > 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. Hmm. Good point. I guess you could really only stop the startup process safely when it wasn't holding any locks anyhow - you couldn't just kill it and have it release the locks. ....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 09:56 On Thu, 2010-04-08 at 09:40 -0400, Robert Haas wrote: > On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > > 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. > > Hmm. Good point. I guess you could really only stop the startup > process safely when it wasn't holding any locks anyhow - you couldn't > just kill it and have it release the locks. .... and if it isn't holding any locks at all, there is no reason to kill Startup first => no TODO item. -- 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 10:00 On Thu, Apr 8, 2010 at 9:56 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: > On Thu, 2010-04-08 at 09:40 -0400, Robert Haas wrote: >> On Thu, Apr 8, 2010 at 8:00 AM, Simon Riggs <simon(a)2ndquadrant.com> wrote: >> > 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. >> >> Hmm. Good point. I guess you could really only stop the startup >> process safely when it wasn't holding any locks anyhow - you couldn't >> just kill it and have it release the locks. > > ... and if it isn't holding any locks at all, there is no reason to kill > Startup first => no TODO item. I think you could shut it down at the first point at which it is holding no locks, rather than letting it continue recovering and potentially retake some new locks. That would be more consistent with the general idea of what a smart shutdown is supposed to be about. I think the real question is whether it's worth the code complexity. I suspect most people use fast shutdown most of the time anyway in real-world applications. ....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: Fujii Masao on 9 Apr 2010 04:18 On Thu, Apr 8, 2010 at 11:00 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > I think you could shut it down at the first point at which it is > holding no locks, rather than letting it continue recovering and > potentially retake some new locks. That would be more consistent with > the general idea of what a smart shutdown is supposed to be about. I > think the real question is whether it's worth the code complexity. I don't think it's worth. So I agree to just remove the TODO item: "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 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: Heikki Linnakangas on 13 Apr 2010 11:49
Robert Haas wrote: > On Tue, Apr 6, 2010 at 10:36 AM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> Robert Haas wrote: >>>>> * If standby_mode is enabled, and neither primary_conninfo nor restore_command are set, the standby would get stuck. >>>> It's not really stuck, it will replay any WAL files you drop into >>>> pg_xlog. I concur with Robert Haas though that it shouldn't print the >>>> message to the log every few seconds. It should print a message the >>>> first time it hits the end of WAL, but subsequent messages should be >>>> suppressed until some progress has been made. >>> Any idea how to implement this? >> I'll take a look. It shouldn't be too hard. > > The tricky part, I believe, is that there's more than one message that > can potentially be emitted, and you don't want ANY of them to repeat > every 2 s, so some thought needs to be given to where to hook in the > logic. We have the emode_for_corrupt_record() function that's used in all the errors that indicate a corrupt WAL record, that's a perfect place to hook this into. See attached patch. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com |