Re: ALTER TABLE lock strength reduction patch is unsafe

Noah Misch <noah@leadboat.com>

From: Noah Misch <noah@leadboat.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Bruce Momjian <bruce@momjian.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-01-03T04:40:38Z
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. Add bytea_agg, parallel to string_agg.

  2. Fix ALTER TABLE ONLY .. DROP CONSTRAINT.

On Tue, Jan 03, 2012 at 01:18:41AM +0000, Simon Riggs wrote:
> Just for the record, yes we do run multiple catalog scans in some
> parts of the code.
> 
> So I can see how we might trigger 4 nested scans, using cache
> replacement while scanning, so best assume more, with no guarantee of
> them being neatly stacked for pop/push type access.

Yeah, I wouldn't want to commit to a nesting limit.  However, I _would_ have
expected that a stack would suffice; PushActiveSnapshot()/PopActiveSnapshot()
is adequate for a great deal of the backend, after all.  In what sort of
situation do catalog scans not strictly nest?

Thanks,
nm