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 14:27:03
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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
>   --> cannot accept connnections until new WAL has been created

a manual CHECKPOINT on the primary does help

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: Yeb HavingaDate: 2010-04-12 14:28:44
Subject: Re: explain and PARAM_EXEC
Previous:From: Joseph ConwayDate: 2010-04-12 14:26:04
Subject: Re: walreceiver is uninterruptible on win32

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