On Thu, Apr 1, 2010 at 12:16 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Mar 31, 2010 at 5:02 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >>> > >From what I have seen, the comment about PM_WAIT_BACKENDS is incorrect. >>> > "backends might be waiting for the WAL record that conflicts with their >>> > queries to be replayed". Recovery sometimes waits for backends, but >>> > backends never wait for recovery. >>> >>> Really? As Heikki explained before, backends might wait for the lock >>> taken by the startup process. >>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg02984.php >> >> Backends wait for locks, yes, but they could be waiting for user locks >> also. That is not "waiting for the WAL record", that concept does not >> exist. > > Hmm... this is a good point, on two levels. First, the comment is not > as well-phrased as it could be. Second, I wonder why we can't kill > the startup process and WAL receiver right away, and then wait for the > backends to die off afterwards.
I tested whether killing the startup process and walreceiver releases the lock which the backends are waiting for. Unfortunately it doesn't, and the backends have gotten stuck in my box. The behavior which the startup process shuts down without releasing the lock is a bug? BTW, I tested that by compiling postgres with the attached patch and doing the following operations. 1. Make the SR environment 2. Issue some SQLs to the primary psql -h <primary server> =# CREATE TABLE t(i int); =# BEGIN; =# DROP TABLE t; =# SELECT pg_switch_xlog(); (keep this session alive) 3. Issue some SQLs to the standby psql -h <standby server> =# BEGIN; =# SELECT * FROM t; --> waiting 4. Perform smart shutdown on the standby Then the startup process and walreceiver shut down, but the session created in #3 is still waiting. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
shutdown_test.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
