public inbox for [email protected]help / color / mirror / Atom feed
Re: Injection points: some tools to wait and wake 2+ messages / 2 participants [nested] [flat]
* Re: Injection points: some tools to wait and wake @ 2024-02-21 08:07 Bertrand Drouvot <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Bertrand Drouvot @ 2024-02-21 08:07 UTC (permalink / raw) To: Michael Paquier <[email protected]>; +Cc: Postgres hackers <[email protected]>; Ashutosh Bapat <[email protected]> Hi, On Wed, Feb 21, 2024 at 07:08:03AM +0900, Michael Paquier wrote: > On Tue, Feb 20, 2024 at 03:55:08PM +0000, Bertrand Drouvot wrote: > > +PG_FUNCTION_INFO_V1(injection_points_wake); > > +Datum > > +injection_points_wake(PG_FUNCTION_ARGS) > > +{ > > > > I think that This function will wake up all the "wait" injection points. > > Would that make sense to implement some filtering based on the name? That could > > be useful for tests that would need multiple wait injection points and that want > > to wake them up "sequentially". > > > > We could think about it if there is such a need in the future though. > > Well, both you and Andrey are asking for it now, so let's do it. Thanks! > The implementation is simple: > - Store in InjectionPointSharedState an array of wait_counts and an > array of names. There is only one condition variable. > - When a point wants to wait, it takes the spinlock and looks within > the array of names until it finds a free slot, adds its name into the > array to reserve a wait counter at the same position, releases the > spinlock. Then it loops on the condition variable for an update of > the counter it has reserved. It is possible to make something more > efficient, but at a small size it would not really matter. > - The wakeup takes a point name in argument, acquires the spinlock, > and checks if it can find the point into the array, pinpoints the > location of the counter to update and updates it. Then it broadcasts > the change. > - The wait loop checks its counter, leaves its loop, cancels the > sleep, takes the spinlock to unregister from the array, and leaves. > I think that makes sense and now the "counter" makes more sense to me (thanks to it we don't need multiple CV). > I would just hardcode the number of points that can wait, say 5 of > them tracked in shmem? Does that look like what you are looking at? I think so yes and more than 5 points would look like a complicated test IMHO. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com ^ permalink raw reply [nested|flat] 2+ messages in thread
* Proposal : Retain explainable statement location on ExplainStmt structure. @ 2026-07-10 12:35 Anton Ratundalov <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Anton Ratundalov @ 2026-07-10 12:35 UTC (permalink / raw) To: [email protected] Hi hackers Let me propose to amend ExplainStmt structure with an new attribute explainable_loc of ParseLoc type with the purpose of separating an EXPLAIN command ( together with it's options ) from the statement to be explained. This, for example, will allow to execute EXPLAIN remotely with a different set of options. Please, find code changes in the patch. Best regards, Anton Ratundalov, Postgres Professional Attachments: [text/x-patch] retain_explainable_statement_location.patch (1.4K, ../../[email protected]/2-retain_explainable_statement_location.patch) download | inline diff: diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y index 0f4e8638c3d..c431fce7ac9 100644 --- a/src/backend/parser/gram.y +++ b/src/backend/parser/gram.y @@ -12758,6 +12758,7 @@ ExplainStmt: n->query = $2; n->options = NIL; + n->explainable_loc = @2; $$ = (Node *) n; } | EXPLAIN analyze_keyword opt_verbose ExplainableStmt @@ -12769,6 +12770,7 @@ ExplainStmt: if ($3) n->options = lappend(n->options, makeDefElem("verbose", NULL, @3)); + n->explainable_loc = @4; $$ = (Node *) n; } | EXPLAIN VERBOSE ExplainableStmt @@ -12777,6 +12779,7 @@ ExplainStmt: n->query = $3; n->options = list_make1(makeDefElem("verbose", NULL, @2)); + n->explainable_loc = @3; $$ = (Node *) n; } | EXPLAIN '(' utility_option_list ')' ExplainableStmt @@ -12785,6 +12788,7 @@ ExplainStmt: n->query = $5; n->options = $3; + n->explainable_loc = @5; $$ = (Node *) n; } ; diff --git a/src/include/nodes/parsenodes.h b/src/include/nodes/parsenodes.h index a92dbda0770..bad933d4f0e 100644 --- a/src/include/nodes/parsenodes.h +++ b/src/include/nodes/parsenodes.h @@ -4152,4 +4152,5 @@ typedef struct ExplainStmt NodeTag type; Node *query; /* the query (see comments above) */ List *options; /* list of DefElem nodes */ + ParseLoc explainable_loc; } ExplainStmt; ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-07-10 12:35 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2024-02-21 08:07 Re: Injection points: some tools to wait and wake Bertrand Drouvot <[email protected]> 2026-07-10 12:35 Proposal : Retain explainable statement location on ExplainStmt structure. Anton Ratundalov <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox