Re: INDEX with optional storage parameter value
On Sat, Jun 27, 2020 at 05:14:23PM -0400, Bruce Momjian wrote: > I found a few more places that also didn't properly document this; > patch attached. Good catch! I am not seeing any missing spots, so this looks good to me. You are planning a backpatch, right? -- Michael signature.asc Description: PGP signature
Re: INDEX with optional storage parameter value
On Sat, 2020-06-27 at 17:14 -0400, Bruce Momjian wrote:
> > I noticed an slight inaccuracy in the documentation for CREATE INDEX and
> > ALTER INDEX:
> >
> > CREATE INDEX ... [ WITH ( storage_parameter = value [, ... ] ) ]
> > ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter = value [, ... ] )
> >
> > In indices, as in tables, you can omit the вoolean value for a parameter.
> > For example:
> >
> > CREATE INDEX ON public.testtable USING GIN (c1) WITH (fastupdate);
> > ALTER INDEX testtable_c1_idx SET (fastupdate);
> >
> > It might be more correct to use the construct from CREATE TABLE:
> >
> > storage_parameter [= value] [, ... ]
>
> I found a few more places that also didn't properly document this;
> patch attached.
Looks good.
Perhaps it is worth explaining this explicitly, as in the attached.
Yours,
Laurenz Albe
From 6f88d34f94a8f6aadff1ccb5fd634f42c45e6501 Mon Sep 17 00:00:00 2001
From: Laurenz Albe
Date: Mon, 29 Jun 2020 09:25:07 +0200
Subject: [PATCH] Document that values can be omitted for boolean storage
parameters
This was already documented for CREATE TABLE, but not for CREATE INDEX.
Discussion: https://postgr.es/m/159283163235.684.4482737698910467...@wrigleys.postgresql.org
---
doc/src/sgml/ref/alter_index.sgml | 4 ++--
doc/src/sgml/ref/alter_materialized_view.sgml | 2 +-
doc/src/sgml/ref/alter_table.sgml | 4 ++--
doc/src/sgml/ref/create_index.sgml| 8 +++-
doc/src/sgml/ref/create_table.sgml| 6 ++
5 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/doc/src/sgml/ref/alter_index.sgml b/doc/src/sgml/ref/alter_index.sgml
index de6f89d458..a5e3b06ee4 100644
--- a/doc/src/sgml/ref/alter_index.sgml
+++ b/doc/src/sgml/ref/alter_index.sgml
@@ -25,7 +25,7 @@ ALTER INDEX [ IF EXISTS ] name RENA
ALTER INDEX [ IF EXISTS ] name SET TABLESPACE tablespace_name
ALTER INDEX name ATTACH PARTITION index_name
ALTER INDEX name DEPENDS ON EXTENSION extension_name
-ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter = value [, ... ] )
+ALTER INDEX [ IF EXISTS ] name SET ( storage_parameter [= value] [, ... ] )
ALTER INDEX [ IF EXISTS ] name RESET ( storage_parameter [, ... ] )
ALTER INDEX [ IF EXISTS ] name ALTER [ COLUMN ] column_number
SET STATISTICS integer
@@ -113,7 +113,7 @@ ALTER INDEX ALL IN TABLESPACE name
-SET ( storage_parameter = value [, ... ] )
+SET ( storage_parameter [= value] [, ... ] )
This form changes one or more index-method-specific storage parameters
diff --git a/doc/src/sgml/ref/alter_materialized_view.sgml b/doc/src/sgml/ref/alter_materialized_view.sgml
index 9df8a79977..7321183dd0 100644
--- a/doc/src/sgml/ref/alter_materialized_view.sgml
+++ b/doc/src/sgml/ref/alter_materialized_view.sgml
@@ -42,7 +42,7 @@ ALTER MATERIALIZED VIEW ALL IN TABLESPACE namecolumn_name SET STORAGE { PLAIN | EXTERNAL | EXTENDED | MAIN }
CLUSTER ON index_name
SET WITHOUT CLUSTER
-SET ( storage_parameter = value [, ... ] )
+SET ( storage_parameter [= value] [, ... ] )
RESET ( storage_parameter [, ... ] )
OWNER TO { new_owner | CURRENT_USER | SESSION_USER }
diff --git a/doc/src/sgml/ref/alter_table.sgml b/doc/src/sgml/ref/alter_table.sgml
index cbfb4828e5..b2eb7097a9 100644
--- a/doc/src/sgml/ref/alter_table.sgml
+++ b/doc/src/sgml/ref/alter_table.sgml
@@ -76,7 +76,7 @@ ALTER TABLE [ IF EXISTS ] name
SET WITHOUT OIDS
SET TABLESPACE new_tablespace
SET { LOGGED | UNLOGGED }
-SET ( storage_parameter = value [, ... ] )
+SET ( storage_parameter [= value] [, ... ] )
RESET ( storage_parameter [, ... ] )
INHERIT parent_table
NO INHERIT parent_table
@@ -702,7 +702,7 @@ WITH ( MODULUS numeric_literal, REM
-SET ( storage_parameter = value [, ... ] )
+SET ( storage_parameter [= value] [, ... ] )
This form changes one or more storage parameters for the table. See
diff --git a/doc/src/sgml/ref/create_index.sgml b/doc/src/sgml/ref/create_index.sgml
index ff87b2d28f..0edfc92f2e 100644
--- a/doc/src/sgml/ref/create_index.sgml
+++ b/doc/src/sgml/ref/create_index.sgml
@@ -24,7 +24,7 @@ PostgreSQL documentation
CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ] name ] ON [ ONLY ] table_name [ USING method ]
( { column_name | ( expression ) } [ COLLATE collation ] [ opclass [ ( opclass_parameter = value [, ... ] ) ] ] [ ASC | DESC ] [ NULLS { FIRST | LAST } ] [, ...] )
[ INCLUDE ( column_name [, ...] ) ]
-[ WITH ( storage_parameter = value [, ... ] ) ]
+[ WITH ( storage_parameter [= value] [, ... ] ) ]
[ TABLESPACE tablespace_name ]
[ WHERE predicate ]
@@ -375,6 +375,12 @@ CREATE [ UNIQUE ] INDEX [ CONCURRENTLY ] [ [ IF NOT EXISTS ]
+
+For boolean storage parameters, the
+value can be omitted; it is
+set to TRUE in that case.
+
+
fillfactor (integer)
diff --git a/doc/src/sgml/ref/create_table.sgml b/doc/src/sgml/re
Re: INDEX with optional storage parameter value
On Mon, Jun 29, 2020 at 04:18:58PM +0900, Michael Paquier wrote: > On Sat, Jun 27, 2020 at 05:14:23PM -0400, Bruce Momjian wrote: > > I found a few more places that also didn't properly document this; > > patch attached. > > Good catch! I am not seeing any missing spots, so this looks good to > me. You are planning a backpatch, right? Yes, backpatch. I found the pattern of areas needing fixes to be quite odd. ;-) -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Re: reindex database
On Sun, Jun 28, 2020 at 08:42:10PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/10/sql-reindex.html > Description: > > Hello, > I am using this command to reindex the databases for a PostgreSQL 10 > cluster. > What I can not find in the reindex explanation page is how is this affecting > the standby database. I tracked the log creation on the Primary cluster but > I saw nothing like this on the Standby cluster. > I was able to find the following statement on the hot-standby description > page (26.5. Hot Standby) from the documentation: > "As a result, you cannot create additional indexes that exist solely on the > standby, nor statistics that exist solely on the standby. If these > administration commands are needed, they should be executed on the primary, > and eventually those changes will propagate to the standby." > (https://www.postgresql.org/docs/10/hot-standby.html) > Can you please tell me more on this topic or point me to the documentation > page that explained more on this topic (database reindex - synching with the > standby cluster and impact on the standby cluster). > Thank you, > Andrei Bancila For full-cluster, non-logical replication, the data files on the primary and replicas have to be identical, so any reindex on the primary generates replayed WAL records to the replica to recreate the index. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Create Procedure
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/11/sql-createprocedure.html Description: Hi all, The Create Procedure could be improved: - Provide more examples; - Describe the use of IN and INOUT variables; - Describe the use of cursors.
Re: Create Procedure
On Mon, Jun 29, 2020 at 03:02:57PM +, PG Doc comments form wrote: > The following documentation comment has been logged on the website: > > Page: https://www.postgresql.org/docs/11/sql-createprocedure.html > Description: > > Hi all, > > The Create Procedure could be improved: > > - Provide more examples; > - Describe the use of IN and INOUT variables; > - Describe the use of cursors. You might find those in CREATE FUNCTION, which is similar. -- Bruce Momjian https://momjian.us EnterpriseDB https://enterprisedb.com The usefulness of a cup is in its emptiness, Bruce Lee
Re: The description for pg_replication_slots.restart_lsn
On 2020/06/25 14:48, Fujii Masao wrote: On 2020/06/25 10:00, Alvaro Herrera wrote: On 2020-Jun-17, Fujii Masao wrote: The document explains that restart_lsn column in pg_replication_slots view is: The address (LSN) of oldest WAL which still might be required by the consumer of this slot and thus won't be automatically removed during checkpoints. But the latter part is not true in v13 thanks to max_slot_wal_keep_size. I think that we need to update it as follows. Thought? The address (LSN) of oldest WAL which still might be required by the consumer of this slot and thus won't be automatically removed during checkpoints unless this LSN gets behind more than max_slot_wal_keep_size from the current LSN. We just added the invalidated_at LSN to replication slots; while working on the tests for that today, I was thinking that it might be useful to display that LSN in pg_replication_slots. What do you think of the idea of publishing the invalidated_at LSN in pg_replication_slot.restart_lsn when the slot is invalid? I like having separate column for invalidated_at because (at least for me) it's a bit confusing to report the different meaning values in the same column depending on the state. Is there any other objection to the patch? If nothing, I'd like to push it. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
