On Sun, Nov 03, 2024 at 10:29:25AM -0800, Noah Misch wrote:
> On Fri, Nov 01, 2024 at 04:38:29PM -0700, Noah Misch wrote:
> > This was a near miss to having a worst-in-years regression in a minor
> > release,
> > so I'm proposing this sequence:
> >
> > - Revert from non-master branches commits 8e
On Sun, Nov 03, 2024 at 10:29:25AM -0800, Noah Misch wrote:
> Pushed as 0bada39.
>
> Buildfarm member hornet REL_15_STABLE was in the same hang. Other buildfarm
> runs 2024-10-25T13:51:02Z - 2024-11-02T16:04:56Z may hang the same way. It's
> early to make a comprehensive list of hung buildfarm m
On Fri, Nov 01, 2024 at 04:38:29PM -0700, Noah Misch wrote:
> This was a near miss to having a worst-in-years regression in a minor release,
> so I'm proposing this sequence:
>
> - Revert from non-master branches commits 8e7e672 (inplace180, "WAL-log
> inplace update before revealing it to other
On Thu, Oct 31, 2024 at 09:20:52PM -0700, Noah Misch wrote:
> Here, one of the autovacuum workers had the guilty stack trace, appearing at
> the end of this message. heap_inplace_update_and_unlock() calls
> CacheInvalidateHeapTupleInplace() while holding BUFFER_LOCK_EXCLUSIVE on a
> buffer of pg_c
On Thu, Oct 31, 2024 at 01:01:39PM -0700, Noah Misch wrote:
> On Thu, Oct 31, 2024 at 05:00:02PM +0300, Alexander Lakhin wrote:
> > I've accidentally discovered an incorrect behaviour caused by commit
> > 4eac5a1fa. Running this script:
>
> Thanks. This looks important.
>
> > parallel -j40 --lin
On Thu, Oct 31, 2024 at 05:00:02PM +0300, Alexander Lakhin wrote:
> I've accidentally discovered an incorrect behaviour caused by commit
> 4eac5a1fa. Running this script:
Thanks. This looks important.
> parallel -j40 --linebuffer --tag .../reproi.sh ::: `seq 40`
This didn't reproduce it for me,
Hello Noah,
31.10.2024 04:39, Noah Misch wrote:
I had pushed this during the indicated week, before your mail. Reverting it
is an option. Let's see if more opinions arrive.
I've accidentally discovered an incorrect behaviour caused by commit
4eac5a1fa. Running this script:
for ((j=1; j<=100;
On Mon, Oct 28, 2024 at 02:27:03PM +0530, Nitin Motiani wrote:
> On Thu, Oct 24, 2024 at 8:24 AM Noah Misch wrote:
> > With the releases wrapping in 2.5 weeks, I'm ambivalent about pushing this
> > before the release or after. Pushing before means fewer occurrences of
> > corruption, but pushing
On Thu, Oct 24, 2024 at 8:24 AM Noah Misch wrote:
>
> With the releases wrapping in 2.5 weeks, I'm ambivalent about pushing this
> before the release or after. Pushing before means fewer occurrences of
> corruption, but pushing after gives more bake time to discover these changes
> were defective
On Mon, Oct 14, 2024 at 3:15 PM Nitin Motiani wrote:
>
> On Sun, Oct 13, 2024 at 6:15 AM Noah Misch wrote:
> >
> > On Sat, Oct 12, 2024 at 06:05:06PM +0530, Nitin Motiani wrote:
> > > 1. In heap_inplace_update_and_unlock, currently both buffer and tuple
> > > are unlocked outside the critical sec
On Sun, Oct 13, 2024 at 6:15 AM Noah Misch wrote:
>
> On Sat, Oct 12, 2024 at 06:05:06PM +0530, Nitin Motiani wrote:
> > 1. In heap_inplace_update_and_unlock, currently both buffer and tuple
> > are unlocked outside the critical section. Why do we have to move the
> > buffer unlock within the crit
On Sat, Oct 12, 2024 at 06:05:06PM +0530, Nitin Motiani wrote:
> 1. In heap_inplace_update_and_unlock, currently both buffer and tuple
> are unlocked outside the critical section. Why do we have to move the
> buffer unlock within the critical section here? My guess is that it
> needs to be unlocked
On Sat, Oct 12, 2024 at 5:47 PM Noah Misch wrote:
>
> Rebased.
Hi,
I have a couple of questions :
1. In heap_inplace_update_and_unlock, currently both buffer and tuple
are unlocked outside the critical section. Why do we have to move the
buffer unlock within the critical section here? My guess
Rebased.
Author: Noah Misch
Commit: Noah Misch
For inplace update, send nontransactional invalidations.
The inplace update survives ROLLBACK. The inval didn't, so another
backend's DDL could then update the row without incorporating the
inplace update. In the test
On Tue, Jun 18, 2024 at 08:23:49AM -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> > On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah M
On Tue, Jun 18, 2024 at 08:23:49AM -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> > On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > > That inplace150 patch turned out to be unnecessary. Contrary to the
> > > "noncritical resource releasing" comment
On Mon, Jun 17, 2024 at 04:58:54PM -0700, Noah Misch wrote:
> attached v2 patch stack.
Rebased. This applies on top of three patches from
https://postgr.es/m/20240629024251.03.nmi...@google.com. I'm attaching those
to placate cfbot, but this thread is for review of the last patch only.
Author:
On Tue, Jun 18, 2024 at 08:23:49AM -0700, Noah Misch wrote:
> On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> > On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah M
On Mon, Jun 17, 2024 at 06:57:30PM -0700, Andres Freund wrote:
> On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> > On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > > > https://postgr.es/m/20240512232923.aa.nmi...@goo
Hi,
On 2024-06-17 16:58:54 -0700, Noah Misch wrote:
> On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> > On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > > https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> > > > Separable, nontrivial things not fixed in t
On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> > https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> > > Separable, nontrivial things not fixed in the attached patch stack:
> > >
> > > - Inplace update uses t
On Sat, Jun 15, 2024 at 03:37:18PM -0700, Noah Misch wrote:
> I'm attaching the implementation.
I'm withdrawing inplace150-inval-durability-atcommit-v1.patch, having found
two major problems so far:
1. It sends transactional invalidation messages before
ProcArrayEndTransaction(), so other back
On Wed, May 22, 2024 at 05:05:48PM -0700, Noah Misch wrote:
> https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> > Separable, nontrivial things not fixed in the attached patch stack:
> >
> > - Inplace update uses transactional CacheInvalidateHeapTuple(). ROLLBACK of
> > CREATE IND
https://postgr.es/m/20240512232923.aa.nmi...@google.com wrote:
> Separable, nontrivial things not fixed in the attached patch stack:
>
> - Inplace update uses transactional CacheInvalidateHeapTuple(). ROLLBACK of
> CREATE INDEX wrongly discards the inval, leading to the relhasindex=t loss
> s
24 matches
Mail list logo
