Re: Future In-Core Replication

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Hannu Krosing <hannu(at)krosing(dot)net>, Jim Nasby <jim(at)nasby(dot)net>, Christopher Browne <cbbrowne(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Future In-Core Replication
Date: 2012-05-04 13:16:22
Message-ID: CA+U5nM+Bi7Z-7rzvPJxMZaXku3Tvrw08mEUJ94AdvVXaiQ7OTQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 4 May 2012 14:01, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, May 4, 2012 at 8:32 AM, Hannu Krosing <hannu(at)krosing(dot)net> wrote:
>> For logical we don't really need to uniquely identify such rows - it
>> should sufficient if we just update exactly one of the matching rows.
>>
>> The way to do this is to put all fields of the OLD.* tuple in the WHERE
>> clause and then update just one matching row.
>>
>> IIRC updating (or deleting) CURRENT OF a cursor is currently supported
>> only in pl/pgsql so this needs to be done using a plpgsql cursor.
>>
>> If the table has no indexes or index lookup returns lots of rows, then
>> this is bound to be slow, but in this case it was probably slow on
>> master too :)
>
> I was about to write a reply saying exactly this, but you said it
> better than I would have been able to manage.
>
> I think this is all exactly right.

Yes, but its not a high priority for inclusion. Many things like this
will need to wait behind the really critical additional features.

--
 Simon Riggs                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-04 13:17:28 Re: Advisory locks seem rather broken
Previous Message Simon Riggs 2012-05-04 13:11:52 Re: CLOG extension