On Fri, Jun 14, 2024 at 02:31:37PM +0900, Michael Paquier wrote:
> I don't think that this is going to fly far except if we introduce a
> concept of "generation" or "age" in the stats entries. The idea is
> simple: when a stats entry is reinitialized because of a drop,
> increment a counter to
On Wed, Jun 12, 2024 at 08:00:00PM +0300, Alexander Lakhin wrote:
> With extra logging added, I see the following events happening:
> 1) pgstat_rc_1.setup calls pgstat_create_replslot(), gets
> ReplicationSlotIndex(slot) = 0 and calls
> pgstat_get_entry_ref_locked(PGSTAT_KIND_REPLSLOT,
Hello hackers,
20.03.2023 09:10, Peter Smith wrote:
Using this I was also able to reproduce the problem. But test failures
were rare. The make check-world seemed OK, and indeed the
test_decoding tests would also appear to PASS around 14 out of 15
times.
I've stumbled upon this assertion
On Sun, Mar 19, 2023 at 2:00 AM Alexander Lakhin wrote:
>
> Hi,
>
> 18.03.2023 07:26, Tom Lane wrote:
>
> Amit Kapila writes:
>
> Peter Smith has recently reported a BF failure [1]. AFAICS, the call
> stack of failure [2] is as follows:
>
> Note the assertion report a few lines further up:
>
>
Hi,
18.03.2023 07:26, Tom Lane wrote:
Amit Kapila writes:
Peter Smith has recently reported a BF failure [1]. AFAICS, the call
stack of failure [2] is as follows:
Note the assertion report a few lines further up:
TRAP: failed Assert("pg_atomic_read_u32(_ref->shared_entry->refcount) == 0"),
Amit Kapila writes:
> Peter Smith has recently reported a BF failure [1]. AFAICS, the call
> stack of failure [2] is as follows:
Note the assertion report a few lines further up:
TRAP: failed Assert("pg_atomic_read_u32(_ref->shared_entry->refcount) ==
0"), File: "pgstat_shmem.c", Line: 560,
Hi,
Peter Smith has recently reported a BF failure [1]. AFAICS, the call
stack of failure [2] is as follows:
0x1e66644 at postgres
0x1d0143c at postgres
0x1d02534 at postgres
0x1cfb120 at postgres
0x1cfd590 at postgres
0x1cfbfc0 at postgres
0x1ca7b08 at postgres
0x1ca7c74 at postgres
