"Pavan Deolasee" <pavan.deolasee@gmail.com> writes:
> On 11/10/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> (2) Isn't this full of race conditions?
> I agree, there could be race conditions. But IMO we can handle those.
Doubtless you can prevent races by introducing a bunch of additional
locking. The question was really directed to how much concurrent
performance is left, once you get done locking it down.
> (3) I thought you already used up the one remaining t_infomask bit.
> Yes. The last bit in the t_infomask is used up to mark presence of overflow
> tuple header. But I believe there are few more bits that can be reused.
> There are three bits available in the t_ctid field as well (since ip_posid
> needs maximum 13 bits).
No, you cannot have those bits --- BLCKSZ is not limited to 8K, and even
if it were, we will not hold still for sticking flag bits into an
unrelated datatype.
You can probably fix this by inventing multiple context-dependent
interpretations of t_infomask bits, but that strikes me as a mighty
ugly and fragile way to proceed.
(Actually, the assumption that you can throw an additional back-pointer
into overflow tuple headers is the worst feature of this proposal in
that regard --- it's really not that easy to support multiple header
formats.)
regards, tom lane
