On Fri, Oct 14, 2016 at 3:14 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Thu, Oct 13, 2016 at 6:33 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> If we agree that above is a problematic case, then some of the options >>> to solve it could be (a) Vacuum should not wait for a cleanup lock and >>> instead just give up and start again which I think is a bad idea (b) >>> don't allow to take lock of higher granularity after the scan is >>> suspended, not sure if that is feasible (c) document the above danger, >>> this sounds okay on the ground that nobody has reported the problem >>> till now > >> I don't think any of these sound particularly good. > > Note that it's a mistake to imagine that this is specific to indexes; > the same type of deadlock risk exists just when considering heap cleanup. > We've ameliorated the heap case quite a bit by recognizing situations > where it's okay to skip a page and move on, but it's not gone. > Unfortunately indexes don't get to decide that deletion is optional. > > I was about to suggest that maybe we didn't need cleanup locks in btree > indexes anymore now that SnapshotNow is gone, >
Wouldn't it still be a problem for SnapshotAny? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
