On Tue, Sep 09, 2025 at 04:07:45PM +0300, Kouber Saparev wrote:
> Yet again one of our replicas died. Should I file a bug report or
> something, what should we do in order to prevent it? Restart the database
> every month/week or so?...
I don't think we need another bug to report the same problem.
На пт, 12.09.2025 г. в 3:37 Michael Paquier написа:
> Okay, the bit about the cascading standby is a useful piece of
> information. Do you have some data about the relation reported in the
> error message this is choking on based on its OID? Is this actively
> used in read-only workloads, with
On Tue, Sep 16, 2025 at 02:45:03PM +0300, Kouber Saparev wrote:
> На пт, 12.09.2025 г. в 3:37 Michael Paquier написа:
>> With which process has this cascading standby been created?
>> Does the workload of the primary involve a high consumption of OIDs
>> for relations, say many temporary tables?
>
On Thu, Sep 11, 2025 at 04:35:01PM +0300, Kouber Saparev wrote:
> The pattern is the same, although I am not 100% sure that the same replica
> is having this - it is a cascaded streaming replica, i.e. a replica of
> another replica. Once we had this in October 2024, with version 15.4, then
> in Aug
На чт, 11.09.2025 г. в 2:28 Michael Paquier написа:
> As a start, are these failures only in the startup process? Has the
> startup process reached a consistent state when the problem happens
> because the replay code is too eager at removing the stats entries?
> Has it not reached a consistent
Yet again one of our replicas died. Should I file a bug report or
something, what should we do in order to prevent it? Restart the database
every month/week or so?...
2025-09-09 12:08:10.688 UTC,,,1510554,,67b3d8bc.170c9a,337,,2025-02-18
00:47:56 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entr
Indeed, nothing exotic about our replication.
As for the object 4169049057, I am not able to find it anywhere in the
catalogs. Perhaps it was something that was dropped in the meantime.
На чт, 7.08.2025 г. в 2:18 Michael Paquier написа:
> On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev
On Thu, Aug 07, 2025 at 08:35:17AM +, Bertrand Drouvot wrote:
> On Thu, Aug 07, 2025 at 04:17:29PM +0900, Michael Paquier wrote:
>> Yes, that could prove to be useful when debugging such issues. We do
>> not have a lot of information here.
>
> Yes, done in the attached.
Thanks. With the nex
Hi,
On Thu, Aug 07, 2025 at 04:17:29PM +0900, Michael Paquier wrote:
> On Thu, Aug 07, 2025 at 05:28:17AM +, Bertrand Drouvot wrote:
> > On Thu, Aug 07, 2025 at 08:18:26AM +0900, Michael Paquier wrote:
> >> On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote:
> >> You are close to w
On Thu, Aug 07, 2025 at 05:28:17AM +, Bertrand Drouvot wrote:
> On Thu, Aug 07, 2025 at 08:18:26AM +0900, Michael Paquier wrote:
>> On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote:
>> You are close to wraparound for this relation. Is that vanilla
>> streaming replication with he
Hi,
On Thu, Aug 07, 2025 at 08:18:26AM +0900, Michael Paquier wrote:
> On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote:
> > We just had the same sudden replica shutdown, this time with version 17.3.
> >
> > 2025-08-02 22:10:02.229 UTC,,,473966,,67b3d76c.73b6e,14,,2025-02-18
> > 00:
On Mon, Aug 04, 2025 at 01:00:35PM +0300, Kouber Saparev wrote:
> We just had the same sudden replica shutdown, this time with version 17.3.
>
> 2025-08-02 22:10:02.229 UTC,,,473966,,67b3d76c.73b6e,14,,2025-02-18
> 00:42:20 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entry already
> dropped: ki
We just had the same sudden replica shutdown, this time with version 17.3.
2025-08-02 22:10:02.229 UTC,,,473966,,67b3d76c.73b6e,14,,2025-02-18
00:42:20 UTC,8111/0,0,FATAL,XX000,"trying to drop stats entry already
dropped: kind=relation dboid=16420 objoid=4169049057 refcount=1","WAL
redo at 633
On Thu, Nov 14, 2024 at 10:07:41AM +, Bertrand Drouvot wrote:
> === 1
>
> Maybe use "generation" instead of generation in the comments (where it's not
> done,
> some comments do it already).
I've tweaked things to be more consistency, and applied that down to 15.
> === 2
>
> We could think
Hi,
On Thu, Nov 14, 2024 at 04:55:23PM +0900, Michael Paquier wrote:
> I've been going through this patch again, and the failures that could
> be seen because of such failures, like standbys failing in an
> unpredictible way is not cool, so I am planning to apply the attached
> down to 15 now that
On Thu, Oct 17, 2024 at 01:24:50PM +0900, Michael Paquier wrote:
>> Yeah, FWIW, we would be going from 32 bytes:
>>/* total size (bytes): 32 */
>>
>> to 40 bytes (with the patch applied):
>>/* total size (bytes): 40 */
>>
>> Due
On Wed, Oct 16, 2024 at 10:11:08AM +, Bertrand Drouvot wrote:
> Indeed, in pgstat_release_entry_ref(), we're doing:
>
> if (pg_atomic_fetch_sub_u32(&entry_ref->shared_entry->refcount, 1) == 1)
> .
> .
> shent = dshash_find(pgStatLocal.shared_hash,
> &entry_ref->sh
Hi,
On Wed, Oct 16, 2024 at 09:43:48AM +0900, Michael Paquier wrote:
> On Fri, Oct 11, 2024 at 08:18:58AM +, Bertrand Drouvot wrote:
> > On Fri, Oct 11, 2024 at 11:07:29AM +0300, Kouber Saparev wrote:
> >> Unfortunately not, we are running 15.4 and planning to upgrade very soon.
> >> Is the pa
On Fri, Oct 11, 2024 at 08:18:58AM +, Bertrand Drouvot wrote:
> On Fri, Oct 11, 2024 at 11:07:29AM +0300, Kouber Saparev wrote:
>> Unfortunately not, we are running 15.4 and planning to upgrade very soon.
>> Is the patch mentioned already merged in PostgreSQL 16?
>
> Yes, as of 16.4.
Right.
Hi,
On Fri, Oct 11, 2024 at 11:07:29AM +0300, Kouber Saparev wrote:
> На чт, 10.10.2024 г. в 17:42 Bertrand Drouvot
> написа:
>
> >
> > Does the error message looks like (added in [1]):
> >
> > "
> > trying to drop stats entry already dropped: kind=%s dboid=%u objoid=%u
> > refcount=%u",
> > "
>
На чт, 10.10.2024 г. в 17:42 Bertrand Drouvot
написа:
>
> Does the error message looks like (added in [1]):
>
> "
> trying to drop stats entry already dropped: kind=%s dboid=%u objoid=%u
> refcount=%u",
> "
>
> by any chance? If so, would you mind to share it?
>
> Regards,
>
> [1]: https://postgr
Hi,
On Thu, Oct 10, 2024 at 06:19:30AM +, Kouber Saparev wrote:
> Am I correct to believe this patch is fixing the "can only drop stats once"
> issue?
>
> It just happened to us, one of our streaming replicas decided to shut down.
Does the error message looks like (added in [1]):
"
trying
Am I correct to believe this patch is fixing the "can only drop stats once"
issue?
It just happened to us, one of our streaming replicas decided to shut down.
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&create,
> increment a counter
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, InvalidO
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 failu
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:
>
> TR
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(&entry_ref->shared_entry->refcount) ==
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(&entry_ref->shared_entry->refcount) ==
0"), File: "pgstat_shmem.c", Line: 56
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
0x1c
30 matches
Mail list logo
