On Tue, Jan 31, 2017 at 9:05 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
>> Personally I don't think lack of access to the GID justifies blocking 2PC
>> logical decoding. It can be added separately. But it'd be nice to have
>> especially if it's cheap.
>
> I think it should be added reading this thread.
+1. If on the logical replication master the user executes PREPARE
TRANSACTION 'mumble', isn't it sensible to want the logical replica to
prepare the same set of changes with the same GID? To me, that not
only seems like *a* sensible thing to want to do but probably the
*most* sensible thing to want to do. And then, when the eventual
COMMIT PREPAPARED 'mumble' comes along, you want to have the replica
run the same command. If you don't do that, then the alternative is
that the replica has to make up new names based on the master's XID.
But that kinda sucks, because now if replication stops due to a
conflict or whatever and you have to disentangle things by hand, all
the names on the replica are basically meaningless.
Also, including the GID in the WAL for each COMMIT/ABORT PREPARED
doesn't seem inordinately expensive to me. For that to really add up
to a significant cost, wouldn't you need to be doing LOTS of 2PC
transactions, each with very little work, so that the commit/abort
prepared records weren't swamped by everything else? That seems like
an unlikely scenario, but if it does happen, that's exactly when
you'll be most grateful for the GID tracking. I think.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company