Re: Hot standby, recovery procs

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby, recovery procs
Date: 2009-02-26 09:36:19
Message-ID: 49A66293.3050904@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs wrote:
> On Thu, 2009-02-26 at 10:04 +0200, Heikki Linnakangas wrote:
>
>> we keep track of which xids
>> have already been "reported" in the WAL (similar to what you had in an
>> earlier version of the patch)
>
> You objected to doing exactly that earlier.

I'm talking about the "xidMarkedInWAL" and "hasUnMarkedSubXids" fields
you had in TransactionState, at least still in version
hs.v7.20090112_1.tar.bz2 of the patch. I objected to adding the
corresponding flags in the WAL header, and that made tracking the status
in TransactionState obsolete in the patch too, since it wasn't used for
anything anymore. There's nothing wrong per se about tracking the
"marked" or "reported" status in master.

> You haven't even given a good reason to make these changes.

Simplicity.

> We don't have time to make this change and then shake out everything
> else that will break as a result. Are you suggesting that you will make
> these changes and then follow up on all other breakages? Forcing this
> request seems like a great way to cancel this patch, since it will be
> marked as "author refused to make change".

I'm not suggesting anything to be canceled. I simply think these are
changes that should be made. I wish you could make them, because that
means less work for me. But if you're not willing to, I can pick it up
myself.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-02-26 10:16:17 Re: Hot standby, recovery procs
Previous Message Simon Riggs 2009-02-26 09:27:58 Re: Synchronous replication & Hot standby patches