Re: Incorrect checksum in control file with pg_rewind test

Hi, just to clarify, it isn't pg_rewind related issue and can fire spontaneously. I don't have any strong scenario how to reproduce it, tests sometimes fired on our local CI, but as you can see on thread [1], where the same issue for frontends was discussed, it is very hard to reproduce and the

Re: Panic during xlog building with big values

Hi, Andy, thanks for your review! I've checked RecordTransactionCommit too, but I don't think it can fire similar error. Problem, that was described above, occurred because we used external column storage without compression and with REPLICA IDENTITY FULL. To be honest, it's degenerate case, t

Re: Preferred use of macro GetPGProcByNumber

Thanks for your comment,  I've attached patch version without procarray.c changes. Best regards Melnikov Maksim From a7112592352756a4b41789ab7f73cd546ac7633b Mon Sep 17 00:00:00 2001 From: Maksim Melnikov Date: Fri, 12 Sep 2025 15:17:39 +0300 Subject: [PATCH v2] Preferred use of macro GetPGPr

Preferred use of macro GetPGProcByNumber

Hello hackers, I've noticed some places where elements of ProcGlobal->allProcs are addressed directly via arr index. But in proc.h macros GetPGProcByNumber exist, that was added to get proc objects by index, so I suggest minor refactoring 'ProcGlobal->allProcs[index]' -> 'GetPGProcByNumber(inde

Incorrect checksum in control file with pg_rewind test

Hi, hackers! I've got test failure for pg_rewind tests and it seems we have read/write races for pg_control file. The test error is incorrect checksum in control file. Build was compiled with -DEXEC_BACKEND flag. # +++ tap check in src/bin/pg_rewind +++ Bailout called.  Further testing stopped

Re: Panic during xlog building with big values

Hi, forgot to exec pgindent for patch, so attach new version with indents fixes. Best regards, Maksim MelnikovFrom d218fdcdfc01642a01f488c6a01f55f10668f399 Mon Sep 17 00:00:00 2001 From: Maksim Melnikov Date: Thu, 14 Aug 2025 11:11:30 +0300 Subject: [PATCH v2] Pre-check potential XLogRecord ov

Re: Add 64-bit XIDs into PostgreSQL 15

Hi all, On 07.07.2025 11:17, Evgeny Voropaev wrote: Do-side: 1. Having page ABC with several tuples. 2. Starting to perform insertion of new tuple    2.1. In the case of an inappropriate xid_base, trying to fit base    2.1.1 Freezing and pruning tuples without further repairing fragmentation.  

Panic during xlog building with big values

Hello, during testing we found following issue when update records with big values. 2025-07-07 14:40:30.434 MSK [125435] PANIC:  oversized WAL record 2025-07-07 14:40:30.434 MSK [125435] DETAIL:  WAL record would be 1073742015 bytes (of maximum 1069547520 bytes); rmid 10 flags 64. tested commi

Re: sync_standbys_defined read/write race on startup

On 10.04.2025 12:15, Michael Paquier wrote: Hmm, yeah. Instead of last, it would be better to put it in second place perhaps, for clarity? That would be the same at the end, but we would be slightly more consistent with the past logic regarding the ordering. Does that look OK to you? Yes, f

Re: sync_standbys_defined read/write race on startup

On 10.04.2025 05:25, Michael Paquier wrote: Confirmed. One thing where it would be possible to make things work is to introduce some persistency of the injection points, say these are flushed at shutdown. We could do that without touching at the backend code and only in the module injection_p

Re: sync_standbys_defined read/write race on startup

Hi Michael, thanks for your answer. Test 041_checkpoint_at_promote.pl is really good example of using injection points, but anyway, I still don't see how injection points can help us here. In failed test case we started postgres, immediately open psql connection and commit prepared transaction. P

Re: sync_standbys_defined read/write race on startup

Hi everyone, thanks for your comments. I've just wanted to share little cosmetic fixes for previous patch. Best Regards, Maksim MelnikovFrom 748c5fe8efd4c6365f380f7f9bbeba5e91887ab4 Mon Sep 17 00:00:00 2001 From: Maksim Melnikov Date: Wed, 26 Mar 2025 16:44:09 +0300 Subject: [PATCH] Fix sync_sta

Re: sync_standbys_defined read/write race on startup

On 27.03.2025 01:13, Michael Paquier wrote: Tracking if the configuration has been properly loaded in WalSndCtlData makes sense here, but I am confused by the patch: you have defined SYNCSTANDBYSDEFINED but sync_standbys_defined never sets it. It may be simpler to use a separate boolean flag fo

sync_standbys_defined read/write race on startup

Hi, On my windows machine I've found unstable test, it fails very rarely, but anyway, sometimes it fails. src/test/recovery/t/009_twophase.pl #   Failed test 'Committed prepared transaction is visible to new snapshot in standby' #   at t/009_twophase.pl line 360. #  got: '0' # ex

Spinlock can be released twice in procsignal.c

Hi, it seems we can release spinlock twice in /src/backend/storage/ipc/procsignal.c file, method ProcSignalInit. void ProcSignalInit(bool cancel_key_valid, int32 cancel_key) {     ProcSignalSlot *slot;     uint64    barrier_generation; ...