From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ALTER TABLE lock strength reduction patch is unsafe |
Date: | 2011-06-21 17:13:08 |
Message-ID: | 1308675968-sup-3892@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)2ndquadrant(dot)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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | David Fetter | 2011-06-21 17:52:38 | Re: Table Partitioning |
Previous Message | Robert Haas | 2011-06-21 17:07:17 | Re: Table Partitioning |