Re: Hot Standby, max_connections and max_prepared_transactions

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot Standby, max_connections and max_prepared_transactions
Date: 2009-09-04 06:29:52
Message-ID: 1252045792.2889.542.camel@ebony.2ndQuadrant
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On Fri, 2009-09-04 at 01:25 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> > On Thu, 2009-09-03 at 22:22 +0300, Heikki Linnakangas wrote:
> >> Simon Riggs wrote:
> >>> I propose we just accept that both max_connections and
> >>> max_prepared_transactions need to be set correctly for recovery to work.
> >>> This will make the state transitions more robust and it will avoid
> >>> spurious and hard to test error messages.
> >>> Any objections to me removing this slice of code from the patch?
>
> >> Umm, what slice of code? I don't recall any code trying to make it work.
>
> > Well, its there.
>
> Just to be clear: you're proposing requiring that these be set the
> same on master and slave?

Yes, or more precisely: Slave value >= Master value

> I don't have a problem with that, but
> I do suggest that we must provide a mechanism to check it --- I don't
> want DBAs to be faced with obscure failures when (not if) they
> mess it up. Perhaps include the values in checkpoint WAL records?

Good plan. We can generate an immediate message at startup.

--
Simon Riggs www.2ndQuadrant.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-09-04 11:29:02 Re: Tightening binary receive functions
Previous Message Tom Lane 2009-09-04 05:25:07 Re: Hot Standby, max_connections and max_prepared_transactions