In fact, I had proposed a simpler UNDO capability that revisited tuples
and set their XID to a fixed aborted XID to clean up aborted
subtransactions, but most now like the multiple XID solution.
I think for the implicit subtransactions that we will want
(with error codes comming) using a
I see no concurrency problems. If two or more backends visit the same
tuple, they either write the same value to the same position which
doesn't hurt, or one sees the other's changes which is a good thing.
AFAIR, on multi-CPU platforms it's possible that second transaction could
see COMMITTED
On Thu, Mar 20, 2003 at 01:40:44AM -0500, Tom Lane wrote:
There are indeed some first-cut provisions in the lock code for multiple
transactions owned by a backend, but it'd be dangerous to assume that
they are either correct or complete. The only case that's tested is for
VACUUM to hold a
Manfred Koizar [EMAIL PROTECTED] writes:
If we set XMIN/MAX_IS_COMMITTED in a tuple header, we have to replace
a sub-transaction xid in xmin or xmax respectively with the
main-transaction xid at the same time. Otherwise we'd have to look
for the main xid, whenever a tuple is touched.
This
On Wed, 19 Mar 2003 11:18:38 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
If we set XMIN/MAX_IS_COMMITTED in a tuple header, we have to replace
a sub-transaction xid in xmin or xmax respectively with the
main-transaction xid at the same time. Otherwise we'd
Manfred Koizar [EMAIL PROTECTED] writes:
If the sequence is first update xmin, then set the commit bit, we
never have an inconsistent state. And if the change is lost, it can
be redone by the next backend visiting the tuple.
Not if the subtransaction log state has been removed as no longer
I see no concurrency problems. If two or more backends visit the same
tuple, they either write the same value to the same position which
doesn't hurt, or one sees the other's changes which is a good thing.
AFAIR, on multi-CPU platforms it's possible that second transaction could
see COMMITTED
On Wed, 19 Mar 2003 13:00:07 -0500, Tom Lane [EMAIL PROTECTED]
wrote:
Manfred Koizar [EMAIL PROTECTED] writes:
And if the change is lost, it can
be redone by the next backend visiting the tuple.
Not if the subtransaction log state has been removed as no longer
needed.
But this problem is not
Hiroshi Inoue [EMAIL PROTECTED] writes:
Sorry I have a basic question.
Was there any consensus we would introduce nested transactions
(or savepoints) in the way currently discussed ?
I think we are a long way from saying we can or will actually do it.
Error handling and resource management (eg
Here is, what I've put together from various messages posted
November/December last year.
. Subtrans trees
. Transaction states
. Tuple visibility
. HeapTupleSatifiesUpdate
. Shortcuts
. Still missing
. Objections and suggestions
Subtrans
10 matches
Mail list logo
