Horton

Re: ALTER TABLE lock strength reduction patch is unsafe

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-21T13:40:16Z
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 Mon, Jun 20, 2011 at 6:55 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> I agree the scope for RELOID errors increased with my 9.1 patch. I'm
> now happy with the locking patch (attached), which significantly
> reduces the scope - back to the original error scope, in my testing.
>
> I tried to solve both, but I think that's a step too far given the timing.
>
> It seems likely that there will be objections to this patch. All I
> would say is that issuing a stream of ALTER TABLEs against the same
> table is not a common situation; if it were we would have seen more of
> the pre-existing bug. ALTER TABLE command encompasses many subcommands
> and we should evaluate each subcommand differently when we decide what
> to do.

Well, my principal objection is that I think heavyweight locking is an
excessively expensive solution to this problem.  I think the patch is
simple enough that I wouldn't object to applying it on those grounds
even at this late date, but I bet if we do some benchmarking on the
right workload we'll find a significant performance regression.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company