Re: Injection point locking - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Injection point locking
Date
Msg-id 1161825.1719241389@sss.pgh.pa.us
Whole thread Raw
In response to Injection point locking  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Injection point locking
Re: Injection point locking
List pgsql-hackers
Heikki Linnakangas <hlinnaka@iki.fi> 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? Could we use a simple 
> spinlock instead? With a fast path for the case that no injection points 
> are attached or something?

Even taking a spinlock in the postmaster is contrary to project
policy.  Maybe we could look the other way for debug-only code,
but it seems like a pretty horrible precedent.

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.  Or just rip
out the removal capability, and say that once installed an
injection point is there until postmaster shutdown (or till
shared memory reinitialization, anyway).

            regards, tom lane



pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Next
From: Robert Haas
Date:
Subject: Re: scalability bottlenecks with (many) partitions (and more)