public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v18 17/18] tableam: Add function to determine newest xid among tuples.
9+ messages / 6 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; 9+ 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] 9+ messages in thread
* Re: Build versionless .so for Android
@ 2024-01-18 08:27 Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Peter Eisentraut @ 2024-01-18 08:27 UTC (permalink / raw)
To: Matthias Kuhn <[email protected]>; +Cc: Robert Haas <[email protected]>; Michael Paquier <[email protected]>; [email protected]
On 14.01.24 12:37, Matthias Kuhn wrote:
> What I try to do is packaging an app with androiddeployqt which fails
> with an error:
>
> The bundled library lib/libpq.so.5 doesn't end with .so. Android only
> supports versionless libraries ending with the .so suffix.
>
> This error was introduced in response to this issue which contains hints
> about the underlying problem:
>
> https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-101346
> <https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-101346;
I think the scenario there is using dlopen(), possibly via Qt, possibly
via Java, so it's a very specific scenario, not necessarily indicative
of a general requirement on Android, and apparently not using build-time
linking. It's quite conceivable that this issue would also exist with
Qt on other platforms.
As I mentioned before, Meson has Android support. Some people there
clearly thought about it. So I suggest you try building PostgreSQL for
your Android environment using Meson and see what it produces.(*) If
the output files are the same as the autoconf/make build, then I would
think your scenario is nonstandard. If the output files are different,
then we should check that and consider changes to get them to match.
It's of course possible that Meson is wrong, too, but then we need to
have a broader analysis, because the implicit goal is to keep the two
build systems for PostgreSQL consistent.
(*) - This means specifically that the installation trees produced by
"make install-world-bin" and "meson install" should produce exactly the
same set of files (same names in the same directories, not necessarily
the same contents).
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Build versionless .so for Android
@ 2024-01-19 10:08 Matthias Kuhn <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Matthias Kuhn @ 2024-01-19 10:08 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: Robert Haas <[email protected]>; Michael Paquier <[email protected]>; [email protected]
Hi
On Thu, Jan 18, 2024 at 9:27 AM Peter Eisentraut <[email protected]>
wrote:
> On 14.01.24 12:37, Matthias Kuhn wrote:
> > What I try to do is packaging an app with androiddeployqt which fails
> > with an error:
> >
> > The bundled library lib/libpq.so.5 doesn't end with .so. Android only
> > supports versionless libraries ending with the .so suffix.
> >
> > This error was introduced in response to this issue which contains hints
> > about the underlying problem:
> >
> > https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-101346
> > <https://bugreports.qt.io/plugins/servlet/mobile#issue/QTBUG-101346;
>
> I think the scenario there is using dlopen(), possibly via Qt, possibly
> via Java, so it's a very specific scenario, not necessarily indicative
> of a general requirement on Android, and apparently not using build-time
> linking. It's quite conceivable that this issue would also exist with
> Qt on other platforms.
>
>
I haven't experienced this issue with Qt on any other platform (and I build
and run the same stack on windows, linux, macos and ios).
Also the links posted earlier in this thread hint to the same limitation of
Android, unrelated to Qt.
> As I mentioned before, Meson has Android support. Some people there
> clearly thought about it. So I suggest you try building PostgreSQL for
> your Android environment using Meson and see what it produces.(*) If
> the output files are the same as the autoconf/make build, then I would
> think your scenario is nonstandard. If the output files are different,
> then we should check that and consider changes to get them to match.
>
> It's of course possible that Meson is wrong, too, but then we need to
> have a broader analysis, because the implicit goal is to keep the two
> build systems for PostgreSQL consistent.
>
When trying to build with meson, including the patch which was provided by
Andres Freud (thanks),
I am currently stuck with the following error:
Configuring pg_config_ext.h using configuration
../src/tgresql-16-685bc9fc97.clean/src/include/meson.build:12:0: ERROR:
File port/android.h does not exist.
Kind regards
Matthias
>
> (*) - This means specifically that the installation trees produced by
> "make install-world-bin" and "meson install" should produce exactly the
> same set of files (same names in the same directories, not necessarily
> the same contents).
>
>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Build versionless .so for Android
@ 2024-01-19 14:00 Peter Eisentraut <[email protected]>
parent: Matthias Kuhn <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Peter Eisentraut @ 2024-01-19 14:00 UTC (permalink / raw)
To: Matthias Kuhn <[email protected]>; +Cc: [email protected]; Andres Freund <[email protected]>
On 19.01.24 11:08, Matthias Kuhn wrote:
> When trying to build with meson, including the patch which was provided
> by Andres Freud (thanks),
> I am currently stuck with the following error:
>
> Configuring pg_config_ext.h using configuration
>
> ../src/tgresql-16-685bc9fc97.clean/src/include/meson.build:12:0: ERROR:
> File port/android.h does not exist.
I think there is actually small bug in the meson setup.
In the top-level meson.build, line 166 has
portname = host_system
but then later around line 190, host_system is changed for some cases
(including the android case that was added in the proposed patch). So
that won't work, and probably also won't work for the existing cases
there. The portname assignment needs to be moved later in the file.
Maybe you can try that on your own.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Build versionless .so for Android
@ 2024-01-19 17:12 Matthias Kuhn <[email protected]>
parent: Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Matthias Kuhn @ 2024-01-19 17:12 UTC (permalink / raw)
To: Peter Eisentraut <[email protected]>; +Cc: [email protected]; Andres Freund <[email protected]>
Thanks,
This patch brought it further and indeed, the resulting libpq.so file is
unversioned when built for Android while it's versioned when built for
linux.
Matthias
On Fri, Jan 19, 2024 at 3:00 PM Peter Eisentraut <[email protected]>
wrote:
> On 19.01.24 11:08, Matthias Kuhn wrote:
> > When trying to build with meson, including the patch which was provided
> > by Andres Freud (thanks),
> > I am currently stuck with the following error:
> >
> > Configuring pg_config_ext.h using configuration
> >
> > ../src/tgresql-16-685bc9fc97.clean/src/include/meson.build:12:0: ERROR:
> > File port/android.h does not exist.
>
> I think there is actually small bug in the meson setup.
>
> In the top-level meson.build, line 166 has
>
> portname = host_system
>
> but then later around line 190, host_system is changed for some cases
> (including the android case that was added in the proposed patch). So
> that won't work, and probably also won't work for the existing cases
> there. The portname assignment needs to be moved later in the file.
> Maybe you can try that on your own.
>
>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: Build versionless .so for Android
@ 2024-01-23 19:42 Peter Eisentraut <[email protected]>
parent: Matthias Kuhn <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Peter Eisentraut @ 2024-01-23 19:42 UTC (permalink / raw)
To: Matthias Kuhn <[email protected]>; +Cc: [email protected]; Andres Freund <[email protected]>
On 19.01.24 18:12, Matthias Kuhn wrote:
> Thanks,
>
> This patch brought it further and indeed, the resulting libpq.so file is
> unversioned when built for Android while it's versioned when built for
> linux.
Ok, I have committed all of this now:
- Fix for correct order of host_system and portname assignment in
meson.build.
- Patch from Andres to map android to linux in meson.build.
- Makefile.shlib support for Android (based on your patch, but I
reworked it a bit).
So this should all work for you now.
^ permalink raw reply [nested|flat] 9+ 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; 9+ 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] 9+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
@ 2024-08-02 17:39 Robert Haas <[email protected]>
0 siblings, 1 reply; 9+ 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] 9+ messages in thread
* Re: can we mark upper/lower/textlike functions leakproof?
@ 2024-08-02 18:18 Jacob Champion <[email protected]>
parent: Robert Haas <[email protected]>
0 siblings, 0 replies; 9+ 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] 9+ messages in thread
end of thread, other threads:[~2024-08-02 18:18 UTC | newest]
Thread overview: 9+ 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-01-18 08:27 Re: Build versionless .so for Android Peter Eisentraut <[email protected]>
2024-01-19 10:08 ` Re: Build versionless .so for Android Matthias Kuhn <[email protected]>
2024-01-19 14:00 ` Re: Build versionless .so for Android Peter Eisentraut <[email protected]>
2024-01-19 17:12 ` Re: Build versionless .so for Android Matthias Kuhn <[email protected]>
2024-01-23 19:42 ` Re: Build versionless .so for Android Peter Eisentraut <[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