Re: Per tuple overhead, cmin, cmax

Manfred Koizar <mkoi-pg@aon.at> 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