Manfred Koizar <[EMAIL PROTECTED]> writes:
> (3d) t_xmin == t_xmax == current transaction. The tuple has been
> inserted and then deleted by the current transaction. Then I claim
> (but I'm not absolutely sure), that insert and delete cannot have
> happened in the same command,
> so t_cmin < t_cmax,
> so t_cmin < CurrentCommandId,
> so the exact value of t_cmin is irrelevant.
The hole in this logic is that there can be multiple active scans with
different values of CurrentCommandId (eg, within a function
CurrentCommandId may be different than it is outside). If you overwrite
cmin with cmax then you are destroying the information needed by a scan
with smaller CurrentCommandId than yours.
> (Q4) Is it really easy to change the size of HeapTupleHeaderData? Are
> the data of this struct only accessed by field names or are there
> dirty tricks using memcpy() and pointer arithmetic?
AFAIK there are no dirty tricks there. I am hesitant to change the
header layout without darn good reason, because it breaks any chance
of having a working pg_upgrade process. But that's strictly a
production-system concern, and need not discourage you from
experimenting.
> (Q5) Are these thoughts obsolete as soon as nested transactions are
> considered?
Possibly. We haven't worked out exactly how nested transactions would
work, but to the extent that they are handled as different CommandIds
we'd have the same issue already mentioned: we should not assume that
execution of different CommandIds can't overlap in time.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
