public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v2] Do not use RelationNeedsWAL to identify relation persistence 2+ messages / 2 participants [nested] [flat]
* [PATCH v2] Do not use RelationNeedsWAL to identify relation persistence @ 2021-01-18 05:47 Kyotaro Horiguchi <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Kyotaro Horiguchi @ 2021-01-18 05:47 UTC (permalink / raw) RelationNeedsWAL() may return false for a permanent relation when wal_level=minimal and the relation is created or truncated in the current transaction. Directly examine relpersistence instead of using the function to know relation persistence. --- src/backend/catalog/pg_publication.c | 2 +- src/backend/optimizer/util/plancat.c | 3 ++- src/include/utils/rel.h | 9 ++++++++- src/include/utils/snapmgr.h | 2 +- src/test/subscription/t/001_rep_changes.pl | 20 +++++++++++++++++++- 5 files changed, 31 insertions(+), 5 deletions(-) diff --git a/src/backend/catalog/pg_publication.c b/src/backend/catalog/pg_publication.c index 5f8e1c64e1..84d2efcfd2 100644 --- a/src/backend/catalog/pg_publication.c +++ b/src/backend/catalog/pg_publication.c @@ -67,7 +67,7 @@ check_publication_add_relation(Relation targetrel) errdetail("System tables cannot be added to publications."))); /* UNLOGGED and TEMP relations cannot be part of publication. */ - if (!RelationNeedsWAL(targetrel)) + if (targetrel->rd_rel->relpersistence != RELPERSISTENCE_PERMANENT) ereport(ERROR, (errcode(ERRCODE_INVALID_PARAMETER_VALUE), errmsg("table \"%s\" cannot be replicated", diff --git a/src/backend/optimizer/util/plancat.c b/src/backend/optimizer/util/plancat.c index da322b453e..177e6e336a 100644 --- a/src/backend/optimizer/util/plancat.c +++ b/src/backend/optimizer/util/plancat.c @@ -126,7 +126,8 @@ get_relation_info(PlannerInfo *root, Oid relationObjectId, bool inhparent, relation = table_open(relationObjectId, NoLock); /* Temporary and unlogged relations are inaccessible during recovery. */ - if (!RelationNeedsWAL(relation) && RecoveryInProgress()) + if (relation->rd_rel->relpersistence != RELPERSISTENCE_PERMANENT && + RecoveryInProgress()) ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), errmsg("cannot access temporary or unlogged relations during recovery"))); diff --git a/src/include/utils/rel.h b/src/include/utils/rel.h index 10b63982c0..1e2c11fdd3 100644 --- a/src/include/utils/rel.h +++ b/src/include/utils/rel.h @@ -552,9 +552,16 @@ typedef struct ViewOptions (relation)->rd_smgr->smgr_targblock = (targblock); \ } while (0) +/* + * RelationIsPermanent + * True if relation is WAL-logged. + */ +#define RelationIsWalLogged(relation) \ + ((relation)->rd_rel->relpersistence == RELPERSISTENCE_PERMANENT) + /* * RelationNeedsWAL - * True if relation needs WAL. + * True if relation needs WAL at the time. * * Returns false if wal_level = minimal and this relation is created or * truncated in the current transaction. See "Skipping WAL for New diff --git a/src/include/utils/snapmgr.h b/src/include/utils/snapmgr.h index 579be352c5..35acccb29c 100644 --- a/src/include/utils/snapmgr.h +++ b/src/include/utils/snapmgr.h @@ -37,7 +37,7 @@ */ #define RelationAllowsEarlyPruning(rel) \ ( \ - RelationNeedsWAL(rel) \ + rel->rd_rel->relpersistence == RELPERSISTENCE_PERMANENT \ && !IsCatalogRelation(rel) \ && !RelationIsAccessibleInLogicalDecoding(rel) \ ) diff --git a/src/test/subscription/t/001_rep_changes.pl b/src/test/subscription/t/001_rep_changes.pl index 0680f44a1a..ed9b48e8bc 100644 --- a/src/test/subscription/t/001_rep_changes.pl +++ b/src/test/subscription/t/001_rep_changes.pl @@ -3,7 +3,7 @@ use strict; use warnings; use PostgresNode; use TestLib; -use Test::More tests => 23; +use Test::More tests => 24; # Initialize publisher node my $node_publisher = get_new_node('publisher'); @@ -358,3 +358,21 @@ is($result, qq(0), 'check replication origin was dropped on subscriber'); $node_subscriber->stop('fast'); $node_publisher->stop('fast'); + +# +# CREATE PUBLICATION while wal_level=mimal should succeed, with a WARNING +$node_publisher->append_conf( + 'postgresql.conf', qq( +wal_level=minimal +max_wal_senders=0 +)); +$node_publisher->start; +($result, my $retout, my $reterr) = $node_publisher->psql( + 'postgres', qq{ +BEGIN; +CREATE TABLE skip_wal(); +CREATE PUBLICATION tap_pub2 FOR TABLE skip_wal; +ROLLBACK; +}); +ok($reterr =~ m/WARNING: wal_level is insufficient to publish logical changes/, + 'test CREATE PUBLICATION can be done while wal_leve=minimal'); -- 2.27.0 ----Next_Part(Mon_Jan_18_15_08_38_2021_069)---- ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs @ 2024-03-29 13:07 Laurenz Albe <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Laurenz Albe @ 2024-03-29 13:07 UTC (permalink / raw) To: Daniel Verite <[email protected]>; +Cc: pgsql-hackers; Tom Lane <[email protected]>; Robert Haas <[email protected]>; Jakub Wartak <[email protected]> On Tue, 2024-01-30 at 15:29 +0100, Daniel Verite wrote: > PFA a rebased version. I had a look at patch 0001 (0002 will follow). > - <sect1 id="libpq-single-row-mode"> > - <title>Retrieving Query Results Row-by-Row</title> > + <sect1 id="libpq-chunked-results-modes"> > + <title>Retrieving Query Results by chunks</title> That should be "in chunks". > + <para> > + <variablelist> > + <varlistentry id="libpq-PQsetChunkedRowsMode"> > + <term><function>PQsetChunkedRowsMode</function> > + <indexterm><primary>PQsetChunkedRowsMode</primary></indexterm></term> > + <listitem> > + <para> > + Select the mode retrieving results in chunks for the currently-executing query. That is questionable English. How about Select to receive the results for the currently-executing query in chunks. > + This function is similar to <xref linkend="libpq-PQsetSingleRowMode"/>, > + except that it can retrieve a user-specified number of rows > + per call to <xref linkend="libpq-PQgetResult"/>, instead of a single row. The "user-specified number" is "maxRows". So a better wording would be: ... except that it can retrieve <replaceable>maxRows</replaceable> rows per call to <xref linkend="libpq-PQgetResult"/> instead of a single row. > - error. But in single-row mode, those rows will have already been > + error. But in single-row or chunked modes, those rows will have already been I'd say it should be "in *the* single-row or chunk modes". > --- a/src/interfaces/libpq/fe-exec.c > +++ b/src/interfaces/libpq/fe-exec.c > @@ -41,7 +41,8 @@ char *const pgresStatus[] = { > "PGRES_COPY_BOTH", > "PGRES_SINGLE_TUPLE", > "PGRES_PIPELINE_SYNC", > - "PGRES_PIPELINE_ABORTED" > + "PGRES_PIPELINE_ABORTED", > + "PGRES_TUPLES_CHUNK" > }; I think that PGRES_SINGLE_TUPLE and PGRES_TUPLES_CHUNK should be next to each other, but that's no big thing. The same applies to the change in src/interfaces/libpq/libpq-fe.h I understand that we need to keep the single-row mode for compatibility reasons. But I think that under the hood, "single-row mode" should be the same as "chunk mode with chunk size one". That should save some code repetition. Yours, Laurenz Albe ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-03-29 13:07 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-01-18 05:47 [PATCH v2] Do not use RelationNeedsWAL to identify relation persistence Kyotaro Horiguchi <[email protected]> 2024-03-29 13:07 Re: psql's FETCH_COUNT (cursor) is not being respected for CTEs Laurenz Albe <[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