Heikki Linnakangas <hlinnaka@iki.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
