On Mon, Jul 15, 2024 at 10:55:26AM +0300, Heikki Linnakangas wrote:
> Ok, committed this.
Okidoki. Thanks!
--
Michael
signature.asc
Description: PGP signature
On 10/07/2024 06:44, Michael Paquier wrote:
On Tue, Jul 09, 2024 at 12:12:04PM +0300, Heikki Linnakangas wrote:
I thought about it, but no. If the generation number doesn't match, there
are a few possibilities:
1. The entry was what we were looking for, but it was concurrently detached.
Return
On Tue, Jul 09, 2024 at 12:12:04PM +0300, Heikki Linnakangas wrote:
> I thought about it, but no. If the generation number doesn't match, there
> are a few possibilities:
>
> 1. The entry was what we were looking for, but it was concurrently detached.
> Return NULL is correct in that case.
>
> 2.
On 09/07/2024 08:16, Michael Paquier wrote:
typedef struct InjectionPointCacheEntry
{
charname[INJ_NAME_MAXLEN];
+intslot_idx;
+uint64generation;
charprivate_data[INJ_PRIVATE_MAXLEN];
InjectionPointCallback callback;
} InjectionP
On Mon, Jul 08, 2024 at 04:21:37PM +0300, Heikki Linnakangas wrote:
> I came up with the attached. It replaces the shmem hash table with an array
> that's scanned linearly. On each slot in the array, there's a generation
> number that indicates whether the slot is in use, and allows detecting
> con
On Mon, Jul 08, 2024 at 10:17:49AM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
>> Note that until we actually add an injection point to a function that
>> runs in the postmaster, there's no risk. If we're uneasy about that, we
>> could add an assertion to InjectionPointRun() to prevent i
Heikki Linnakangas writes:
> Note that until we actually add an injection point to a function that
> runs in the postmaster, there's no risk. If we're uneasy about that, we
> could add an assertion to InjectionPointRun() to prevent it from running
> in the postmaster, so that we don't cross tha
On 25/06/2024 05:25, Noah Misch wrote:
On Mon, Jun 24, 2024 at 11:03:09AM -0400, Tom Lane wrote:
Heikki Linnakangas writes:
... I can't do that, because InjectionPointRun() requires a PGPROC
entry, because it uses an LWLock. That also makes it impossible to use
injection points in the postmast
On Wed, Jun 26, 2024 at 10:56:12AM +0900, Michael Paquier wrote:
> That's true, we could delay the release of the lock to happen just
> before a callback is run.
I am not sure what else we can do for the postmaster case for now, so
I've moved ahead with the concern regarding the existing locking
r
On Tue, Jun 25, 2024 at 09:10:06AM -0700, Noah Misch wrote:
> I think your last sentence is what Heikki is saying should happen, and I
> agree. Yes, it matters. As written, InjectionPointRun() could cache an
> entry_by_name->function belonging to a different injection point.
That's true, we coul
On Tue, Jun 25, 2024 at 11:14:57AM +0900, Michael Paquier wrote:
> On Mon, Jun 24, 2024 at 01:29:38PM +0300, Heikki Linnakangas wrote:
> > InjectionPointRun() acquires InjectionPointLock, looks up the hash entry,
> > and releases the lock:
> >
> > > LWLockAcquire(InjectionPointLock, LW_SHARED);
On Mon, Jun 24, 2024 at 11:03:09AM -0400, Tom Lane wrote:
> Given your point that the existing locking is just a fig leaf
> anyway, maybe we could simply not have any? Then it's on the
> test author to be sure that the injection point won't be
> getting invoked when it's about to be removed.
That
On Mon, Jun 24, 2024 at 11:03:09AM -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > ... I can't do that, because InjectionPointRun() requires a PGPROC
> > entry, because it uses an LWLock. That also makes it impossible to use
> > injection points in the postmaster. Any chance we could all
On Mon, Jun 24, 2024 at 01:29:38PM +0300, Heikki Linnakangas wrote:
> InjectionPointRun() acquires InjectionPointLock, looks up the hash entry,
> and releases the lock:
>
> > LWLockAcquire(InjectionPointLock, LW_SHARED);
> > entry_by_name = (InjectionPointEntry *)
> > hash_sear
Heikki Linnakangas writes:
> ... I can't do that, because InjectionPointRun() requires a PGPROC
> entry, because it uses an LWLock. That also makes it impossible to use
> injection points in the postmaster. Any chance we could allow injection
> points to be triggered without a PGPROC entry? Cou
InjectionPointRun() acquires InjectionPointLock, looks up the hash
entry, and releases the lock:
LWLockAcquire(InjectionPointLock, LW_SHARED);
entry_by_name = (InjectionPointEntry *)
hash_search(InjectionPointHash, name,
HA
16 matches
Mail list logo
