public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v21 3/8] Row pattern recognition patch (rewriter).
5+ messages / 3 participants
[nested] [flat]
* [PATCH v21 3/8] Row pattern recognition patch (rewriter).
@ 2024-08-26 04:32 Tatsuo Ishii <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Tatsuo Ishii @ 2024-08-26 04:32 UTC (permalink / raw)
---
src/backend/utils/adt/ruleutils.c | 103 ++++++++++++++++++++++++++++++
1 file changed, 103 insertions(+)
diff --git a/src/backend/utils/adt/ruleutils.c b/src/backend/utils/adt/ruleutils.c
index 00eda1b34c..dff7e169e7 100644
--- a/src/backend/utils/adt/ruleutils.c
+++ b/src/backend/utils/adt/ruleutils.c
@@ -426,6 +426,10 @@ static void get_rule_groupingset(GroupingSet *gset, List *targetlist,
bool omit_parens, deparse_context *context);
static void get_rule_orderby(List *orderList, List *targetList,
bool force_colno, deparse_context *context);
+static void get_rule_pattern(List *patternVariable, List *patternRegexp,
+ bool force_colno, deparse_context *context);
+static void get_rule_define(List *defineClause, List *patternVariables,
+ bool force_colno, deparse_context *context);
static void get_rule_windowclause(Query *query, deparse_context *context);
static void get_rule_windowspec(WindowClause *wc, List *targetList,
deparse_context *context);
@@ -6460,6 +6464,67 @@ get_rule_orderby(List *orderList, List *targetList,
}
}
+/*
+ * Display a PATTERN clause.
+ */
+static void
+get_rule_pattern(List *patternVariable, List *patternRegexp,
+ bool force_colno, deparse_context *context)
+{
+ StringInfo buf = context->buf;
+ const char *sep;
+ ListCell *lc_var,
+ *lc_reg = list_head(patternRegexp);
+
+ sep = "";
+ appendStringInfoChar(buf, '(');
+ foreach(lc_var, patternVariable)
+ {
+ char *variable = strVal((String *) lfirst(lc_var));
+ char *regexp = NULL;
+
+ if (lc_reg != NULL)
+ {
+ regexp = strVal((String *) lfirst(lc_reg));
+
+ lc_reg = lnext(patternRegexp, lc_reg);
+ }
+
+ appendStringInfo(buf, "%s%s", sep, variable);
+ if (regexp !=NULL)
+ appendStringInfoString(buf, regexp);
+
+ sep = " ";
+ }
+ appendStringInfoChar(buf, ')');
+}
+
+/*
+ * Display a DEFINE clause.
+ */
+static void
+get_rule_define(List *defineClause, List *patternVariables,
+ bool force_colno, deparse_context *context)
+{
+ StringInfo buf = context->buf;
+ const char *sep;
+ ListCell *lc_var,
+ *lc_def;
+
+ sep = " ";
+ Assert(list_length(patternVariables) == list_length(defineClause));
+
+ forboth(lc_var, patternVariables, lc_def, defineClause)
+ {
+ char *varName = strVal(lfirst(lc_var));
+ TargetEntry *te = (TargetEntry *) lfirst(lc_def);
+
+ appendStringInfo(buf, "%s%s AS ", sep, varName);
+ get_rule_expr((Node *) te->expr, context, false);
+ sep = ",\n ";
+ }
+}
+
/*
* Display a WINDOW clause.
*
@@ -6597,6 +6662,44 @@ get_rule_windowspec(WindowClause *wc, List *targetList,
appendStringInfoString(buf, "EXCLUDE GROUP ");
else if (wc->frameOptions & FRAMEOPTION_EXCLUDE_TIES)
appendStringInfoString(buf, "EXCLUDE TIES ");
+ /* RPR */
+ if (wc->rpSkipTo == ST_NEXT_ROW)
+ appendStringInfoString(buf,
+ "\n AFTER MATCH SKIP TO NEXT ROW ");
+ else if (wc->rpSkipTo == ST_PAST_LAST_ROW)
+ appendStringInfoString(buf,
+ "\n AFTER MATCH SKIP PAST LAST ROW ");
+ else if (wc->rpSkipTo == ST_FIRST_VARIABLE)
+ appendStringInfo(buf,
+ "\n AFTER MATCH SKIP TO FIRST %s ",
+ wc->rpSkipVariable);
+ else if (wc->rpSkipTo == ST_LAST_VARIABLE)
+ appendStringInfo(buf,
+ "\n AFTER MATCH SKIP TO LAST %s ",
+ wc->rpSkipVariable);
+ else if (wc->rpSkipTo == ST_VARIABLE)
+ appendStringInfo(buf,
+ "\n AFTER MATCH SKIP TO %s ",
+ wc->rpSkipVariable);
+
+ if (wc->initial)
+ appendStringInfoString(buf, "\n INITIAL");
+
+ if (wc->patternVariable)
+ {
+ appendStringInfoString(buf, "\n PATTERN ");
+ get_rule_pattern(wc->patternVariable, wc->patternRegexp,
+ false, context);
+ }
+
+ if (wc->defineClause)
+ {
+ appendStringInfoString(buf, "\n DEFINE\n");
+ get_rule_define(wc->defineClause, wc->patternVariable,
+ false, context);
+ appendStringInfoChar(buf, ' ');
+ }
+
/* we will now have a trailing space; remove it */
buf->len--;
}
--
2.25.1
----Next_Part(Mon_Aug_26_13_39_47_2024_878)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v21-0004-Row-pattern-recognition-patch-planner.patch"
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Clear padding in PgStat_HashKey keys
@ 2024-11-04 08:52 Bertrand Drouvot <[email protected]>
2024-11-04 09:49 ` Re: Clear padding in PgStat_HashKey keys Michael Paquier <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Bertrand Drouvot @ 2024-11-04 08:52 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: [email protected]
Hi,
On Mon, Nov 04, 2024 at 04:25:00PM +0900, Michael Paquier wrote:
> On Sun, Nov 03, 2024 at 04:25:41AM +0000, Bertrand Drouvot wrote:
> > We are using sizeof(PgStat_HashKey) in pgstat_cmp_hash_key() and we compute the
> > hash hash key in pgstat_hash_hash_key() using the PgStat_HashKey struct size as
> > input: this lead to unexpected results if the keys contain random data in the
> > padding bytes.
>
> So you've seen that your patch was behaving weirdly once you have
> added padding because the hash key size has been extended, leading to
> relfilenode entries not being fetched when they should, right?
Yeah, but not only the relfilenode ones. All kinds were affected as random data
was in the padding bytes for all of them.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Clear padding in PgStat_HashKey keys
2024-11-04 08:52 Re: Clear padding in PgStat_HashKey keys Bertrand Drouvot <[email protected]>
@ 2024-11-04 09:49 ` Michael Paquier <[email protected]>
2024-11-04 10:07 ` Re: Clear padding in PgStat_HashKey keys Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Michael Paquier @ 2024-11-04 09:49 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: [email protected]
On Mon, Nov 04, 2024 at 08:52:04AM +0000, Bertrand Drouvot wrote:
> Yeah, but not only the relfilenode ones. All kinds were affected as random data
> was in the padding bytes for all of them.
A quick test where I add some padding junk in PgStat_HashKey proves
that you are right. I'm wondering if we should backpatch that,
actually, down to where it has been introduced. We are unlikely going
to change this structure, but if we do for the sake of a bug fix,
which is always a possibility as ABI does not matter much for this
internal structure, that's potentially trouble waiting ahead.
Thoughts?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Clear padding in PgStat_HashKey keys
2024-11-04 08:52 Re: Clear padding in PgStat_HashKey keys Bertrand Drouvot <[email protected]>
2024-11-04 09:49 ` Re: Clear padding in PgStat_HashKey keys Michael Paquier <[email protected]>
@ 2024-11-04 10:07 ` Bertrand Drouvot <[email protected]>
2024-11-05 00:43 ` Re: Clear padding in PgStat_HashKey keys Michael Paquier <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Bertrand Drouvot @ 2024-11-04 10:07 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: [email protected]
Hi,
On Mon, Nov 04, 2024 at 06:49:04PM +0900, Michael Paquier wrote:
> On Mon, Nov 04, 2024 at 08:52:04AM +0000, Bertrand Drouvot wrote:
> > Yeah, but not only the relfilenode ones. All kinds were affected as random data
> > was in the padding bytes for all of them.
>
> A quick test where I add some padding junk in PgStat_HashKey proves
> that you are right.
Thanks for the testing!
> I'm wondering if we should backpatch that,
> actually, down to where it has been introduced. We are unlikely going
> to change this structure,
Yeah.
> but if we do for the sake of a bug fix,
> which is always a possibility as ABI does not matter much for this
> internal structure, that's potentially trouble waiting ahead.
That's right.
> Thoughts?
hm, yeah I think that it could fall into the "low-risk fixes" category [0] and
that we can opt for backpatch.
[0]: https://www.postgresql.org/support/versioning/
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Clear padding in PgStat_HashKey keys
2024-11-04 08:52 Re: Clear padding in PgStat_HashKey keys Bertrand Drouvot <[email protected]>
2024-11-04 09:49 ` Re: Clear padding in PgStat_HashKey keys Michael Paquier <[email protected]>
2024-11-04 10:07 ` Re: Clear padding in PgStat_HashKey keys Bertrand Drouvot <[email protected]>
@ 2024-11-05 00:43 ` Michael Paquier <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Michael Paquier @ 2024-11-05 00:43 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: [email protected]
On Mon, Nov 04, 2024 at 10:07:37AM +0000, Bertrand Drouvot wrote:
> On Mon, Nov 04, 2024 at 06:49:04PM +0900, Michael Paquier wrote:
>> but if we do for the sake of a bug fix,
>> which is always a possibility as ABI does not matter much for this
>> internal structure, that's potentially trouble waiting ahead.
>
> That's right.
After sleeping on it, it would be annoying to come back to this issue
for a separate backpatchable change, and what's proposed is simple.
So applied down to 15.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2024-11-05 00:43 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2024-08-26 04:32 [PATCH v21 3/8] Row pattern recognition patch (rewriter). Tatsuo Ishii <[email protected]>
2024-11-04 08:52 Re: Clear padding in PgStat_HashKey keys Bertrand Drouvot <[email protected]>
2024-11-04 09:49 ` Re: Clear padding in PgStat_HashKey keys Michael Paquier <[email protected]>
2024-11-04 10:07 ` Re: Clear padding in PgStat_HashKey keys Bertrand Drouvot <[email protected]>
2024-11-05 00:43 ` Re: Clear padding in PgStat_HashKey keys Michael Paquier <[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