On Fri, Oct 8, 2010 at 11:10 AM, Simon Riggs wrote:
> This patch is a rough WIP, mostly stripping out and streamlining. It
> doesn't work yet, but people say they like to see me working, so here
> 'tis.
It's been two months since you posted this. Any update?
I'd like to actually review the two
On Sat, Oct 9, 2010 at 3:33 AM, Simon Riggs wrote:
> On Fri, 2010-10-08 at 12:23 -0400, Robert Haas wrote:
>
>> It seems like it would be more helpful if you were working on
>> implementing a design that had more than one vote. As far as I can
>> tell, we have rough consensus that for the first c
On Fri, 2010-10-08 at 12:23 -0400, Robert Haas wrote:
> It seems like it would be more helpful if you were working on
> implementing a design that had more than one vote. As far as I can
> tell, we have rough consensus that for the first commit we should only
> worry about the case where k = 1; t
On Fri, Oct 8, 2010 at 5:59 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> It seems like it would be more helpful if you were working on
>> implementing a design that had more than one vote. As far as I can
>> tell, we have rough consensus that for the first commit we should only
>> worry
Robert Haas writes:
> It seems like it would be more helpful if you were working on
> implementing a design that had more than one vote. As far as I can
> tell, we have rough consensus that for the first commit we should only
> worry about the case where k = 1; that is, only one ACK is ever
> req
On Fri, Oct 8, 2010 at 11:10 AM, Simon Riggs wrote:
> On Tue, 2010-09-14 at 18:48 +0100, Simon Riggs wrote:
>
>> I'm working on a patch to implement synchronous replication for
>> PostgreSQL, with user-controlled durability specified on the master. The
>> design also provides high throughput by al
On Tue, 2010-09-14 at 18:48 +0100, Simon Riggs wrote:
> I'm working on a patch to implement synchronous replication for
> PostgreSQL, with user-controlled durability specified on the master. The
> design also provides high throughput by allowing concurrent processes to
> handle the WAL stream. The
On Tue, 2010-09-14 at 18:48 +0100, Simon Riggs wrote:
> I'm working on a patch to implement synchronous replication for
> PostgreSQL, with user-controlled durability specified on the master. The
> design also provides high throughput by allowing concurrent processes to
> handle the WAL stream. The
On Sep 15, 2010, at 5:23 AM, Simon Riggs wrote:
> Fast, efficient, no extra code.
I love that sentence. Even if it has no verb.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On Wed, 2010-09-15 at 11:54 +0300, Heikki Linnakangas wrote:
> On 14/09/10 20:48, Simon Riggs wrote:
> > When each new messages arrives from master the WALreceiver will write
> > the new data to the WAL file, wake the WALwriter and then reply. Each
> > new message from master receives a reply. If n
On 14/09/10 20:48, Simon Riggs wrote:
When each new messages arrives from master the WALreceiver will write
the new data to the WAL file, wake the WALwriter and then reply. Each
new message from master receives a reply. If no further WAL data has
been received the WALreceiver waits on the latch.
On 14 September 2010 21:36, David E. Wheeler wrote:
> On Sep 14, 2010, at 10:48 AM, Simon Riggs wrote:
>
>> I will post my patch on this thread when it is available.
>
> Sounds awesome Simon, I look forward to seeing the discussion!
>
> Best,
>
> David
Excellent! :) I actually understand how tha
On Sep 14, 2010, at 10:48 AM, Simon Riggs wrote:
> I will post my patch on this thread when it is available.
Sounds awesome Simon, I look forward to seeing the discussion!
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
13 matches
Mail list logo
