From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
Date: | 2013-12-04 19:43:52 |
Message-ID: | 23606.1386186232@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> On Tue, Dec 3, 2013 at 7:20 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I assume what would happen is the slave would PANIC upon seeing a WAL
>> record code it didn't recognize.
> I wonder if we should for the future have the START_REPLICATION command (or
> the IDENTIFY_SYSTEM would probably make more sense - or even adding a new
> command like IDENTIFY_CLIENT. The point is, something in the replication
> protocol) have walreceiver include it's version sent to the master. That
> way we could have the walsender identify a walreceiver that's too old and
> disconnect it right away - with a much nicer error message than a PANIC.
Meh. That only helps for the case of streaming replication, and not for
the thirty-seven other ways that some WAL might arrive at something that
wants to replay it.
It might be worth doing anyway, but I can't get excited about it for this
scenario.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2013-12-04 20:51:57 | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
Previous Message | Magnus Hagander | 2013-12-04 17:19:36 | Re: pgsql: Fix a couple of bugs in MultiXactId freezing |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2013-12-04 19:44:43 | Re: RFC: programmable file format for postgresql.conf |
Previous Message | Joshua D. Drake | 2013-12-04 19:40:56 | Re: Why we are going to have to go DirectIO |