On Wed, Nov 30, 2016 at 11:38 AM, Andrew Borodin <boro...@octonica.com> wrote: > This scan acquires cleanup lock on root of scan (not necessarily root > of posting tree). Cleanup lock ensures no inserts are inside subtree. > Scan traverses subtree DF taking exclusive locks from left to right. > For any page being deleted all leftmost pages were locked and unlocked > before. New reads cannot enter subtree, all old readscans were > excluded by lock\unlock. Thus there shall not be deadlocks with > ginStepRight(). > > We get lock on page being deleted, then on a left page. > ginStepRight() takes lock on left page, than on right page. But it’s > presence is excluded by cleanup lock and DFS scan with locks of upper > and left parts of tree. > > Thank you for reading this. Concurrency bothers me a lot. If you see > that anything is wrong or suspicious, please do not hesitate to post > your thoughts.
I don't know much about GIN, but this seems like an interesting improvement. I hope somebody who knows more about GIN will step up to review it in depth. -- 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