Re: recovery_connections cannot start (was Re: master in standby mode croaks)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: recovery_connections cannot start (was Re: master in standby mode croaks)
Date: 2010-04-23 22:42:34
Message-ID: 18644.1272062554@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> In my understanding this means that archive_mode does completely and the
> max_wal_senders does not affect WAL contents?

I think we'd concluded that we have to keep archive_mode as a separate
boolean. (Or we could use Heikki's idea of a max number of unarchived
segments to hold onto, but I maintain that there are only two useful
values and so we might as well leave it as the existing boolean.)

> Does that mean that wal_mode can be SIGHUP now? It would be good. I
> think this is how to do that:
> At the start of every WAL-avoiding operation we could take a copy of
> wal_mode for the server and store in MyProc->wal_mode. At transaction
> start we would set that to "not set". We could then make
> pg_start_backup() wait for all transactions with wal_mode set to
> complete before we continue.

I think that there are probably more synchronization issues than that,
and in any case now is not the time to be trying to implement that
feature. Maybe we can make it work in 9.1.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pasher 2010-04-23 22:46:16 Re: Postgres stats collector showing high disk I/O
Previous Message Simon Riggs 2010-04-23 22:39:48 Re: testing HS/SR - 1 vs 2 performance