Re: foreign key locks, 2nd attempt

Excerpts from Bruce Momjian's message of vie mar 16 00:04:06 -0300 2012:
>
> On Tue, Mar 13, 2012 at 02:35:02PM -0300, Alvaro Herrera wrote:
> >
> > Excerpts from Bruce Momjian's message of mar mar 13 14:00:52 -0300 2012:
> > >
> > > On Tue, Mar 06, 2012 at 04:39:32PM -0300, Alvaro Herrera wrote:
> >
> > > > When there is a single locker in a tuple, we can just store the locking info
> > > > in the tuple itself. We do this by storing the locker's Xid in XMAX, and
> > > > setting hint bits specifying the locking strength. There is one exception
> > > > here: since hint bit space is limited, we do not provide a separate hint bit
> > > > for SELECT FOR SHARE, so we have to use the extended info in a MultiXact in
> > > > that case. (The other cases, SELECT FOR UPDATE and SELECT FOR KEY SHARE, are
> > > > presumably more commonly used due to being the standards-mandated locking
> > > > mechanism, or heavily used by the RI code, so we want to provide fast paths
> > > > for those.)
> > >
> > > Are those tuple bits actually "hint" bits? They seem quite a bit more
> > > powerful than a "hint".
> >
> > I'm not sure what's your point. We've had a "hint" bit for SELECT FOR
> > UPDATE for ages. Even 8.2 had HEAP_XMAX_EXCL_LOCK and
> > HEAP_XMAX_SHARED_LOCK. Maybe they are misnamed and aren't really
> > "hints", but it's not the job of this patch to fix that problem.
>
> Now I am confused. Where do you see the word "hint" used by
> HEAP_XMAX_EXCL_LOCK and HEAP_XMAX_SHARED_LOCK. These are tuple infomask
> bits, not hints, meaning they are not optional or there just for
> performance.

Okay, I think this is just a case of confusing terminology. I have
always assumed (because I have not seen any evidence to the contrary)
that anything in t_infomask and t_infomask2 is a "hint bit" --
regardless of it being actually a hint or something with a stronger
significance. HEAP_XMAX_EXCL_LOCK and HEAP_XMAX_SHARED_LOCK are
certainly not "optional" in the sense that if they are missing, the
meaning of the Xmax field is completely different. So in all
correctness they are not "hints", though we call them that.

Now, if we want to differentiate infomask bits that are just hints from
those that are something else, we can do that, but I'm not sure it's
useful -- AFAICS only XMAX_COMMITTED and XMIN_COMMITTED are proper
hints.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support