Prev: [HACKERS] Hot Standby and handling max_standby_delay
Next: Mammoth in Core?
From: Simon Riggs on 18 Jan 2010 06:30
On Mon, 2010-01-18 at 20:18 +0900, Fujii Masao wrote:
> On Mon, Jan 18, 2010 at 6:35 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
> > On Mon, Jan 18, 2010 at 5:45 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote:
> >> How accurate is this now? With regard to remaining items of work.
> >> http://wiki.postgresql.org/wiki/Streaming_Replication
> >
> > Not accurate. I'll correct that and provide the link from
> > "v8.5 Open Items page" to that.
>
> I listed the TODO items that need to be addressed for v8.5.
> http://wiki.postgresql.org/wiki/Streaming_Replication#v8.5
>
> If you find any other TODO items, please add them to the list.

What were the blockers that prevented sync rep from being included? I
must have missed the discussion on that part.

--
Simon Riggs www.2ndQuadrant.com


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 18 Jan 2010 06:30
Fujii Masao wrote:
> On Mon, Jan 18, 2010 at 6:35 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote:
>> On Mon, Jan 18, 2010 at 5:45 PM, Simon Riggs <simon(a)2ndquadrant.com> wrote:
>>> How accurate is this now? With regard to remaining items of work.
>>> http://wiki.postgresql.org/wiki/Streaming_Replication
>> Not accurate. I'll correct that and provide the link from
>> "v8.5 Open Items page" to that.
>
> I listed the TODO items that need to be addressed for v8.5.
> http://wiki.postgresql.org/wiki/Streaming_Replication#v8.5
>
> If you find any other TODO items, please add them to the list.

Thanks! That's very useful.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 18 Jan 2010 07:12
Simon Riggs wrote:
> What were the blockers that prevented sync rep from being included? I
> must have missed the discussion on that part.

For one, figuring out how to send back the notifications about WAL
applied in standby, and all the IPC required for that.

Streaming replication is a complex enough patch in just asynchronous
mode. Including synchronous mode would certainly have meant missing 8.5,
we just don't have the resources to review all at once. Even if we did,
splitting the project into smaller increments is a good idea anyway.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Tom Lane on 18 Jan 2010 09:34
Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes:
> Simon Riggs wrote:
>> Do we need a new record type for that, is there a handy record type to
>> bounce from?

> After starting streaming, slices of WAL are sent as CopyData messages.
> The CopyData payload begins with an XLogRecPtr, followed by the WAL
> data. That payload format needs to be extended with a 'message type'
> field and a new message type for the timestamps need to be added.

Whether or not anyone bothers with the timestamp message, I think adding
a message type header is a Must Fix item. A protocol with no provision
for extension is certainly going to bite us in the rear before long.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Heikki Linnakangas on 18 Jan 2010 10:20
Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes:
>> Simon Riggs wrote:
>>> Do we need a new record type for that, is there a handy record type to
>>> bounce from?
>
>> After starting streaming, slices of WAL are sent as CopyData messages.
>> The CopyData payload begins with an XLogRecPtr, followed by the WAL
>> data. That payload format needs to be extended with a 'message type'
>> field and a new message type for the timestamps need to be added.
>
> Whether or not anyone bothers with the timestamp message, I think adding
> a message type header is a Must Fix item. A protocol with no provision
> for extension is certainly going to bite us in the rear before long.

Agreed a message type header is a good idea, although we don't expect
streaming replication and the protocol to work across different major
versions anyway.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: [HACKERS] Hot Standby and handling max_standby_delay
Next: Mammoth in Core?