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 loo
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 do
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 the
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 co
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 al
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
