Re: pgsql: Don't trust unvalidated xl_tot_len.

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

In response to

Browse pgsql-committers by date

  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.

Browse pgsql-hackers by date

  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.