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: > >

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. >

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: 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

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

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

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", > > "(")) > > -

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

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"

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

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

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

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

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

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: 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

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: 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

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

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: 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

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 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

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

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

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

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:

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

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: 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

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

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: 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

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

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: 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".

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

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: 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: 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,

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

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

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.

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: 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

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

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

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: "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 >>>

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 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: 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=2021-02-02%2010%3A19%3A15 drongo │

Re: Avoid stuck of pbgench due to skipped transactions

Hello Yugo-san, For example, when I usee a large rate (-R) for throttling and a small latency limit (-L) values with a duration (-T), pbbench got stuck. $ pgbench -T 5 -R 1 -L 1; Indeed, it does not get out of the catchup loop for a long time because even scheduling takes more time

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

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 > authentication. > Not sure whether you were just listing