Re: foreign key locks, 2nd attempt

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: foreign key locks, 2nd attempt
Date: 2012-03-16 18:15:11
Message-ID: 20120316181511.GB28340@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Mar 16, 2012 at 10:40:01AM -0300, Alvaro Herrera wrote:
>
> Excerpts from Alvaro Herrera's message of vie mar 16 10:36:11 -0300 2012:
>
> > > 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.
>
> Maybe this is just my mistake. I see in
> http://wiki.postgresql.org/wiki/Hint_Bits that we only call the
> COMMITTED/INVALID infomask bits "hints".
>
> I think it's easy enough to correct the README to call them "infomask
> bits" rather than hints .. I'll go do that.

OK, thanks. I only brought it up so people would not be confused by
thinking these were optional pieces of information, and that the real
information is stored somewhere else.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-03-16 18:22:05 Re: foreign key locks, 2nd attempt
Previous Message Bruce Momjian 2012-03-16 18:08:53 Re: [BUGS] BUG #6532: pg_upgrade fails on Python stored procedures