Horton

Re: foreign key locks, 2nd attempt

Bruce Momjian <bruce@momjian.us>

View thread
From: Bruce Momjian <bruce@momjian.us>
To: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-03-16T18:15:11Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Try to avoid running with a full fsync request queue.

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@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

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