public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 5/6] Documentation for slot-limit feature
18+ messages / 7 participants
[nested] [flat]
* [PATCH 5/6] Documentation for slot-limit feature
@ 2018-01-11 06:00 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Kyotaro Horiguchi @ 2018-01-11 06:00 UTC (permalink / raw)
---
doc/src/sgml/catalogs.sgml | 28 ++++++++++++++++++++++++++++
doc/src/sgml/config.sgml | 23 +++++++++++++++++++++++
doc/src/sgml/high-availability.sgml | 8 +++++---
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index af4d0625ea..7ec8764ce5 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9825,6 +9825,34 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</entry>
</row>
+ <row>
+ <entry><structfield>wal_status</structfield></entry>
+ <entry><type>text</type></entry>
+ <entry></entry>
+
+ <entry>Availability of WAL records claimed by this
+ slot. <literal>streaming</literal>, <literal>keeping</literal>,
+ <literal>lost</literal>
+ or <literal>unknown</literal>. <literal>streaming</literal> means that
+ the claimed records are available. <literal>keeping</literal> means that
+ some of them are to be removed by the next checkpoint.
+ <literal>lost</literal> means that some of them are no longer
+ available. The last two states are seen only when
+ <xref linkend="guc-max-slot-wal-keep-size"/> is
+ non-negative. If <structfield>restart_lsn</structfield> is NULL, this
+ field is <literal>unknown</literal>.
+ </entry>
+ </row>
+
+ <row>
+ <entry><structfield>remain</structfield></entry>
+ <entry><type>bigint</type></entry>
+ <entry></entry>
+ <entry>The amount in bytes that WAL location (LSN) can advance until
+ this slot may lose required WAL records.
+ </entry>
+ </row>
+
</tbody>
</tgroup>
</table>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 4a7121a51f..3d034ac0d1 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3531,6 +3531,29 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</listitem>
</varlistentry>
+ <varlistentry id="guc-max-slot-wal-keep-size" xreflabel="max_slot_wal_keep_size">
+ <term><varname>max_slot_wal_keep_size</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>max_slot_wal_keep_size</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Specify the maximum size of WAL files
+ that <link linkend="streaming-replication-slots">replication
+ slots</link> are allowed to retain in the <filename>pg_wal</filename>
+ directory at checkpoint time.
+ If <varname>max_slot_wal_keep_size</varname> is -1 (the default),
+ replication slots retain unlimited size of WAL files. If restart_lsn
+ of a replication slot gets behind more than that bytes from the
+ current LSN, the standby using the slot may no longer be able to
+ reconnect due to removal of required WAL records. You can see the WAL
+ availability of replication slots
+ in <link linkend="view-pg-replication-slots">pg_replication_slots</link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-wal-sender-timeout" xreflabel="wal_sender_timeout">
<term><varname>wal_sender_timeout</varname> (<type>integer</type>)
<indexterm>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index d8fd195da0..e30eaaeebe 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -925,9 +925,11 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
<xref linkend="guc-archive-command"/>.
However, these methods often result in retaining more WAL segments than
required, whereas replication slots retain only the number of segments
- known to be needed. An advantage of these methods is that they bound
- the space requirement for <literal>pg_wal</literal>; there is currently no way
- to do this using replication slots.
+ known to be needed. On the other hand, replication slots can retain so
+ many WAL segments that they fill up the space allocated
+ for <literal>pg_wal</literal>;
+ <xref linkend="guc-max-slot-wal-keep-size"/> limits the size of WAL files
+ retained by replication slots.
</para>
<para>
Similarly, <xref linkend="guc-hot-standby-feedback"/>
--
2.16.3
----Next_Part(Thu_Dec_20_16_24_38_2018_792)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v11-0006-Check-removal-of-in-reading-segment-file.patch"
^ permalink raw reply [nested|flat] 18+ messages in thread
* [PATCH 4/4] Documentation for slot-limit feature
@ 2018-01-11 06:00 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Kyotaro Horiguchi @ 2018-01-11 06:00 UTC (permalink / raw)
---
doc/src/sgml/catalogs.sgml | 28 ++++++++++++++++++++++++++++
doc/src/sgml/config.sgml | 23 +++++++++++++++++++++++
doc/src/sgml/high-availability.sgml | 8 +++++---
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 0179deea2e..84a937e1fe 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9879,6 +9879,34 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</entry>
</row>
+ <row>
+ <entry><structfield>wal_status</structfield></entry>
+ <entry><type>text</type></entry>
+ <entry></entry>
+
+ <entry>Availability of WAL records claimed by the
+ slot. <literal>streaming</literal>, <literal>keeping</literal>,
+ <literal>lost</literal>
+ or <literal>unknown</literal>. <literal>streaming</literal> means that
+ the claimed records are available. <literal>keeping</literal> means that
+ some of them are to be removed by the next checkpoint.
+ <literal>lost</literal> means that some of them are no longer
+ available. The last two states are seen only when
+ <xref linkend="guc-max-slot-wal-keep-size"/> is non-negative. If the
+ slot doesn't have valid restart_lsn, this field
+ is <literal>unknown</literal>.
+ </entry>
+ </row>
+
+ <row>
+ <entry><structfield>remain</structfield></entry>
+ <entry><type>bigint</type></entry>
+ <entry></entry>
+ <entry>The amount in bytes that WAL location (LSN) can advance until the
+ slot may lose required WAL records.
+ </entry>
+ </row>
+
</tbody>
</tgroup>
</table>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index bee4afbe4e..edd5419ec6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3116,6 +3116,29 @@ include_dir 'conf.d'
</listitem>
</varlistentry>
+ <varlistentry id="guc-max-slot-wal-keep-size" xreflabel="max_slot_wal_keep_size">
+ <term><varname>max_slot_wal_keep_size</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>max_slot_wal_keep_size</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Specify the maximum size of WAL files
+ that <link linkend="streaming-replication-slots">replication
+ slots</link> are allowed to retain in the <filename>pg_wal</filename>
+ directory at checkpoint time.
+ If <varname>max_slot_wal_keep_size</varname> is -1 (the default),
+ replication slots retain unlimited size of WAL files. If restart_lsn
+ of a replication slot gets behind more than that bytes from the
+ current LSN, the standby using the slot may no longer be able to
+ reconnect due to removal of required WAL records. You can see the WAL
+ availability of replication slots
+ in <link linkend="view-pg-replication-slots">pg_replication_slots</link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-wal-sender-timeout" xreflabel="wal_sender_timeout">
<term><varname>wal_sender_timeout</varname> (<type>integer</type>)
<indexterm>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 8cb77f85ec..04cdccb10d 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -927,9 +927,11 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
<xref linkend="guc-archive-command"/>.
However, these methods often result in retaining more WAL segments than
required, whereas replication slots retain only the number of segments
- known to be needed. An advantage of these methods is that they bound
- the space requirement for <literal>pg_wal</literal>; there is currently no way
- to do this using replication slots.
+ known to be needed. On the other hand, replication slots can retain so
+ many WAL segments that they fill up the space allotted
+ for <literal>pg_wal</literal>;
+ <xref linkend="guc-max-slot-wal-keep-size"/> limits the size of WAL files
+ retained by replication slots.
</para>
<para>
Similarly, <xref linkend="guc-hot-standby-feedback"/>
--
2.16.3
----Next_Part(Thu_Sep_13_18_29_31_2018_032)----
^ permalink raw reply [nested|flat] 18+ messages in thread
* [PATCH 5/6] Documentation for slot-limit feature
@ 2018-01-11 06:00 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Kyotaro Horiguchi @ 2018-01-11 06:00 UTC (permalink / raw)
---
doc/src/sgml/catalogs.sgml | 28 ++++++++++++++++++++++++++++
doc/src/sgml/config.sgml | 23 +++++++++++++++++++++++
doc/src/sgml/high-availability.sgml | 8 +++++---
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index af4d0625ea..7ec8764ce5 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9825,6 +9825,34 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</entry>
</row>
+ <row>
+ <entry><structfield>wal_status</structfield></entry>
+ <entry><type>text</type></entry>
+ <entry></entry>
+
+ <entry>Availability of WAL records claimed by this
+ slot. <literal>streaming</literal>, <literal>keeping</literal>,
+ <literal>lost</literal>
+ or <literal>unknown</literal>. <literal>streaming</literal> means that
+ the claimed records are available. <literal>keeping</literal> means that
+ some of them are to be removed by the next checkpoint.
+ <literal>lost</literal> means that some of them are no longer
+ available. The last two states are seen only when
+ <xref linkend="guc-max-slot-wal-keep-size"/> is
+ non-negative. If <structfield>restart_lsn</structfield> is NULL, this
+ field is <literal>unknown</literal>.
+ </entry>
+ </row>
+
+ <row>
+ <entry><structfield>remain</structfield></entry>
+ <entry><type>bigint</type></entry>
+ <entry></entry>
+ <entry>The amount in bytes that WAL location (LSN) can advance until
+ this slot may lose required WAL records.
+ </entry>
+ </row>
+
</tbody>
</tgroup>
</table>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index b6f5822b84..7177c6122a 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3537,6 +3537,29 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</listitem>
</varlistentry>
+ <varlistentry id="guc-max-slot-wal-keep-size" xreflabel="max_slot_wal_keep_size">
+ <term><varname>max_slot_wal_keep_size</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>max_slot_wal_keep_size</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Specify the maximum size of WAL files
+ that <link linkend="streaming-replication-slots">replication
+ slots</link> are allowed to retain in the <filename>pg_wal</filename>
+ directory at checkpoint time.
+ If <varname>max_slot_wal_keep_size</varname> is -1 (the default),
+ replication slots retain unlimited size of WAL files. If restart_lsn
+ of a replication slot gets behind more than that bytes from the
+ current LSN, the standby using the slot may no longer be able to
+ reconnect due to removal of required WAL records. You can see the WAL
+ availability of replication slots
+ in <link linkend="view-pg-replication-slots">pg_replication_slots</link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-wal-sender-timeout" xreflabel="wal_sender_timeout">
<term><varname>wal_sender_timeout</varname> (<type>integer</type>)
<indexterm>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index bbab7395a2..79901c5f06 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -925,9 +925,11 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
<xref linkend="guc-archive-command"/>.
However, these methods often result in retaining more WAL segments than
required, whereas replication slots retain only the number of segments
- known to be needed. An advantage of these methods is that they bound
- the space requirement for <literal>pg_wal</literal>; there is currently no way
- to do this using replication slots.
+ known to be needed. On the other hand, replication slots can retain so
+ many WAL segments that they fill up the space allocated
+ for <literal>pg_wal</literal>;
+ <xref linkend="guc-max-slot-wal-keep-size"/> limits the size of WAL files
+ retained by replication slots.
</para>
<para>
Similarly, <xref linkend="guc-hot-standby-feedback"/>
--
2.16.3
----Next_Part(Wed_Jan_30_10_42_04_2019_681)--
Content-Type: Text/X-Patch; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="v12-0006-Check-removal-of-in-reading-segment-file.patch"
^ permalink raw reply [nested|flat] 18+ messages in thread
* [PATCH 4/4] Documentation for slot-limit feature
@ 2018-01-11 06:00 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Kyotaro Horiguchi @ 2018-01-11 06:00 UTC (permalink / raw)
---
doc/src/sgml/catalogs.sgml | 28 ++++++++++++++++++++++++++++
doc/src/sgml/config.sgml | 23 +++++++++++++++++++++++
doc/src/sgml/high-availability.sgml | 8 +++++---
3 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 9edba96fab..fc4cbc9239 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9881,6 +9881,34 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</entry>
</row>
+ <row>
+ <entry><structfield>wal_status</structfield></entry>
+ <entry><type>text</type></entry>
+ <entry></entry>
+
+ <entry>Availability of WAL records claimed by the
+ slot. <literal>streaming</literal>, <literal>keeping</literal>,
+ <literal>lost</literal>
+ or <literal>unknown</literal>. <literal>streaming</literal> means that
+ the claimed records are available. <literal>keeping</literal> means that
+ some of them are to be removed by the next checkpoint.
+ <literal>lost</literal> means that some of them are no longer
+ available. The last two states are seen only when
+ <xref linkend="guc-max-slot-wal-keep-size"/> is non-negative. If the
+ slot doesn't have valid restart_lsn, this field
+ is <literal>unknown</literal>.
+ </entry>
+ </row>
+
+ <row>
+ <entry><structfield>remain</structfield></entry>
+ <entry><type>bigint</type></entry>
+ <entry></entry>
+ <entry>The amount in bytes that WAL location (LSN) can advance until the
+ slot may lose required WAL records.
+ </entry>
+ </row>
+
</tbody>
</tgroup>
</table>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 7554cba3f9..f3e504862c 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3117,6 +3117,29 @@ include_dir 'conf.d'
</listitem>
</varlistentry>
+ <varlistentry id="guc-max-slot-wal-keep-size" xreflabel="max_slot_wal_keep_size">
+ <term><varname>max_slot_wal_keep_size</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>max_slot_wal_keep_size</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Specify the maximum size of WAL files
+ that <link linkend="streaming-replication-slots">replication
+ slots</link> are allowed to retain in the <filename>pg_wal</filename>
+ directory at checkpoint time.
+ If <varname>max_slot_wal_keep_size</varname> is -1 (the default),
+ replication slots retain unlimited size of WAL files. If restart_lsn
+ of a replication slot gets behind more than that bytes from the
+ current LSN, the standby using the slot may no longer be able to
+ reconnect due to removal of required WAL records. You can see the WAL
+ availability of replication slots
+ in <link linkend="view-pg-replication-slots">pg_replication_slots</link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-wal-sender-timeout" xreflabel="wal_sender_timeout">
<term><varname>wal_sender_timeout</varname> (<type>integer</type>)
<indexterm>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index ebcb3daaed..15a98340a6 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -927,9 +927,11 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
<xref linkend="guc-archive-command"/>.
However, these methods often result in retaining more WAL segments than
required, whereas replication slots retain only the number of segments
- known to be needed. An advantage of these methods is that they bound
- the space requirement for <literal>pg_wal</literal>; there is currently no way
- to do this using replication slots.
+ known to be needed. On the other hand, replication slots can retain so
+ many WAL segments that they fill up the space allotted
+ for <literal>pg_wal</literal>;
+ <xref linkend="guc-max-slot-wal-keep-size"/> limits the size of WAL files
+ retained by replication slots.
</para>
<para>
Similarly, <xref linkend="guc-hot-standby-feedback"/>
--
2.16.3
----Next_Part(Thu_Oct_25_21_55_18_2018_318)----
^ permalink raw reply [nested|flat] 18+ messages in thread
* [PATCH 4/4] Documentation for slot-limit feature
@ 2018-01-11 06:00 Kyotaro Horiguchi <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Kyotaro Horiguchi @ 2018-01-11 06:00 UTC (permalink / raw)
---
doc/src/sgml/catalogs.sgml | 28 ++++++++++++++++++++++++++++
doc/src/sgml/config.sgml | 22 ++++++++++++++++++++++
doc/src/sgml/high-availability.sgml | 8 +++++---
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
index 07e8b3325f..7e31267d68 100644
--- a/doc/src/sgml/catalogs.sgml
+++ b/doc/src/sgml/catalogs.sgml
@@ -9887,6 +9887,34 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
</entry>
</row>
+ <row>
+ <entry><structfield>wal_status</structfield></entry>
+ <entry><type>text</type></entry>
+ <entry></entry>
+
+ <entry>Availability of WAL records claimed by the
+ slot. <literal>streaming</literal>, <literal>keeping</literal>,
+ <literal>lost</literal>
+ or <literal>unknown</literal>. <literal>streaming</literal> means that
+ the claimed records are available. <literal>keeping</literal> means that
+ some of them are to be removed by the next checkpoint.
+ <literal>lost</literal> means that some of them have been removed. The
+ last two states are seen only when
+ <xref linkend="guc-max-slot-wal-keep-size"/> is not zero. If the slot
+ doesn't have valid restart_lsn, this field
+ is <literal>unknown</literal>.
+ </entry>
+ </row>
+
+ <row>
+ <entry><structfield>remain</structfield></entry>
+ <entry><type>bigint</type></entry>
+ <entry></entry>
+ <entry>The amount in bytes that WAL location (LSN) can advance until the
+ slot may lose required WAL records.
+ </entry>
+ </row>
+
</tbody>
</tgroup>
</table>
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index bee4afbe4e..9d190c3daa 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3116,6 +3116,28 @@ include_dir 'conf.d'
</listitem>
</varlistentry>
+ <varlistentry id="guc-max-slot-wal-keep-size" xreflabel="max_slot_wal_keep_size">
+ <term><varname>max_slot_wal_keep_size</varname> (<type>integer</type>)
+ <indexterm>
+ <primary><varname>max_slot_wal_keep_size</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Specify the maximum size of WAL files
+ that <link linkend="streaming-replication-slots">replication
+ slots</link> are allowed to retain in the <filename>pg_wal</filename>
+ directory at checkpoint time.
+ If <varname>max_slot_wal_keep_size</varname> is zero (the default),
+ replication slots retain unlimited size of WAL files.
+ </para>
+ <para>
+ This parameter is used being rounded down to the multiples of WAL file
+ size.
+ </para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="guc-wal-sender-timeout" xreflabel="wal_sender_timeout">
<term><varname>wal_sender_timeout</varname> (<type>integer</type>)
<indexterm>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 8cb77f85ec..04cdccb10d 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -927,9 +927,11 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
<xref linkend="guc-archive-command"/>.
However, these methods often result in retaining more WAL segments than
required, whereas replication slots retain only the number of segments
- known to be needed. An advantage of these methods is that they bound
- the space requirement for <literal>pg_wal</literal>; there is currently no way
- to do this using replication slots.
+ known to be needed. On the other hand, replication slots can retain so
+ many WAL segments that they fill up the space allotted
+ for <literal>pg_wal</literal>;
+ <xref linkend="guc-max-slot-wal-keep-size"/> limits the size of WAL files
+ retained by replication slots.
</para>
<para>
Similarly, <xref linkend="guc-hot-standby-feedback"/>
--
2.16.3
----Next_Part(Tue_Sep_04_19_52_50_2018_992)----
^ permalink raw reply [nested|flat] 18+ messages in thread
* [PATCH 05/10] Add opclass parameters to BRIN
@ 2019-06-10 16:49 Tomas Vondra <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Tomas Vondra @ 2019-06-10 16:49 UTC (permalink / raw)
---
src/backend/access/brin/brin.c | 10 ++++++++++
src/backend/access/brin/brin_validate.c | 16 ++++++++++------
src/include/access/brin.h | 2 +-
src/include/access/brin_internal.h | 3 +++
src/include/catalog/pg_proc.dat | 12 ++++++------
5 files changed, 30 insertions(+), 13 deletions(-)
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index ae7b729edd..63f2d7990c 100644
--- a/src/backend/access/brin/brin.c
+++ b/src/backend/access/brin/brin.c
@@ -102,6 +102,7 @@ brinhandler(PG_FUNCTION_ARGS)
amroutine->amcanparallel = false;
amroutine->amcaninclude = false;
amroutine->amkeytype = InvalidOid;
+ amroutine->amopclassoptions = brinopclassoptions;
amroutine->ambuild = brinbuild;
amroutine->ambuildempty = brinbuildempty;
@@ -518,6 +519,7 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
PointerGetDatum(bval),
PointerGetDatum(key));
addrange = DatumGetBool(add);
+
if (!addrange)
break;
}
@@ -845,6 +847,14 @@ brinoptions(Datum reloptions, bool validate)
return (bytea *) rdopts;
}
+bytea *
+brinopclassoptions(Relation index, AttrNumber attnum, Datum attoptions,
+ bool validate)
+{
+ return index_opclass_options_generic(index, attnum, BRIN_OPCLASSOPT_PROC,
+ attoptions, validate);
+}
+
/*
* SQL-callable function to scan through an index and summarize all ranges
* that are not currently summarized.
diff --git a/src/backend/access/brin/brin_validate.c b/src/backend/access/brin/brin_validate.c
index 012933833b..4222a1781f 100644
--- a/src/backend/access/brin/brin_validate.c
+++ b/src/backend/access/brin/brin_validate.c
@@ -93,18 +93,22 @@ brinvalidate(Oid opclassoid)
break;
case BRIN_PROCNUM_ADDVALUE:
ok = check_amproc_signature(procform->amproc, BOOLOID, true,
- 4, 4, INTERNALOID, INTERNALOID,
- INTERNALOID, INTERNALOID);
+ 4, 5, INTERNALOID, INTERNALOID,
+ INTERNALOID, INTERNALOID, INTERNALOID);
break;
case BRIN_PROCNUM_CONSISTENT:
ok = check_amproc_signature(procform->amproc, BOOLOID, true,
- 3, 3, INTERNALOID, INTERNALOID,
- INTERNALOID);
+ 3, 4, INTERNALOID, INTERNALOID,
+ INTERNALOID, INTERNALOID);
break;
case BRIN_PROCNUM_UNION:
ok = check_amproc_signature(procform->amproc, BOOLOID, true,
- 3, 3, INTERNALOID, INTERNALOID,
- INTERNALOID);
+ 3, 4, INTERNALOID, INTERNALOID,
+ INTERNALOID, INTERNALOID);
+ break;
+ case BRIN_OPCLASSOPT_PROC:
+ ok = check_amproc_signature(procform->amproc, INTERNALOID, false,
+ 2, 2, INTERNALOID, BOOLOID);
break;
default:
/* Complain if it's not a valid optional proc number */
diff --git a/src/include/access/brin.h b/src/include/access/brin.h
index 612721baf3..8271404332 100644
--- a/src/include/access/brin.h
+++ b/src/include/access/brin.h
@@ -37,6 +37,7 @@ typedef struct BrinStatsData
#define BRIN_DEFAULT_PAGES_PER_RANGE 128
+
#define BrinGetPagesPerRange(relation) \
((relation)->rd_options ? \
((BrinOptions *) (relation)->rd_options)->pagesPerRange : \
@@ -46,7 +47,6 @@ typedef struct BrinStatsData
((BrinOptions *) (relation)->rd_options)->autosummarize : \
false)
-
extern void brinGetStats(Relation index, BrinStatsData *stats);
#endif /* BRIN_H */
diff --git a/src/include/access/brin_internal.h b/src/include/access/brin_internal.h
index b1c9199946..0532094e28 100644
--- a/src/include/access/brin_internal.h
+++ b/src/include/access/brin_internal.h
@@ -68,6 +68,7 @@ typedef struct BrinDesc
#define BRIN_PROCNUM_ADDVALUE 2
#define BRIN_PROCNUM_CONSISTENT 3
#define BRIN_PROCNUM_UNION 4
+#define BRIN_OPCLASSOPT_PROC 5 /* optional */
#define BRIN_MANDATORY_NPROCS 4
/* procedure numbers up to 10 are reserved for BRIN future expansion */
#define BRIN_FIRST_OPTIONAL_PROCNUM 11
@@ -103,6 +104,8 @@ extern IndexBulkDeleteResult *brinbulkdelete(IndexVacuumInfo *info,
extern IndexBulkDeleteResult *brinvacuumcleanup(IndexVacuumInfo *info,
IndexBulkDeleteResult *stats);
extern bytea *brinoptions(Datum reloptions, bool validate);
+extern bytea *brinopclassoptions(Relation index, AttrNumber colno,
+ Datum attoptions, bool validate);
/* brin_validate.c */
extern bool brinvalidate(Oid opclassoid);
diff --git a/src/include/catalog/pg_proc.dat b/src/include/catalog/pg_proc.dat
index 82b51fc1bb..bc3d08caec 100644
--- a/src/include/catalog/pg_proc.dat
+++ b/src/include/catalog/pg_proc.dat
@@ -7887,15 +7887,15 @@
proargtypes => 'internal', prosrc => 'brin_minmax_opcinfo' },
{ oid => '3384', descr => 'BRIN minmax support',
proname => 'brin_minmax_add_value', prorettype => 'bool',
- proargtypes => 'internal internal internal internal',
+ proargtypes => 'internal internal internal internal internal',
prosrc => 'brin_minmax_add_value' },
{ oid => '3385', descr => 'BRIN minmax support',
proname => 'brin_minmax_consistent', prorettype => 'bool',
- proargtypes => 'internal internal internal',
+ proargtypes => 'internal internal internal internal',
prosrc => 'brin_minmax_consistent' },
{ oid => '3386', descr => 'BRIN minmax support',
proname => 'brin_minmax_union', prorettype => 'bool',
- proargtypes => 'internal internal internal', prosrc => 'brin_minmax_union' },
+ proargtypes => 'internal internal internal internal', prosrc => 'brin_minmax_union' },
# BRIN inclusion
{ oid => '4105', descr => 'BRIN inclusion support',
@@ -7903,15 +7903,15 @@
proargtypes => 'internal', prosrc => 'brin_inclusion_opcinfo' },
{ oid => '4106', descr => 'BRIN inclusion support',
proname => 'brin_inclusion_add_value', prorettype => 'bool',
- proargtypes => 'internal internal internal internal',
+ proargtypes => 'internal internal internal internal internal',
prosrc => 'brin_inclusion_add_value' },
{ oid => '4107', descr => 'BRIN inclusion support',
proname => 'brin_inclusion_consistent', prorettype => 'bool',
- proargtypes => 'internal internal internal',
+ proargtypes => 'internal internal internal internal',
prosrc => 'brin_inclusion_consistent' },
{ oid => '4108', descr => 'BRIN inclusion support',
proname => 'brin_inclusion_union', prorettype => 'bool',
- proargtypes => 'internal internal internal',
+ proargtypes => 'internal internal internal internal',
prosrc => 'brin_inclusion_union' },
# userlock replacements
--
2.20.1
--54rc27wh4iahvygf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
filename="0006-Pass-all-keys-to-BRIN-consistent-function-a-20190611.patch"
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
@ 2024-12-20 21:41 Trey Boudreau <[email protected]>
2024-12-20 21:49 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 21:57 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
0 siblings, 3 replies; 18+ messages in thread
From: Trey Boudreau @ 2024-12-20 21:41 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
> On Dec 20, 2024, at 2:58 PM, Tom Lane <[email protected]> wrote:
> Seems reasonable in the abstract, and given the UNLISTEN * precedent
> it's hard to quibble with that syntax choice. I think what actually
> needs discussing are the semantics, specifically how this'd interact
> with other LISTEN/UNLISTEN actions.
My first pass at the documentation looks like this:
<para>
The special wildcard <literal>*</literal> cancels all listener
registrations for the current session and replaces them with a
virtual registration that matches all channels. Further
<command>LISTEN</command> and <command>UNLISTEN <replaceable
class="parameter">channel</replaceable></command> commands will
be ignored until the session sees the <command>UNLISTEN *</command>
command.
</para>
> Explain what you think should
> be the behavior after:
>
> LISTEN foo;
> LISTEN *;
> UNLISTEN *;
> -- are we still listening on foo?
>
No, as the ‘LISTEN *’ wipes existing registrations.
> LISTEN *;
> LISTEN foo;
> UNLISTEN *;
> -- how about now?
Not listening on ‘foo’ or anything else.
> LISTEN *;
> UNLISTEN foo;
> -- how about now?
‘UNLISTEN foo’ ignored.
> LISTEN *;
> LISTEN foo;
> UNLISTEN foo;
> -- does that make a difference?
‘LISTEN foo’ and ‘UNLISTEN foo’ ignored, leaving only the wildcard.
> I don't have any strong preferences about this, but we ought to
> have a clear idea of the behavior we want before we start coding.
These semantics made sense to me, but I have limited experience and
a very specific use case in mind. Changing the behavior of ‘UNLISTEN *’
feels extremely impolite, and if we leave that alone I don’t see using
the ‘LISTEN *’ syntax with behavior that leaves other LISTENs in place.
We could have a different set of keywords, like LISTEN_ALL/UNLISTEN_ALL
that doesn’t interfere with the existing behavior.
-- Trey
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
@ 2024-12-20 21:49 ` David G. Johnston <[email protected]>
2 siblings, 0 replies; 18+ messages in thread
From: David G. Johnston @ 2024-12-20 21:49 UTC (permalink / raw)
To: Trey Boudreau <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers
On Fri, Dec 20, 2024 at 2:42 PM Trey Boudreau <[email protected]> wrote:
>
> > On Dec 20, 2024, at 2:58 PM, Tom Lane <[email protected]> wrote:
> > Seems reasonable in the abstract, and given the UNLISTEN * precedent
> > it's hard to quibble with that syntax choice. I think what actually
> > needs discussing are the semantics, specifically how this'd interact
> > with other LISTEN/UNLISTEN actions.
>
> My first pass at the documentation looks like this:
>
> <para>
> The special wildcard <literal>*</literal> cancels all listener
> registrations for the current session and replaces them with a
> virtual registration that matches all channels. Further
> <command>LISTEN</command> and <command>UNLISTEN <replaceable
> class="parameter">channel</replaceable></command> commands will
> be ignored until the session sees the <command>UNLISTEN *</command>
> command.
> </para>
>
I just sent my thoughts here as well. The choice to "cancel all listener
registrations" seems unintuitive and unnecessary - so long as we either
document or handle deduplication internally.
As I noted in my email, * is a permit-all policy in a "deny by default"
system. Such a system is allowed to have other more targeted "allow"
policies existing at the same time. If the permit-all policy gets removed
then those individual allow policies immediately become useful again. If
you want to remove those targeted allowed policies execute Unlisten *
before executing Listen *.
I dislike the non-symmetric meaning of * in the command sequence above but
it likely is better than inventing a whole new syntax.
David J.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
@ 2024-12-20 21:57 ` David G. Johnston <[email protected]>
2 siblings, 0 replies; 18+ messages in thread
From: David G. Johnston @ 2024-12-20 21:57 UTC (permalink / raw)
To: Trey Boudreau <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers
On Fri, Dec 20, 2024 at 2:42 PM Trey Boudreau <[email protected]> wrote:
> We could have a different set of keywords, like LISTEN_ALL/UNLISTEN_ALL
> that doesn’t interfere with the existing behavior.
>
>
I think we will need something along these lines. We've given * a meaning
in UNLISTEN * that doesn't match what this proposal wants to accomplish.
I suggested using monitor/unmonitor but I suppose any unquoted symbol or
keyword that is invalid as a channel name would work within the
Listen/Unlisten syntax.
Otherwise I mis-spoke in my previous design since regardless of whether
Listen * unregisters existing channels or not Unlisten * will remove
everything and leave the session back at nothing. In which case you might
as well just remove the redundant channel listeners.
David J.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
@ 2024-12-20 22:07 ` Tom Lane <[email protected]>
2024-12-20 22:23 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 22:47 ` Re: Discussion on a LISTEN-ALL syntax Daniel Gustafsson <[email protected]>
2024-12-22 18:53 ` Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2 siblings, 3 replies; 18+ messages in thread
From: Tom Lane @ 2024-12-20 22:07 UTC (permalink / raw)
To: Trey Boudreau <[email protected]>; +Cc: pgsql-hackers
Trey Boudreau <[email protected]> writes:
> My first pass at the documentation looks like this:
> <para>
> The special wildcard <literal>*</literal> cancels all listener
> registrations for the current session and replaces them with a
> virtual registration that matches all channels. Further
> <command>LISTEN</command> and <command>UNLISTEN <replaceable
> class="parameter">channel</replaceable></command> commands will
> be ignored until the session sees the <command>UNLISTEN *</command>
> command.
> </para>
Hmph. After thinking about it a bit I have a different idea
(and I see David has yet a third one). So maybe this is more
contentious than it seems. But at any rate, I have two
fundamental thoughts:
* "Listen to all but X" seems like a reasonable desire.
* The existing implementation already has the principle that
you can't listen to a channel more than once; that is,
LISTEN foo;
LISTEN foo; -- this is a no-op, not a duplicate subscription
Therefore I propose:
* "LISTEN *" wipes away all previous listen state, and
sets up a state where you're listening to all channels
(within your database).
* "UNLISTEN *" wipes away all previous listen state, and
sets up a state where you're listening to no channels
(which is the same as it does now).
* "LISTEN foo" adds "foo" to what you are listening to,
with no effect if you already were listening to foo
(whether it was a virtual or explicit listen).
* "UNLISTEN foo" removes "foo" from what you are listening to,
with no effect if you already weren't listening to foo.
This is just about the same as the current behavior, and it makes
"LISTEN *" act the same as though you had somehow explicitly listed
every possible channel. Which I think is a lot cleaner than
conceptualizing it as an independent gating behavior, as well
as more useful because it'll permit "all but" behavior.
The implementation of this could be something like
struct {
bool all; /* true if listening to all */
List *plus; /* channels explicitly listened */
List *minus; /* channels explicitly unlistened */
} ListenChannels;
with the proviso that "plus" must be empty if "all" is true,
while "minus" must be empty if "all" is false. The two lists
are always empty right after LISTEN * or UNLISTEN *, but could
be manipulated by subsequent channel-specific LISTEN/UNLISTEN.
(Since only one list would be in use at a time, you could
alternatively combine "plus" and "minus" into a single list
of exceptions to the all/none state. I suspect that would
be confusingly error-prone to code; but perhaps it would turn
out elegantly.)
One other thing that needs to be thought about in any case
is what the pg_listening_channels() function ought to return
in these newly-possible states.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
@ 2024-12-20 22:23 ` David G. Johnston <[email protected]>
2024-12-20 22:45 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2 siblings, 1 reply; 18+ messages in thread
From: David G. Johnston @ 2024-12-20 22:23 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Trey Boudreau <[email protected]>; pgsql-hackers
On Friday, December 20, 2024, Tom Lane <[email protected]> wrote:
> Trey Boudreau <[email protected]> writes:
>
> * "Listen to all but X" seems like a reasonable desire.
>
This I concur with, and would add: let me name my channels
accounting.payables, accounting.receivables, sales.leads; and let me listen
or ignore all accounting/sales channel names.
But staying within the existing “deny default, permissive grants only”
design to meet this specific goal seems like a reasonable incremental step
to accept. Let others wanting to work on a more expansive capability
change brings those patches forth.
As for exposing this to the user, this allow-all “channel” would be
presented as any other normal channel. The reader would need to know about
the special meaning of whatever label we end up using. IOW, the wildcard is
the label and no attempt to tie real in-use channel names to it should or
even could be attempted.
David J.
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-20 22:23 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
@ 2024-12-20 22:45 ` Tom Lane <[email protected]>
2024-12-21 04:12 ` Re: Discussion on a LISTEN-ALL syntax Vik Fearing <[email protected]>
2024-12-21 17:42 ` Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
0 siblings, 2 replies; 18+ messages in thread
From: Tom Lane @ 2024-12-20 22:45 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: Trey Boudreau <[email protected]>; pgsql-hackers
"David G. Johnston" <[email protected]> writes:
> On Friday, December 20, 2024, Tom Lane <[email protected]> wrote:
>> * "Listen to all but X" seems like a reasonable desire.
> This I concur with, and would add: let me name my channels
> accounting.payables, accounting.receivables, sales.leads; and let me listen
> or ignore all accounting/sales channel names.
Hmm. That reminds me that there was recently a proposal to allow
LISTEN/UNLISTEN with pattern arguments. (It wasn't anything you'd
expect like regex patterns or LIKE patterns, but some off-the-wall
syntax, which I doubt we'd accept in that form. But clearly there's
some desire for that out there.)
While I don't say we need to implement that as part of this,
it'd be a good idea to anticipate that that will happen. And
that kind of blows a hole in my idea, because mine was predicated on
the assumption that you could unambiguously match UNLISTENs against
LISTENs. A patterned UNLISTEN might revoke a superset or subset
of previous LISTENs, and I'm not sure you could readily tell which.
I think we can still hold to the idea that LISTEN * or UNLISTEN *
cancels all previous requests, but it's feeling like we might
have to accumulate subsequent requests without trying to make
contradictory ones cancel out. Is it okay if the behavior is
explicitly dependent on the order of those requests, more or
less "last match wins"? If not, how do we avoid that?
> As for exposing this to the user, this allow-all “channel” would be
> presented as any other normal channel. The reader would need to know about
> the special meaning of whatever label we end up using. IOW, the wildcard is
> the label and no attempt to tie real in-use channel names to it should or
> even could be attempted.
Don't think that quite flies. We might have to regurgitate the
state explicitly:
LISTEN *
UNLISTEN foo.*
LISTEN foo.bar.*
showing that we're listening to channels foo.bar.*, but not other
channels beginning "foo", and also to all channels not beginning
"foo".
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-20 22:23 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 22:45 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
@ 2024-12-21 04:12 ` Vik Fearing <[email protected]>
2024-12-21 04:23 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
1 sibling, 1 reply; 18+ messages in thread
From: Vik Fearing @ 2024-12-21 04:12 UTC (permalink / raw)
To: Tom Lane <[email protected]>; David G. Johnston <[email protected]>; +Cc: Trey Boudreau <[email protected]>; pgsql-hackers
On 20/12/2024 23:45, Tom Lane wrote:
> Don't think that quite flies. We might have to regurgitate the
> state explicitly:
>
> LISTEN *
> UNLISTEN foo.*
> LISTEN foo.bar.*
>
> showing that we're listening to channels foo.bar.*, but not other
> channels beginning "foo", and also to all channels not beginning
> "foo".
Could I perhaps propose a sort of wildmat[1] syntax?
The above sequence could be expressed simply as:
LISTEN *,!foo.*,foo.bar.*
I would like this in psql's backslash commands, too.
[1] https://en.wikipedia.org/wiki/Wildmat
--
Vik Fearing
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-20 22:23 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 22:45 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-21 04:12 ` Re: Discussion on a LISTEN-ALL syntax Vik Fearing <[email protected]>
@ 2024-12-21 04:23 ` Tom Lane <[email protected]>
2024-12-21 05:22 ` Re: Discussion on a LISTEN-ALL syntax Vik Fearing <[email protected]>
0 siblings, 1 reply; 18+ messages in thread
From: Tom Lane @ 2024-12-21 04:23 UTC (permalink / raw)
To: Vik Fearing <[email protected]>; +Cc: David G. Johnston <[email protected]>; Trey Boudreau <[email protected]>; pgsql-hackers
Vik Fearing <[email protected]> writes:
> Could I perhaps propose a sort of wildmat[1] syntax?
> The above sequence could be expressed simply as:
> LISTEN *,!foo.*,foo.bar.*
That doesn't absolve you from having to say what happens if the
user then issues another "LISTEN zed" or "UNLISTEN foo.bar.baz"
command. We can't break the existing behavior that "LISTEN foo"
followed by "LISTEN bar" results in listening to both channels.
So on the whole this seems like it just adds complexity without
removing any. I'm inclined to limit things to one pattern per
LISTEN/UNLISTEN command, with more complex behaviors reached
by issuing a sequence of commands.
regards, tom lane
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-20 22:23 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 22:45 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-21 04:12 ` Re: Discussion on a LISTEN-ALL syntax Vik Fearing <[email protected]>
2024-12-21 04:23 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
@ 2024-12-21 05:22 ` Vik Fearing <[email protected]>
0 siblings, 0 replies; 18+ messages in thread
From: Vik Fearing @ 2024-12-21 05:22 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; Trey Boudreau <[email protected]>; pgsql-hackers
On 21/12/2024 05:23, Tom Lane wrote:
> Vik Fearing <[email protected]> writes:
>> Could I perhaps propose a sort of wildmat[1] syntax?
>> The above sequence could be expressed simply as:
>> LISTEN *,!foo.*,foo.bar.*
> That doesn't absolve you from having to say what happens if the
> user then issues another "LISTEN zed" or "UNLISTEN foo.bar.baz"
> command. We can't break the existing behavior that "LISTEN foo"
> followed by "LISTEN bar" results in listening to both channels.
> So on the whole this seems like it just adds complexity without
> removing any. I'm inclined to limit things to one pattern per
> LISTEN/UNLISTEN command, with more complex behaviors reached
> by issuing a sequence of commands.
Fair enough.
--
Vik Fearing
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-20 22:23 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 22:45 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
@ 2024-12-21 17:42 ` Trey Boudreau <[email protected]>
1 sibling, 0 replies; 18+ messages in thread
From: Trey Boudreau @ 2024-12-21 17:42 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-hackers
> On Dec 20, 2024, at 4:45 PM, Tom Lane <[email protected]> wrote:
>
> "David G. Johnston" <[email protected]> writes:
>> On Friday, December 20, 2024, Tom Lane <[email protected]> wrote:
>>> * "Listen to all but X" seems like a reasonable desire.
>
>> This I concur with, and would add: let me name my channels
>> accounting.payables, accounting.receivables, sales.leads; and let me listen
>> or ignore all accounting/sales channel names.
>
> Hmm. That reminds me that there was recently a proposal to allow
> LISTEN/UNLISTEN with pattern arguments. (It wasn't anything you'd
> expect like regex patterns or LIKE patterns, but some off-the-wall
> syntax, which I doubt we'd accept in that form. But clearly there's
> some desire for that out there.)
>
I dug into the archives prior to starting this discussion. If folks really want
this then someone should probably promote the ‘ltree’ data type from contrib
to built-in and reuse the matching code. NOTIFY, LISTEN, and UNLISTEN
all use ‘ColId’ in the grammar, limiting patterns to NAMEDATALEN, and that
probably needs to change. I didn’t propose it because it seemed like too big
of a lift for a newbie project.
> While I don't say we need to implement that as part of this,
> it'd be a good idea to anticipate that that will happen. And
> that kind of blows a hole in my idea, because mine was predicated on
> the assumption that you could unambiguously match UNLISTENs against
> LISTENs. A patterned UNLISTEN might revoke a superset or subset
> of previous LISTENs, and I'm not sure you could readily tell which.
>
A version of LISTEN/UNLISTEN that accepts real patterns probably
wants a new keyword, like LISTEN_LTREE. If someone uses the new keyword
then they explicitly opt-out of non-pattern searches, perhaps?
> I think we can still hold to the idea that LISTEN * or UNLISTEN *
> cancels all previous requests, but it's feeling like we might
> have to accumulate subsequent requests without trying to make
> contradictory ones cancel out. Is it okay if the behavior is
> explicitly dependent on the order of those requests, more or
> less "last match wins"? If not, how do we avoid that?
I’d like a solution that doesn’t require walking the entire exception list. From
your earlier email I started sketching up something based on simplehash.h,
but that doesn’t lend itself to any sort of pattern matching. I don’t think you
can go too far down the road of resolving pattern matching conflicts until
we settle on the pattern matching technique. It feels like it will devolve to
dynamically assembling some kind of unified regex tree from the various
include/exclude patterns. I’d want to do a pretty serious literature search
to see if someone has already solved the problem.
Can/Should we stick to something simpler for now?
-- Trey
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
@ 2024-12-20 22:47 ` Daniel Gustafsson <[email protected]>
2 siblings, 0 replies; 18+ messages in thread
From: Daniel Gustafsson @ 2024-12-20 22:47 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Trey Boudreau <[email protected]>; pgsql-hackers
> On 20 Dec 2024, at 23:07, Tom Lane <[email protected]> wrote:
> ..it makes "LISTEN *" act the same as though you had somehow explicitly listed
> every possible channel.
When thinking about it while reading this thread, this is what I came up with
as well. Since the current workings of LISTEN is so well established I can't
see how we could make this anything but a natural extension of the current.
--
Daniel Gustafsson
^ permalink raw reply [nested|flat] 18+ messages in thread
* Re: Discussion on a LISTEN-ALL syntax
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
@ 2024-12-22 18:53 ` Trey Boudreau <[email protected]>
2 siblings, 0 replies; 18+ messages in thread
From: Trey Boudreau @ 2024-12-22 18:53 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: pgsql-hackers
> On Dec 20, 2024, at 4:07 PM, Tom Lane <[email protected]> wrote:
>
> Hmph. After thinking about it a bit I have a different idea
> (and I see David has yet a third one). So maybe this is more
> contentious than it seems. But at any rate, I have two
> fundamental thoughts:
>
> * "Listen to all but X" seems like a reasonable desire.
>
> * The existing implementation already has the principle that
> you can't listen to a channel more than once; that is,
> LISTEN foo;
> LISTEN foo; -- this is a no-op, not a duplicate subscription
>
> Therefore I propose:
>
> * "LISTEN *" wipes away all previous listen state, and
> sets up a state where you're listening to all channels
> (within your database).
>
> * "UNLISTEN *" wipes away all previous listen state, and
> sets up a state where you're listening to no channels
> (which is the same as it does now).
>
> * "LISTEN foo" adds "foo" to what you are listening to,
> with no effect if you already were listening to foo
> (whether it was a virtual or explicit listen).
>
> * "UNLISTEN foo" removes "foo" from what you are listening to,
> with no effect if you already weren't listening to foo.
>
I have an implementation of this that replaces List with a simplehash.h
variant, merging 'plus/minus' as ‘exceptions’.
> One other thing that needs to be thought about in any case
> is what the pg_listening_channels() function ought to return
> in these newly-possible states.
>
My previous cut at this replaced the list with ‘*’, but since we now
allow exceptions, how about preceding the list with ‘*” in the
Want-all case, following with the list of exceptions?
In another branch of this discussion covering patterns I mentioned
building a tree of regular expressions. If we go with the notion of
‘want-all/want-none, with exceptions’ then we could introduce a
function like ‘pg_listens_use_regexes(bool)’. When true we’d
build a pre-parsed regex from the exception list by encapsulating
the patterns in something like ‘(^’<pattern>‘$)’ and aggregating with ‘|’.
We could alternatively have ‘pg_listen_pattern(style)’, with style
choices of IDENT (current behavior), REGEX, LTREE, LIKE, etc.
So long as we treated all of the exceptions as the same type it seems
pretty sane. Allowing mixing would take lots of work.
-- Trey
^ permalink raw reply [nested|flat] 18+ messages in thread
end of thread, other threads:[~2024-12-22 18:53 UTC | newest]
Thread overview: 18+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-01-11 06:00 [PATCH 5/6] Documentation for slot-limit feature Kyotaro Horiguchi <[email protected]>
2018-01-11 06:00 [PATCH 4/4] Documentation for slot-limit feature Kyotaro Horiguchi <[email protected]>
2018-01-11 06:00 [PATCH 5/6] Documentation for slot-limit feature Kyotaro Horiguchi <[email protected]>
2018-01-11 06:00 [PATCH 4/4] Documentation for slot-limit feature Kyotaro Horiguchi <[email protected]>
2018-01-11 06:00 [PATCH 4/4] Documentation for slot-limit feature Kyotaro Horiguchi <[email protected]>
2019-06-10 16:49 [PATCH 05/10] Add opclass parameters to BRIN Tomas Vondra <[email protected]>
2024-12-20 21:41 Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 21:49 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 21:57 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 22:07 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-20 22:23 ` Re: Discussion on a LISTEN-ALL syntax David G. Johnston <[email protected]>
2024-12-20 22:45 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-21 04:12 ` Re: Discussion on a LISTEN-ALL syntax Vik Fearing <[email protected]>
2024-12-21 04:23 ` Re: Discussion on a LISTEN-ALL syntax Tom Lane <[email protected]>
2024-12-21 05:22 ` Re: Discussion on a LISTEN-ALL syntax Vik Fearing <[email protected]>
2024-12-21 17:42 ` Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[email protected]>
2024-12-20 22:47 ` Re: Discussion on a LISTEN-ALL syntax Daniel Gustafsson <[email protected]>
2024-12-22 18:53 ` Re: Discussion on a LISTEN-ALL syntax Trey Boudreau <[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