Re: ALTER TABLE lock strength reduction patch is unsafe - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: ALTER TABLE lock strength reduction patch is unsafe
Date
Msg-id CAOeZVifePi5ZcoRZPNO3jh=BkrfCYepQwDdgsa1RsSKUp9QEyA@mail.gmail.com
Whole thread Raw
In response to Re: ALTER TABLE lock strength reduction patch is unsafe  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: ALTER TABLE lock strength reduction patch is unsafe  (Simon Riggs <simon@2ndQuadrant.com>)
Re: ALTER TABLE lock strength reduction patch is unsafe  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers


Good points.

In most cases, DDL is applied manually after careful thought, so
people seldom dump at the same time they upgrade the database. This is
especially true for pg_dump since it captures the logical definition
of tables. So most people will be happy with the default locking, but
we could make the lock level optional.

Currently we use AccessShareLock. Locking out all DDL, even with this
patch applied would only require ShareUpdateExclusiveLock.

Looking at the code, it will take about an hour to add an option to
pg_dump that specifies the lock level used when dumping. I would be
happy to include that as part of this patch.

 
I think the use case for specifying multiple locks is pretty slim given that a ShareUpdateExclusiveLock is good enough mostly for everybody.

If its not the case, the user should be more careful about when he is scheduling backups to so that they dont conflict with DDL changes.

I am not too comfortable with exposing the locking type to the user. That may be just me though.

Regards,

Atri
--
Regards,
 
Atri
l'apprenant

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: jsonb and nested hstore
Next
From: Simon Riggs
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire