Re: Two-phase commit issues

Heikki Linnakangas <hlinnaka(at)iki(dot)fi> writes:
> As Alvaro pointed out elsewhere, the multixacts are harder because a
> backend doesn't know which multixactids it belongs to. AFAICS, the most
> straightforward solution is to xlog every CreateMultixact call, so that
> the multixact slru files can be completely reconstructed on recovery.

I realized this morning that in fact it *can't* know that, since even
after a particular transaction commits it's still possible for others to
add it to new multixacts. In the case of a prepared xact it would
continue to get added to new multixacts indefinitely :-(. So the idea
of recording info about this in the state files is clearly a loser.
I think we will indeed have to start xlogging multixact operations.

> Third, we have to cater for PITR. I haven't given it much thought, but if
> we want to do log shipping and PITR, I believe we must have everything in
> the WAL.

Hmm. All your other arguments for WAL-logging a prepare are bogus, but
this one seems real. (It's also a reason why multixact stuff needs to
be xlogged, I guess.)

>> * I'm inclined to think that the "gid" identifiers for prepared
>> transactions ought to be SQL identifiers (names), not string literals.
>> Was there a particular reason for making them strings?

> Sure. No Reason. While you're at it, do you think it's possible to make it
> unlimited size? I couldn't think of a simple way.

Actually, one reason for wanting them to be identifiers is so that
there's a principled reason for saying what the max length is ;-)

> I think the safest way to handle the GUC case as well is to just refuse to
> prepare a transaction that has changed local GUC variables.

That seems unnecessarily restrictive.

> Another possibility is to rethink the contract of PREPARE TRANSACTION and
> COMMIT/ROLLBACK PREPARED. If PREPARE TRANSACTION would put the backend to
> a state where you can't do anything else than COMMIT/ROLLBACK the prepared
> transaction, we could do more sensible things with GUC and temp tables.
> That would have complications of it's own though. What would happen if
> another backend then tries to COMMIT/ROLLBACK the transaction the original
> backend is still tied to?

Yeah, I do not think this is a useful answer. Allowing the commit to
happen somewhere else and restricting what a prepared xact can do with
temp tables seems much more useful in practice.

regards, tom lane