On Thu, Dec 05, 2024 at 07:11:54AM +, Bertrand Drouvot wrote:
> Yeah that seems the right thing to do for me too.
Thanks for the review. I've looked a bit more at the other paths
handling dropped entries and they should be fine, created a TAP test
that's able to check the scenario sent by Ant
Hi,
On Thu, Dec 05, 2024 at 01:26:38PM +0900, Michael Paquier wrote:
> On Wed, Dec 04, 2024 at 03:20:03PM +, Bertrand Drouvot wrote:
> > I need to think more about it but it seems to me that those values make
> > sense,
> > so maybe we should drop the entry for this particular case (shmem_exi
On Wed, Dec 04, 2024 at 03:20:03PM +, Bertrand Drouvot wrote:
> I need to think more about it but it seems to me that those values make sense,
> so maybe we should drop the entry for this particular case (shmem_exit()).
The values reported in the central hash table make sense to me. What
does
Hi,
On Wed, Dec 04, 2024 at 03:45:13AM +0300, Anton A. Melnikov wrote:
> Hi!
>
> b36fbd9f8d message says that inconsistency may still be possible because
> statistics are not completely consistent for a single scan of
> pg_stat_replication_slots under concurrent replication slot drop or
> creatio
Hi!
b36fbd9f8d message says that inconsistency may still be possible because
statistics are not completely consistent for a single scan of
pg_stat_replication_slots under concurrent replication slot drop or
creation activity.
Seems there is a reproduction of such a case via isolation test.
Pleas
On Tue, Apr 02, 2024 at 03:18:24PM -0400, Tom Lane wrote:
> I've closed the CF entry for this [1] as committed. Please re-open
> it if there was something left to do here.
>
> [1] https://commitfest.postgresql.org/47/4878/
Thanks, I was not aware of this one.
--
Michael
signature.asc
Descripti
Michael Paquier writes:
> On Fri, Mar 08, 2024 at 07:46:26PM +0900, Michael Paquier wrote:
>> Sounds good to me.
> I've applied the patch of this thread as b36fbd9f8da1, though I did
> not see a huge point in backpatching as at the end this is just a
> consistency improvement.
I've closed the CF
On Fri, Mar 08, 2024 at 07:46:26PM +0900, Michael Paquier wrote:
> Sounds good to me.
I've applied the patch of this thread as b36fbd9f8da1, though I did
not see a huge point in backpatching as at the end this is just a
consistency improvement.
--
Michael
signature.asc
Description: PGP signature
On Fri, Mar 08, 2024 at 10:26:21AM +, Bertrand Drouvot wrote:
> Yeah, good point: I'll create a dedicated patch for that.
Sounds good to me.
> Note that currently pgstat_drop_replslot() would not satisfy this new Assert
> when being called from InvalidatePossiblyObsoleteSlot(). I think this c
Hi,
On Thu, Mar 07, 2024 at 02:17:53PM +0900, Michael Paquier wrote:
> On Wed, Mar 06, 2024 at 09:05:59AM +, Bertrand Drouvot wrote:
> > Yeah, all of the above done in v3 attached.
>
> In passing.. pgstat_create_replslot() and pgstat_drop_replslot() rely
> on the assumption that the LWLock R
On Thu, Mar 07, 2024 at 11:30:55AM +0530, shveta malik wrote:
> It slightly improves the chances. pgstat_fetch_replslot is only
> called from pg_stat_get_replication_slot(), I thought it might be
> better to acquire lock before we call pgstat_fetch_replslot and
> release once we are done copying t
On Thu, Mar 7, 2024 at 11:12 AM Michael Paquier wrote:
>
> Yeah, it is possible that what you retrieve from
> pgstat_fetch_replslot() does not refer exactly to the slot's content
> under concurrent activity, but you cannot protect a single scan of
> pg_stat_replication_slots as of an effect of it
On Thu, Mar 07, 2024 at 10:57:28AM +0530, shveta malik wrote:
> --It can happen in a small window in pg_stat_get_replication_slot()
> when we are consuming the return values of pgstat_fetch_replslot
> (using slotent).
Yeah, it is possible that what you retrieve from
pgstat_fetch_replslot() does no
On Wed, Mar 6, 2024 at 2:36 PM Bertrand Drouvot
wrote:
>
> Hi,
>
> On Wed, Mar 06, 2024 at 10:24:46AM +0530, shveta malik wrote:
> > On Tue, Mar 5, 2024 at 6:52 PM Bertrand Drouvot
> > wrote:
> > Thanks. Can we try to get rid of multiple LwLockRelease in
> > pgstat_reset_replslot(). Is this any
On Wed, Mar 06, 2024 at 09:05:59AM +, Bertrand Drouvot wrote:
> Yeah, all of the above done in v3 attached.
Interesting, so this relies on the slot index to ensure the unicity of
the stat entries. And if the entry pointing to this ID is updated
we may refer to just incorrect data.
The incons
Hi,
On Wed, Mar 06, 2024 at 10:24:46AM +0530, shveta malik wrote:
> On Tue, Mar 5, 2024 at 6:52 PM Bertrand Drouvot
> wrote:
> Thanks. Can we try to get rid of multiple LwLockRelease in
> pgstat_reset_replslot(). Is this any better?
>
> /*
> -* Nothing to do for physical slots a
On Tue, Mar 5, 2024 at 6:52 PM Bertrand Drouvot
wrote:
>
> > /*
> > * Nothing to do for physical slots as we collect stats only for logical
> > * slots.
> > */
> > if (SlotIsPhysical(slot))
> > return;
>
> D'oh! Thanks! Fixed in v2 shared up-thread.
Thanks. Can we try to get rid of multiple LwLo
Hi,
On Tue, Mar 05, 2024 at 02:19:19PM +0530, shveta malik wrote:
> On Tue, Mar 5, 2024 at 1:25 PM Heikki Linnakangas wrote:
>
> > SearchNamedReplicationSlot() will also acquire the lock in LW_SHARED
> > mode, when you pass need_lock=true. So that at least should be changed
> > to false.
> >
>
Hi,
On Tue, Mar 05, 2024 at 09:55:32AM +0200, Heikki Linnakangas wrote:
> On 01/03/2024 12:15, Bertrand Drouvot wrote:
> > Hi hackers,
> >
> > I think that pgstat_reset_replslot() is missing LWLock protection. Indeed,
> > we
> > don't have any guarantee that the slot is active (then preventing i
On Tue, Mar 5, 2024 at 1:25 PM Heikki Linnakangas wrote:
> SearchNamedReplicationSlot() will also acquire the lock in LW_SHARED
> mode, when you pass need_lock=true. So that at least should be changed
> to false.
>
Also don't we need to release the lock when we return here:
/*
* Nothing to do f
On 01/03/2024 12:15, Bertrand Drouvot wrote:
Hi hackers,
I think that pgstat_reset_replslot() is missing LWLock protection. Indeed, we
don't have any guarantee that the slot is active (then preventing it to be
dropped/recreated) when this function is executed.
Yes, so it seems at quick glance.
21 matches
Mail list logo
