> 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 d
> 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 COMMITT
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
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
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 probl
> 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 COMMITT
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 lon
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. Othe
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.
Th
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 t
10 matches
Mail list logo
