From: | Mitsumasa KONDO <kondo(dot)mitsumasa(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | KONDO Mitsumasa <kondo(dot)mitsumasa(at)lab(dot)ntt(dot)co(dot)jp>, fabriziomello(at)gmail(dot)com, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Time-Delayed Standbys |
Date: | 2013-12-04 13:47:47 |
Message-ID: | CADupcHU+WAaadvaX3MOETZd6LBXnog15pdD8_sWU94PNiUDHmg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2013/12/4 Andres Freund <andres(at)2ndquadrant(dot)com>
> On 2013-12-04 11:13:58 +0900, KONDO Mitsumasa wrote:
> > >4) Start the slave and connect to it using psql and in another session
> I can see
> > >all archive recovery log
> > Hmm... I had thought my mistake in reading your email, but it reproduce
> again.
> > When I sat small recovery_time_delay(=30000), it might work collectry.
> > However, I sat long timed recovery_time_delay(=3000000), it didn't work.
>
> > My reporduced operation log is under following.
> > >[mitsu-ko(at)localhost postgresql]$ bin/pgbench -T 30 -c 8 -j4 -p5432
> > >starting vacuum...end.
> > >transaction type: TPC-B (sort of)
> > >scaling factor: 10
> > >query mode: simple
> > >number of clients: 8
> > >number of threads: 4
> > >duration: 30 s
> > >number of transactions actually processed: 68704
> > >latency average: 3.493 ms
> > >tps = 2289.196747 (including connections establishing)
> > >tps = 2290.175129 (excluding connections establishing)
> > >[mitsu-ko(at)localhost postgresql]$ vim slave/recovery.conf
> > >[mitsu-ko(at)localhost postgresql]$ bin/pg_ctl -D slave start
> > >server starting
> > >[mitsu-ko(at)localhost postgresql]$ LOG: database system was shut down
> in recovery at 2013-12-03 10:26:41 JST
> > >LOG: entering standby mode
> > >LOG: consistent recovery state reached at 0/5C4D8668
> > >LOG: redo starts at 0/5C4000D8
> > >[mitsu-ko(at)localhost postgresql]$ FATAL: the database system is
> starting up
> > >FATAL: the database system is starting up
> > >FATAL: the database system is starting up
> > >FATAL: the database system is starting up
> > >FATAL: the database system is starting up
> > >[mitsu-ko(at)localhost postgresql]$ bin/psql -p6543
> > >psql: FATAL: the database system is starting up
> > >[mitsu-ko(at)localhost postgresql]$ bin/psql -p6543
> > >psql: FATAL: the database system is starting up
> > I attached my postgresql.conf and recovery.conf. It will be reproduced.
>
> So, you brought up a standby and it took more time to become consistent
> because it waited on commits? That's the problem? If so, I don't think
> that's a bug?
>
When it happened, psql cannot connect standby server at all. I think this
behavior is not good.
It should only delay recovery position and can seen old delay table data.
Cannot connect server is not hoped behavior.
If you think this behavior is the best, I will set ready for commiter. And
commiter will fix it better.
Rregards,
--
Mitsumasa KONDO
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2013-12-04 13:51:19 | Re: Review: ECPG infrastructure changes part 1, was: Re: ECPG fixes |
Previous Message | Tom Lane | 2013-12-04 13:46:24 | Re: ruleutils vs. empty targetlists |