Re: ALTER TABLE lock strength reduction patch is unsafe
Alvaro Herrera <alvherre@commandprompt.com>
From: Alvaro Herrera <alvherre@commandprompt.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-21T17:13:08Z
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 →
-
Add bytea_agg, parallel to string_agg.
- d5448c7d31b5 9.2.0 cited
-
Fix ALTER TABLE ONLY .. DROP CONSTRAINT.
- c0f03aae0469 9.2.0 cited
Excerpts from Robert Haas's message of mar jun 21 09:40:16 -0400 2011: > 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. Yeah, taking a hw lock at each relcache item build is likely to be prohibitively expensive. Heck, relation extension is expensive already in some loads. (I'm guessing that things will tank when there's a relcache reset). Still, this seems to be an overall better approach to the problem than what's been proposed elsewhere. Maybe we can do something with a map of relations that are protected by a bunch of lwlocks instead. (We could use that for relation extension too; that'd rock.) The patch may be simple, but is it complete? I think you need to have lock acquisition on create rule and create index too. Right now it only has locks on trigger stuff and alter table. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support