On Wed, Oct 15, 2014 at 12:13 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > What is "timely service lock requests"? You got the lock before firing > off the background workers, you hold it till they're done.
If you want to run any non-trivial (read: useful) code in the background workers, it rapidly gets very hard to predict which relation locks they might need, and infeasible to hold them for the lifetime of the computation. For example, suppose we restrict background workers to running only operators found in btree opclasses. That's a far more draconian restriction than we'd like to have, but perhaps liveable in a pinch. But bttextcmp() uses PG_GETARG_TEXT_PP(), which means it may (or may not) need to lock the TOAST table; and it can indirectly call lookup_collation_cache() which does SearchSysCache1(COLLOID, ...) which may result in scanning pg_collation. And enum_cmp_internal() will do SearchSysCache1(ENUMOID, ...) which may result in scanning pg_enum. There's obviously a balance to be struck, here. It will never be safe to run just anything in a background worker, and we'll go crazy if we try to make that work. On the other hand, if there's essentially no code that can run in a background worker without extensive modification, we might as well not bother implementing parallelism in the first place. I admit that getting group locking is far from simple, but I also don't believe it's as complicated as previous projects like SSI, logical decoding, or LATERAL. -- 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