Re: ALTER TABLE lock strength reduction patch is unsafe
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2011-06-20T22:55:35Z
Lists: pgsql-hackers
Attachments
- relation_definition_lock.v3.patch (application/octet-stream)
On Mon, Jun 20, 2011 at 10:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Sun, Jun 19, 2011 at 5:13 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> We scan pg_class in two ways: to rebuild a relcache entry based on a >>> relation's oid (easy fix). We also scan pg_class to resolve the name >>> to oid mapping. The name to oid mapping is performed *without* a lock >>> on the relation, since we don't know which relation to lock. So the >>> name lookup can fail if we are in the middle of a pg_class update. >>> This is an existing potential bug in Postgres unrelated to my patch. > >> If this is a pre-existing bug, then it's not clear to me why we need >> to do anything about it at all right now. > > Yeah. This behavior has been there since day zero, and there have been > very few complaints about it. But note that there's only a risk for > pg_class updates, not any other catalog, and there is exactly one kind > of failure with very predictable consequences. I agree we shouldn't do anything about the name lookups for 9.1 That is SearchCatCache using RELNAMENSP lookups, to be precise, as well as triggers and few other similar call types. > The ALTER TABLE patch > has greatly expanded the scope of the issue, and that *is* a regression > compared to prior releases. 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. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services