Skip site navigation (1) Skip section navigation (2)

Re: pending patch: Re: HS/SR and smart shutdown

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pending patch: Re: HS/SR and smart shutdown
Date: 2010-04-01 08:42:13
Message-ID: u2q3f0b79eb1004010142q66792e64w201f5bc73ea54195@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Apr 1, 2010 at 12:16 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Mar 31, 2010 at 5:02 AM, Simon Riggs <simon(at)2ndquadrant(dot)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

Attachment: shutdown_test.patch
Description: application/octet-stream (527 bytes)

In response to

Responses

pgsql-hackers by date

Next:From: gabriele.bartoliniDate: 2010-04-01 08:47:24
Subject: Re: [HACKERS] Postgres 9.1 - Release Theme
Previous:From: Michael MeskesDate: 2010-04-01 08:41:22
Subject: Re: Problems with variable cursorname in ecpg

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group