Re: logical changeset generation v6.1 - Mailing list pgsql-hackers

On 2013-10-08 12:20:22 -0400, Robert Haas wrote:
> On Mon, Oct 7, 2013 at 9:32 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> >> - RelationIsDoingTimetravel is still a crappy name.  How about
> >> RelationRequiredForLogicalDecoding?  And maybe the reloption
> >> treat_as_catalog_table can become required_for_logical_decoding.
> >
> > Hm. I don't really like the name, required seems to imply that it's
> > necessary to turn this on to get data replicated in that relation. How
> > about "accessible_during_logical_decoding" or "user_catalog_table"? The
> > latter would allow us to use it to add checks for user relations used in
> > indexes which need a treatment similar to enums.
> 
> user_catalog_table is a pretty good description, but should we worry
> about the fact that logical replication isn't mentioned in there
> anywhere?

I personally don't worry about it, although I see why somebody could.

> In what way do you feel that it's more clear to say *accessible
> during* rather than *required for* logical decoding?

Because "required for" can easily be understood that you need to set it
if you want a table's changes to be replicated. Which is not the case...

> I was trying to make the naming consistent; i.e. if we have
> RelationRequiredForLogicalDecoding then name the option to match.

Maybe this should be RelationAccessibleInLogicalDecoding() then - that
seems like a better description anyway?

> >> All in all, it seems to me that we shouldn't try to punt.  Maybe we
> >> should have something that works like ALTER TABLE name CLUSTER ON
> >> index_name to configure which index should be used for logical
> >> replication.  Possibly this same syntax could be used as ALTER
> >> MATERIALIZED VIEW to set the candidate key for that case.
> >
> > How about using the current logic by default but allow to tune it
> > additionally with an option like that?
> 
> I'm OK with defaulting to the primary key if there is one, but I think
> that no other candidate key should be entertained unless the user
> configures it.  I think the behavior we get without that will be just
> too weird.  We could use the same logic you're proposing here for
> CLUSTER, too, but we don't; that's because we've (IMHO, rightly)
> decided that the choice of index is too important to be left to
> chance.

I don't understand why this would be a good path. If you DELETE/UPDATE
and you don't have a primary key you get something that definitely
identifies the row with the current behaviour. It might not be the best
thing, but it sure is better than nothing. E.g. for auditing it's
probably quite sufficient to just use any of the candidate keys if
there (temporarily) is no primary key.
If you implement a replication solution and don't want that behaviour
there, you are free to guard against it there - which is a good thing
to do.

Greetings,

Andres Freund

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