Re: Streaming replication and postmaster signaling

From: Dave Page <dpage(at)pgadmin(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Devrim GÜNDÜZ <devrim(at)gunduz(dot)org>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Streaming replication and postmaster signaling
Date: 2010-01-07 20:44:27
Message-ID: 937d27e11001071244s15a96b56rcc674c895b137e85@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 7, 2010 at 7:00 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> That may well be so, but adding another one is not going to improve
>> the situation even a little bit.  I don't think what you're saying
>> weakens in the slightest the argument that I was making, namely, that
>> if this isn't committed RSN it should be postponed to 8.6.  Do you
>> disagree?
>
> Well, the argument to my mind is about a suitable value of "RSN".
> I think you were stating that we should bounce SR if it's not committed
> before the final commitfest starts (ie, next week).  I think we can give
> it more slack than that.  Maybe the end of the fest (where the length of
> the fest is determined by the other open patches)?

Absolutely agree. Stretching the freeze to accomodate SR is what we
should avoid, but bumping it before it's even started is completely
over the top and would be the complete opposite of our past errors.
Especially given that Heikki is spending significant time on it right
now...

--
Dave Page
EnterpriseDB UK: http://www.enterprisedb.com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-07 20:47:47 Re: Hot Standy introduced problem with query cancel behavior
Previous Message Kevin Grittner 2010-01-07 20:43:10 Re: true serializability and predicate locking