On 1 September 2016 at 21:28, Simon Riggs <si...@2ndquadrant.com> wrote:
> So the only way to handle multiple locks is to do this roughly the way > Rod suggests. I've just been reading the VACUUM code and it turns out that we already use Rod's mechanism internally. So on that basis it seems fine to support this as a useful user-level feature. If there is a better way of doing it, then that can be added later. My proposed changes to this patch are these 1. Rename this WAIT PATIENTLY, which is IMHO a better description of what is being requested. Bikeshedding welcome. 2. Introduce a new API call LockTablePatiently() that returns bool. So its usage is similar to ConditionalLockTable(), the only difference is you supply some other wait parameters with it. This isolates the internal mechanism from the usage, so allows us to more easily support any fancy new way of doing this we think of later. 3. Use LockTablePatiently() within lockcmds.c where appropriate 4. Replace the code for waiting in VACUUM with the new call to LockTablePatiently() So I see this as 2 patches: 1) new API and make VACUUM use new API, 2) Rod's LOCK TABLE patch First patch attached, requires also lock by Oid. If we agree, Rod, please update your patch to match? (I pushed this back to next CF, but we can still go ahead if we complete) Comments? -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
patientLockTable.v1.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
