| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Cc: | Greg Burd <greg(at)burd(dot)me>, Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support for 8-byte TOAST values, round two |
| Date: | 2026-09-16 23:50:34 |
| Message-ID: | aqsrSswQHhLoksQa@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 16, 2026 at 10:48:35AM -0700, Bharath Rupireddy wrote:
> While I agree with the general idea that having a way to enforce the
> initial OID after an initdb is a good one, just curious, why is this
> specific to the pg_resetwal being added to the recovery test in
> 006_logical_decoding.pl? Or is the intention to not exercise this test
> always? I'm still not clear on why we need to solve this problem here.
The duplication at SQL level in the TAP tests that all these
pg_resetwal commands create is what drives me toward a more general
solution as being suited. We want to check for UNIT32_MAX overflows
in a general way than just something inside one test. Using a
pg_resetwal command in the pg_upgrade test feels like a good
investment: we run the main regression test suite all the time there.
Instead of a PG_TEST_EXTRA variable another set of ideas one I can
think of out-of-the-box is something that would be based on a compile
flag. For example a development GUC?
Or maybe just a few feature in itself, like an initdb option that
forces an initial OID after bootstrap in the control file? Then link
it to a new PG_TEST_EXTRA mode? Having something that could be
directly used by the buildfarm on an opt-in basis would be kind of
nice.
So, I'd rather have a more general mechanism in place rather than
finishing with 250 pg_resetwal commands sprinkled across the tree that
duplicate SQL tests we have in the script in 10 years.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2026-09-16 23:50:59 | Re: POC: Carefully exposing information without authentication |
| Previous Message | Nikolay Samokhvalov | 2026-09-16 23:24:26 | Re: [PG19][PATCH] Make postgres_fdw statistics import atomic |