Re: Two-phase commit issues - Mailing list pgsql-hackers

On Wed, May 18, 2005 at 07:29:38PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@surnet.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.

Hm, this assumes the transaction knows what MultiXactIds it belongs to.
This is not true, is it?  I'm not sure how to find that out.

> >> * 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.

I think I confused the issue with using local buffers instead of shared
buffers, for example where btree creation skips WAL.  But certainly it
doesn't have anything to do with it.


> 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.

Hmm.  I think not being able to use temp tables is an important
restriction.  I can see the implementation issue though.

> 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.

Maybe the restriction could be lighter -- what if the prepared
transaction inserts tuples on a temp table, for example.  It's
inconsistent, I think, that a temp table could have tuples on it that
suddenly appear when some other backend commits my prepared transaction.


> 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.

That'd require labelling tuples in temp tables with a different Xid,
than non-temp tables, no?  It'd get strange very quickly.

-- 
Alvaro Herrera (<alvherre[a]surnet.cl>)
"La persona que no quería pecar / estaba obligada a sentarseen duras y empinadas sillas    / desprovistas, por ciertode
blandosatenuantes"                          (Patricio Vogel)