Re: [PATCH] Add support for leading/trailing bytea trim()ing

On Fri, Dec 4, 2020, at 22:02, Tom Lane wrote: >"trim left ends" (plural) seems wrong. A string only has one left end, >at least in my universe. Fixed, the extra "s" came from copying from btrim()'s description. >(Maybe the existing ltrim/rtrim descrs are also like this, but if so I>'d change th

Re: POC: Cleaning up orphaned files using undo logs

On Fri, Dec 4, 2020 at 1:50 PM Antonin Houska wrote: > > Amit Kapila wrote: > > > > The earlier version of the patch having all these ideas > > implemented is attached > > (Infrastructure-to-execute-pending-undo-actions and > > Provide-interfaces-to-store-and-fetch-undo-records). The second one >

Re: Proposed patch for key managment

On Sat, Dec 5, 2020 at 12:15:13PM +0900, Masahiko Sawada wrote: > diff --git a/src/common/cryptohash_openssl.c b/src/common/cryptohash_openssl.c > index e5233daab6..a45c86fa67 100644 > --- a/src/common/cryptohash_openssl.c > +++ b/src/common/cryptohash_openssl.c > @@ -81,6 +81,8 @@ pg_cryptohash_c

Re: Hybrid Hash/Nested Loop joins and caching results from subplans

There are two blocks with almost identical code (second occurrence in cache_store_tuple): + if (rcstate->mem_used > rcstate->mem_upperlimit) + { It would be nice if the code can be extracted to a method and shared. node->rc_status = RC_END_OF_SCAN; ret

Re: Add Information during standby recovery conflicts

On Fri, Dec 4, 2020 at 7:22 PM Drouvot, Bertrand wrote: > > Hi, > > On 12/4/20 2:21 AM, Fujii Masao wrote: > > > > On 2020/12/04 9:28, Masahiko Sawada wrote: > >> On Fri, Dec 4, 2020 at 2:54 AM Fujii Masao > >> wrote: > >>> > >>> > >>> > >>> On 2020/12/01 17:29, Drouvot, Bertrand wrote: > Hi

Re: Proposed patch for key managment

On Sat, Dec 5, 2020 at 11:39:18AM +0900, Michael Paquier wrote: > On Fri, Dec 04, 2020 at 09:08:03PM -0500, Bruce Momjian wrote: > > Here is an updated patch to handle the new hash API introduced by > > commit 87ae9691d2. > > + if (!ossl_initialized) > + { > +#ifdef HAVE_OPENSSL_INIT_

Re: Proposed patch for key managment

On Fri, Dec 04, 2020 at 09:08:03PM -0500, Bruce Momjian wrote: > Here is an updated patch to handle the new hash API introduced by > commit 87ae9691d2. + if (!ossl_initialized) + { +#ifdef HAVE_OPENSSL_INIT_SSL + OPENSSL_init_ssl(OPENSSL_INIT_LOAD_CONFIG, NULL); +#else +

Re: convert elog(LOG) calls to ereport

On Fri, Dec 04, 2020 at 02:34:26PM +0100, Peter Eisentraut wrote: > On 2020-12-02 15:04, Alvaro Herrera wrote: >> I do wonder if it'd be a good idea to move the syscall >> name itself out of the message, too; that would reduce the number of >> messages to translate 50x to just "%s(%s) failed: %m" i

Re: Proposed patch for key managment

On Wed, Dec 2, 2020 at 04:38:14PM -0500, Bruce Momjian wrote: > If most people approve of this general approach, and the design > decisions made, I would like to apply this in the next few weeks, but > this brings complications. The syntax added by this commit might not > provide a useful feature

Re: Single transaction in the tablesync worker?

On Fri, Dec 4, 2020 at 7:12 PM Ashutosh Bapat wrote: > > On Thu, Dec 3, 2020 at 7:24 PM Amit Kapila wrote: > > > > On Thu, Dec 3, 2020 at 7:04 PM Ashutosh Bapat > > wrote: > > > > > > On Thu, Dec 3, 2020 at 2:55 PM Amit Kapila > > > wrote: > > > > > > > > The tablesync worker in logical replic

Re: A few new options for CHECKPOINT

On Sat, Dec 05, 2020 at 12:11:13AM +, Bossart, Nathan wrote: > On 12/4/20, 3:33 PM, "Alvaro Herrera" wrote: >> Instead of adding checkpt_option_list, how about utility_option_list? >> It seems intended for reuse. +1. It is intended for reuse. > Ah, good call. That simplifies the grammar ch

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Fri, Dec 04, 2020 at 04:28:26PM -0300, Alvaro Herrera wrote: > FWIW I'm with Peter on this. Okay, attached is a patch to adjust the enums for the set of utility commands that is the set of things I have touched lately. Should that be extended more? I have not done that as a lot of those struc

Hybrid Hash/Nested Loop joins and caching results from subplans

Hi, David: For nodeResultCache.c : +#define SH_EQUAL(tb, a, b) ResultCacheHash_equal(tb, a, b) == 0 I think it would be safer if the comparison is enclosed in parentheses (in case the macro appears in composite condition). +ResultCacheHash_equal(struct resultcache_hash *tb, const ResultCacheKey

Re: A few new options for CHECKPOINT

On 2020-Dec-04, Bossart, Nathan wrote: > On 12/4/20, 1:47 PM, "Alvaro Herrera" wrote: > > On the UI of this patch, you're proposing to add the option FAST. I'm > > not a fan of this option name and propose that (if we have it) we use > > the name SPREAD instead (defaults to false). > > > > Now w

Re: Removal of operator_precedence_warning

Alvaro Herrera writes: > Reading the reports mentioned in those commits, it doesn't look like any > of them were actually using the feature -- they all seem to have come > across the problems by accidents of varying nature. The two oldest reports look like the submitters had operator_precedence_w

Re: A few new options for CHECKPOINT

Greetings, * Alvaro Herrera (alvhe...@alvh.no-ip.org) wrote: > I think starting a spread checkpoint has some usefulness, if your > checkpoint interval is very large but your completion target is not very > close to 1. In that case, you're expressing that you want a checkpoint > to start now and n

Re: Removal of operator_precedence_warning

On 2020-Dec-04, Tom Lane wrote: > I think it's time for $SUBJECT. We added this GUC in 9.5, which > will be EOL by the time of our next major release, and it was never > meant as more than a transitional aid. Moreover, it's been buggy > as heck (cf abb164655, 05104f693, 01e0cbc4f, 4cae471d1), an

Re: POC: Better infrastructure for automated testing of concurrency issues

On Fri, Dec 4, 2020 at 1:20 PM Alexander Korotkov wrote: > Thank you for your feedback. We probably can't think over everything > in advance. We can start with configure option enabled for developers > and some buildfarm animals. That causes no risk of overhead in > standard builds. After some

Re: A few new options for CHECKPOINT

On the UI of this patch, you're proposing to add the option FAST. I'm not a fan of this option name and propose that (if we have it) we use the name SPREAD instead (defaults to false). Now we don't actually explain the term "spread" much in the documentation; we just say "the writes are spread".

Re: [PATCH] pg_dumpall options proposal/patch

c...@remington.io writes: > I have a relatively trivial proposal - this affects pg_dumpall exclusively. > Primary use case in ability to use pg_dumpall without SUPERUSER. > * Add --no-alter-role flag to only use CREATE ROLE syntax instead of CREATE > then ALTER. What's the point of that? > * L

Removal of operator_precedence_warning

I think it's time for $SUBJECT. We added this GUC in 9.5, which will be EOL by the time of our next major release, and it was never meant as more than a transitional aid. Moreover, it's been buggy as heck (cf abb164655, 05104f693, 01e0cbc4f, 4cae471d1), and the fact that some of those errors went

[PATCH] pg_dumpall options proposal/patch

Hi pgsql-hackers, I have a relatively trivial proposal - this affects pg_dumpall exclusively. Primary use case in ability to use pg_dumpall without SUPERUSER. * Add --no-alter-role flag to only use CREATE ROLE syntax instead of CREATE then ALTER. * Add --exclude-role flag similar to --exclude

Re: Improving spin-lock implementation on ARM.

On Wed, Dec 2, 2020 at 6:58 AM Krunal Bauskar wrote: > Let me know what do you think about this analysis and any specific direction > that we should consider to help move forward. BTW, it would be also nice to benchmark my lwlock patch on the Kunpeng. I'm very optimistic about this patch, but i

Re: POC: Better infrastructure for automated testing of concurrency issues

On Fri, Dec 4, 2020 at 9:57 PM Peter Geoghegan wrote: > On Wed, Nov 25, 2020 at 6:11 AM Alexander Korotkov > wrote: > > While the postgres community does a great job on investigating and fixing > > the problems, our ability to reproduce concurrency issues in the source > > code test suites is

Re: POC: Better infrastructure for automated testing of concurrency issues

On Fri, Dec 4, 2020 at 9:29 PM Alvaro Herrera wrote: > On 2020-Nov-25, Alexander Korotkov wrote: > > In the view of above, I'd like to propose a POC patch, which implements new > > builtin infrastructure for reproduction of concurrency issues in automated > > test suites. The general idea is so-c

Re: [PATCH] Add support for leading/trailing bytea trim()ing

"Joel Jacobson" writes: > On Fri, Dec 4, 2020, at 17:37, Tom Lane wrote: >> The grammar in the functions' descr strings seems a bit shaky too. > Not sure what you mean? "trim left ends" (plural) seems wrong. A string only has one left end, at least in my universe. (Maybe the existing ltrim/rtr

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On Fri, Dec 04, 2020 at 09:40:31PM +0300, Alexey Kondratov wrote: > > I liked the bools, but dropped them so the patch is smaller. > > I had a look on 0001 and it looks mostly fine to me except some strange > mixture of tabs/spaces in the ExecReindex(). There is also a couple of > meaningful comm

Re: Add docs stub for recovery.conf

Greetings, * David G. Johnston (david.g.johns...@gmail.com) wrote: > On Fri, Dec 4, 2020 at 12:00 PM Stephen Frost wrote: > > Obviously, I'd then have to adjust the patch that I proposed for default > > roles, or move forward with it as-is, depending on what we end up doing > > here. I dislike w

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On 2020-Dec-04, Michael Paquier wrote: > VacuumOption does that since 6776142, and ClusterOption since 9ebe057, > so switching ReindexOption to just match the two others still looks > like the most consistent move. 9ebe057 goes to show why this is a bad idea, since it has this: +typedef enum Clu

Re: Add docs stub for recovery.conf

On Fri, Dec 4, 2020 at 12:00 PM Stephen Frost wrote: > Obviously, I'd then have to adjust the patch that I proposed for default > roles, or move forward with it as-is, depending on what we end up doing > here. I dislike what feels like a state of limbo for this right now > though. > > We have a

Re: WIP: WAL prefetch (another approach)

Greetings, * Andres Freund (and...@anarazel.de) wrote: > On 2020-12-04 13:27:38 -0500, Stephen Frost wrote: > > If I follow correctly, this patch will scan ahead in the WAL and let > > the kernel know that certain blocks will be needed soon. Ideally, > > though I don't think it does yet, we'd onl

Re: Add docs stub for recovery.conf

Greetings, * Bruce Momjian (br...@momjian.us) wrote: > On Wed, Dec 2, 2020 at 08:07:47PM -0500, Isaac Morland wrote: > > On Wed, 2 Dec 2020 at 19:33, David G. Johnston > > wrote: > > > > On Wed, Dec 2, 2020 at 5:26 PM Bruce Momjian wrote: > > > > I think the ideal solution is to c

Re: Improper use about DatumGetInt32

On 2020-Dec-03, Peter Eisentraut wrote: > On 2020-11-30 16:32, Alvaro Herrera wrote: > > On 2020-Nov-30, Peter Eisentraut wrote: > > > > > Patch updated this way. I agree it's better that way. > > > > Thanks, LGTM. > > For a change like this, do we need to change the C symbol names, so that >

Re: POC: Better infrastructure for automated testing of concurrency issues

On Wed, Nov 25, 2020 at 6:11 AM Alexander Korotkov wrote: > While the postgres community does a great job on investigating and fixing the > problems, our ability to reproduce concurrency issues in the source code test > suites is limited. +1. This seems really cool. > For sure, evaluation of s

Re: WIP: WAL prefetch (another approach)

Hi, On 2020-12-04 13:27:38 -0500, Stephen Frost wrote: > If I follow correctly, this patch will scan ahead in the WAL and let > the kernel know that certain blocks will be needed soon. Ideally, > though I don't think it does yet, we'd only do that for blocks that > aren't already in shared buffer

Re: [PATCH] Add support for leading/trailing bytea trim()ing

On Fri, Dec 4, 2020, at 17:37, Tom Lane wrote: >No objection in principle, but you need to extend the code added by >commit 40c24bfef to know about these functions. Oh, I see, that's a very nice improvement. I've now added F_LTRIM_BYTEA_BYTEA and F_RTRIM_BYTEA_BYTEA to ruleutils.c accordingly, a

Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly

On 2020-12-04 04:25, Justin Pryzby wrote: On Thu, Dec 03, 2020 at 04:12:53PM +0900, Michael Paquier wrote: > +typedef struct ReindexParams { > + bool concurrently; > + bool verbose; > + bool missingok; > + > + int options;/* bitmask of lowlevel REINDEXOPT_* */ > +} ReindexParams; > + By

Re: POC: Better infrastructure for automated testing of concurrency issues

On 2020-Nov-25, Alexander Korotkov wrote: > In the view of above, I'd like to propose a POC patch, which implements new > builtin infrastructure for reproduction of concurrency issues in automated > test suites. The general idea is so-called "stop events", which are > special places in the code,

Re: Logical archiving

On Fri, 4 Dec 2020 at 14:36, Andrey Borodin wrote: > > > > The most time consuming process is logical decoding, mainly due to long > running transactions. > Currently I do not experience problem of high CPU utilisation. > > I'm wondering why the LSN isn't moving fast enough for your use case. >

Re: WIP: WAL prefetch (another approach)

Greetings, * Thomas Munro (thomas.mu...@gmail.com) wrote: > On Thu, Nov 19, 2020 at 10:00 AM Stephen Frost wrote: > > * Thomas Munro (thomas.mu...@gmail.com) wrote: > > > Hmm. Every time I try to think of a protocol change for the > > > restore_command API that would be acceptable, I go around t

Re: walsender bug: stuck during shutdown

On 2020-Nov-26, Fujii Masao wrote: > Yes, so the problem here is that walsender goes into the busy loop > in that case. Seems this happens only in logical replication walsender. > In physical replication walsender, WaitLatchOrSocket() in WalSndLoop() > seems to work as expected and prevent it from

Re: [HACKERS] [PATCH] Generic type subscripting

BTW, I had a thought about this patch, which I wanted to write down before it disappears again (I'm not offering to code it right now). I think we should split array_subscript_handler into two functions, one for "regular" varlena arrays and one for the fixed-length pseudo-array types like "name" a

Re: pg_dump, ATTACH, and independently restorable child partitions

On Fri, Dec 04, 2020 at 12:13:05PM -0500, Tom Lane wrote: > Justin Pryzby writes: > > [ v4-0001-pg_dump-output-separate-object-for-ALTER-TABLE.AT.patch ] > > The cfbot is being picky about this: > > 3218pg_dump.c: In function ‘dumpTableAttach’: > 3219pg_dump.c:15600:42: error: suggest parenthese

Re: Logical archiving

Hi Euler! Thanks for your response. > 4 дек. 2020 г., в 22:14, Euler Taveira > написал(а): > > On Fri, 4 Dec 2020 at 04:33, Andrey Borodin wrote: > > I was discussing problems of CDC with scientific community and they asked > this simple question: "So you have efficient WAL archive on a ver

Re: [PATCH] Covering SPGiST index

> > The cfbot's still unhappy --- looks like you omitted a file from the > patch? > You are right, thank you. Corrected this. PFA v13 -- Best regards, Pavel Borisov Postgres Professional: http://postgrespro.com v13-0001-Covering-SP-GiST-index-support-for-INCLUDE-co

Re: pg_ls_tmpdir to show directories and shared filesets (and pg_ls_*)

Justin Pryzby writes: [ v24-0001-Document-historic-behavior-of-links-to-directori.patch ] The cfbot is unhappy with one of the test cases you added: 6245@@ -259,9 +259,11 @@ 6246 select path, filename, type from pg_ls_dir_metadata('.', true, false, true) where path!~'[0-9]|pg_internal.init|glob

Re: Logical archiving

On Fri, 4 Dec 2020 at 04:33, Andrey Borodin wrote: > > I was discussing problems of CDC with scientific community and they asked > this simple question: "So you have efficient WAL archive on a very cheap > storage, why don't you have a logical archive too?" > WAL archive doesn't process data; it

Re: pg_dump, ATTACH, and independently restorable child partitions

Justin Pryzby writes: > [ v4-0001-pg_dump-output-separate-object-for-ALTER-TABLE.AT.patch ] The cfbot is being picky about this: 3218pg_dump.c: In function ‘dumpTableAttach’: 3219pg_dump.c:15600:42: error: suggest parentheses around comparison in operand of ‘&’ [-Werror=parentheses] 3220 if (a

Re: [PATCH] Covering SPGiST index

Pavel Borisov writes: > I've noticed CI error due to the fact that MSVC doesn't allow arrays of > flexible size arrays and made a fix for the issue. > Also did some minor refinement in tuple creation. > PFA v12 of a patch. The cfbot's still unhappy --- looks like you omitted a file from the patch

Re: Corner-case bug in pg_rewind

On 04/12/2020 00:16, Heikki Linnakangas wrote: On 03/12/2020 16:10, Heikki Linnakangas wrote: On 02/12/2020 15:26, Ian Barwick wrote: On 02/12/2020 20:13, Heikki Linnakangas wrote: Attached are two patches. The first patch is your original patch, unmodified (except for a cosmetic rename of the

Re: [PATCH] Add support for leading/trailing bytea trim()ing

"Joel Jacobson" writes: > The attached patch adds LEADING | TRAILING support for the bytea version of > trim(): No objection in principle, but you need to extend the code added by commit 40c24bfef to know about these functions. The grammar in the functions' descr strings seems a bit shaky too.

[PATCH] Add support for leading/trailing bytea trim()ing

Dear hackers, Let's say we want to strip the leading zero bytes from '\xbeefbabe00'::bytea. This is currently not supported, since trim() for bytea values only support the BOTH mode: SELECT trim(LEADING '\x00'::bytea FROM '\xbeefbabe00'::bytea); ERROR: function pg_catalog.ltrim(bytea,

Re: Add session statistics to pg_stat_database

On Thu, 2020-12-03 at 13:22 +0100, Laurenz Albe wrote: > > Basically, that would change pgStatSessionDisconnectedNormally into instead > > being an > > enum of reasons, which could be normal disconnect, abnormal disconnect and > > admin. > > And we'd track all those three as separate numbers in t

Re: [HACKERS] [PATCH] Generic type subscripting

Pavel Stehule writes: > I tested the last patch on my FC33 Lenovo T520 (I7) and I don't see 15% > slowdown too .. On my comp there is a slowdown of about 1.5-3%. I used your > function arraytest. After repeating the experiment a few times, I think I was misled by ASLR variance (ie, hot code falli

Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements

On 2020-Dec-04, Dmitry Dolgov wrote: > * This one is mostly for me to understand. There are couple of places > with a commentary that 'PROC_IN_SAFE_IC is not necessary, because the > transaction only takes a snapshot to do some catalog manipulation'. > But for some of them I don't immediatel

Re: Single transaction in the tablesync worker?

On Thu, Dec 3, 2020 at 7:24 PM Amit Kapila wrote: > > On Thu, Dec 3, 2020 at 7:04 PM Ashutosh Bapat > wrote: > > > > On Thu, Dec 3, 2020 at 2:55 PM Amit Kapila wrote: > > > > > > The tablesync worker in logical replication performs the table data > > > sync in a single transaction which means it

Re: convert elog(LOG) calls to ereport

On 2020-12-03 08:55, Noah Misch wrote: For the changes I didn't mention explicitly (most of them), I'm -0.5. Many of them "can't happen", use source code terms of art, and/or breach guideline "Avoid mentioning called function names, either; instead say what the code was trying to do" (https://ww

Re: convert elog(LOG) calls to ereport

On 2020-12-03 08:02, Michael Paquier wrote: + else + ereport(LOG, + (errmsg("checkpoint starting:%s%s%s%s%s%s%s%s", Would it be better to add a note for translators here, in short that all those %s are options related to checkpoint/restartpoints? done The ones in geqo_e

Re: convert elog(LOG) calls to ereport

On 2020-12-02 15:04, Alvaro Herrera wrote: - elog(LOG, "WSAIoctl(SIO_KEEPALIVE_VALS) failed: %ui", -WSAGetLastError()); + ereport(LOG, + (errmsg("WSAIoctl(SIO_KEEPALIVE_VALS) failed: %ui", +

Re: [HACKERS] Custom compression methods

On Tue, Dec 1, 2020 at 9:15 PM Dilip Kumar wrote: > > On Tue, Dec 1, 2020 at 4:50 PM Dilip Kumar wrote: > > > > On Sat, Nov 21, 2020 at 3:50 AM Robert Haas wrote: > > > > While working on this comment I have doubts. > > > > > I wonder in passing about TOAST tables and materialized views, which >

Re: [bug fix] ALTER TABLE SET LOGGED/UNLOGGED on a partitioned table does nothing silently

On Fri, Dec 4, 2020 at 8:22 AM tsunakawa.ta...@fujitsu.com wrote: > > From: Bharath Rupireddy > > 1) What happens if a partitioned table has a foreign partition along > > with few other local partitions[1]? Currently, if we try to set > > logged/unlogged of a foreign table, then an "ERROR: "

Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements

> On Mon, Nov 30, 2020 at 04:54:39PM -0300, Alvaro Herrera wrote: > > In a previous thread [1], we added smarts so that processes running > CREATE INDEX CONCURRENTLY would not wait for each other. > > One is adding the same to REINDEX CONCURRENTLY. I've attached patch > 0002 here which does that.

Re: [Patch] Optimize dropping of relation buffers using dlist

On Fri, Nov 27, 2020 at 11:36 AM Kyotaro Horiguchi wrote: > > At Fri, 27 Nov 2020 02:19:57 +, "k.jami...@fujitsu.com" > wrote in > > > From: Kyotaro Horiguchi > > > Hello, Kirk. Thank you for the new version. > > > > Hi, Horiguchi-san. Thank you for your very helpful feedback. > > I'm updat

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Fri, Dec 4, 2020 at 1:46 PM Bharath Rupireddy wrote: > > On Fri, Dec 4, 2020 at 11:49 AM Fujii Masao > wrote: > > > > > Attaching the v2 patch set. Please review it further. > > > > Regarding the 0001 patch, we should add the function that returns > > the information of cached connections lik

Re: Get memory contexts of an arbitrary backend process

On 2020-12-03 10:36, Tom Lane wrote: Fujii Masao writes: I'm starting to study how this feature behaves. At first, when I executed the following query, the function never returned. ISTM that since the autovacuum launcher cannot respond to the request of memory contexts dump, the function keeps

Re: pg_stat_statements oddity with track = all

On Fri, Dec 04, 2020 at 12:06:10PM +0300, Sergei Kornilov wrote: > Hello > > Seems we need also change PGSS_FILE_HEADER. Indeed, thanks! v2 attached. >From 1da24926d9645ee997aabd2907482a29332e3729 Mon Sep 17 00:00:00 2001 From: Julien Rouhaud Date: Fri, 4 Dec 2020 13:33:51 +0800 Subject: [PATCH

Re: On login trigger: take three

On 04.12.2020 3:50, Greg Nancarrow wrote: On Tue, Sep 15, 2020 at 2:12 AM Pavel Stehule wrote: It is always possible to login by disabling startup triggers using disable_session_start_trigger GUC: psql "dbname=postgres options='-c disable_session_start_trigger=true'" sure, I know. Just t

Re: A new function to wait for the backend exit after termination

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: tested, passed Documentation:not tested Thanks for the new patch, the patch LGTM and works as expected T

Re: A new function to wait for the backend exit after termination

On Fri, Dec 4, 2020 at 2:02 PM Hou, Zhijie wrote: > > Hi, > > When test pg_terminate_backend_and_wait with parallel query. > I noticed that the function is not defined as parallel safe. > > I am not very familiar with the standard about whether a function should be > parallel safe. > But I found

Re: pg_stat_statements oddity with track = all

Hello Seems we need also change PGSS_FILE_HEADER. regards, Sergei

Re: Remove incorrect assertion in reorderbuffer.c.

On Fri, Dec 4, 2020 at 11:19 AM Dilip Kumar wrote: > > On Thu, Dec 3, 2020 at 5:33 PM Amit Kapila wrote: > > > > We start recording changes in ReorderBufferTXN even before we reach > > SNAPBUILD_CONSISTENT state so that if the commit is encountered after > > reaching that we should be able to sen

Re: Single transaction in the tablesync worker?

On Fri, Dec 4, 2020 at 10:29 AM Amit Kapila wrote: > > On Fri, Dec 4, 2020 at 7:53 AM Craig Ringer > wrote: > > > > On Thu, 3 Dec 2020 at 17:25, Amit Kapila wrote: > > > > > Is there any fundamental problem if > > > we commit the transaction after initial copy and slot creation in > > > LogicalR

RE: A new function to wait for the backend exit after termination

Hi, When test pg_terminate_backend_and_wait with parallel query. I noticed that the function is not defined as parallel safe. I am not very familiar with the standard about whether a function should be parallel safe. But I found the following function are all defined as parallel safe: pg_promot

Re: [PATCH] postgres_fdw connection caching - cause remote sessions linger till the local session exit

On Fri, Dec 4, 2020 at 11:49 AM Fujii Masao wrote: > > > Attaching the v2 patch set. Please review it further. > > Regarding the 0001 patch, we should add the function that returns > the information of cached connections like dblink_get_connections(), > together with 0001 patch? Otherwise it's not

Re: pg_stat_statements oddity with track = all

On Thu, Dec 03, 2020 at 04:53:59PM +0800, Julien Rouhaud wrote: > On Thu, Dec 03, 2020 at 11:40:22AM +0300, Sergei Kornilov wrote: > > Hello > > > > > To get an increase in the number of records that means that the same > > > statement > > > would appear at top level AND nested level. This seems a