Re: Set new system identifier using pg_resetxlog

On Tue, Jun 17, 2014 at 12:50 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> >> I can clearly understand the utility of being able to reset the system
>> >> ID to a new, randomly-generated system ID - but giving the user the
>> >> ability to set a particular value of their own choosing seems like a
>> >> pretty sharp tool. What is the use case for that?
>
> I've previously hacked this up adhoc during data recovery when I needed
> to make another cluster similar enough that I could replay WAL.
>
> Another usecase is to mark a database as independent from its
> origin. Imagine a database that gets sharded across several
> servers. It's not uncommon to do that by initially basebackup'ing the
> database to several nodes and then use them separately from
> thereon. It's quite useful to actually mark them as being
> distinct. Especially as several of them right now would end up with the
> same timeline id...

Sure, but that only requires being able to reset the ID randomly, not
to a particular value.

>> But it seems to me that we might need to have a process discussion
>> here, because, while I'm all in favor of incremental feature proposals
>> that build towards a larger goal, it currently appears that the larger
>> goal toward which you are building is not something that's been
>> publicly discussed and debated on this list. And I really think we
>> need to have that conversation. Obviously, individual patches will
>> still need to be debated, but I feel like 2ndQuadrant is trying to
>> construct a castle without showing the community the floor plan. I
>> believe that there is relatively broad agreement that we would all
>> like a castle, but different people may have legitimately different
>> ideas about how it should be constructed. If the work arrives as a
>> series of disconnected pieces (user-specified system ID, event
>> triggers for CREATE, etc.), then everyone outside of 2ndQuadrant has
>> to take it on faith that those pieces are going to eventually fit
>> together in a way that we'll all be happy with. In some cases, that's
>> fine, because the feature is useful on its own merits whether it ends
>> up being part of the castle or not.
>>
>
> Uh. Right now this patch has been written because it's needed for a out
> of core replication solution. That's what BDR is at this point. The
> patch is unobtrusive, has other usecases than just our internal one and
> doesn't make pg_resetxlog even more dangerous than it already is. I
> don't see much problem with considering it on it's own cost/benefit?

Well, I think it *does* make pg_resetxlog more dangerous; see previous
discussion of pg_computemaxlsn.

> So this seems to be a concern that's relatively independent of this
> patch. Am I seing that right?

Partially; not completely.

> I actually don't think any of the discussions I was involved in had the
> externally visible version of replication identifiers limited to 16bits?
> If you are referring to my patch, 16bits was just the width of the
> *internal* name that should basically never be looked at. User visible
> replication identifiers are always identified by an arbitrary string -
> whose format is determined by the user of the replication identifier
> facility. *BDR* currently stores the system identifer, the database id
> and a name in there - but that's nothing core needs to concern itself
> with.

I don't think you're going to be able to avoid users needing to know
about those IDs. The configuration table is going to have to be the
same on all nodes, and how are you going to get that set up without
those IDs being user-visible?

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