public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v18 17/18] tableam: Add function to determine newest xid among tuples. 4+ messages / 4 participants [nested] [flat]
* [PATCH v18 17/18] tableam: Add function to determine newest xid among tuples. @ 2018-12-19 20:52 Andres Freund <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Andres Freund @ 2018-12-19 20:52 UTC (permalink / raw) Author: Reviewed-By: Discussion: https://postgr.es/m/ Backpatch: --- src/backend/access/heap/heapam_handler.c | 1 + src/backend/access/index/genam.c | 2 +- src/include/access/tableam.h | 17 +++++++++++++++++ 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/src/backend/access/heap/heapam_handler.c b/src/backend/access/heap/heapam_handler.c index b183b22ca16..eba8dbb28da 100644 --- a/src/backend/access/heap/heapam_handler.c +++ b/src/backend/access/heap/heapam_handler.c @@ -2340,6 +2340,7 @@ static const TableAmRoutine heapam_methods = { .tuple_fetch_row_version = heapam_fetch_row_version, .tuple_get_latest_tid = heap_get_latest_tid, .tuple_satisfies_snapshot = heapam_tuple_satisfies_snapshot, + .compute_xid_horizon_for_tuples = heap_compute_xid_horizon_for_tuples, .relation_set_new_filenode = heapam_set_new_filenode, .relation_nontransactional_truncate = heapam_relation_nontransactional_truncate, diff --git a/src/backend/access/index/genam.c b/src/backend/access/index/genam.c index 3dbb264e728..70de8ff75f7 100644 --- a/src/backend/access/index/genam.c +++ b/src/backend/access/index/genam.c @@ -302,7 +302,7 @@ index_compute_xid_horizon_for_tuples(Relation irel, /* determine the actual xid horizon */ latestRemovedXid = - heap_compute_xid_horizon_for_tuples(hrel, htids, nitems); + table_compute_xid_horizon_for_tuples(hrel, htids, nitems); pfree(htids); diff --git a/src/include/access/tableam.h b/src/include/access/tableam.h index 2ed25ec748f..827fe6f35a7 100644 --- a/src/include/access/tableam.h +++ b/src/include/access/tableam.h @@ -240,6 +240,15 @@ typedef struct TableAmRoutine bool (*tuple_satisfies_snapshot) (Relation rel, TupleTableSlot *slot, Snapshot snapshot); + /* + * Compute the newest xid among the tuples pointed to by items. This is + * used to compute what snapshots to conflict with when replaying WAL + * records for page-level index vacuums. + */ + TransactionId (*compute_xid_horizon_for_tuples) (Relation rel, + ItemPointerData *items, + int nitems); + /* ------------------------------------------------------------------------ * Manipulations of physical tuples. @@ -678,6 +687,14 @@ table_tuple_satisfies_snapshot(Relation rel, TupleTableSlot *slot, Snapshot snap return rel->rd_tableam->tuple_satisfies_snapshot(rel, slot, snapshot); } +static inline TransactionId +table_compute_xid_horizon_for_tuples(Relation rel, + ItemPointerData *items, + int nitems) +{ + return rel->rd_tableam->compute_xid_horizon_for_tuples(rel, items, nitems); +} + /* ---------------------------------------------------------------------------- * Functions for manipulations of physical tuples. -- 2.21.0.dirty --yvn3crbc4qf4vymf Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v18-0018-tableam-Fetch-tuples-for-triggers-EPQ-using-a-pr.patch" ^ permalink raw reply [nested|flat] 4+ messages in thread
* [PATCH v16 3/8] Row pattern recognition patch (rewriter). @ 2024-04-12 06:49 Tatsuo Ishii <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Tatsuo Ishii @ 2024-04-12 06:49 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 24e3514b00..c204565cc1 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); @@ -6487,6 +6491,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. * @@ -6624,6 +6689,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(Fri_Apr_12_16_09_08_2024_262)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="v16-0004-Row-pattern-recognition-patch-planner.patch" ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof? @ 2024-08-02 17:39 Robert Haas <[email protected]> 2024-08-02 18:18 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[email protected]> 0 siblings, 1 reply; 4+ messages in thread From: Robert Haas @ 2024-08-02 17:39 UTC (permalink / raw) To: Jacob Champion <[email protected]>; +Cc: Tom Lane <[email protected]>; Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]> On Fri, Aug 2, 2024 at 12:33 PM Jacob Champion <[email protected]> wrote: > (Now, if there aren't that many cases where we can all agree on > "unsafe", then the proposal loses pretty much all value, because we'll > never shrink the uncertainty.) My belief is that nearly everything in unsafe. We ship with very little marked leakproof right now, and that might be too conservative, but probably not by much. For example: -- +(int4, int4) is not leakproof robert.haas=# select 2147483647::int4+1; ERROR: integer out of range -- textcat is not leakproof robert.haas=# create temp table x as select repeat('a',(2^29)::int4-2)::text a; SELECT 1 robert.haas=# select length(a||a) from x; ERROR: invalid memory alloc request size 1073741824 -- absolute value is not leakproof robert.haas=# select @(-2147483648); ERROR: integer out of range -- textlike is not leakproof robert.haas=# select 'a' ~ 'b\'; ERROR: invalid regular expression: invalid escape \ sequence -- division is not leakproof robert.haas=# select 2/0; ERROR: division by zero -- to_date is not leakproof robert.haas=# select to_date('abc', 'def'); ERROR: invalid value "a" for "d" DETAIL: Value must be an integer. I think it would be safe to mark the bitwise xor operator for integers as leakproof. But that isn't likely to be used in a query. Most of the stuff that people actually use in queries isn't even arguably leakproof. -- Robert Haas EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof? 2024-08-02 17:39 Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]> @ 2024-08-02 18:18 ` Jacob Champion <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Jacob Champion @ 2024-08-02 18:18 UTC (permalink / raw) To: Robert Haas <[email protected]>; +Cc: Tom Lane <[email protected]>; Joe Conway <[email protected]>; Andrew Dunstan <[email protected]>; David Rowley <[email protected]>; PostgreSQL Hackers <[email protected]> On Fri, Aug 2, 2024 at 10:40 AM Robert Haas <[email protected]> wrote: > My belief is that nearly everything in unsafe. We ship with very > little marked leakproof right now, and that might be too conservative, > but probably not by much. Then to me, that seems like the best-case scenario for a "maybe" classification. I'm still not sold on the idea of automatically treating all "maybes" as leakproof (personally I'd prefer that users surgically opt in), but if the pool is small... Thanks, --Jacob ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2024-08-02 18:18 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2018-12-19 20:52 [PATCH v18 17/18] tableam: Add function to determine newest xid among tuples. Andres Freund <[email protected]> 2024-04-12 06:49 [PATCH v16 3/8] Row pattern recognition patch (rewriter). Tatsuo Ishii <[email protected]> 2024-08-02 17:39 Re: can we mark upper/lower/textlike functions leakproof? Robert Haas <[email protected]> 2024-08-02 18:18 ` Re: can we mark upper/lower/textlike functions leakproof? Jacob Champion <[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