Re: [HACKERS] sync rep and smart shutdown
On Sat, Apr 9, 2011 at 3:53 AM, Robert Haas robertmh...@gmail.com wrote: There are a couple of plausible ways to proceed here: 1. Do nothing. 2. When a smart shutdown is initiated, shut off synchronous replication. 3. Accept new replication connections even when the system is undergoing a smart shutdown. I agree that #3 is impractical and #2 is a bad idea, which seems to leave us with #1 (unless anyone has a #4)? This is probably just something we should figure is going to be one of the rough edges in the first release of sync rep. That's kind of where my mind was headed too, although I was (probably vainly) hoping for a better option. Though I proposed #3, I can live with #1 for now. Even if smart shutdown gets stuck, we can resolve that by requesting fast shutdown or emptying synchronous_standby_names. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sync rep and smart shutdown
Robert Haas robertmh...@gmail.com writes: There is an open item for synchronous replication and smart shutdown, with a link to here: http://archives.postgresql.org/pgsql-hackers/2011-03/msg01391.php There are a couple of plausible ways to proceed here: 1. Do nothing. 2. When a smart shutdown is initiated, shut off synchronous replication. 3. Accept new replication connections even when the system is undergoing a smart shutdown. I agree that #3 is impractical and #2 is a bad idea, which seems to leave us with #1 (unless anyone has a #4)? This is probably just something we should figure is going to be one of the rough edges in the first release of sync rep. A #4 idea did just come to mind: once we realize that there are no working replication connections, automatically do a fast shutdown instead, ie, forcibly roll back those transactions that are never gonna complete. Or at least have the postmaster bleat about it. But I'm not sure what it'd take to code that, and am also unsure that it's something to undertake at this stage of the cycle. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] sync rep and smart shutdown
On Fri, Apr 8, 2011 at 2:38 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: There is an open item for synchronous replication and smart shutdown, with a link to here: http://archives.postgresql.org/pgsql-hackers/2011-03/msg01391.php There are a couple of plausible ways to proceed here: 1. Do nothing. 2. When a smart shutdown is initiated, shut off synchronous replication. 3. Accept new replication connections even when the system is undergoing a smart shutdown. I agree that #3 is impractical and #2 is a bad idea, which seems to leave us with #1 (unless anyone has a #4)? This is probably just something we should figure is going to be one of the rough edges in the first release of sync rep. That's kind of where my mind was headed too, although I was (probably vainly) hoping for a better option. A #4 idea did just come to mind: once we realize that there are no working replication connections, automatically do a fast shutdown instead, ie, forcibly roll back those transactions that are never gonna complete. Or at least have the postmaster bleat about it. But I'm not sure what it'd take to code that, and am also unsure that it's something to undertake at this stage of the cycle. Well, you certainly can't do that. By the time a transaction is waiting for sync rep, it's too late to roll back; the commit record is already, and necessarily, on disk. But in theory we could notice that all of the remaining backends are waiting for sync rep, and switch to a fast shutdown. Several people have suggested refinements for smart shutdown in general, such as switching to fast shutdown after a certain number of seconds, or having backends exit at the end of the current transaction (or immediately if idle). Such things would both make this problem less irksome and increase the overall utility of smart shutdown tremendously. So maybe it's not worth expending too much effort on it right now. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
