From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: verify_heapam for sequences? |
Date: | 2021-09-28 14:05:40 |
Message-ID: | 98911a2a-a5e4-8c00-643b-3c89629a248c@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 30.08.21 21:00, Mark Dilger wrote:
> The attached patch changes both contrib/amcheck/ and src/bin/pg_amcheck/ to allow checking sequences. In both cases, the changes required are fairly minor, though they both entail some documentation changes.
>
> It seems fairly straightforward that if a user calls verify_heapam() on a sequence, then the new behavior is what they want. It is not quite so clear for pg_amcheck.
>
> In pg_amcheck, the command-line arguments allow discriminating between tables and indexes with materialized views quietly treated as tables (which, of course, they are.) In v14, sequences were not treated as tables, nor checked at all. In this new patch, sequences are quietly treated the same way as tables. By "quietly", I mean there are no command-line switches to specifically filter them in or out separately from filtering ordinary tables.
>
> This is a user-facing behavioral change, and the user might not be imagining sequences specifically when specifying a table name pattern that matches both tables and sequences. Do you see any problem with that? It was already true that materialized views matching a table name pattern would be checked, so this new behavior is not entirely out of line with the old behavior.
>
> The new behavior is documented, and since I'm updating the docs, I made the behavior with respect to materialized views more explicit.
committed
From | Date | Subject | |
---|---|---|---|
Next Message | Antonin Houska | 2021-09-28 14:08:27 | Re: POC: Cleaning up orphaned files using undo logs |
Previous Message | Andrew Dunstan | 2021-09-28 14:01:19 | Re: Fixing WAL instability in various TAP tests |