On Thu, Sep 15, 2016 at 7:21 AM, Masahiko Sawada <sawada.m...@gmail.com> wrote: > I'm implementing this patch but I need to resolve the problem > regarding lock for extension by multiple parallel workers. > In parallel vacuum, multiple workers could try to acquire the > exclusive lock for extension on same relation. > Since acquiring the exclusive lock for extension by multiple workers > is regarded as locking from same locking group, multiple workers > extend fsm or vm at the same time and end up with error. > I thought that it might be involved with parallel update operation, so > I'd like to discuss about this in advance.
Hmm, yeah. This is one of the reasons why parallel queries currently need to be entirely read-only. I think there's a decent argument that the relation extension lock mechanism should be entirely redesigned: the current system is neither particularly fast nor particularly elegant, and some of the services that the heavyweight lock manager provides, such as deadlock detection, are not relevant for relation extension locks. I'm not sure if we should try to fix that right away or come up with some special-purpose hack for vacuum, such as having backends use condition variables to take turns calling visibilitymap_set(). -- 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
