| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Euler Taveira <euler(at)eulerto(dot)com> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Add a perl function in Cluster.pm to generate WAL |
| Date: | 2023-12-21 01:21:45 |
| Message-ID: | ZYOTKV1MV7gDYpCV@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 20, 2023 at 12:24:04AM -0300, Euler Taveira wrote:
> LGTM.
I was eyeing at 020_messages.pl and it has a pg_switch_wal() after a
transaction rollbacked. 020_archive_status.pl creates a table, does
one segment switch, then a checkpoint (table is used afterwards).
Perhaps these could be changed with the new routine, but it does not
seem like this improves the readability of the tests, either, contrary
to the ones updated here where a fake table is created to force some
records. What do you think?
We have a few more pg_switch_wal() calls, as well, but these rely on
WAL being already generated beforehand.
I have added a comment about pg_logical_emit_message() being in
non-transactional mode and the flush implied by pg_switch_wal() as
that's important, edited a bit the whole, then applied the patch.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2023-12-21 01:32:37 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
| Previous Message | John Naylor | 2023-12-21 01:19:44 | Re: [PoC] Improve dead tuple storage for lazy vacuum |