On 2014-11-01 16:59:34 -0400, Robert Haas wrote:
> > I completely fail to see why you'd generally think it's safe for two
> > backends to hold the same self conflicting lock. Yes, within carefully
> > restricted sections of code that might be doable. But I don't think you
> > can fully enforce that. People *will* mark their own functions at
> > parallel safe. And do stupid stuff. That shouldn't cause
> > segfaults/exploits/low level data corruption/.. as long as it's done
> > from !C functions.
>
> I agree that people will mark their own functions as parallel-safe,
> and I also agree that shouldn't cause segfaults, exploits, or
> low-level data corruption. Clearly, we'll need to impose a bunch of
> restrictions to achieve that.
> But if you put a LOCK TABLE statement
> in an SQL function, it won't conflict with other locking request made
> by the same or another function elsewhere in the same transaction;
> surely you don't want that behavior to be *different* in parallel
> mode. That would be a blatant, user-visible behavior difference
> justified by ... nothing at all.
That's just a mislabeled function. It's obviously not parallel safe at
all. I see absolutely no problem with erroring out.
> There's no hazard there. Where you
> start getting into crash/exploit/data corruption territory is when you
> are talking about DDL operations that change the physical structure of
> the table. That's why we have stuff like CheckTableNotInUse() to
> verify that, for example, there are no old cursors around that are
> still expecting the old relfilenode and tuple descriptor to be valid.
It's not just fully structural changes although they are a concern.
It's also that we've amassed a number of hacks to deal with local state
that just won't be nicely transported. What's with stuff like
RelationSetIndexList() (which is infrequently enough used to not be a
big problem in practice...)? If we only allow parallel access while
independent backends could acquire the relevant we can rely on us
already having taken care about the concurrency hazards. Otherwise not.
And before you say that'd prohibit a number of useful things - yes, it
might. But e.g. CREATE INDEX can still be parallelized. The primary
backend takes a Exclusive/ShareUpdateExclusive (depending on
CONCURRENTLY), workers just a AccessShare.
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services