Re: [PATCH] Fix vacuum_delay_point happening inside lock - Mailing list pgsql-hackers

From Kevin Rocker
Subject Re: [PATCH] Fix vacuum_delay_point happening inside lock
Date
Msg-id d6dd6d5d-a257-4c2b-8f82-cff80ea2707e@app.fastmail.com
Whole thread
In response to Re: [PATCH] Fix vacuum_delay_point happening inside lock  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
Attached is v5, which takes Tom's suggestion for a spin.

0002 adds asserts at the top of vacuum_delay_point(). I picked separate asserts instead of
INTERRUPTS_CAN_BE_PROCESSED(),just like Neil.
 

Running check-world with that assert tripped on hashbucketcleanup().

Since hashbucketcleanup is called assuming a lock is in place, no place in it is safe. Instead, I moved the delay to
theper-bucket loop. It's a switch from a per-page delay to a per-bucket delay, but the per-page delay we're removing
wasn'tvalid anyway.
 

Andrey, let me know if you have concerns about lock chaining/cleanup with this approach. There shouldn't be any issues
sincewe're outside the locked function entirely.
 

With both patches applied, check-world passes with assertions enabled, and each patch passes on its own.

- Kevin Rocker
Attachment

pgsql-hackers by date:

Previous
From: Andrey Borodin
Date:
Subject: Re: [PATCH]Fix pg_xact corruption from subtransaction abort after subcommit
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Remove redundant ORDER BY from COUNT aggregates