On 4/3/22 22:10, Peter Geoghegan wrote:
> On Sun, Apr 3, 2022 at 11:53 AM Andres Freund wrote:
>> We've had bugs in pg_upgrade where post-upgrade xid horizons weren't
>> correctly
>> set. We've had bugs were indexes were corrupted during replay.
>>
>> The latter can be caught by
On Mon, Apr 04, 2022 at 05:39:58PM -0700, Andres Freund wrote:
> On my workstation it takes about 2.39s to run pg_amcheck on a regression
> database with all thoroughness options enabled. With -j4 it's 0.62s.
>
> Without more thorough checking it's 1.24s and 0.30s with -j4.
Okay. That sounds
Hi,
On 2022-04-05 08:46:06 +0900, Michael Paquier wrote:
> On Sun, Apr 03, 2022 at 11:53:03AM -0700, Andres Freund wrote:
> > It seems $subject would have a chance of catching some of these bugs, as
> > well
> > as exposing amcheck to a database with a bit more varied content?
>
> Makes sense
On Sun, Apr 03, 2022 at 11:53:03AM -0700, Andres Freund wrote:
> It seems $subject would have a chance of catching some of these bugs, as well
> as exposing amcheck to a database with a bit more varied content?
Makes sense to me to extend that.
> Depending on the cost it might make sense to do
On Mon, Apr 4, 2022 at 2:16 PM Andres Freund wrote:
> On 2022-04-04 10:02:37 -0400, Robert Haas wrote:
> > It does a good job, I think, checking all the things that a human being
> > could potentially spot just by looking at an individual page.
>
> I think there's a few more things that'd be good
Hi,
On 2022-04-04 10:02:37 -0400, Robert Haas wrote:
> It does a good job, I think, checking all the things that a human being
> could potentially spot just by looking at an individual page.
I think there's a few more things that'd be good to check. For example amcheck
doesn't verify that HOT
> On Apr 4, 2022, at 9:27 AM, Peter Geoghegan wrote:
>
> I'd really like it if amcheck had HOT chain verification. That's the
> other area where catching bugs passively with assertions and whatnot
> is clearly not good enough.
I agree, and was hoping to get around to this in the postgres 15
On Mon, Apr 4, 2022 at 7:02 AM Robert Haas wrote:
> Yeah, I was very excited about verify_heapam(). There is a lot more
> stuff that we could check, but a lot of those things would be much
> more expensive to check.
If anything I understated the value of verify_heapam() with this kind
of work
On Sun, Apr 3, 2022 at 10:10 PM Peter Geoghegan wrote:
> I meant to tell the authors of verify_heapam() (also CC'd) that it
> really helped with my recent VACUUM project. While the assertions that
> I wrote in vacuumlazy.c might catch certain bugs like this,
> verify_heapam() is much more
On Sun, Apr 3, 2022 at 11:53 AM Andres Freund wrote:
> We've had bugs in pg_upgrade where post-upgrade xid horizons weren't correctly
> set. We've had bugs were indexes were corrupted during replay.
>
> The latter can be caught by wal_consistency_checking - but that's pretty
> expensive.
>
> It
Hi,
We've had bugs in pg_upgrade where post-upgrade xid horizons weren't correctly
set. We've had bugs were indexes were corrupted during replay.
The latter can be caught by wal_consistency_checking - but that's pretty
expensive.
It seems $subject would have a chance of catching some of these
11 matches
Mail list logo
