On Fri, Jan 27, 2012 at 11:53 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > If the master process keeps the locks it acquires in the beginning, you > could fall back to dumping those tables where the child lock fails using the > master connection.
Hmm, that's a thought. Another idea I just had is to allow a transaction that has imported a snapshot to jump the queue when attempting to acquire a lock that the backend from which the snapshot was imported already holds. We don't want to allow queue-jumping in general because there are numerous places in the code where we rely on the current behavior to avoid starving strong lockers, but it seems like it might be reasonable to allow it in this special case. -- 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
