Re: Continuing instability in insert-conflict-specconflict test

The test material added in commit 43e0841 continues to yield buildfarm failures. Failures new since the rest of this thread: damselfly│ 2021-02-02 10:19:15 │ HEAD │ http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=damselfly&dt=2021-02-02%2010%3A19%3A15 drongo │ 2021-02

Re: "an SQL" vs. "a SQL"

On Sun, Jun 13, 2021 at 07:36:54AM +0100, Geoff Winkless wrote: > On Thu, 10 Jun 2021, 15:35 Alvaro Herrera, wrote: >> src/backend/libpq/auth.c:847:* has. If it's an MD5 hash, we must do >> MD5 authentication, and if it's a >> src/backend/libpq/auth.c:848:* SCRAM secret, we must do SCRAM

Re: pg_regress.c also sensitive to various PG* environment variables

On Sat, Jun 12, 2021 at 09:10:06AM +0900, Michael Paquier wrote: > Good idea, thanks. I'll add comments for each one that cannot be > unsetted. And done, finally. -- Michael signature.asc Description: PGP signature

Re: "an SQL" vs. "a SQL"

On 6/13/21 7:13 AM, Michael Paquier wrote: > On Sun, Jun 13, 2021 at 07:36:54AM +0100, Geoff Winkless wrote: >> On Thu, 10 Jun 2021, 15:35 Alvaro Herrera, wrote: >>> src/backend/libpq/auth.c:847:* has. If it's an MD5 hash, we must do >>> MD5 authentication, and if it's a >>> src/backend/lib

Re: unnesting multirange data types

On Sun, Jun 13, 2021 at 2:58 AM Alexander Korotkov wrote: > On Sun, Jun 13, 2021 at 1:16 AM Jonathan S. Katz wrote: > > On 6/12/21 5:57 PM, Alexander Korotkov wrote: > > > On Sat, Jun 12, 2021 at 2:44 AM Alexander Korotkov > > > wrote: > > >> ()On Sat, Jun 12, 2021 at 2:30 AM Justin Pryzby >

Re: doc issue missing type name "multirange" in chapter title

On Fri, Jun 11, 2021 at 11:16 PM Tom Lane wrote: > > Alexander Korotkov writes: > > What about "Range/Multirange Functions and Operators"? > > Better than a comma, I guess. Personally I didn't have a > problem with the form with two "ands". Thank you. I propose to push the slash option because

Re: An out-of-date comment in nodeIndexonlyscan.c

On Sat, Jun 12, 2021 at 2:35 PM Thomas Munro wrote: > ... and here is the corresponding code change, with a test to > demonstrate the change. > > I'm working on a proof-of-concept to skip the btree page lock > sometimes too, which seems promising, but it requires some planner > work which has temp

Re: unnesting multirange data types

On 6/13/21 7:43 AM, Alexander Korotkov wrote: > On Sun, Jun 13, 2021 at 2:58 AM Alexander Korotkov > wrote: >> On Sun, Jun 13, 2021 at 1:16 AM Jonathan S. Katz >> wrote: >>> Again, I'll defer to others on the code, but this seems to solve the use >>> case I presented. Thanks for the quick turn

Re: unnesting multirange data types

On 6/13/21 8:26 AM, Jonathan S. Katz wrote: > One question: if I were to make a custom multirange type (e.g. let's say > I use "inet" to make "inetrange" and then a "inetmultirange") will this > method still work? It seems so, but I wanted clarify. I went ahead and answered this myself: "yes":

Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

Hi Andres, thanks for taking a look. Em sáb., 12 de jun. de 2021 às 16:27, Andres Freund escreveu: > Hi, > > On 2021-06-12 10:55:22 -0300, Ranier Vilela wrote: > > With the recent changes at procarray.c, I take a look in. > > msvc compiler, has some warnings about signed vs unsigned. > > > 1. Si

Re: An out-of-date comment in nodeIndexonlyscan.c

On Mon, 14 Jun 2021 at 00:02, Thomas Munro wrote: > Here's a highly experimental patch I came up with that seems to > produce the right results in simple cases, without (yet) involving the > planner. + /* Find all equality quals. */ + for (int i = 0; i < n_scan_keys; ++i) + { + if (scan_keys[i].s

Re: a path towards replacing GEQO with something better

Hi, On 6/10/21 3:21 AM, John Naylor wrote: > Hi, > > On occasion it comes up that the genetic query optimizer (GEQO) doesn't > produce particularly great plans, and is slow ([1] for example). The > only alternative that has gotten as far as a prototype patch (as far as > I know) is simulated anne

Re: Fdw batch insert error out when set batch_size > 65535

On 6/13/21 2:40 AM, Alvaro Herrera wrote: > On 2021-Jun-12, Tomas Vondra wrote: > >> There's one caveat, though - for regular builds the slowdown is pretty >> much eliminated. But with valgrind it's still considerably slower. For >> postgres_fdw the "make check" used to take ~5 minutes for me, n

Re: unnesting multirange data types

On Sat, Jun 12, 2021 at 4:58 PM Alexander Korotkov wrote: > On Sun, Jun 13, 2021 at 1:16 AM Jonathan S. Katz > wrote: > > On 6/12/21 5:57 PM, Alexander Korotkov wrote: > > > On Sat, Jun 12, 2021 at 2:44 AM Alexander Korotkov < > aekorot...@gmail.com> wrote: > > >> ()On Sat, Jun 12, 2021 at 2:30

Re: unnesting multirange data types

On 6/13/21 10:57 AM, Zhihong Yu wrote: > > > On Sat, Jun 12, 2021 at 4:58 PM Alexander Korotkov > wrote: > > On Sun, Jun 13, 2021 at 1:16 AM Jonathan S. Katz > mailto:jk...@postgresql.org>> wrote: > > On 6/12/21 5:57 PM, Alexander Korotkov wrote: > >

Re: Fdw batch insert error out when set batch_size > 65535

On Sun, Jun 13, 2021 at 6:10 AM Alvaro Herrera wrote: > > On 2021-Jun-12, Tomas Vondra wrote: > > > There's one caveat, though - for regular builds the slowdown is pretty > > much eliminated. But with valgrind it's still considerably slower. For > > postgres_fdw the "make check" used to take ~5 mi

Re: unnesting multirange data types

On Sun, Jun 13, 2021 at 11:25:05AM -0400, Jonathan S. Katz wrote: > On 6/13/21 10:57 AM, Zhihong Yu wrote: > > +/* Turn multirange into a set of ranges */ > > > > set of ranges: sequence of ranges > > I believe "set of ranges" is accurate here, as the comparable return is > a "SETOF rangetype". S

Re: Fdw batch insert error out when set batch_size > 65535

On 6/13/21 5:25 PM, Bharath Rupireddy wrote: > On Sun, Jun 13, 2021 at 6:10 AM Alvaro Herrera > wrote: >> >> On 2021-Jun-12, Tomas Vondra wrote: >> >>> There's one caveat, though - for regular builds the slowdown is pretty >>> much eliminated. But with valgrind it's still considerably slower.

Re: Race condition in recovery?

On 2021-06-10 01:09, Tom Lane wrote: Robert Haas writes: Got it. I have now committed the patch to all branches, after adapting your changes just a little bit. Thanks to you and Kyotaro-san for all the time spent on this. What a slog! conchuela failed its first encounter with this test cas

Re: Slow standby snapshot

)Hello. > I recently ran into a problem in one of our production postgresql cluster. > I had noticed lock contention on procarray lock on standby, which causes WAL > replay lag growth. Yes, I saw the same issue on my production cluster. > 1) set max_connections to big number, like 10 I made

Re: unnesting multirange data types

On 6/13/21 11:49 AM, Justin Pryzby wrote: > On Sun, Jun 13, 2021 at 11:25:05AM -0400, Jonathan S. Katz wrote: >> On 6/13/21 10:57 AM, Zhihong Yu wrote: >>> +/* Turn multirange into a set of ranges */ >>> >>> set of ranges: sequence of ranges >> >> I believe "set of ranges" is accurate here, as the

Re: Use extended statistics to estimate (Var op Var) clauses

Hi, Here is a slightly updated version of the patch - rebased to current master and fixing some minor issues to handle expressions (and not just the Var nodes as before). The changes needed to support (Expr op Expr) are mostly mechanical, though I'm sure the code needs some cleanup. The main

Re: Continuing instability in insert-conflict-specconflict test

Noah Misch writes: > The test material added in commit 43e0841 continues to yield buildfarm > failures. Yeah. It's only a relatively small fraction of the total volume of isolation-test failures, so I'm not sure it's worth expending a whole lot of effort on this issue by itself. > On Tue, Aug 2

Re: unnesting multirange data types

On Sun, Jun 13, 2021 at 5:53 PM Zhihong Yu wrote: > + ObjectAddress myself, > > nit: myself -> self Probably "self" is a better name than "myself" in this context. However, you can see that the surrounding code already uses the name "myself". Therefore, I prefer to stay with "myself". --

Re: logical decoding and replication of sequences

Hi, Seems the cfbot was not entirely happy with the patch on some platforms, so here's a fixed version. There was a bogus call to ensure_transaction function (which does not exist at all) and a silly bug in transaction management in apply_handle_sequence. regards -- Tomas Vondra Enterprise

Re: unnesting multirange data types

On Sun, Jun 13, 2021 at 9:46 PM Jonathan S. Katz wrote: > > On 6/13/21 11:49 AM, Justin Pryzby wrote: > > On Sun, Jun 13, 2021 at 11:25:05AM -0400, Jonathan S. Katz wrote: > >> On 6/13/21 10:57 AM, Zhihong Yu wrote: > >>> +/* Turn multirange into a set of ranges */ > >>> > >>> set of ranges: seque

Re: Continuing instability in insert-conflict-specconflict test

On Sun, Jun 13, 2021 at 04:48:48PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Tue, Aug 25, 2020 at 12:04:41PM -0400, Tom Lane wrote: > >> I think what we have to do to salvage this test is to get rid of the > >> use of NOTICE outputs, and instead have the test functions insert > >> log rec

Re: An out-of-date comment in nodeIndexonlyscan.c

On Mon, Jun 14, 2021 at 12:54 AM David Rowley wrote: > I think a more optimal and nicer way of doing that would be setting > bits in a Bitmapset then checking bms_num_members is equal to > n_scan_keys. Shouldn't it be compared with indnkeyatts? Yes, much nicer, thanks! From 2325ae403196f73865f7c

Re: Continuing instability in insert-conflict-specconflict test

Noah Misch writes: > On Sun, Jun 13, 2021 at 04:48:48PM -0400, Tom Lane wrote: >> * Adjust the test script's functions to emit a NOTICE *after* acquiring >> a lock, not before. > I suspect that particular lock acquisition merely unblocks the processing that > reaches the final lock state expected

Re: Continuing instability in insert-conflict-specconflict test

On Sun, Jun 13, 2021 at 06:09:20PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Sun, Jun 13, 2021 at 04:48:48PM -0400, Tom Lane wrote: > >> * Adjust the test script's functions to emit a NOTICE *after* acquiring > >> a lock, not before. > > > I suspect that particular lock acquisition merel

Re: Continuing instability in insert-conflict-specconflict test

Hi, On 2021-06-13 15:22:12 -0700, Noah Misch wrote: > On Sun, Jun 13, 2021 at 06:09:20PM -0400, Tom Lane wrote: > > We might be able to get rid of the stuff about concurrent step > > completion in isolationtester.c if we required the spec files > > to use annotations to force a deterministic step

Re: Continuing instability in insert-conflict-specconflict test

On 14/06/21 11:49 am, Andres Freund wrote: Hi, On 2021-06-13 15:22:12 -0700, Noah Misch wrote: On Sun, Jun 13, 2021 at 06:09:20PM -0400, Tom Lane wrote: We might be able to get rid of the stuff about concurrent step completion in isolationtester.c if we required the spec files to use annotatio

Re: Fix DROP TABLESPACE on Windows with ProcSignalBarrier?

Just as an FYI: this entry currently fails with "Timed out!" on cfbot because of an oversight in the master branch[1], AFAICS. It should pass again once that's fixed. [1] https://www.postgresql.org/message-id/CA%2BhUKGLah2w1pWKHonZP_%2BEQw69%3Dq56AHYwCgEN8GDzsRG_Hgw%40mail.gmail.com

Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

On Thu, Jun 10, 2021 at 11:09:52AM +0900, Michael Paquier wrote: > On Tue, Jun 08, 2021 at 11:32:21PM -0400, Tom Lane wrote: >> In the meantime I'm +1 for dropping this logic from VACUUM FULL. >> I don't even want to spend enough more time on it to confirm the >> different overhead measurements tha

RE: pgbench bug candidate: negative "initial connection time"

Dear Fabien, Thank you for replying! > Hmmm. Possibly. Another option could be not to report anything after some > errors. I'm not sure, because it would depend on the use case. I guess the > command returned an error status as well. I did not know any use cases and decisions , but I vote to r

Re: Error on pgbench logs

>> + while ((next = agg->start_time + agg_interval * INT64CONST(100)) >> <= now) >> >> I can find the similar code to convert "seconds" to "us" using casting >> like >> >> end_time = threads[0].create_time + (int64) 100 * duration; >> >> or >> >> next_report = last_report + (int64) 100

Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

Em dom., 13 de jun. de 2021 às 09:43, Ranier Vilela escreveu: > Hi Andres, thanks for taking a look. > > Em sáb., 12 de jun. de 2021 às 16:27, Andres Freund > escreveu: > >> Hi, >> >> On 2021-06-12 10:55:22 -0300, Ranier Vilela wrote: >> > With the recent changes at procarray.c, I take a look in

Re: Different compression methods for FPI

On Tue, Jun 01, 2021 at 11:06:53AM +0900, Michael Paquier wrote: > - Speed and CPU usage. We should worry about that for CPU-bounded > environments. > - Compression ratio, which is just monitoring the difference in WAL. > - Effect of the level of compression perhaps? > - Use a fixed amount of WAL

Re: unnesting multirange data types

On Sun, Jun 13, 2021 at 2:10 PM Alexander Korotkov wrote: > On Sun, Jun 13, 2021 at 5:53 PM Zhihong Yu wrote: > > + ObjectAddress myself, > > > > nit: myself -> self > > Probably "self" is a better name than "myself" in this context. > However, you can see that the surrounding code already use

Re: Use extended statistics to estimate (Var op Var) clauses

On Sun, Jun 13, 2021 at 1:29 PM Tomas Vondra wrote: > Hi, > > Here is a slightly updated version of the patch - rebased to current > master and fixing some minor issues to handle expressions (and not just > the Var nodes as before). > > The changes needed to support (Expr op Expr) are mostly mech

Re: Continuing instability in insert-conflict-specconflict test

On Sun, Jun 13, 2021 at 04:49:04PM -0700, Andres Freund wrote: > On 2021-06-13 15:22:12 -0700, Noah Misch wrote: > > On Sun, Jun 13, 2021 at 06:09:20PM -0400, Tom Lane wrote: > > > We might be able to get rid of the stuff about concurrent step > > > completion in isolationtester.c if we required th

RE: Transactions involving multiple postgres foreign servers, take 2

From: Robert Haas > On Thu, Jun 10, 2021 at 9:58 PM tsunakawa.ta...@fujitsu.com > wrote: > > The question I have been asking is how. With that said, we should only have > two options; one is the return value of the FDW commit routine, and the other > is > via ereport(ERROR). I suggested the po

Re: Avoid stuck of pbgench due to skipped transactions

Hello Fabien, On Sun, 13 Jun 2021 08:56:59 +0200 (CEST) Fabien COELHO wrote: > > I attached a patch for this fix. > > The patch mostly works for me, and I agree that the bench should not be in > a loop on any parameters, even when "crazy" parameters are given… > > However I'm not sure this is

Re: unnesting multirange data types

On Sun, Jun 13, 2021 at 06:36:42PM -0700, Zhihong Yu wrote: > On Sun, Jun 13, 2021 at 2:10 PM Alexander Korotkov > wrote: > > On Sun, Jun 13, 2021 at 5:53 PM Zhihong Yu wrote: > > > + ObjectAddress myself, > > > > > > nit: myself -> self > > > > Probably "self" is a better name than "myself" i

Re: An out-of-date comment in nodeIndexonlyscan.c

On Mon, 14 Jun 2021 at 10:03, Thomas Munro wrote: > > On Mon, Jun 14, 2021 at 12:54 AM David Rowley wrote: > > I think a more optimal and nicer way of doing that would be setting > > bits in a Bitmapset then checking bms_num_members is equal to > > n_scan_keys. > > Shouldn't it be compared with i

Re: Added missing tab completion for alter subscription set option

On Fri, Jun 11, 2021 at 12:27 PM Michael Paquier wrote: > > On Sun, May 23, 2021 at 04:24:59PM +0530, vignesh C wrote: > > /* Complete "CREATE SUBSCRIPTION ... WITH ( " */ > > else if (HeadMatches("CREATE", "SUBSCRIPTION") && TailMatches("WITH", > > "(")) > > - COMPLETE_

Re: Decoding speculative insert with toast leaks memory

On Fri, Jun 11, 2021 at 7:23 PM Amit Kapila wrote: > > On Fri, Jun 11, 2021 at 11:37 AM Dilip Kumar wrote: > > > > On Thu, Jun 10, 2021 at 7:15 PM Amit Kapila wrote: > > > > > > > > > > > Please find the patch for HEAD attached. Can you please prepare the > > > patch for back-branches by doing a

RE: psql - factor out echo code

>-Original Message- >From: Fabien COELHO >Sent: Sunday, May 30, 2021 6:10 PM >To: PostgreSQL Developers >Subject: psql - factor out echo code > > >While working on something in "psql/common.c" I noticed some triplicated code, >including a long translatable string. This minor patch refacto

Re: Decoding speculative insert with toast leaks memory

On Mon, Jun 14, 2021 at 8:34 AM Amit Kapila wrote: > > I think the test in this patch is quite similar to what Noah has > pointed in the nearby thread [1] to be failing at some intervals. Can > you also please once verify the same and if we can expect similar > failures here then we might want to

Relaxing the sub-transaction restriction in parallel query

Hi, Currently we don't allow a sub-transaction to be spawned from inside a parallel worker (and also from a leader who is in parallel mode). This imposes a restriction that pl/pgsql functions that use an exception block can't be marked parallel safe, even when the exception block is there only to

RE: [PATCH] expand the units that pg_size_pretty supports on output

>From: David Christensen >Sent: Friday, June 4, 2021 4:18 AM >To: PostgreSQL-development >Subject: Re: [PATCH] expand the units that pg_size_pretty supports on output > >New versions attached to address the initial CF feedback and rebase on HEAD as >of now. > >0001-Expand-the-units-that-pg_size

Re: Failure in subscription test 004_sync.pl

On Sat, Jun 12, 2021 at 9:57 PM Amit Kapila wrote: > > On Sat, Jun 12, 2021 at 1:13 PM Michael Paquier wrote: > > > > wrasse has just failed with what looks like a timing error with a > > replication slot drop: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=wrasse&dt=2021-06-12%2006%

Re: An out-of-date comment in nodeIndexonlyscan.c

On Mon, Jun 14, 2021 at 2:29 PM David Rowley wrote: > Have you also thought about deferrable unique / primary key constraints? > > It's possible to the uniqueness temporarily violated during a > transaction when the unique constraint is deferred, Oh, yeah, very good question. I think many scenar

Fix around conn_duration in pgbench

Hi, TState has a field called "conn_duration" and this is, the comment says, "cumulated connection and deconnection delays". This value is summed over threads and reported as "average connection time" under -C/--connect. If this options is not specified, the value is never used. However, I found

Re: [bug?] Missed parallel safety checks, and wrong parallel safety

On Sat, Jun 12, 2021 at 1:56 AM Robert Haas wrote: > > On Fri, Jun 11, 2021 at 12:13 AM Amit Kapila wrote: > > Do we invalidate relcache entry if someone changes say trigger or some > > index AM function property via Alter Function (in our case from safe > > to unsafe or vice-versa)? Tsunakawa-Sa

Re: Decoding speculative insert with toast leaks memory

On Mon, Jun 14, 2021 at 9:44 AM Dilip Kumar wrote: > > On Mon, Jun 14, 2021 at 8:34 AM Amit Kapila wrote: > > > > I think the test in this patch is quite similar to what Noah has > > pointed in the nearby thread [1] to be failing at some intervals. Can > > you also please once verify the same and

Re: [bug?] Missed parallel safety checks, and wrong parallel safety

Amit Kapila writes: > Why do you think we don't need to check index AM functions? Primarily because index AMs and opclasses can only be defined by superusers, and the superuser is assumed to know what she's doing. More generally, we've never made any provisions for the properties of index AMs or

Re: Avoid stuck of pbgench due to skipped transactions

I attached a patch for this fix. The patch mostly works for me, and I agree that the bench should not be in a loop on any parameters, even when "crazy" parameters are given… However I'm not sure this is the right way to handle this issue. The catch-up loop can be dropped and the automaton ca

Re: Fix dropped object handling in pg_event_trigger_ddl_commands

On Fri, Jun 11, 2021 at 09:36:57PM +0900, Michael Paquier wrote: > Hm, nope. I think that we had better pass true as argument here. The main patch has been applied as of 2d689ba. > First, this is more consistent with the identity lookup (OK, it does > not matter as we would have discarded the ob

RE: psql - factor out echo code

Wouldn't it be better to comment it like any other function? Sure. Attached. -- Fabien.diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c index 9a00499510..00e5bf290b 100644 --- a/src/bin/psql/common.c +++ b/src/bin/psql/common.c @@ -523,6 +523,18 @@ PrintTiming(double elapsed_msec)