From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Sending notifications from the master to the standby |
Date: | 2012-01-10 16:55:50 |
Message-ID: | 25200.1326214550@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:
> On Tue, Jan 10, 2012 at 5:00 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It might be a bit tricky to get walreceivers to inject
>> the data into the slave-side ring buffer at the right time, ie, not
>> until after the commit a given message describes has been replayed;
>> but I don't immediately see a reason to think that's infeasible.
> [ Simon sketches a design for that ]
Seems a bit overcomplicated. I was just thinking of having walreceiver
note the WAL endpoint at the instant of receipt of a notify message,
and not release the notify message to the slave ring buffer until WAL
replay has advanced that far. You'd need to lay down ground rules about
how the walsender times the insertion of notify messages relative to
WAL in its output. But I don't see the need for either explicit markers
in the WAL stream or a hash table. Indeed, a hash table scares me
because it doesn't clearly guarantee that notifies will be released in
arrival order.
> Suggest we add something to initial handshake from standby to say
> "please send me notify traffic",
+1 on that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2012-01-10 17:13:42 | Re: libpq: PQcmdStatus, PQcmdTuples signatures can be painlessly improved |
Previous Message | Simon Riggs | 2012-01-10 16:38:26 | Re: Sending notifications from the master to the standby |