"Pavan Deolasee" <[EMAIL PROTECTED]> writes: > On 11/10/06, Tom Lane <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org