On Thu, Apr 1, 2010 at 12:16 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Wed, Mar 31, 2010 at 5:02 AM, Simon Riggs <simon@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
