Re: logical changeset generation v6.4

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: logical changeset generation v6.4
Date: 2013-10-25 14:58:15
Message-ID: 20131025145815.GD5627@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2013-10-22 16:07:16 +0200, Andres Freund wrote:
> On 2013-10-21 20:16:29 +0200, Andres Freund wrote:
> > Current draft is:
> > ALTER TABLE ... REPLICA IDENTITY NOTHING|FULL|DEFAULT
> > ALTER TABLE ... REPLICA IDENTITY USING INDEX ...;
> >
> > which leaves the door open for
> >
> > ALTER TABLE ... REPLICA IDENTITY USING '(' column_name_list ')';
> >
> > Does anybody have a strong feeling about requiring support for CREATE
> > TABLE for this?
>
> Attached is a patch ontop of master implementing this syntax. It's not
> wired up to the changeset extraction patch yet as I am not sure whether
> others agree about the storage.

So, I am currently wondering about how to store the "old" tuple, based
on this. Currently it is stored using the TupleDesc of the index the old
tuple is based on. But if we want to allow transporting the entire tuple
that obviously cannot be the only option.
One option would be to change the stored format based on what's
configured, using the relation's TupleDesc if FULL is used. But I think
always using the heap relation's desc is better.
The not-logged columns would then just be represented as NULLs. That
will make old primary keys bigger if the relation has a high number of
columns and the key small, but I don't think it matters enough.

Opinions?

Greetings,

Andres Freund

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-10-25 15:01:28 Re: Detection of nested function calls
Previous Message Andres Freund 2013-10-25 14:48:12 Re: Detection of nested function calls