Re: Evaluate expression at planning time for two more cases

Hi Pavel Borisov, It's always good to select the optimal way even if it didn't have performance gain but in case of this patch i see 4x speed up on my laptop and it will work on any table that have NULL constraint regards Surafel

Huge memory consumption on partitioned table with FKs

Hi Hackers, My company (NTT Comware) and NTT OSS Center did verification of partitioned table on PG14dev, and we faced a problem that consumed huge memory when we created a Foreign key constraint on a partitioned table including 500 partitioning tables and inserted some data. We investigated it

Re: walsender bug: stuck during shutdown

On 2020/11/24 5:52, Alvaro Herrera wrote: Hello Chloe Dives reported that sometimes a walsender would become stuck during shutdown and *not* shutdown, thus preventing postmaster from completing the shutdown cycle. This has been observed to cause the servers to remain in such state for

RE: [PoC] Non-volatile WAL buffer

From: Tomas Vondra > So I wonder if using PMEM for the WAL buffer is the right way forward. > AFAIK the WAL buffer is quite concurrent (multiple clients writing > data), which seems to contradict the PMEM vs. DRAM trade-offs. > > The design I've originally expected would look more like this > >

Re: Use macros for calculating LWLock offset

Thanks! On Nov 24, 2020, at 11:51 AM, Michael Paquier mailto:mich...@paquier.xyz>> wrote: On Fri, Nov 20, 2020 at 03:25:50PM +0900, Michael Paquier wrote: I agree that this makes this code a bit cleaner, so let's use those macros. Others may have some comments here, so let's wait a bit first.

Re: Terminate the idle sessions

Hi, David Thanks for your suggestion! On Nov 24, 2020, at 11:39 AM, David G. Johnston mailto:david.g.johns...@gmail.com>> wrote: On Mon, Nov 23, 2020 at 5:02 PM kuroda.hay...@fujitsu.com mailto:kuroda.hay...@fujitsu.com>> wrote: No one have any comments,

Re: Terminate the idle sessions

Hi, Kuroda Thank for your review. > On Nov 24, 2020, at 8:01 AM, kuroda.hay...@fujitsu.com wrote: > > No one have any comments, patch tester says OK, and I think this works well. > I changed status to "Ready for Committer." > > Hayato Kuroda > FUJITSU LIMITED > > -Original Message- >

Re: [POC] Fast COPY FROM command for the table with foreign partitions

On 11/24/20 9:27 AM, tsunakawa.ta...@fujitsu.com wrote: Andrey-san, Fujita-san, From: Etsuro Fujita On Mon, Nov 23, 2020 at 5:39 PM Andrey Lepikhov wrote: On 11/23/20 7:49 AM, tsunakawa.ta...@fujitsu.com wrote: Could I or my colleague continue this patch in a few days? It looks it's

Re: Strange behavior with polygon and NaN

At Fri, 20 Nov 2020 15:57:46 -0500, Tom Lane wrote in > I spent some more time looking at this patch. > > Some experimentation shows that the changes around bounding box > calculation (ie float8_min_nan() and its call sites) seem to be > completely pointless: removing them doesn't change any of

RE: [POC] Fast COPY FROM command for the table with foreign partitions

Andrey-san, Fujita-san, From: Etsuro Fujita > On Mon, Nov 23, 2020 at 5:39 PM Andrey Lepikhov > wrote: > > On 11/23/20 7:49 AM, tsunakawa.ta...@fujitsu.com wrote: > > > Could I or my colleague continue this patch in a few days? It looks it's > stalled over one month. > > > > I don't found any

Re: bug in pageinspect's "tuple data" feature

On Mon, Nov 23, 2020 at 09:11:26AM +0200, Heikki Linnakangas wrote: > On 21/11/2020 21:32, Alvaro Herrera wrote: >> This is pretty unhelpful; it would be better not to try to print the >> data instead of dying. With that, at least you can know where the >> problem is. >> >> This was introduced

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

Thanks for the review comments. On Mon, Nov 23, 2020 at 9:57 PM Alexey Kondratov wrote: > > > v1-0001-postgres_fdw-function-to-discard-cached-connections.patch > > This patch looks pretty straightforward for me, but there are some > things to be addressed IMO: > > + server =

Re: Use macros for calculating LWLock offset

On Fri, Nov 20, 2020 at 03:25:50PM +0900, Michael Paquier wrote: > I agree that this makes this code a bit cleaner, so let's use those > macros. Others may have some comments here, so let's wait a bit > first. Got this one committed as of d03d754. -- Michael signature.asc Description: PGP

Re: Terminate the idle sessions

On Mon, Nov 23, 2020 at 5:02 PM kuroda.hay...@fujitsu.com < kuroda.hay...@fujitsu.com> wrote: > No one have any comments, patch tester says OK, and I think this works > well. > I changed status to "Ready for Committer." > Some proof-reading: v8-0001 Documentation: My suggestion wasn't taken

Re: [POC] Fast COPY FROM command for the table with foreign partitions

On Mon, Nov 23, 2020 at 5:39 PM Andrey Lepikhov wrote: > On 11/23/20 7:49 AM, tsunakawa.ta...@fujitsu.com wrote: > > Could I or my colleague continue this patch in a few days? It looks it's > > stalled over one month. > > I don't found any problems with this patch that needed to be corrected. >

Re: Strange behavior with polygon and NaN

At Sat, 21 Nov 2020 17:33:53 -0500, Tom Lane wrote in > I went ahead and pushed 0001 and 0003 (the latter in two parts), since > they didn't seem particularly controversial to me. Just to keep the > cfbot from whining, here's a rebased version of 0002. I didn't noticed that inf == inf sould be

RE: Disable WAL logging to speed up data loading

Hi On Monday, Nov 23, 2020 12:17 PM Tsunakawa, Takayuki wrote: > PREPARE TRANSACTION is the same as COMMIT in that it persists > transaction updates. A crash during wal_level = none loses both of them. > So, I don't think PREPARE TRANSACTION needs special treatment. Yeah, I got it. That makes

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

On Mon, Nov 23, 2020 at 06:13:17PM -0500, Tom Lane wrote: > Alvaro Herrera writes: >> Please feel free to go ahead, including the change to ProcSleep. > > Will do. Thank you both for 450c823 and 789b938. -- Michael signature.asc Description: PGP signature

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

On 2020-Nov-23, Tom Lane wrote: > I never cared that much for "is_log_level_output" either. Thinking > about renaming it to "should_output_to_log()", and then the new function > would be "should_output_to_client()". Ah, that sounds nicely symmetric and grammatical. Thanks!

Re: should INSERT SELECT use a BulkInsertState?

On Mon, Nov 02, 2020 at 12:45:51PM -0600, Justin Pryzby wrote: > On Mon, Nov 02, 2020 at 07:53:45AM +0100, Luc Vlaming wrote: > > On 30.10.20 05:51, Justin Pryzby wrote: > > > On Thu, Oct 22, 2020 at 01:29:53PM +0100, Simon Riggs wrote: > > > > On Fri, 16 Oct 2020 at 22:05, Justin Pryzby > > > >

Re: abstract Unix-domain sockets

On Fri, Nov 20, 2020 at 04:06:43PM +0100, Peter Eisentraut wrote: > I think we are getting a bit sidetracked here with the message wording. The > reason I looked at this was that "remove socket file and retry" is never an > appropriate action with abstract sockets. And on further analysis, it is

Re: Online verification of checksums

Greetings, On Mon, Nov 23, 2020 at 20:28 Michael Paquier wrote: > On Mon, Nov 23, 2020 at 05:28:52PM -0500, Stephen Frost wrote: > > * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote: > >> Yes and this is a tricky part. Until you have explained it in your > latest > >> message, I

Re: POC: postgres_fdw insert batching

On 11/23/20 3:17 AM, tsunakawa.ta...@fujitsu.com wrote: > From: Tomas Vondra >> I don't think this is usable in practice, because a single session >> may be using multiple FDW servers, with different implementations, >> latency to the data nodes, etc. It's unlikely a single GUC value >> will be

Re: deferred primary key and logical replication

On Tue, Nov 24, 2020 at 3:04 AM Anastasia Lubennikova wrote: > > On 27.10.2020 13:46, Amit Kapila wrote: > > On Sun, Oct 25, 2020 at 9:39 PM Euler Taveira > > wrote: > >> On Mon, 5 Oct 2020 at 08:34, Amit Kapila wrote: > >>> On Mon, May 11, 2020 at 2:41 AM Euler Taveira > >>> wrote: > Hi,

Re: enable_incremental_sort changes query behavior

On Mon, Nov 23, 2020 at 2:24 PM Tom Lane wrote: > > James Coleman writes: > > But I think that still leaves something missing: after all, > > prepare_sort_from_pathkeys does know how to insert new target list > > entries, so something either there (or in the caller/how its called) > > has to be

Re: Online verification of checksums

On Mon, Nov 23, 2020 at 05:28:52PM -0500, Stephen Frost wrote: > * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote: >> Yes and this is a tricky part. Until you have explained it in your latest >> message, I wasn't sure how we can distinct concurrent update from a page >> header

Re: Online verification of checksums

On Mon, Nov 23, 2020 at 10:35:54AM -0500, Stephen Frost wrote: > * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote: >> It seems reasonable to me to rely on checksums only. >> >> As for retry, I think that API for concurrent I/O will be complicated. >> Instead, we can introduce a

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

David Rowley writes: > On Tue, 24 Nov 2020 at 12:50, Greg Nancarrow wrote: >> Hmmm, unfortunately this seems to break my build ... > >> I think your commit needs to be fixed based on the following documentation: >> >>

Re: Parallel plans and "union all" subquery

On Tue, Nov 24, 2020 at 2:34 AM Luc Vlaming wrote: > > Hi, > > For this problem there is a patch I created, which is registered under > https://commitfest.postgresql.org/30/2787/ that should fix this without > any workarounds. Maybe someone can take a look at it? > I tried your patch with the

Re: remove spurious CREATE INDEX CONCURRENTLY wait

Hi, On 2020-11-23 12:30:05 -0300, Alvaro Herrera wrote: > ProcSleep: no bug here. > The flags are checked to see if we should kill() the process (used when > autovac blocks some other process). The lock here appears to be > inconsequential, since we release it before we do kill(); so strictly >

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Tue, 24 Nov 2020 at 12:50, Greg Nancarrow wrote: > Hmmm, unfortunately this seems to break my build ... > I think your commit needs to be fixed based on the following documentation: > > https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005fattribute.html#g_t_005f_005fhas_005fattribute Agreed.

RE: Terminate the idle sessions

No one have any comments, patch tester says OK, and I think this works well. I changed status to "Ready for Committer." Hayato Kuroda FUJITSU LIMITED -Original Message- From: kuroda.hay...@fujitsu.com Sent: Friday, November 20, 2020 11:05 AM To: 'japin' Cc: David G. Johnston ; Kyotaro

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Tue, Nov 24, 2020 at 10:06 AM David Rowley wrote: > > On Tue, 24 Nov 2020 at 09:36, David Rowley wrote: > > Well, that makes it look pretty good. If we can get 10-15% on some > > machines without making things slower on any other machines, then that > > seems like a good win to me. > >

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

Alvaro Herrera writes: > On 2020-Nov-23, Tom Lane wrote: >> I'm not too fussed about whether we invent is_log_level_output_client, >> although that name doesn't seem well-chosen compared to >> is_log_level_output. > Just replacing "log" for "client" in that seemed strictly worse, and I > didn't

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

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> I took a quick look through this. This is just MHO, of course: >> >> * I don't think it's okay to change the existing signatures of >> pg_ls_logdir() et al. > I disagree that we need to stress over this- we pretty routinely

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Tue, 24 Nov 2020 at 09:36, David Rowley wrote: > Well, that makes it look pretty good. If we can get 10-15% on some > machines without making things slower on any other machines, then that > seems like a good win to me. Pushed. Thank you both for reviewing this. David

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

On 2020-Nov-23, Tom Lane wrote: > Ah, I see I didn't cover the case in ProcSleep that you were originally on > about ... I'd just looked for existing references to log_min_messages > and client_min_messages. Yeah, it seemed bad form to add that when you had just argued against it :-) > I think

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

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Justin Pryzby writes: > >> This patch has been waiting for input from a committer on the approach I've > >> taken with the patches since March 10, so I'm planning to set to "Ready" - > >> at > >> least ready for senior review. > > I took a

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

Alvaro Herrera writes: > Your version has the advantage that errstart() doesn't get a new > function call. I'm +1 for going with that ... we could avoid the > duplicate code with some additional contortions but this changes so > rarely that it's probably not worth the trouble. I was considering

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

Alvaro Herrera writes: > On 2020-Nov-23, Tom Lane wrote: >> Here's a draft patch. > Here's another of my own. Outside of elog.c it seems identical. Ah, I see I didn't cover the case in ProcSleep that you were originally on about ... I'd just looked for existing references to log_min_messages

Re: optimizer/clauses.h needn't include access/htup.h

On 2020-Nov-23, Tom Lane wrote: > Anyway, if you're feeling motivated to explore a more wide-ranging > refactoring, by all means have a go at it. I was contemplating commands/trigger.c this morning (after Heikki split copy.c) thinking about the three pieces embedded in there -- one

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

On 2020-Nov-23, Alvaro Herrera wrote: > On 2020-Nov-23, Tom Lane wrote: > > > Here's a draft patch. > > Here's another of my own. Outside of elog.c it seems identical. Your version has the advantage that errstart() doesn't get a new function call. I'm +1 for going with that ... we could

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

On 2020-Nov-23, Tom Lane wrote: > Here's a draft patch. Here's another of my own. Outside of elog.c it seems identical. diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c index 03c553e7ea..a4ab9090f9 100644 --- a/src/backend/access/transam/xact.c +++

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

Here's a draft patch. regards, tom lane diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c index 03c553e7ea..9cd0b7c11b 100644 --- a/src/backend/access/transam/xact.c +++ b/src/backend/access/transam/xact.c @@ -5344,7 +5344,7 @@ static void

Re: New default role- 'pg_read_all_data'

Greetings, * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote: > On 29.10.2020 17:19, Stephen Frost wrote: > >* Georgios Kokolatos (gkokola...@protonmail.com) wrote: > >>this patch is in "Ready for committer" state and the Cfbot is happy. > >Glad that's still the case. :) > > > >>Is

Re: Online verification of checksums

Greetings, * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote: > On 23.11.2020 18:35, Stephen Frost wrote: > >* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote: > >>On 21.11.2020 04:30, Michael Paquier wrote: > >>>The only method I can think as being really > >>>reliable is

Re: PATCH: Batch/pipelining support for libpq

On 2020-Nov-23, Daniel Verite wrote: > Hi, > > Here's a new version with the pgbench support included. Thanks, incorporated into my local copy.

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

On 2020-Nov-23, Tom Lane wrote: > Alvaro Herrera writes: > > Well, we already do this in a number of places. But I can get behind > > this: > > >> Maybe it'd be a good idea to have elog.c expose a new function > >> along the lines of "bool message_level_is_interesting(int elevel)" > >> to

Re: New default role- 'pg_read_all_data'

On 29.10.2020 17:19, Stephen Frost wrote: Greetings, * Georgios Kokolatos (gkokola...@protonmail.com) wrote: this patch is in "Ready for committer" state and the Cfbot is happy. Glad that's still the case. :) Is there any committer that is available for taking a look at it? If there aren't

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

Alvaro Herrera writes: > Well, we already do this in a number of places. But I can get behind > this: >> Maybe it'd be a good idea to have elog.c expose a new function >> along the lines of "bool message_level_is_interesting(int elevel)" >> to support this and similar future optimizations in a

Re: optimizer/clauses.h needn't include access/htup.h

Justin Pryzby writes: > It was only needed between these: > commit a8677e3ff6bb8ef78a9ba676faa647bba237b1c4 > commit f09346a9c6218dd239fdf3a79a729716c0d305bd Hm, you're right. Removed. > I noticed while looking at "what includes what" and wondered if some of these > are kind of "modularity

Re: PATCH: Batch/pipelining support for libpq

Hi, Here's a new version with the pgbench support included. Best regards, -- Daniel Vérité PostgreSQL-powered mailer: https://www.manitou-mail.org Twitter: @DanielVerite diff --git a/doc/src/sgml/libpq.sgml b/doc/src/sgml/libpq.sgml index 9ce32fb39b..2a94f8f6b9 100644 ---

Re: deferred primary key and logical replication

On 27.10.2020 13:46, Amit Kapila wrote: On Sun, Oct 25, 2020 at 9:39 PM Euler Taveira wrote: On Mon, 5 Oct 2020 at 08:34, Amit Kapila wrote: On Mon, May 11, 2020 at 2:41 AM Euler Taveira wrote: Hi, While looking at an old wal2json issue, I stumbled on a scenario that a table with a

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

On 2020-Nov-23, Tom Lane wrote: > Alvaro Herrera writes: > > On 2020-Nov-19, Michael Paquier wrote: > >> By the way, it strikes me that you could just do nothing as long as > >> (log_min_messages > DEBUG1), so you could encapsulate most of the > >> logic that plays with the lock tag using that.

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

Alvaro Herrera writes: > On 2020-Nov-19, Michael Paquier wrote: >> By the way, it strikes me that you could just do nothing as long as >> (log_min_messages > DEBUG1), so you could encapsulate most of the >> logic that plays with the lock tag using that. > Good idea, done. I'm less sure that

Re: Online verification of checksums

On 23.11.2020 18:35, Stephen Frost wrote: Greetings, * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote: On 21.11.2020 04:30, Michael Paquier wrote: The only method I can think as being really reliable is based on two facts: - Do a check only on pd_checksums, as that validates the

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

Justin Pryzby writes: >> This patch has been waiting for input from a committer on the approach I've >> taken with the patches since March 10, so I'm planning to set to "Ready" - at >> least ready for senior review. I took a quick look through this. This is just MHO, of course: * I don't think

optimizer/clauses.h needn't include access/htup.h

It was only needed between these: commit a8677e3ff6bb8ef78a9ba676faa647bba237b1c4 Author: Peter Eisentraut Date: Fri Apr 13 17:06:28 2018 -0400 Support named and default arguments in CALL commit f09346a9c6218dd239fdf3a79a729716c0d305bd Author: Tom Lane Date: Tue Jan 29 15:48:51 2019

walsender bug: stuck during shutdown

Hello Chloe Dives reported that sometimes a walsender would become stuck during shutdown and *not* shutdown, thus preventing postmaster from completing the shutdown cycle. This has been observed to cause the servers to remain in such state for several hours. After a lengthy investigation and

Re: Keep elog(ERROR) and ereport(ERROR) calls in the cold path

On Sat, 21 Nov 2020 at 03:26, Peter Eisentraut wrote: > > I did tests of elog_ereport_attribute_cold_v4.patch on an oldish Mac > Intel laptop with pgbench scale 1 (default), and then: > > pgbench -S -T 60 > > master: tps = 8251.883229 (excluding connections establishing) > patched: tps =

Re: "as quickly as possible" (was: remove spurious CREATE INDEX CONCURRENTLY wait)

On 2020-Nov-19, Michael Paquier wrote: > On Thu, Nov 19, 2020 at 12:13:44PM +0900, Michael Paquier wrote: > > That still looks useful for debugging, so DEBUG1 sounds fine to me. > > By the way, it strikes me that you could just do nothing as long as > (log_min_messages > DEBUG1), so you could

Re: DROP relation IF EXISTS Docs and Tests - Bug Fix

On 30.09.2020 05:00, David G. Johnston wrote: On Tue, Sep 15, 2020 at 3:48 PM Alexander Korotkov mailto:aekorot...@gmail.com>> wrote: Hi! I've skimmed through the thread and checked the patchset. Everything looks good, except one paragraph, which doesn't look completely clear.

Re: mark/restore failures on unsorted merge joins

Andrew Gierth writes: > The problem is that the planner calls ExecSupportsMarkRestore to find > out whether a Materialize node is needed, and that function looks no > further than the Path type of T_Index[Only]Path in order to return true, > even though in this case it's a GiST index which does

mark/restore failures on unsorted merge joins

>From a report by user "kes" on irc, I constructed this test case: create table marktst (id integer, val numrange, exclude using gist (val with &&)); insert into marktst select i, numrange(i, i+1, '[)') from generate_series(1,1000) i; vacuum marktst; analyze marktst; select * from (select val

Re: error_severity of brin work item

I think this formulation (attached v3) has fewer moving parts. However, now that I did that, I wonder if this is really the best approach to solve this problem. Maybe instead of doing this at the BRIN level, it should be handled at the autovac level, by having the worker copy the work-item to

Re: enable_incremental_sort changes query behavior

James Coleman writes: > But I think that still leaves something missing: after all, > prepare_sort_from_pathkeys does know how to insert new target list > entries, so something either there (or in the caller/how its called) > has to be enforcing an apparently implicit rule about what point in >

Re: Connection using ODBC and SSL

Thank you for the assistance. From: Andrew Dunstan Sent: Saturday, November 21, 2020 11:14 To: Corbit, Dann ; PostgreSQL Developers Cc: Luton, Bill ; Fifer, Brian ; Lao, Alexander Subject: Re: Connection using ODBC and SSL On 11/20/20 4:54 PM, Corbit, Dann

Re: truncating timestamps on arbitrary intervals

On Thu, Nov 12, 2020 at 9:56 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > > On 2020-06-30 06:34, John Naylor wrote: > > In v9, I've simplified the patch somewhat to make it easier for future > > work to build on. > > > > - When truncating on month-or-greater intervals, require

Re: Online checksums patch - once again

On 17/11/2020 10:56, Daniel Gustafsson wrote: On 5 Oct 2020, at 13:36, Heikki Linnakangas wrote: 2. The signaling between enable_data_checksums() and the launcher process looks funny to me. The general idea seems to be that enable_data_checksums() just starts the launcher process, and the

Re: Bogus documentation for bogus geometric operators

Pavel Borisov writes: > I've made another check of the final state and suppose it is ready to be > pushed. Sounds good, pushed. regards, tom lane

Re: pg_upgrade fails with non-standard ACL

Tested this patch by running several upgrades from different major versions and different setups. ACL, that are impossible to apply, are detected and reported, so it looks good for me.

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

Hi, On 2020-11-23 09:48, Bharath Rupireddy wrote: Here is how I'm making 4 separate patches: 1. new function and it's documentation. 2. GUC and it's documentation. 3. server level option and it's documentation. 4. test cases for all of the above patches. Hi, I'm attaching the patches here.

Re: pg_proc.dat "proargmodes is not a 1-D char array"

On 2020-Nov-23, Tom Lane wrote: > Alvaro Herrera writes: > > So let's go with this one. > > WFM. Thanks, pushed.

Re: [bug+patch] Inserting DEFAULT into generated columns from VALUES RTE

Dean Rasheed writes: > On Sun, 22 Nov 2020 at 20:58, Tom Lane wrote: >> However, I think that just adjusting the error string would be >> helpful, as attached. > +1 >> (I'm also wondering why the second case is generic ERRCODE_SYNTAX_ERROR >> and not ERRCODE_GENERATED_ALWAYS. Didn't change it

Re: abstract Unix-domain sockets

On Mon, Nov 23, 2020 at 6:50 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2020-11-20 18:23, David G. Johnston wrote: > > If there is dead code there is an underlying problem to > > address/discover, not just removing the dead code. In this case are we > > saying that a new

Re: remove spurious CREATE INDEX CONCURRENTLY wait

Alvaro Herrera writes: > PROC_IN_LOGICAL_DECODING: > Oddly enough, I think the reset of PROC_IN_LOGICAL_DECODING in > ReplicationSlotRelease might be the most problematic one of the lot. > That's because a proc's xmin that had been ignored all along by > ComputeXidHorizons, will now be included

Re: cutting down the TODO list thread

On Mon, Nov 23, 2020 at 10:41:25AM -0400, John Naylor wrote: > With the exception of "Fix /contrib/btree_gist's implementation of inet > indexing", all items above have been either moved over, or removed if they > were > done already by PG13. Thanks. -- Bruce Momjian

Re: Online verification of checksums

Greetings, * Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote: > On 21.11.2020 04:30, Michael Paquier wrote: > >The only method I can think as being really > >reliable is based on two facts: > >- Do a check only on pd_checksums, as that validates the full contents > >of the page. > >-

Re: Parallel plans and "union all" subquery

On 23-11-2020 13:17, Phil Florent wrote: Hi Greg, The implicit conversion was the cause of the non parallel plan, thanks for the explanation and the workarounds. It can cause a huge difference in terms of performance, I will give the information to our developers. Regards, Phil

Re: remove spurious CREATE INDEX CONCURRENTLY wait

On 2020-Nov-18, Andres Freund wrote: > In 13 this is: > LWLockAcquire(ProcArrayLock, LW_EXCLUSIVE); > MyPgXact->vacuumFlags |= PROC_IN_VACUUM; > if (params->is_wraparound) > MyPgXact->vacuumFlags |= PROC_VACUUM_FOR_WRAPAROUND; >

Re: Online verification of checksums

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Fri, Nov 20, 2020 at 11:08:27AM -0500, Stephen Frost wrote: > > David Steele (da...@pgmasters.net) wrote: > >> Our current plan for pgBackRest: > >> > >> 1) Remove the LSN check as you have done in your patch and when rechecking > >>

Re: pg_proc.dat "proargmodes is not a 1-D char array"

Alvaro Herrera writes: > So let's go with this one. WFM. regards, tom lane

Re: pg_proc.dat "proargmodes is not a 1-D char array"

On 2020-Nov-17, Tom Lane wrote: > Robert Haas writes: > > On Tue, Nov 17, 2020 at 10:32 AM Tom Lane wrote: > >> Adding the expected length to the error message might be OK though. > > > Certainly seems like we should do at least that much. The current > > message is just wrong, right? > >

Re: [bug+patch] Inserting DEFAULT into generated columns from VALUES RTE

On Sun, 22 Nov 2020 at 20:58, Tom Lane wrote: > > I found only one nitpicky bug: in > findDefaultOnlyColumns, the test must be bms_is_empty(default_only_cols) > not just default_only_cols == NULL, or it will fail to fall out early > as intended when the first row contains some DEFAULTs but later

Re: cutting down the TODO list thread

With the exception of "Fix /contrib/btree_gist's implementation of inet indexing", all items above have been either moved over, or removed if they were done already by PG13. -- John Naylor EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [PoC] Non-volatile WAL buffer

Hi, On 11/23/20 3:01 AM, Tomas Vondra wrote: > Hi, > > On 10/30/20 6:57 AM, Takashi Menjo wrote: >> Hi Heikki, >> >>> I had a new look at this thread today, trying to figure out where >>> we are. >> >> I'm a bit confused. >>> >>> One thing we have established: mmap()ing WAL files performs worse

Re: abstract Unix-domain sockets

On 2020-11-20 18:23, David G. Johnston wrote: If there is dead code there is an underlying problem to address/discover, not just removing the dead code.  In this case are we saying that a new server won’t ever fail to start because the socket file exists but instead will just clobber the file

Re: libpq compression

** this is a plaintext version of the previous HTML-formatted message ** Hi, I’ve run a couple of pgbenchmarks using this patch with odyssey connection pooler, with client-to-pooler ZSTD compression turned on. pgbench --builtin tpcb-like -t 75 --jobs=32 --client=1000 CPU utilization chart of

Re: Fix generate_useful_gather_paths for parallel unsafe pathkeys

On Sun, Nov 22, 2020 at 4:59 PM Tomas Vondra wrote: > > On 11/21/20 2:55 AM, James Coleman wrote: > > Over on the -bugs list we had a report [1] of a seg fault with > > incremental sort. The short of the investigation there was that a > > subplan wasn't being serialized since it wasn't parallel

Re: Why does create_gather_merge_plan need make_sort?

On Sun, Nov 22, 2020 at 5:07 PM Tomas Vondra wrote: > > On 11/22/20 10:31 PM, Tom Lane wrote: > > Tomas Vondra writes: > >> On 11/20/20 11:24 PM, James Coleman wrote: > >>> While looking at another issue I noticed that create_gather_merge_plan > >>> calls make_sort if the subplan isn't

Re: Online verification of checksums

On 21.11.2020 04:30, Michael Paquier wrote: The only method I can think as being really reliable is based on two facts: - Do a check only on pd_checksums, as that validates the full contents of the page. - When doing a retry, make sure that there is no concurrent I/O activity in the shared

RE: Parallel plans and "union all" subquery

Hi Greg, The implicit conversion was the cause of the non parallel plan, thanks for the explanation and the workarounds. It can cause a huge difference in terms of performance, I will give the information to our developers. Regards, Phil De : Greg Nancarrow

Re: [HACKERS] Custom compression methods

On Sat, Nov 21, 2020 at 3:50 AM Robert Haas wrote: > > On Wed, Nov 11, 2020 at 9:39 AM Dilip Kumar wrote: > > There were a few problems in this rebased version, basically, the > > compression options were not passed while compressing values from the > > brin_form_tuple, so I have fixed this. > >

Re: Bogus documentation for bogus geometric operators

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:tested, passed I've made another check of the final state and suppose it is

Re: [HACKERS] logical decoding of two-phase transactions

On Mon, Nov 23, 2020 at 3:41 PM Ajin Cherian wrote: > > On Sun, Nov 22, 2020 at 12:31 AM Amit Kapila wrote: > > > I am planning to continue review of these patches but I thought it is > > better to check about the above changes before proceeding further. Let > > me know what you think? > > > >

Re: Parallel Inserts in CREATE TABLE AS

On Mon, Oct 19, 2020 at 10:47 PM Bharath Rupireddy wrote: > > Attaching v3 patch herewith. > > I'm done with all the open points in my list. Please review the v3 patch and > provide comments. > Attaching v4 patch, rebased on the latest master 68b1a4877e. Also, added this feature to commitfest -

Re: Use of "long" in incremental sort code

On 05.11.2020 02:53, James Coleman wrote: On Tue, Nov 3, 2020 at 4:42 PM Tomas Vondra wrote: On Tue, Nov 03, 2020 at 03:53:53AM +0100, Tomas Vondra wrote: Hi, I took another look at this, and 99% of the patch (the fixes to sort debug messages) seems fine to me. Attached is the part I plan

Re: Multi Inserts in CREATE TABLE AS - revived patch

On Mon, Nov 23, 2020 at 3:26 PM Heikki Linnakangas wrote: > > On 23/11/2020 11:15, Bharath Rupireddy wrote: > > Attaching v2 patch, rebased on the latest master 17958972. > > I just broke this again with commit c532d15ddd to split up copy.c. > Here's another rebased version. > Thanks! I noticed

Re: [HACKERS] logical decoding of two-phase transactions

On Sun, Nov 22, 2020 at 12:31 AM Amit Kapila wrote: > I am planning to continue review of these patches but I thought it is > better to check about the above changes before proceeding further. Let > me know what you think? > I've had a look at the changes and done a few tests, and have no

prion failed with ERROR: missing chunk number 0 for toast value 14334 in pg_toast_2619

Hi, After my commit c532d15ddd to split up copy.c, buildfarm animal "prion" failed in pg_upgrade (https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion=2020-11-23%2009%3A23%3A16): Upgrade Complete Optimizer statistics are not transferred by pg_upgrade so, once you

  1   2   >