From: | Daniel Wood <hexexpert(at)comcast(dot)net> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: 'Invalid lp' during heap_xlog_delete |
Date: | 2019-11-18 18:49:36 |
Message-ID: | 281509101.330855.1574102977170@connect.xfinity.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> I'll try to look into that with lower page sizes for relation and WAL pages.
The page size is totally unrelated to this bug. When you repro the redo failure it is because the log record is being applied to an old page version. The correct newer page version never got written because of the truncate page invalidation. The cause is not a torn write.
> What's that?
Azure PostgreSQL on Windows has proprietary mechanisms in its filesystem to guarantee that a write is atomic.
- Dan
> On November 18, 2019 at 4:58 AM Michael Paquier < michael(at)paquier(dot)xyz mailto:michael(at)paquier(dot)xyz > wrote:
>
>
> On Thu, Nov 14, 2019 at 07:38:19PM -0800, Daniel Wood wrote:
>
> > > Sorry I missed one thing. Turn off full page writes.
> >
> > > Hmm. Linux FSes use typically 4kB pages. I'll try to look into that
> with lower page sizes for relation and WAL pages.
>
>
> > > I'm running in an env. with atomic 8K writes.
> >
> > > What's that?
> --
> Michael
>
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2019-11-18 20:08:06 | Re: segfault in geqo on experimental gcc animal |
Previous Message | Pavel Stehule | 2019-11-18 18:47:58 | Re: [HACKERS] proposal: schema variables |