From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Christoph Berg <myon(at)debian(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: pgsql: Don't trust unvalidated xl_tot_len. |
Date: | 2023-11-12 00:22:20 |
Message-ID: | ZVAavEe8DdyyJEN1@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
On Sun, Nov 12, 2023 at 12:17:54PM +1300, Thomas Munro wrote:
> No opinion on potential advantages to other approaches, but I don't
> see why this way shouldn't be expected to work. So I hope you can
> drop that diff.
Another thing that could be done in stable branches is just to switch
039_end_of_wal.pl to hardcoded values for $XLP_PAGE_MAGIC and
$XLP_FIRST_IS_CONTRECORD. This is not going to change in a released
version anyway, so there's no real maintenance cost.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2023-11-12 01:07:09 | pgsql: Fix inconsistencies for queries on pg_class in type_sanity.sql |
Previous Message | Thomas Munro | 2023-11-11 23:17:54 | Re: pgsql: Don't trust unvalidated xl_tot_len. |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-11-12 01:00:14 | Re: autovectorize page checksum code included elsewhere |
Previous Message | Thomas Munro | 2023-11-11 23:17:54 | Re: pgsql: Don't trust unvalidated xl_tot_len. |