From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Per tuple overhead, cmin, cmax |
Date: | 2002-05-02 21:16:38 |
Message-ID: | 18176.1020374198@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Manfred Koizar <mkoi-pg(at)aon(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2002-05-02 21:35:01 | Consistency problem with unlabeled intervals |
Previous Message | Michael E. Locasto | 2002-05-02 21:11:30 | Re: PostgreSQL mission statement? |