public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 1/5] pg_rewind: Move syncTargetDirectory() to file_ops.c
14+ messages / 6 participants
[nested] [flat]
* [PATCH 1/5] pg_rewind: Move syncTargetDirectory() to file_ops.c
@ 2020-08-19 12:34 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Heikki Linnakangas @ 2020-08-19 12:34 UTC (permalink / raw)
For consistency. All the other low-level functions that operate on the
target directory are in file_ops.c.
---
src/bin/pg_rewind/file_ops.c | 19 +++++++++++++++++++
src/bin/pg_rewind/file_ops.h | 1 +
src/bin/pg_rewind/pg_rewind.c | 22 +---------------------
src/bin/pg_rewind/pg_rewind.h | 1 +
4 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/src/bin/pg_rewind/file_ops.c b/src/bin/pg_rewind/file_ops.c
index b3bf091c546..55439db20ba 100644
--- a/src/bin/pg_rewind/file_ops.c
+++ b/src/bin/pg_rewind/file_ops.c
@@ -19,6 +19,7 @@
#include <unistd.h>
#include "common/file_perm.h"
+#include "common/file_utils.h"
#include "file_ops.h"
#include "filemap.h"
#include "pg_rewind.h"
@@ -266,6 +267,24 @@ remove_target_symlink(const char *path)
dstpath);
}
+/*
+ * Sync target data directory to ensure that modifications are safely on disk.
+ *
+ * We do this once, for the whole data directory, for performance reasons. At
+ * the end of pg_rewind's run, the kernel is likely to already have flushed
+ * most dirty buffers to disk. Additionally fsync_pgdata uses a two-pass
+ * approach (only initiating writeback in the first pass), which often reduces
+ * the overall amount of IO noticeably.
+ */
+void
+sync_target_dir(void)
+{
+ if (!do_sync || dry_run)
+ return;
+
+ fsync_pgdata(datadir_target, PG_VERSION_NUM);
+}
+
/*
* Read a file into memory. The file to be read is <datadir>/<path>.
diff --git a/src/bin/pg_rewind/file_ops.h b/src/bin/pg_rewind/file_ops.h
index 025f24141c9..d8466385cf5 100644
--- a/src/bin/pg_rewind/file_ops.h
+++ b/src/bin/pg_rewind/file_ops.h
@@ -19,6 +19,7 @@ extern void remove_target_file(const char *path, bool missing_ok);
extern void truncate_target_file(const char *path, off_t newsize);
extern void create_target(file_entry_t *t);
extern void remove_target(file_entry_t *t);
+extern void sync_target_dir(void);
extern char *slurpFile(const char *datadir, const char *path, size_t *filesize);
diff --git a/src/bin/pg_rewind/pg_rewind.c b/src/bin/pg_rewind/pg_rewind.c
index 23fc749e445..c9b9e480c0f 100644
--- a/src/bin/pg_rewind/pg_rewind.c
+++ b/src/bin/pg_rewind/pg_rewind.c
@@ -20,7 +20,6 @@
#include "catalog/pg_control.h"
#include "common/controldata_utils.h"
#include "common/file_perm.h"
-#include "common/file_utils.h"
#include "common/restricted_token.h"
#include "common/string.h"
#include "fe_utils/recovery_gen.h"
@@ -38,7 +37,6 @@ static void createBackupLabel(XLogRecPtr startpoint, TimeLineID starttli,
static void digestControlFile(ControlFileData *ControlFile, char *source,
size_t size);
-static void syncTargetDirectory(void);
static void getRestoreCommand(const char *argv0);
static void sanityChecks(void);
static void findCommonAncestorTimeline(XLogRecPtr *recptr, int *tliIndex);
@@ -455,7 +453,7 @@ main(int argc, char **argv)
if (showprogress)
pg_log_info("syncing target data directory");
- syncTargetDirectory();
+ sync_target_dir();
if (writerecoveryconf && !dry_run)
WriteRecoveryConfig(conn, datadir_target,
@@ -803,24 +801,6 @@ digestControlFile(ControlFileData *ControlFile, char *src, size_t size)
checkControlFile(ControlFile);
}
-/*
- * Sync target data directory to ensure that modifications are safely on disk.
- *
- * We do this once, for the whole data directory, for performance reasons. At
- * the end of pg_rewind's run, the kernel is likely to already have flushed
- * most dirty buffers to disk. Additionally fsync_pgdata uses a two-pass
- * approach (only initiating writeback in the first pass), which often reduces
- * the overall amount of IO noticeably.
- */
-static void
-syncTargetDirectory(void)
-{
- if (!do_sync || dry_run)
- return;
-
- fsync_pgdata(datadir_target, PG_VERSION_NUM);
-}
-
/*
* Get value of GUC parameter restore_command from the target cluster.
*
diff --git a/src/bin/pg_rewind/pg_rewind.h b/src/bin/pg_rewind/pg_rewind.h
index 8a9319ed675..67f90c2a38c 100644
--- a/src/bin/pg_rewind/pg_rewind.h
+++ b/src/bin/pg_rewind/pg_rewind.h
@@ -24,6 +24,7 @@ extern char *datadir_source;
extern char *connstr_source;
extern bool showprogress;
extern bool dry_run;
+extern bool do_sync;
extern int WalSegSz;
/* Target history */
--
2.20.1
--------------D93EDEBFB124D563B723F4BD
Content-Type: text/x-patch; charset=UTF-8;
name="0002-Refactor-pg_rewind-for-more-clear-decision-making.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0002-Refactor-pg_rewind-for-more-clear-decision-making.patch"
^ permalink raw reply [nested|flat] 14+ messages in thread
* [PATCH v3] Add "Backpatch" regions in wait_event_names.txt
@ 2024-03-18 08:34 Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw)
When backpatching, adding an event will renumber others, which can make an
extension report the wrong event until recompiled. This is due to the fact that
generate-wait_event_types.pl sorts events to position them. The "Backpatch"
region added here ensures no ordering is done for the wait events found after
this delimiter.
---
.../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++-
.../utils/activity/wait_event_names.txt | 18 ++++++++++++-
2 files changed, 42 insertions(+), 2 deletions(-)
100.0% src/backend/utils/activity/
diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl
index f1adf0e8e7..d129d94889 100644
--- a/src/backend/utils/activity/generate-wait_event_types.pl
+++ b/src/backend/utils/activity/generate-wait_event_types.pl
@@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously"
open my $wait_event_names, '<', $ARGV[0] or die;
+my @backpatch_lines;
my @lines;
+my $backpatch = 0;
my $section_name;
my $note;
my $note_name;
@@ -59,10 +61,26 @@ while (<$wait_event_names>)
{
$section_name = $_;
$section_name =~ s/^.*- //;
+ $backpatch = 0;
next;
}
- push(@lines, $section_name . "\t" . $_);
+ # Are we dealing with backpatch wait events?
+ if (/^Backpatch:$/)
+ {
+ $backpatch = 1;
+ next;
+ }
+
+ # Backpatch wait events won't be sorted during code generation
+ if ($gen_code && $backpatch)
+ {
+ push(@backpatch_lines, $section_name . "\t" . $_);
+ }
+ else
+ {
+ push(@lines, $section_name . "\t" . $_);
+ }
}
# Sort the lines based on the second column.
@@ -70,6 +88,12 @@ while (<$wait_event_names>)
my @lines_sorted =
sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines;
+# If we are generating code then concat @lines_sorted and @backpatch_lines.
+if ($gen_code)
+{
+ push(@lines_sorted, @backpatch_lines);
+}
+
# Read the sorted lines and populate the hash table
foreach my $line (@lines_sorted)
{
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index c08e00d1d6..0c4788fe77 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -24,7 +24,10 @@
# SGML tables of wait events for inclusion in the documentation.
#
# When adding a new wait event, make sure it is placed in the appropriate
-# ClassName section.
+# ClassName section. Put it in its natural position in the master branch, and
+# then put it in the "Backpatch:" region for any other branch (should the wait
+# event be backpatched).
+# Ensure that the backpatch regions are always empty on the master branch.
#
# WaitEventLWLock and WaitEventLock have their own C code for their wait event
# enums and function names. Hence, for these, only the SGML documentation is
@@ -61,6 +64,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process."
WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated."
WAL_WRITER_MAIN "Waiting in main loop of WAL writer process."
+Backpatch:
#
# Wait Events - Client
@@ -82,6 +86,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the
WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process."
WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process."
+Backpatch:
#
# Wait Events - IPC
@@ -149,6 +154,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation."
+Backpatch:
#
# Wait Events - Timeout
@@ -169,6 +175,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point."
VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed."
WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error."
+Backpatch:
#
# Wait Events - IO
@@ -256,6 +263,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage."
WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method."
WAL_WRITE "Waiting for a write to a WAL file."
+Backpatch:
#
# Wait Events - Buffer Pin
@@ -265,6 +273,7 @@ Section: ClassName - WaitEventBufferPin
BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer."
+Backpatch:
#
# Wait Events - Extension
@@ -274,6 +283,8 @@ Section: ClassName - WaitEventExtension
Extension "Waiting in an extension."
+Backpatch:
+
#
# Wait Events - LWLock
#
@@ -330,6 +341,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry."
InjectionPoint "Waiting to read or update information related to injection points."
SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state."
+# Don't create a Backpatch region here.
+
#
# END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE)
#
@@ -377,6 +390,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache."
SubtransSLRU "Waiting to access the sub-transaction SLRU cache."
XactSLRU "Waiting to access the transaction status SLRU cache."
+# Don't create a Backpatch region here.
#
# Wait Events - Lock
@@ -399,3 +413,5 @@ object "Waiting to acquire a lock on a non-relation database object."
userlock "Waiting to acquire a user lock."
advisory "Waiting to acquire an advisory user lock."
applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber."
+
+Backpatch:
--
2.34.1
--m1fyrkxSXqjY+FO1--
^ permalink raw reply [nested|flat] 14+ messages in thread
* [PATCH v2] Add "Backpatch" regions in wait_event_names.txt
@ 2024-03-18 08:34 Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw)
When backpatching, adding an event will renumber others, which can make an
extension report the wrong event until recompiled. This is due to the fact that
generate-wait_event_types.pl sorts events to position them. The "Backpatch"
region added here ensures no ordering is done for the wait events found after
this delimiter.
---
.../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++-
.../utils/activity/wait_event_names.txt | 19 +++++++++++++-
2 files changed, 43 insertions(+), 2 deletions(-)
100.0% src/backend/utils/activity/
diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl
index f1adf0e8e7..d129d94889 100644
--- a/src/backend/utils/activity/generate-wait_event_types.pl
+++ b/src/backend/utils/activity/generate-wait_event_types.pl
@@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously"
open my $wait_event_names, '<', $ARGV[0] or die;
+my @backpatch_lines;
my @lines;
+my $backpatch = 0;
my $section_name;
my $note;
my $note_name;
@@ -59,10 +61,26 @@ while (<$wait_event_names>)
{
$section_name = $_;
$section_name =~ s/^.*- //;
+ $backpatch = 0;
next;
}
- push(@lines, $section_name . "\t" . $_);
+ # Are we dealing with backpatch wait events?
+ if (/^Backpatch:$/)
+ {
+ $backpatch = 1;
+ next;
+ }
+
+ # Backpatch wait events won't be sorted during code generation
+ if ($gen_code && $backpatch)
+ {
+ push(@backpatch_lines, $section_name . "\t" . $_);
+ }
+ else
+ {
+ push(@lines, $section_name . "\t" . $_);
+ }
}
# Sort the lines based on the second column.
@@ -70,6 +88,12 @@ while (<$wait_event_names>)
my @lines_sorted =
sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines;
+# If we are generating code then concat @lines_sorted and @backpatch_lines.
+if ($gen_code)
+{
+ push(@lines_sorted, @backpatch_lines);
+}
+
# Read the sorted lines and populate the hash table
foreach my $line (@lines_sorted)
{
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index c08e00d1d6..b6303a0fdb 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -24,7 +24,11 @@
# SGML tables of wait events for inclusion in the documentation.
#
# When adding a new wait event, make sure it is placed in the appropriate
-# ClassName section.
+# ClassName section. If the wait event is backpatched from master to a version
+# >= 17 then put it under a "Backpatch:" delimiter at the end of the related
+# ClassName section (on the non master branches) or at its natural position on
+# the master branch.
+# Ensure that the backpatch regions are always empty on the master branch.
#
# WaitEventLWLock and WaitEventLock have their own C code for their wait event
# enums and function names. Hence, for these, only the SGML documentation is
@@ -61,6 +65,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process."
WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated."
WAL_WRITER_MAIN "Waiting in main loop of WAL writer process."
+Backpatch:
#
# Wait Events - Client
@@ -82,6 +87,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the
WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process."
WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process."
+Backpatch:
#
# Wait Events - IPC
@@ -149,6 +155,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation."
+Backpatch:
#
# Wait Events - Timeout
@@ -169,6 +176,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point."
VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed."
WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error."
+Backpatch:
#
# Wait Events - IO
@@ -256,6 +264,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage."
WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method."
WAL_WRITE "Waiting for a write to a WAL file."
+Backpatch:
#
# Wait Events - Buffer Pin
@@ -265,6 +274,7 @@ Section: ClassName - WaitEventBufferPin
BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer."
+Backpatch:
#
# Wait Events - Extension
@@ -274,6 +284,8 @@ Section: ClassName - WaitEventExtension
Extension "Waiting in an extension."
+Backpatch:
+
#
# Wait Events - LWLock
#
@@ -330,6 +342,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry."
InjectionPoint "Waiting to read or update information related to injection points."
SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state."
+# Don't create a Backpatch region here.
+
#
# END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE)
#
@@ -377,6 +391,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache."
SubtransSLRU "Waiting to access the sub-transaction SLRU cache."
XactSLRU "Waiting to access the transaction status SLRU cache."
+# Don't create a Backpatch region here.
#
# Wait Events - Lock
@@ -399,3 +414,5 @@ object "Waiting to acquire a lock on a non-relation database object."
userlock "Waiting to acquire a user lock."
advisory "Waiting to acquire an advisory user lock."
applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber."
+
+Backpatch:
--
2.34.1
--Xg/TgUq/K7vNmQT2--
^ permalink raw reply [nested|flat] 14+ messages in thread
* [PATCH v3] Add "Backpatch" regions in wait_event_names.txt
@ 2024-03-18 08:34 Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw)
When backpatching, adding an event will renumber others, which can make an
extension report the wrong event until recompiled. This is due to the fact that
generate-wait_event_types.pl sorts events to position them. The "Backpatch"
region added here ensures no ordering is done for the wait events found after
this delimiter.
---
.../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++-
.../utils/activity/wait_event_names.txt | 18 ++++++++++++-
2 files changed, 42 insertions(+), 2 deletions(-)
100.0% src/backend/utils/activity/
diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl
index f1adf0e8e7..d129d94889 100644
--- a/src/backend/utils/activity/generate-wait_event_types.pl
+++ b/src/backend/utils/activity/generate-wait_event_types.pl
@@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously"
open my $wait_event_names, '<', $ARGV[0] or die;
+my @backpatch_lines;
my @lines;
+my $backpatch = 0;
my $section_name;
my $note;
my $note_name;
@@ -59,10 +61,26 @@ while (<$wait_event_names>)
{
$section_name = $_;
$section_name =~ s/^.*- //;
+ $backpatch = 0;
next;
}
- push(@lines, $section_name . "\t" . $_);
+ # Are we dealing with backpatch wait events?
+ if (/^Backpatch:$/)
+ {
+ $backpatch = 1;
+ next;
+ }
+
+ # Backpatch wait events won't be sorted during code generation
+ if ($gen_code && $backpatch)
+ {
+ push(@backpatch_lines, $section_name . "\t" . $_);
+ }
+ else
+ {
+ push(@lines, $section_name . "\t" . $_);
+ }
}
# Sort the lines based on the second column.
@@ -70,6 +88,12 @@ while (<$wait_event_names>)
my @lines_sorted =
sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines;
+# If we are generating code then concat @lines_sorted and @backpatch_lines.
+if ($gen_code)
+{
+ push(@lines_sorted, @backpatch_lines);
+}
+
# Read the sorted lines and populate the hash table
foreach my $line (@lines_sorted)
{
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index c08e00d1d6..0c4788fe77 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -24,7 +24,10 @@
# SGML tables of wait events for inclusion in the documentation.
#
# When adding a new wait event, make sure it is placed in the appropriate
-# ClassName section.
+# ClassName section. Put it in its natural position in the master branch, and
+# then put it in the "Backpatch:" region for any other branch (should the wait
+# event be backpatched).
+# Ensure that the backpatch regions are always empty on the master branch.
#
# WaitEventLWLock and WaitEventLock have their own C code for their wait event
# enums and function names. Hence, for these, only the SGML documentation is
@@ -61,6 +64,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process."
WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated."
WAL_WRITER_MAIN "Waiting in main loop of WAL writer process."
+Backpatch:
#
# Wait Events - Client
@@ -82,6 +86,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the
WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process."
WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process."
+Backpatch:
#
# Wait Events - IPC
@@ -149,6 +154,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation."
+Backpatch:
#
# Wait Events - Timeout
@@ -169,6 +175,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point."
VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed."
WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error."
+Backpatch:
#
# Wait Events - IO
@@ -256,6 +263,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage."
WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method."
WAL_WRITE "Waiting for a write to a WAL file."
+Backpatch:
#
# Wait Events - Buffer Pin
@@ -265,6 +273,7 @@ Section: ClassName - WaitEventBufferPin
BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer."
+Backpatch:
#
# Wait Events - Extension
@@ -274,6 +283,8 @@ Section: ClassName - WaitEventExtension
Extension "Waiting in an extension."
+Backpatch:
+
#
# Wait Events - LWLock
#
@@ -330,6 +341,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry."
InjectionPoint "Waiting to read or update information related to injection points."
SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state."
+# Don't create a Backpatch region here.
+
#
# END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE)
#
@@ -377,6 +390,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache."
SubtransSLRU "Waiting to access the sub-transaction SLRU cache."
XactSLRU "Waiting to access the transaction status SLRU cache."
+# Don't create a Backpatch region here.
#
# Wait Events - Lock
@@ -399,3 +413,5 @@ object "Waiting to acquire a lock on a non-relation database object."
userlock "Waiting to acquire a user lock."
advisory "Waiting to acquire an advisory user lock."
applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber."
+
+Backpatch:
--
2.34.1
--m1fyrkxSXqjY+FO1--
^ permalink raw reply [nested|flat] 14+ messages in thread
* [PATCH v2] Add "Backpatch" regions in wait_event_names.txt
@ 2024-03-18 08:34 Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw)
When backpatching, adding an event will renumber others, which can make an
extension report the wrong event until recompiled. This is due to the fact that
generate-wait_event_types.pl sorts events to position them. The "Backpatch"
region added here ensures no ordering is done for the wait events found after
this delimiter.
---
.../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++-
.../utils/activity/wait_event_names.txt | 19 +++++++++++++-
2 files changed, 43 insertions(+), 2 deletions(-)
100.0% src/backend/utils/activity/
diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl
index f1adf0e8e7..d129d94889 100644
--- a/src/backend/utils/activity/generate-wait_event_types.pl
+++ b/src/backend/utils/activity/generate-wait_event_types.pl
@@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously"
open my $wait_event_names, '<', $ARGV[0] or die;
+my @backpatch_lines;
my @lines;
+my $backpatch = 0;
my $section_name;
my $note;
my $note_name;
@@ -59,10 +61,26 @@ while (<$wait_event_names>)
{
$section_name = $_;
$section_name =~ s/^.*- //;
+ $backpatch = 0;
next;
}
- push(@lines, $section_name . "\t" . $_);
+ # Are we dealing with backpatch wait events?
+ if (/^Backpatch:$/)
+ {
+ $backpatch = 1;
+ next;
+ }
+
+ # Backpatch wait events won't be sorted during code generation
+ if ($gen_code && $backpatch)
+ {
+ push(@backpatch_lines, $section_name . "\t" . $_);
+ }
+ else
+ {
+ push(@lines, $section_name . "\t" . $_);
+ }
}
# Sort the lines based on the second column.
@@ -70,6 +88,12 @@ while (<$wait_event_names>)
my @lines_sorted =
sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines;
+# If we are generating code then concat @lines_sorted and @backpatch_lines.
+if ($gen_code)
+{
+ push(@lines_sorted, @backpatch_lines);
+}
+
# Read the sorted lines and populate the hash table
foreach my $line (@lines_sorted)
{
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index c08e00d1d6..b6303a0fdb 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -24,7 +24,11 @@
# SGML tables of wait events for inclusion in the documentation.
#
# When adding a new wait event, make sure it is placed in the appropriate
-# ClassName section.
+# ClassName section. If the wait event is backpatched from master to a version
+# >= 17 then put it under a "Backpatch:" delimiter at the end of the related
+# ClassName section (on the non master branches) or at its natural position on
+# the master branch.
+# Ensure that the backpatch regions are always empty on the master branch.
#
# WaitEventLWLock and WaitEventLock have their own C code for their wait event
# enums and function names. Hence, for these, only the SGML documentation is
@@ -61,6 +65,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process."
WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated."
WAL_WRITER_MAIN "Waiting in main loop of WAL writer process."
+Backpatch:
#
# Wait Events - Client
@@ -82,6 +87,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the
WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process."
WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process."
+Backpatch:
#
# Wait Events - IPC
@@ -149,6 +155,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation."
+Backpatch:
#
# Wait Events - Timeout
@@ -169,6 +176,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point."
VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed."
WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error."
+Backpatch:
#
# Wait Events - IO
@@ -256,6 +264,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage."
WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method."
WAL_WRITE "Waiting for a write to a WAL file."
+Backpatch:
#
# Wait Events - Buffer Pin
@@ -265,6 +274,7 @@ Section: ClassName - WaitEventBufferPin
BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer."
+Backpatch:
#
# Wait Events - Extension
@@ -274,6 +284,8 @@ Section: ClassName - WaitEventExtension
Extension "Waiting in an extension."
+Backpatch:
+
#
# Wait Events - LWLock
#
@@ -330,6 +342,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry."
InjectionPoint "Waiting to read or update information related to injection points."
SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state."
+# Don't create a Backpatch region here.
+
#
# END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE)
#
@@ -377,6 +391,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache."
SubtransSLRU "Waiting to access the sub-transaction SLRU cache."
XactSLRU "Waiting to access the transaction status SLRU cache."
+# Don't create a Backpatch region here.
#
# Wait Events - Lock
@@ -399,3 +414,5 @@ object "Waiting to acquire a lock on a non-relation database object."
userlock "Waiting to acquire a user lock."
advisory "Waiting to acquire an advisory user lock."
applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber."
+
+Backpatch:
--
2.34.1
--Xg/TgUq/K7vNmQT2--
^ permalink raw reply [nested|flat] 14+ messages in thread
* [PATCH v2] Add "Backpatch" regions in wait_event_names.txt
@ 2024-03-18 08:34 Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw)
When backpatching, adding an event will renumber others, which can make an
extension report the wrong event until recompiled. This is due to the fact that
generate-wait_event_types.pl sorts events to position them. The "Backpatch"
region added here ensures no ordering is done for the wait events found after
this delimiter.
---
.../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++-
.../utils/activity/wait_event_names.txt | 19 +++++++++++++-
2 files changed, 43 insertions(+), 2 deletions(-)
100.0% src/backend/utils/activity/
diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl
index f1adf0e8e7..d129d94889 100644
--- a/src/backend/utils/activity/generate-wait_event_types.pl
+++ b/src/backend/utils/activity/generate-wait_event_types.pl
@@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously"
open my $wait_event_names, '<', $ARGV[0] or die;
+my @backpatch_lines;
my @lines;
+my $backpatch = 0;
my $section_name;
my $note;
my $note_name;
@@ -59,10 +61,26 @@ while (<$wait_event_names>)
{
$section_name = $_;
$section_name =~ s/^.*- //;
+ $backpatch = 0;
next;
}
- push(@lines, $section_name . "\t" . $_);
+ # Are we dealing with backpatch wait events?
+ if (/^Backpatch:$/)
+ {
+ $backpatch = 1;
+ next;
+ }
+
+ # Backpatch wait events won't be sorted during code generation
+ if ($gen_code && $backpatch)
+ {
+ push(@backpatch_lines, $section_name . "\t" . $_);
+ }
+ else
+ {
+ push(@lines, $section_name . "\t" . $_);
+ }
}
# Sort the lines based on the second column.
@@ -70,6 +88,12 @@ while (<$wait_event_names>)
my @lines_sorted =
sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines;
+# If we are generating code then concat @lines_sorted and @backpatch_lines.
+if ($gen_code)
+{
+ push(@lines_sorted, @backpatch_lines);
+}
+
# Read the sorted lines and populate the hash table
foreach my $line (@lines_sorted)
{
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index c08e00d1d6..b6303a0fdb 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -24,7 +24,11 @@
# SGML tables of wait events for inclusion in the documentation.
#
# When adding a new wait event, make sure it is placed in the appropriate
-# ClassName section.
+# ClassName section. If the wait event is backpatched from master to a version
+# >= 17 then put it under a "Backpatch:" delimiter at the end of the related
+# ClassName section (on the non master branches) or at its natural position on
+# the master branch.
+# Ensure that the backpatch regions are always empty on the master branch.
#
# WaitEventLWLock and WaitEventLock have their own C code for their wait event
# enums and function names. Hence, for these, only the SGML documentation is
@@ -61,6 +65,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process."
WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated."
WAL_WRITER_MAIN "Waiting in main loop of WAL writer process."
+Backpatch:
#
# Wait Events - Client
@@ -82,6 +87,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the
WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process."
WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process."
+Backpatch:
#
# Wait Events - IPC
@@ -149,6 +155,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation."
+Backpatch:
#
# Wait Events - Timeout
@@ -169,6 +176,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point."
VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed."
WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error."
+Backpatch:
#
# Wait Events - IO
@@ -256,6 +264,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage."
WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method."
WAL_WRITE "Waiting for a write to a WAL file."
+Backpatch:
#
# Wait Events - Buffer Pin
@@ -265,6 +274,7 @@ Section: ClassName - WaitEventBufferPin
BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer."
+Backpatch:
#
# Wait Events - Extension
@@ -274,6 +284,8 @@ Section: ClassName - WaitEventExtension
Extension "Waiting in an extension."
+Backpatch:
+
#
# Wait Events - LWLock
#
@@ -330,6 +342,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry."
InjectionPoint "Waiting to read or update information related to injection points."
SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state."
+# Don't create a Backpatch region here.
+
#
# END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE)
#
@@ -377,6 +391,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache."
SubtransSLRU "Waiting to access the sub-transaction SLRU cache."
XactSLRU "Waiting to access the transaction status SLRU cache."
+# Don't create a Backpatch region here.
#
# Wait Events - Lock
@@ -399,3 +414,5 @@ object "Waiting to acquire a lock on a non-relation database object."
userlock "Waiting to acquire a user lock."
advisory "Waiting to acquire an advisory user lock."
applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber."
+
+Backpatch:
--
2.34.1
--Xg/TgUq/K7vNmQT2--
^ permalink raw reply [nested|flat] 14+ messages in thread
* [PATCH v3] Add "Backpatch" regions in wait_event_names.txt
@ 2024-03-18 08:34 Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Bertrand Drouvot @ 2024-03-18 08:34 UTC (permalink / raw)
When backpatching, adding an event will renumber others, which can make an
extension report the wrong event until recompiled. This is due to the fact that
generate-wait_event_types.pl sorts events to position them. The "Backpatch"
region added here ensures no ordering is done for the wait events found after
this delimiter.
---
.../activity/generate-wait_event_types.pl | 26 ++++++++++++++++++-
.../utils/activity/wait_event_names.txt | 18 ++++++++++++-
2 files changed, 42 insertions(+), 2 deletions(-)
100.0% src/backend/utils/activity/
diff --git a/src/backend/utils/activity/generate-wait_event_types.pl b/src/backend/utils/activity/generate-wait_event_types.pl
index f1adf0e8e7..d129d94889 100644
--- a/src/backend/utils/activity/generate-wait_event_types.pl
+++ b/src/backend/utils/activity/generate-wait_event_types.pl
@@ -38,7 +38,9 @@ die "Not possible to specify --docs and --code simultaneously"
open my $wait_event_names, '<', $ARGV[0] or die;
+my @backpatch_lines;
my @lines;
+my $backpatch = 0;
my $section_name;
my $note;
my $note_name;
@@ -59,10 +61,26 @@ while (<$wait_event_names>)
{
$section_name = $_;
$section_name =~ s/^.*- //;
+ $backpatch = 0;
next;
}
- push(@lines, $section_name . "\t" . $_);
+ # Are we dealing with backpatch wait events?
+ if (/^Backpatch:$/)
+ {
+ $backpatch = 1;
+ next;
+ }
+
+ # Backpatch wait events won't be sorted during code generation
+ if ($gen_code && $backpatch)
+ {
+ push(@backpatch_lines, $section_name . "\t" . $_);
+ }
+ else
+ {
+ push(@lines, $section_name . "\t" . $_);
+ }
}
# Sort the lines based on the second column.
@@ -70,6 +88,12 @@ while (<$wait_event_names>)
my @lines_sorted =
sort { uc((split(/\t/, $a))[1]) cmp uc((split(/\t/, $b))[1]) } @lines;
+# If we are generating code then concat @lines_sorted and @backpatch_lines.
+if ($gen_code)
+{
+ push(@lines_sorted, @backpatch_lines);
+}
+
# Read the sorted lines and populate the hash table
foreach my $line (@lines_sorted)
{
diff --git a/src/backend/utils/activity/wait_event_names.txt b/src/backend/utils/activity/wait_event_names.txt
index c08e00d1d6..0c4788fe77 100644
--- a/src/backend/utils/activity/wait_event_names.txt
+++ b/src/backend/utils/activity/wait_event_names.txt
@@ -24,7 +24,10 @@
# SGML tables of wait events for inclusion in the documentation.
#
# When adding a new wait event, make sure it is placed in the appropriate
-# ClassName section.
+# ClassName section. Put it in its natural position in the master branch, and
+# then put it in the "Backpatch:" region for any other branch (should the wait
+# event be backpatched).
+# Ensure that the backpatch regions are always empty on the master branch.
#
# WaitEventLWLock and WaitEventLock have their own C code for their wait event
# enums and function names. Hence, for these, only the SGML documentation is
@@ -61,6 +64,7 @@ WAL_SENDER_MAIN "Waiting in main loop of WAL sender process."
WAL_SUMMARIZER_WAL "Waiting in WAL summarizer for more WAL to be generated."
WAL_WRITER_MAIN "Waiting in main loop of WAL writer process."
+Backpatch:
#
# Wait Events - Client
@@ -82,6 +86,7 @@ WAIT_FOR_STANDBY_CONFIRMATION "Waiting for WAL to be received and flushed by the
WAL_SENDER_WAIT_FOR_WAL "Waiting for WAL to be flushed in WAL sender process."
WAL_SENDER_WRITE_DATA "Waiting for any activity when processing replies from WAL receiver in WAL sender process."
+Backpatch:
#
# Wait Events - IPC
@@ -149,6 +154,7 @@ WAL_RECEIVER_WAIT_START "Waiting for startup process to send initial data for st
WAL_SUMMARY_READY "Waiting for a new WAL summary to be generated."
XACT_GROUP_UPDATE "Waiting for the group leader to update transaction status at end of a parallel operation."
+Backpatch:
#
# Wait Events - Timeout
@@ -169,6 +175,7 @@ VACUUM_DELAY "Waiting in a cost-based vacuum delay point."
VACUUM_TRUNCATE "Waiting to acquire an exclusive lock to truncate off any empty pages at the end of a table vacuumed."
WAL_SUMMARIZER_ERROR "Waiting after a WAL summarizer error."
+Backpatch:
#
# Wait Events - IO
@@ -256,6 +263,7 @@ WAL_SYNC "Waiting for a WAL file to reach durable storage."
WAL_SYNC_METHOD_ASSIGN "Waiting for data to reach durable storage while assigning a new WAL sync method."
WAL_WRITE "Waiting for a write to a WAL file."
+Backpatch:
#
# Wait Events - Buffer Pin
@@ -265,6 +273,7 @@ Section: ClassName - WaitEventBufferPin
BUFFER_PIN "Waiting to acquire an exclusive pin on a buffer."
+Backpatch:
#
# Wait Events - Extension
@@ -274,6 +283,8 @@ Section: ClassName - WaitEventExtension
Extension "Waiting in an extension."
+Backpatch:
+
#
# Wait Events - LWLock
#
@@ -330,6 +341,8 @@ DSMRegistry "Waiting to read or update the dynamic shared memory registry."
InjectionPoint "Waiting to read or update information related to injection points."
SerialControl "Waiting to read or update shared <filename>pg_serial</filename> state."
+# Don't create a Backpatch region here.
+
#
# END OF PREDEFINED LWLOCKS (DO NOT CHANGE THIS LINE)
#
@@ -377,6 +390,7 @@ SerialSLRU "Waiting to access the serializable transaction conflict SLRU cache."
SubtransSLRU "Waiting to access the sub-transaction SLRU cache."
XactSLRU "Waiting to access the transaction status SLRU cache."
+# Don't create a Backpatch region here.
#
# Wait Events - Lock
@@ -399,3 +413,5 @@ object "Waiting to acquire a lock on a non-relation database object."
userlock "Waiting to acquire a user lock."
advisory "Waiting to acquire an advisory user lock."
applytransaction "Waiting to acquire a lock on a remote transaction being applied by a logical replication subscriber."
+
+Backpatch:
--
2.34.1
--m1fyrkxSXqjY+FO1--
^ permalink raw reply [nested|flat] 14+ messages in thread
* tab complete for COPY populated materialized view TO
@ 2025-04-09 08:23 jian he <[email protected]>
2025-04-09 09:25 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: jian he @ 2025-04-09 08:23 UTC (permalink / raw)
To: pgsql-hackers
hi.
we allow the "COPY table TO" command to copy rows from materialized
views in [1].
The attached patch is to add a tab complete for it.
[1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=534874fac0b34535c9a5ab9257d6574f78423578
Attachments:
[text/x-patch] v1-0001-tab-complete-for-COPY-populated-materialized-view.patch (1.7K, ../../CACJufxFxnSkikp+GormAGHcMTX1YH2HRXW1+3dJM9w7yY9hdsg@mail.gmail.com/2-v1-0001-tab-complete-for-COPY-populated-materialized-view.patch)
download | inline diff:
From c016a14b42d4f23bf5ece7ab8374d6e93bc5646f Mon Sep 17 00:00:00 2001
From: jian he <[email protected]>
Date: Wed, 9 Apr 2025 16:16:54 +0800
Subject: [PATCH v1 1/1] tab complete for COPY populated materialized view TO
---
src/bin/psql/tab-complete.in.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/src/bin/psql/tab-complete.in.c b/src/bin/psql/tab-complete.in.c
index c916b9299a8..2261c0253c5 100644
--- a/src/bin/psql/tab-complete.in.c
+++ b/src/bin/psql/tab-complete.in.c
@@ -683,6 +683,17 @@ static const SchemaQuery Query_for_list_of_tables = {
.result = "c.relname",
};
+static const SchemaQuery Query_for_list_of_tables_for_copy = {
+ .catname = "pg_catalog.pg_class c",
+ .selcondition =
+ "c.relkind IN (" CppAsString2(RELKIND_RELATION) ", "
+ CppAsString2(RELKIND_MATVIEW) ", "
+ CppAsString2(RELKIND_PARTITIONED_TABLE) ") and c.relispopulated ",
+ .viscondition = "pg_catalog.pg_table_is_visible(c.oid)",
+ .namespace = "c.relnamespace",
+ .result = "c.relname",
+};
+
static const SchemaQuery Query_for_list_of_partitioned_tables = {
.catname = "pg_catalog.pg_class c",
.selcondition = "c.relkind IN (" CppAsString2(RELKIND_PARTITIONED_TABLE) ")",
@@ -3249,7 +3260,7 @@ match_previous_words(int pattern_id,
* backslash command).
*/
else if (Matches("COPY|\\copy"))
- COMPLETE_WITH_SCHEMA_QUERY_PLUS(Query_for_list_of_tables, "(");
+ COMPLETE_WITH_SCHEMA_QUERY_PLUS(Query_for_list_of_tables_for_copy, "(");
/* Complete COPY ( with legal query commands */
else if (Matches("COPY|\\copy", "("))
COMPLETE_WITH("SELECT", "TABLE", "VALUES", "INSERT INTO", "UPDATE", "DELETE FROM", "MERGE INTO", "WITH");
--
2.34.1
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: tab complete for COPY populated materialized view TO
2025-04-09 08:23 tab complete for COPY populated materialized view TO jian he <[email protected]>
@ 2025-04-09 09:25 ` Kirill Reshke <[email protected]>
2025-04-09 10:24 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Kirill Reshke @ 2025-04-09 09:25 UTC (permalink / raw)
To: jian he <[email protected]>; +Cc: pgsql-hackers
On Wed, 9 Apr 2025 at 13:23, jian he <[email protected]> wrote:
>
> hi.
>
> we allow the "COPY table TO" command to copy rows from materialized
> views in [1].
> The attached patch is to add a tab complete for it.
>
> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=534874fac0b34535c9a5ab9257d6574f78423578
Hi!
Patch works good for me, but I noticed that psql COPY <tab> suggests
partitioned relation both with and without this patch. Maybe that's
not a big problem, if [0] will be pushed.
[0] https://www.postgresql.org/message-id/CACJufxHjBPrsbNZAp-DCmwvOE_Gkogb%2Brhfqqe1%3DS5cOHR-V7Q%40mail...
--
Best regards,
Kirill Reshke
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: tab complete for COPY populated materialized view TO
2025-04-09 08:23 tab complete for COPY populated materialized view TO jian he <[email protected]>
2025-04-09 09:25 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
@ 2025-04-09 10:24 ` Kirill Reshke <[email protected]>
2025-04-10 19:19 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Kirill Reshke @ 2025-04-09 10:24 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: jian he <[email protected]>; pgsql-hackers
On Wed, 9 Apr 2025 at 14:45, Fujii Masao <[email protected]> wrote:
>
>
>
> On 2025/04/09 18:25, Kirill Reshke wrote:
> > On Wed, 9 Apr 2025 at 13:23, jian he <[email protected]> wrote:
> >>
> >> hi.
> >>
> >> we allow the "COPY table TO" command to copy rows from materialized
> >> views in [1].
> >> The attached patch is to add a tab complete for it.
> >>
> >> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=534874fac0b34535c9a5ab9257d6574f78423578
> >
> > Hi!
> > Patch works good for me, but I noticed that psql COPY <tab> suggests
> > partitioned relation both with and without this patch. Maybe that's
> > not a big problem, if [0] will be pushed.
>
> Is the partitioned table currently tab-completed for the COPY FROM case?
If I'm not mistaken, yes. I double checked.
> INSTEAD OF INSERT triggers - though maybe that's overkill?
That's wild to me, psql tab completions feature designed to support
postgresql not fully, but in frequent cases. So maybe we should keep
it stupud.
--
Best regards,
Kirill Reshke
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: tab complete for COPY populated materialized view TO
2025-04-09 08:23 tab complete for COPY populated materialized view TO jian he <[email protected]>
2025-04-09 09:25 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-09 10:24 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
@ 2025-04-10 19:19 ` Kirill Reshke <[email protected]>
2025-04-10 19:33 ` Re: tab complete for COPY populated materialized view TO David G. Johnston <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Kirill Reshke @ 2025-04-10 19:19 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: jian he <[email protected]>; pgsql-hackers
On Thu, 10 Apr 2025 at 20:07, Fujii Masao <[email protected]> wrote:
>
>
>
> On 2025/04/09 19:24, Kirill Reshke wrote:
> > On Wed, 9 Apr 2025 at 14:45, Fujii Masao <[email protected]> wrote:
> >>
> >>
> >>
> >> On 2025/04/09 18:25, Kirill Reshke wrote:
> >>> On Wed, 9 Apr 2025 at 13:23, jian he <[email protected]> wrote:
> >>>>
> >>>> hi.
> >>>>
> >>>> we allow the "COPY table TO" command to copy rows from materialized
> >>>> views in [1].
> >>>> The attached patch is to add a tab complete for it.
> >>>>
> >>>> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=534874fac0b34535c9a5ab9257d6574f78423578
> >>>
> >>> Hi!
> >>> Patch works good for me, but I noticed that psql COPY <tab> suggests
> >>> partitioned relation both with and without this patch. Maybe that's
> >>> not a big problem, if [0] will be pushed.
> >>
> >> Is the partitioned table currently tab-completed for the COPY FROM case?
> >
> > If I'm not mistaken, yes. I double checked.
> >
> >> INSTEAD OF INSERT triggers - though maybe that's overkill?
> >
> > That's wild to me, psql tab completions feature designed to support
> > postgresql not fully, but in frequent cases. So maybe we should keep
> > it stupud.
>
> I agree that it's reasonable to exclude such rarely used objects from
> tab-completion. How about including just tables, partitioned tables,
> foreign tables, and materialized views?
> I've attached a patch for that.
>
> Regards,
Patch is ok. However...
> If we aim to support tab-completion for all valid targets of both COPY TO
and COPY FROM, shouldn't foreign tables also be included?
Ah.. Sorry I missed this part of your message initially. No, foreign
tables are not supported:
```
reshke=# CREATE FOREIGN TABLE ft (i int) server zz OPTIONS ( filename
'zz.csv', format 'csv' );
reshke=# copy ft to stdout;
ERROR: cannot copy from foreign table "ft"
HINT: Try the COPY (SELECT ...) TO variant.
```
So we will tab complete for cases that yet to be supported (foreign
tables and partitioned tables);
What's funny is that copying foreign tables using MV works fine
```
reshke=# create materialized view mv as table ft;
SELECT 1
reshke=# copy mv to stdout;
228
```
--
Best regards,
Kirill Reshke
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: tab complete for COPY populated materialized view TO
2025-04-09 08:23 tab complete for COPY populated materialized view TO jian he <[email protected]>
2025-04-09 09:25 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-09 10:24 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-10 19:19 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
@ 2025-04-10 19:33 ` David G. Johnston <[email protected]>
2025-04-10 19:37 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: David G. Johnston @ 2025-04-10 19:33 UTC (permalink / raw)
To: Kirill Reshke <[email protected]>; +Cc: Fujii Masao <[email protected]>; jian he <[email protected]>; pgsql-hackers
On Thursday, April 10, 2025, Kirill Reshke <[email protected]> wrote:
> On Thu, 10 Apr 2025 at 20:07, Fujii Masao <[email protected]>
> wrote:
> >
> >
> >
> > On 2025/04/09 19:24, Kirill Reshke wrote:
> > > On Wed, 9 Apr 2025 at 14:45, Fujii Masao <[email protected]>
> wrote:
> > >>
> > >>
> > >>
> > >> On 2025/04/09 18:25, Kirill Reshke wrote:
> > >>> On Wed, 9 Apr 2025 at 13:23, jian he <[email protected]>
> wrote:
> > >>>>
> > >>>> hi.
> > >>>>
> > >>>> we allow the "COPY table TO" command to copy rows from materialized
> > >>>> views in [1].
> > >>>> The attached patch is to add a tab complete for it.
> > >>>>
> > >>>> [1] https://git.postgresql.org/cgit/postgresql.git/commit/?id=
> 534874fac0b34535c9a5ab9257d6574f78423578
> > >>>
> > >>> Hi!
> > >>> Patch works good for me, but I noticed that psql COPY <tab> suggests
> > >>> partitioned relation both with and without this patch. Maybe that's
> > >>> not a big problem, if [0] will be pushed.
> > >>
> > >> Is the partitioned table currently tab-completed for the COPY FROM
> case?
> > >
> > > If I'm not mistaken, yes. I double checked.
> > >
> > >> INSTEAD OF INSERT triggers - though maybe that's overkill?
> > >
> > > That's wild to me, psql tab completions feature designed to support
> > > postgresql not fully, but in frequent cases. So maybe we should keep
> > > it stupud.
> >
> > I agree that it's reasonable to exclude such rarely used objects from
> > tab-completion. How about including just tables, partitioned tables,
> > foreign tables, and materialized views?
> > I've attached a patch for that.
> >
> > Regards,
>
> Patch is ok. However...
I concur with the premise of the patch. Tab-complete is going to happen
before we know whether to/from is specified so the syntax limits our smarts
here.
> > If we aim to support tab-completion for all valid targets of both COPY TO
> and COPY FROM, shouldn't foreign tables also be included?
>
> Ah.. Sorry I missed this part of your message initially. No, foreign
> tables are not supported:
They are supported for the From variant; valid completions need only
satisfy one of to/from, not both.
>
> What's funny is that copying foreign tables using MV works fine
>
> ```
> reshke=# create materialized view mv as table ft;
> SELECT 1
> reshke=# copy mv to stdout;
> 228
> ```
>
I don’t get why this is “funny” or otherwise surprising.
David J.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: tab complete for COPY populated materialized view TO
2025-04-09 08:23 tab complete for COPY populated materialized view TO jian he <[email protected]>
2025-04-09 09:25 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-09 10:24 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-10 19:19 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-10 19:33 ` Re: tab complete for COPY populated materialized view TO David G. Johnston <[email protected]>
@ 2025-04-10 19:37 ` Kirill Reshke <[email protected]>
2025-06-30 09:39 ` Re: tab complete for COPY populated materialized view TO Fujii Masao <[email protected]>
0 siblings, 1 reply; 14+ messages in thread
From: Kirill Reshke @ 2025-04-10 19:37 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: Fujii Masao <[email protected]>; jian he <[email protected]>; pgsql-hackers
On Fri, 11 Apr 2025 at 00:33, David G. Johnston
<[email protected]> wrote:
>
> They are supported for the From variant; valid completions need only satisfy one of to/from, not both.
>
Thank you. If so, then WFM, and I don't have any more objections.
--
Best regards,
Kirill Reshke
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: tab complete for COPY populated materialized view TO
2025-04-09 08:23 tab complete for COPY populated materialized view TO jian he <[email protected]>
2025-04-09 09:25 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-09 10:24 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-10 19:19 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-10 19:33 ` Re: tab complete for COPY populated materialized view TO David G. Johnston <[email protected]>
2025-04-10 19:37 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
@ 2025-06-30 09:39 ` Fujii Masao <[email protected]>
0 siblings, 0 replies; 14+ messages in thread
From: Fujii Masao @ 2025-06-30 09:39 UTC (permalink / raw)
To: Kirill Reshke <[email protected]>; David G. Johnston <[email protected]>; +Cc: jian he <[email protected]>; pgsql-hackers
On 2025/04/11 4:37, Kirill Reshke wrote:
> On Fri, 11 Apr 2025 at 00:33, David G. Johnston
> <[email protected]> wrote:
>>
>> They are supported for the From variant; valid completions need only satisfy one of to/from, not both.
>>
>
> Thank you. If so, then WFM, and I don't have any more objections.
I've pushed the patch. Thanks!
Regards,
--
Fujii Masao
NTT DATA Japan Corporation
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2025-06-30 09:39 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-08-19 12:34 [PATCH 1/5] pg_rewind: Move syncTargetDirectory() to file_ops.c Heikki Linnakangas <[email protected]>
2024-03-18 08:34 [PATCH v3] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]>
2024-03-18 08:34 [PATCH v2] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]>
2024-03-18 08:34 [PATCH v3] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]>
2024-03-18 08:34 [PATCH v2] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]>
2024-03-18 08:34 [PATCH v2] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]>
2024-03-18 08:34 [PATCH v3] Add "Backpatch" regions in wait_event_names.txt Bertrand Drouvot <[email protected]>
2025-04-09 08:23 tab complete for COPY populated materialized view TO jian he <[email protected]>
2025-04-09 09:25 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-09 10:24 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-10 19:19 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-04-10 19:33 ` Re: tab complete for COPY populated materialized view TO David G. Johnston <[email protected]>
2025-04-10 19:37 ` Re: tab complete for COPY populated materialized view TO Kirill Reshke <[email protected]>
2025-06-30 09:39 ` Re: tab complete for COPY populated materialized view TO Fujii Masao <[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