On Sat, 4 Sept 2021 at 20:28, Tom Lane wrote:
> We have two things that we need to worry about when considering
> reducing ALTER TABLE lock levels:
>
> 1. Is it semantically okay (which is what you claim above)?
>
> 2. Will onlooker processes see sufficiently-consistent catalog data
> if they
Simon Riggs writes:
> 897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
> level for CHECK constraints when allowing them to be NOT VALID.
> This is simple and safe, since check constraints are not used in
> planning until validated.
Unfortunately, just asserting that it's safe
On Thu, 15 Jul 2021 at 07:47, Simon Riggs wrote:
>
> On Sat, Jul 10, 2021 at 2:50 PM John Naylor
> wrote:
> > On Thu, Apr 22, 2021 at 8:01 AM Simon Riggs
> > wrote:
> > >
> > > 897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
> > > level for CHECK constraints when allowing
On Sat, Jul 10, 2021 at 2:50 PM John Naylor
wrote:
> On Thu, Apr 22, 2021 at 8:01 AM Simon Riggs
> wrote:
> >
> > 897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
> > level for CHECK constraints when allowing them to be NOT VALID.
> >
> > This is simple and safe, since check
On Thu, Apr 22, 2021 at 8:01 AM Simon Riggs
wrote:
>
> 897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
> level for CHECK constraints when allowing them to be NOT VALID.
>
> This is simple and safe, since check constraints are not used in
> planning until validated.
The patch
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Looks fine to me
The new status of this patch is: Ready for
897795240cfaaed724af2f53ed2c50c9862f951f forgot to reduce the lock
level for CHECK constraints when allowing them to be NOT VALID.
This is simple and safe, since check constraints are not used in
planning until validated.
--
Simon Riggshttp://www.EnterpriseDB.com/
