From: | David Christensen <david(dot)christensen(at)crunchydata(dot)com> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: [PATCH] add relation and block-level filtering to pg_waldump |
Date: | 2022-02-25 15:35:03 |
Message-ID: | CAOxo6XL+BRZhswS2XoOgiQQC1B-Acr0vC8GZC-4uNjWonfhK_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 25, 2022 at 7:08 AM Japin Li <japinli(at)hotmail(dot)com> wrote:
>
> On Fri, 25 Feb 2022 at 20:48, David Christensen <
> david(dot)christensen(at)crunchydata(dot)com> wrote:
> >> Cool. I think we can report an error instead of reading wal files,
> >> if the tablespace, database, or relation is invalid. Does there any
> >> WAL record that has invalid tablespace, database, or relation OID?
> >
> > The only sort of validity check we could do here is range checking for
> the underlying data types
> > (which we certainly could/should add if it’s known to never be valid for
> the underlying types);
>
> The invalid OID I said here is such as negative number and zero, for those
> parameters, we do not need to read the WAL files, since it always invalid.
>
Agreed. Can add some additional range validation to the parsed values.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2022-02-25 15:40:01 | Re: Expose JIT counters/timing in pg_stat_statements |
Previous Message | David Christensen | 2022-02-25 15:33:59 | Re: [PATCH] add relation and block-level filtering to pg_waldump |