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

Re: testing hot standby

From: Jaime Casanova <jcasanov(at)systemguards(dot)com(dot)ec>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: testing hot standby
Date: 2010-04-12 16:27:56
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Mon, Apr 12, 2010 at 9:27 AM, Jaime Casanova
<jcasanov(at)systemguards(dot)com(dot)ec> wrote:
> On Mon, Apr 12, 2010 at 1:48 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Mon, Apr 12, 2010 at 3:29 PM, Jaime Casanova
>> <jcasanov(at)systemguards(dot)com(dot)ec> wrote:
>>> On Mon, Apr 12, 2010 at 1:21 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>>>> Didn't the standby
>>>> accept connections before executing pgbench?
>>> nop, and last time i try it was in that state for an hour (without
>>> accepting connections)... after that i execute on the primary: CREATE
>>> TABLE tt2 AS SELECT generate_series(1, 100) as i
>>> After that, the standby start accepting connections
>> OK. Your reproduction scenario is the following?
>> If not, could you show me the complete scenario?
>> 1. start the primary
>> 2. pg_start_backup()
>> 3. copy $PGDATA from the primary to the standby
>> 4. pg_stop_backup();
>> 5. create the recovery.conf and start the standby
> execute some WAL-logged action (i've seen this happen even with no
> WAL-logged action if i wait for a while before shutdown servers)
>> 6. shutdown (smart mode) the standby
> shutdown (smart) the primary
> start the primary again
>> 7. start the standby again

i guess, this is because the primary is in recovery when the standby
tries to connect to it, and it should wait until the primary is ready
but seems like the primary is failing to advertise itself and the
standby doesn't recheck the condition... could be?

Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

In response to

pgsql-hackers by date

Next:From: Magnus HaganderDate: 2010-04-12 16:56:51
Subject: Re: walreceiver is uninterruptible on win32
Previous:From: Kevin GrittnerDate: 2010-04-12 15:33:12
Subject: non-reproducible failure of random test on HEAD

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