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
