On Sat, Nov 1, 2014 at 5:38 PM, Andres Freund <and...@2ndquadrant.com> wrote:
> That's just a mislabeled function. It's obviously not parallel safe at
> all. I see absolutely no problem with erroring out.

I disagree.  It's entirely parallel-safe, as long as you don't
arbitrarily decide to have the lock manager break it.

>> 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.

RelationSetIndexList() is only used inside REINDEX, which I think
illustrates my point that it's mostly DDL we need to be worried about.

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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to