Re: Two-phase commit issues

Alvaro Herrera <alvherre(at)surnet(dot)cl> writes:
> On Wed, May 18, 2005 at 05:15:09PM -0400, Tom Lane wrote:
>> Similarly, we've got to reconstruct MultiXactIds that any prepared
>> xacts are members of, else row-level locks taken out by prepared xacts
>> won't be enforced correctly. I think this can be handled if we add to
>> the state files a list of all MultiXactIds that each prepared xact
>> belongs to, and then during restart forcibly recreate those
>> MultiXactIds. (They would only be rebuilt with prepared XIDs, not any
>> ordinary XIDs that might originally have been members.)

> I'm not sure if it affects in any way that a Xid=1, which participates
> in a MultiXactId is seen as not prepared when Xid=2 prepares, which also
> participates in the same MultiXactId; if Xid=1 is prepared later, the
> MultiXactId needs to be restored with both Xids as participants.

What I had in mind was that each prepared xact's state file would just
list the MultiXactIds it belongs to. While re-reading the state files
after a crash, we'd construct the opposite lists (ie, which xacts belong
to each MultiXactId) and then write appropriate entries into
pg_multixact at completion of the re-read. I don't think it matters
what order the xacts got prepared in.

>> * There are some fairly ugly cases associated with creation and deletion
>> of temporary tables as well. I think we might want to just decree that
>> you can't PREPARE a transaction that included creating or dropping a
>> temp table. Does anyone have much of a problem with that?

> Does this affect any of the other things that use the direct-fsync-no-WAL
> path in the smgr?

I don't think so. It's not fsync that is at issue, really --- what I'm
concerned about is operations that occur at commit time. For instance,
consider
CREATE TEMP TABLE foo (...) ON COMMIT DELETE ROWS;
BEGIN;
DROP TABLE foo;
PREPARE gid;
foo has an entry in the backend's on-commit-actions list, which the DROP
marks for deletion at commit. It is unclear what to do with that entry
at prepare. We can't really leave it active since the table can't be
touched afterwards (the DROP took an exclusive lock, which we no longer
own). But simply forgetting it is not good either; what if the prepared
xact is later rolled back? Worse, what if some other backend does that
rollback? If it was us doing the ROLLBACK PREPARED, we could at least
in theory resurrect the ON COMMIT item, but there's no communication
path to tell us to do so when someone else does the rollback.

More generally, anything like this implies that a transaction that is no
longer ours is holding locks on our temp tables. This is Really Bad.
(Consider what happens if our backend tries to exit --- it'll want to
delete those temp tables.) I am more than half tempted to put some kind
of test into LockPersistAll to reject attempts to persist any lock of
any kind on a temp table.

I suppose the ideal solution would be something like what I was just
suggesting for GUC: as far as temp tables go, a PREPARE is a COMMIT,
and none of the resources associated with the temp table get assigned
to the prepared xact. I am not sure how do-able that is, though.

regards, tom lane