Re: Add A Glossary

On 2020-May-17, Jürgen Purtz wrote: > On 15.05.20 02:00, Alvaro Herrera wrote: > > Thanks everybody. I have compiled together all the suggestions and the > > result is in the attached patch. Some of it is of my own devising. > > > > * I changed "instance", and made "cluster" be mostly a synonym

Re: Add A Glossary

On 15.05.20 02:00, Alvaro Herrera wrote: Thanks everybody. I have compiled together all the suggestions and the result is in the attached patch. Some of it is of my own devising. * I changed "instance", and made "cluster" be mostly a synonym of that. In my understanding, "instance" and "cluste

Re: [HACKERS] Restricting maximum keep segments by repslots

Hi, On 2020-05-16 22:51:50 -0400, Alvaro Herrera wrote: > On 2020-May-16, Andres Freund wrote: > > > I, independent of this patch, added a few additional paths in which > > checkpointer's latch is reset, and I found a few shutdowns in regression > > tests to be extremely slow / timing out. The r

Re: [HACKERS] Restricting maximum keep segments by repslots

On 2020-May-16, Andres Freund wrote: > I, independent of this patch, added a few additional paths in which > checkpointer's latch is reset, and I found a few shutdowns in regression > tests to be extremely slow / timing out. The reason for that is that > the only check for interrupts is at the to

Re: Add A Glossary

On 2020-May-16, Erik Rijkers wrote: > On 2020-05-15 19:26, Alvaro Herrera wrote: > > Applied all these suggestions, and made a few additional very small > > edits, and pushed -- better to ship what we have now in beta1, but > > further edits are still possible. > > I've gone through the glossary

Re: Potentially misleading name of libpq pass phrase hook

On 5/16/20 7:47 PM, Tom Lane wrote: > Daniel Gustafsson writes: >>> On 16 May 2020, at 03:56, Michael Paquier wrote: >>> Agreed. PQsslKeyPassHook__type sounds fine to me as >>> convention. Wouldn't we want to also rename PQsetSSLKeyPassHook and >>> PQgetSSLKeyPassHook, appending an "_OpenSSL"

Performance penalty when requesting text values in binary format

I'm the creator of the PostgreSQL driver pgx (https://github.com/jackc/pgx) for the Go language. I have found significant performance advantages to using the extended protocol and binary format values -- in particular for types such as timestamptz. However, I was recently very surprised to find th

Re: pg_stat_wal_receiver and flushedUpto/writtenUpto

On Sat, May 16, 2020 at 10:15:47AM +0900, Michael Paquier wrote: > Thanks. If there are no objections, I'll revisit that tomorrow and > apply it with those changes, just in time for beta1. Okay, done this part then. -- Michael signature.asc Description: PGP signature

Re: [HACKERS] Restricting maximum keep segments by repslots

Hi, On 2020-04-29 18:58:16 -0400, Alvaro Herrera wrote: > On 2020-Apr-28, Alvaro Herrera wrote: > > > On 2020-Apr-28, Kyotaro Horiguchi wrote: > > > > > > Anyway I think this patch should fix it also -- instead of adding a new > > > > flag, we just rely on the existing flags (since do_checkpoint

Re: pg_bsd_indent and -Wimplicit-fallthrough

On Sat, May 16, 2020 at 11:56:28AM -0400, Tom Lane wrote: > In the meantime, I went ahead and pushed this to our pg_bsd_indent repo. Thanks, Tom. -- Michael signature.asc Description: PGP signature

Re: Potentially misleading name of libpq pass phrase hook

Daniel Gustafsson writes: >> On 16 May 2020, at 03:56, Michael Paquier wrote: >> Agreed. PQsslKeyPassHook__type sounds fine to me as >> convention. Wouldn't we want to also rename PQsetSSLKeyPassHook and >> PQgetSSLKeyPassHook, appending an "_OpenSSL" to both? > Yes, I think we should. The at

Re: [PATCH] fix GIN index search sometimes losing results

I wrote: > I think the root of the problem is that if we have a query using > weights, and we are testing tsvector data that lacks positions/weights, > we can never say there's definitely a match. I don't see any decently > clean way to fix this without redefining the TSExecuteCallback API > to re

Re: Add A Glossary

On 2020-05-15 19:26, Alvaro Herrera wrote: Applied all these suggestions, and made a few additional very small edits, and pushed -- better to ship what we have now in beta1, but further edits are still possible. I've gone through the glossary as committed and found some more small things; patc

Warn when parallel restoring a custom dump without data offsets

If pg_dump can't seek on its output stream when writing a dump in the custom archive format (possibly because you piped its stdout to a file) it can't update that file with data offsets. These files will often break parallel restoration. Warn when the user is doing pg_restore on such a file to give

Re: [PATCH] Fix pg_dump --no-tablespaces for the custom format

On Sat, 16 May 2020 at 16:31, Tom Lane wrote: > > I think (b) would be a break in the archive format, with unclear > consequences, so I'm not in favor of that. > > I came to the same conclusion while inspecting the source code. -- Euler Taveira http://www.2ndQuadrant.com/ Postg

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

Em sex., 15 de mai. de 2020 às 18:53, Alvaro Herrera < alvhe...@2ndquadrant.com> escreveu: > On 2020-Apr-10, Masahiko Sawada wrote: > > > Okay. I think only adding the check would also help with reducing the > > likelihood. How about the changes for the current HEAD I've attached? > > Pushed this

Re: [PATCH] Fix pg_dump --no-tablespaces for the custom format

Euler Taveira writes: > I'm wondering why there is such a distinction. We have some options: > (a) leave it as is and document that those 2 options has no effect in > pg_dump > and possibly add a warning to report if someone uses it with an archive > format; > (b) exclude owner and tablespace fro

Re: [PATCH] Fix pg_dump --no-tablespaces for the custom format

On Sat, 16 May 2020 at 04:20, Christopher Baines wrote: > > Tom Lane writes: > > > Christopher Baines writes: > >> So I'm new to poking around in the PostgreSQL code, so this is a bit of > >> a shot in the dark. I'm having some problems with pg_dump, and a > >> database with tablespaces. A coup

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

Em sex., 15 de mai. de 2020 às 18:53, Alvaro Herrera < alvhe...@2ndquadrant.com> escreveu: > On 2020-Apr-10, Masahiko Sawada wrote: > > > Okay. I think only adding the check would also help with reducing the > > likelihood. How about the changes for the current HEAD I've attached? > > Pushed this

Re: pgindent && weirdness

Thomas Munro writes: > On Sat, May 16, 2020 at 10:15 AM Tom Lane wrote: >> +1. I think the repo will let you in, but if not, I can do it. > It seems I cannot. Please go ahead. Pushed, and I bumped pg_bsd_indent's version to 2.1.1, and synced our core repo with that. r

Re: pg_bsd_indent and -Wimplicit-fallthrough

Julien Rouhaud writes: > On Fri, May 15, 2020 at 9:17 AM Daniel Gustafsson wrote: >> On 15 May 2020, at 08:28, Julien Rouhaud wrote: >>> The patch looks good to me. It looks like we already have custom >>> patches, so +1 to applying it. >> Shouldn't we try and propose it to upstream first to m

Re: POC: GROUP BY optimization

On Sat, May 16, 2020 at 02:24:31PM +0200, Dmitry Dolgov wrote: On Fri, May 15, 2020 at 01:52:20AM +0200, Tomas Vondra wrote: I wonder if anyone has plans to try again with this optimization in v14 cycle? The patches no longer apply thanks to the incremental sort patch, but I suppose fixing that

Re: Our naming of wait events is a disaster.

I wrote: > Thomas Munro writes: >> On Wed, May 13, 2020 at 3:16 AM Tom Lane wrote: >>> Hash/Batch/Allocating >>> Hash/Batch/Electing >>> Hash/Batch/Loading >>> Hash/GrowBatches/Allocating >> Perhaps we should also drop the 'ing' from the verbs, to be more like >> ...Read etc. > Yeah, that aspec

Re: Potentially misleading name of libpq pass phrase hook

On 5/16/20 3:16 AM, Daniel Gustafsson wrote: >> On 16 May 2020, at 03:56, Michael Paquier wrote: >> >> On Fri, May 15, 2020 at 09:21:52PM -0400, Jonathan S. Katz wrote: >>> +1 on all of the above. >>> >>> I noticed this has been added to Open Items; I added a note that the >>> plan is to fix befor

Re: calling procedures is slow and consumes extra much memory against calling function

Em sáb., 16 de mai. de 2020 às 11:07, Pavel Stehule escreveu: > > > so 16. 5. 2020 v 15:24 odesílatel Ranier Vilela > napsal: > >> Em sáb., 16 de mai. de 2020 às 09:35, Pavel Stehule < >> pavel.steh...@gmail.com> escreveu: >> >>> >>> >>> so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela >>> napsa

Re: calling procedures is slow and consumes extra much memory against calling function

so 16. 5. 2020 v 15:24 odesílatel Ranier Vilela napsal: > Em sáb., 16 de mai. de 2020 às 09:35, Pavel Stehule < > pavel.steh...@gmail.com> escreveu: > >> >> >> so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela >> napsal: >> >>> Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule < >>> pavel.steh..

valgrind vs force_parallel_mode=regress

As I was resuscitating my buildfarm animal lousyjack, which runs tests under valgrind, I neglected to turn off force_parallel=regress in the configuration settings. The results were fairly disastrous. The runs took about 4 times as long, and some steps failed. I'm not sure if this is a known resu

Re: Potentially misleading name of libpq pass phrase hook

On 5/15/20 8:08 PM, Alvaro Herrera wrote: > On 2020-May-15, Magnus Hagander wrote: > >> On Thu, May 14, 2020 at 3:03 PM Daniel Gustafsson wrote: >>> Since we haven't shipped this there is still time to rename, which >>> IMO is the right way forward. PQsslKeyPassHook__type would >>> be one optio

Re: calling procedures is slow and consumes extra much memory against calling function

Em sáb., 16 de mai. de 2020 às 09:35, Pavel Stehule escreveu: > > > so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela > napsal: > >> Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule < >> pavel.steh...@gmail.com> escreveu: >> >>> >>> >>> so 16. 5. 2020 v 5:55 odesílatel Ranier Vilela >>> napsal

Re: ldap tls test fails in some environments

On Sat, May 16, 2020 at 2:25 AM Christoph Berg wrote: > > Somebody should get out the LDAP RFCs and decode the packet contents > > that this log helpfully provides, but I suspect that we're just looking > > at an authentication failure; there's still not much clue as to why. > > The non-TLS tests

Re: calling procedures is slow and consumes extra much memory against calling function

so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela napsal: > Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule < > pavel.steh...@gmail.com> escreveu: > >> >> >> so 16. 5. 2020 v 5:55 odesílatel Ranier Vilela >> napsal: >> >>> Em sáb., 16 de mai. de 2020 às 00:07, Pavel Stehule < >>> pavel.steh...

Re: POC: GROUP BY optimization

> On Fri, May 15, 2020 at 01:52:20AM +0200, Tomas Vondra wrote: > > I wonder if anyone has plans to try again with this optimization in v14 > cycle? The patches no longer apply thanks to the incremental sort patch, > but I suppose fixing that should not be extremely hard. > > The 2020-07 CF is stil

Re: calling procedures is slow and consumes extra much memory against calling function

Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule escreveu: > > > so 16. 5. 2020 v 5:55 odesílatel Ranier Vilela > napsal: > >> Em sáb., 16 de mai. de 2020 às 00:07, Pavel Stehule < >> pavel.steh...@gmail.com> escreveu: >> >>> >>> >>> so 16. 5. 2020 v 0:34 odesílatel Ranier Vilela >>> napsal:

Re: Problem with logical replication

On Fri, May 15, 2020 at 08:48:53AM -0300, Euler Taveira wrote: > On Fri, 15 May 2020 at 02:47, Michael Paquier wrote: >> Agreed. I don't think either that we need to update this comment. I >> was playing with this patch and what you have here looks fine by me. >> Two nits: the extra parenthesis

Re: Is it useful to record whether plans are generic or custom?

> To track executed plan types, I think execution layer hooks > are appropriate. > These hooks, however, take QueryDesc as a param and it does > not include cached plan information. It seems that the same QueryDesc entry is reused when executing a generic plan. For exemple marking queryDesc->plann

Re: [PATCH] Fix pg_dump --no-tablespaces for the custom format

Tom Lane writes: > Christopher Baines writes: >> So I'm new to poking around in the PostgreSQL code, so this is a bit of >> a shot in the dark. I'm having some problems with pg_dump, and a >> database with tablespaces. A couple of the tables are not in the default >> tablespace, and I want to i

Re: Potentially misleading name of libpq pass phrase hook

> On 16 May 2020, at 03:56, Michael Paquier wrote: > > On Fri, May 15, 2020 at 09:21:52PM -0400, Jonathan S. Katz wrote: >> +1 on all of the above. >> >> I noticed this has been added to Open Items; I added a note that the >> plan is to fix before the Beta 1 wrap. > > +1. Thanks. > > Agreed.