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
16 matches
Mail list logo
