Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
Date
Msg-id AANLkTinymDD4joLtEEy8EGzNmVF=j=Ma6_n3K+6ohKTx@mail.gmail.com
Whole thread Raw
In response to Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Re: making write location work (was: Efficient transaction-controlled synchronous replication)
List pgsql-hackers
On Wed, Mar 23, 2011 at 3:33 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> In any case, that's not the only argument for keeping it. We introduce
> the view in this release and I would like it to stay the same from
> now, since we know we will need that info later.

At least as I understand it, it's not our project policy to carry
around code that doesn't accomplish anything useful.  I have no
objection to keeping the field; I simply think that if we're going to
have it, we should make it work, as in fact it did before you changed
it without discussion.  You haven't offered any evidence at all that
it introduces any kind of a performance regression AT ALL, much less
that such any such regression can't be trivially patched around by
making SyncRepReleaseWaiters exit quickly if the flush LSN hasn't
advanced.  The onus is as much on you to justify the change as it is
on me to justify changing it back.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: 2nd Level Buffer Cache
Next
From: Robert Haas
Date:
Subject: Re: psql \dt and table size