public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v6 05/10] doc: s/evade/avoid/
2+ messages / 2 participants
[nested] [flat]
* [PATCH v6 05/10] doc: s/evade/avoid/
@ 2020-04-06 22:16 Justin Pryzby <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Justin Pryzby @ 2020-04-06 22:16 UTC (permalink / raw)
---
src/backend/access/gin/README | 2 +-
src/backend/utils/adt/jsonpath_exec.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/backend/access/gin/README b/src/backend/access/gin/README
index 125a82219b..41d4e1e8a0 100644
--- a/src/backend/access/gin/README
+++ b/src/backend/access/gin/README
@@ -413,7 +413,7 @@ leftmost leaf of the tree.
Deletion algorithm keeps exclusive locks on left siblings of pages comprising
currently investigated path. Thus, if current page is to be removed, all
required pages to remove both downlink and rightlink are already locked. That
-evades potential right to left page locking order, which could deadlock with
+avoids potential right to left page locking order, which could deadlock with
concurrent stepping right.
A search concurrent to page deletion might already have read a pointer to the
diff --git a/src/backend/utils/adt/jsonpath_exec.c b/src/backend/utils/adt/jsonpath_exec.c
index f146767bfc..2d2eb7d7a3 100644
--- a/src/backend/utils/adt/jsonpath_exec.c
+++ b/src/backend/utils/adt/jsonpath_exec.c
@@ -35,7 +35,7 @@
* executeItemOptUnwrapTarget() function have 'unwrap' argument, which indicates
* whether unwrapping of array is needed. When unwrap == true, each of array
* members is passed to executeItemOptUnwrapTarget() again but with unwrap == false
- * in order to evade subsequent array unwrapping.
+ * in order to avoid subsequent array unwrapping.
*
* All boolean expressions (predicates) are evaluated by executeBoolItem()
* function, which returns tri-state JsonPathBool. When error is occurred
--
2.17.0
--C+ts3FVlLX8+P6JN
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment;
filename="v6-0006-doc-Add-logical-replication-support-to-replicate-.patch"
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Sequence Access Methods, round two
@ 2024-03-13 06:00 Peter Eisentraut <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Peter Eisentraut @ 2024-03-13 06:00 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; Tomas Vondra <[email protected]>; +Cc: Peter Smith <[email protected]>; Postgres hackers <[email protected]>
On 12.03.24 00:44, Michael Paquier wrote:
> Anyway, there is one piece of this patch set that I think has a lot of
> value outside of the discussion with access methods, which is to
> redesign pg_sequence_last_value so as it returns a (last_value,
> is_called) tuple rather than a (last_value). This has the benefit of
> switching pg_dump to use this function rather than relying on a scan
> of the heap table used by a sequence to retrieve the state of a
> sequence dumped. This is the main diff:
> - appendPQExpBuffer(query,
> - "SELECT last_value, is_called FROM %s",
> - fmtQualifiedDumpable(tbinfo));
> + /*
> + * In versions 17 and up, pg_sequence_last_value() has been switched to
> + * return a tuple with last_value and is_called.
> + */
> + if (fout->remoteVersion >= 170000)
> + appendPQExpBuffer(query,
> + "SELECT last_value, is_called "
> + "FROM pg_sequence_last_value('%s')",
> + fmtQualifiedDumpable(tbinfo));
> + else
> + appendPQExpBuffer(query,
> + "SELECT last_value, is_called FROM %s",
> + fmtQualifiedDumpable(tbinfo));
>
> Are there any objections to that? pg_sequence_last_value() is
> something that we've only been relying on internally for the catalog
> pg_sequences.
I don't understand what the overall benefit of this change is supposed
to be.
If this route were to be pursued, it should be a different function
name. We shouldn't change the signature of an existing function.
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-03-13 06:00 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-04-06 22:16 [PATCH v6 05/10] doc: s/evade/avoid/ Justin Pryzby <[email protected]>
2024-03-13 06:00 Re: Sequence Access Methods, round two Peter Eisentraut <[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