Re: seawasp failing, maybe in glibc allocator

Hello Thomas, Seawasp should turn green on its next run. Hopefully. It is not scheduled very soon because Tom complained about the induced noise in one buildfarm report, so I put the check to once a week. I changed it to start a run in a few minutes. I've rescheduled to once a day after

Re: Some incorrect logs in TAP tests of pgbench

(What were we thinking in allowing this in the first place?) Temporary debug leftovers that got through, I'd say. Thanks Michaël for the clean up! -- Fabien.

Re: Deadlock risk while inserting directly into partition?

On Thu, Jun 24, 2021 at 10:27:06AM +1200, David Rowley wrote: > I think the reasons for doing operations directly on partitions are > being reduced with each release. What operations do people really > need to do on partitions now? TRUNCATE is probably one, maybe there's > still a need to CREATE I

Re: Some incorrect logs in TAP tests of pgbench

On Fri, Jun 25, 2021 at 09:37:50AM -0400, Andrew Dunstan wrote: > Either that or dereference them, by printing @$out and @$err instead of > $out and $err or something similar. Looking again, we don't really lose context if we remove that, so done this way. > But probably the name of the test is s

Re: [PATCH] Pull general SASL framework out of SCRAM

On Fri, Jun 25, 2021 at 11:40:33PM +, Jacob Champion wrote: > I can definitely move it (into, say, auth-sasl.c?). I'll probably do > that in a second commit, though, since keeping it in place during the > refactor makes the review easier IMO. auth-sasl.c is a name consistent with the existing

Re: [patch] remove strver's leftover from error message in Solution.pm

On Sat, Jun 26, 2021 at 12:47:50AM +0700, Anton Voloshin wrote: > I think this should be backported to REL_13_STABLE, but not to REL_12_STABLE > and earlier, where strver was still present. Good catch! I will take care of that. -- Michael signature.asc Description: PGP signature

Re: [PATCH] Make jsonapi usable from libpq

On Fri, Jun 25, 2021 at 08:58:46PM +, Jacob Champion wrote: > On Thu, 2021-06-24 at 14:56 +0900, Michael Paquier wrote: >> Looking more closely at that, I actually find a bit crazy the >> requirement for any logging within jsonapi.c just to cope with the >> fact that json_errdetail() and report

Re: Pipeline mode and PQpipelineSync()

On 2021-Jun-25, Alvaro Herrera wrote: > From 071757645ee0f9f15f57e43447d7c234deb062c0 Mon Sep 17 00:00:00 2001 > From: Alvaro Herrera > Date: Fri, 25 Jun 2021 16:02:00 -0400 > Subject: [PATCH v2 2/4] Add PQrequestFlush() I forgot to mention: > +/* > + * Send request for server to flush its buff

Re: Pipeline mode and PQpipelineSync()

On 2021-Jun-24, Boris Kolpackov wrote: > Boris Kolpackov writes: > > > What's strange here is that the first PQgetResult() call (marked with ???) > > returns NULL instead of result for INSERT #1 as in the first call sequence. > > I've hit another similar case except now an unexpected NULL resul

Re: [PATCH] Pull general SASL framework out of SCRAM

On Wed, 2021-06-23 at 16:38 +0900, Michael Paquier wrote: > On Tue, Jun 22, 2021 at 10:37:29PM +, Jacob Champion wrote: > > Currently, the SASL logic is tightly coupled to the SCRAM > > implementation. This patch untangles the two, by introducing callback > > structs for both the frontend and b

Re: PG 14 release notes, first draft

> Require custom server variable names to use only character which are valid > for unquoted SQL identifiers (Tom Lane) characters plural (since 69a58bfe4) > This is similar to how Unicode can be specified in literal string. literal strings > Add executor method to cache results from the inner-

Re: [PATCH] Make jsonapi usable from libpq

On Thu, 2021-06-24 at 14:56 +0900, Michael Paquier wrote: > Looking more closely at that, I actually find a bit crazy the > requirement for any logging within jsonapi.c just to cope with the > fact that json_errdetail() and report_parse_error() just want to track > down if the caller is giving some

Re: Decouple operator classes from index access methods

On Fri, Jun 25, 2021 at 12:18 PM Emre Hasegeli wrote: > > In future we could have, for instance, LSM or in-memory B-tree or > > other index AM, which could use existing B-tree or hash opclasses. > > This would be easily possible with my patch: > > CREATE ACCESS METHOD inmemorybtree > TYPE INDEX HA

Re: Emit namespace in post-copy output

On Fri, Jun 25, 2021, at 12:10 PM, Mike wrote: > Awesome, thanks! Are there any other steps I should take? No. Keep an eye on this thread. If you modify this patch, check if PostgreSQL Patch Tester [1] reports failure. Since your patch does not modify a considerable amount of code, it probably won'

[patch] remove strver's leftover from error message in Solution.pm

Hello, in src/tools/msvc/Solution.pm (in the current master) there is a leftover from the past: > confess "Bad format of version: $self->{strver}\n"; strver has been gone since 8f4fb4c6 in 2019, so I suggest an obvious one-line fix in the patch attached: diff --git a/src/too

Re: Some incorrect logs in TAP tests of pgbench

On 2021-Jun-25, Michael Paquier wrote: > I am a bit dubious that this information is useful when it comes to > debugging because we have the name of the tests close by, so I would > just remove those extra logs. If people prefer keeping this > information around, we could fix the format with some

Re: Using indexUnchanged with nbtree

On Fri, Jun 25, 2021 at 1:43 AM Simon Riggs wrote: > Seems a little bizarre to have _bt_check_unique() call back into the > heap block we literally just unpinned. I suppose it is a little bizarre. > This is another case of the UPDATE scan and later heap/index > insertions not working together ve

Re: Emit namespace in post-copy output

Awesome, thanks! Are there any other steps I should take? On Wed, Jun 23, 2021 at 5:46 PM Corey Huinker wrote: > On Tue, Jun 22, 2021 at 6:08 PM Mike wrote: > >> When running a VACUUM or CLUSTER command, the namespace name is not part >> of the emitted message. >> >> Using `vacuumdb` CLI tool r

Re: subscription/t/010_truncate.pl failure on desmoxytes in REL_13_STABLE

Amit Kapila writes: > On Thu, Jun 24, 2021 at 11:25 PM Tom Lane wrote: >> Checking the git history, this was fixed in f560209c6, which also >> included some other mostly-cosmetic cleanup. I'm inclined to >> propose back-patching that whole commit, rather than allowing the >> code in exec_replica

Re: Fix uninitialized copy_data var (src/backend/commands/subscriptioncmds.c)

Em qua., 23 de jun. de 2021 às 14:38, Ranier Vilela escreveu: > Hi, > > Not per Coverity! > > About comments: > 1. For drop, no "copy data" > 2. Only refresh the added/*dropped* list of publications. (my emphasis) > > The documentation says: > https://www.postgresql.org/docs/14/sql-altersubscript

Re: Some incorrect logs in TAP tests of pgbench

On 6/25/21 8:33 AM, Michael Paquier wrote: > Hi all, > > While digging into some of the TAP tests, I have noticed that > 002_pgbench_no_server.pl prints array pointers, like that: > opts=-f no-such-file, stat=1, out=ARRAY(0x1374d7990), > err=ARRAY(0x14028dc40), name=pgbench option error: no file#

Re: alter subscription drop publication fixes

On Fri, Jun 25, 2021 at 1:30 PM Peter Eisentraut wrote: > > On 15.05.21 15:15, vignesh C wrote: > > Thanks Bharath, that looks good. I have added a commitfest entry at [1] > > and marked it to Ready For Committer. > > [1] - https://commitfest.postgresql.org/33/3115/ > >

Some incorrect logs in TAP tests of pgbench

Hi all, While digging into some of the TAP tests, I have noticed that 002_pgbench_no_server.pl prints array pointers, like that: opts=-f no-such-file, stat=1, out=ARRAY(0x1374d7990), err=ARRAY(0x14028dc40), name=pgbench option error: no file# Running: pgbench -f no-such-file I am a bit dubious th

ECPG bug fix: DECALRE STATEMENT and DEALLOCATE, DESCRIBE

Dear Hackers, I checked about DECLARE STATEMENT(added from ad8305a), and I noticed that this connection-control feature cannot be used for DEALLOCATE and DESCRIBE statement. I attached the patch that fixes these bugs, this contains source and test code. How do you think? Best Regards, Hayato

Re: [HACKERS] WIP aPatch: Pgbench Serialization and deadlock errors

On Wed, 23 Jun 2021 10:38:43 +0200 (CEST) Fabien COELHO wrote: > > Hello Yugo-san: > > # About v12.1 > > This is a refactoring patch, which creates a separate structure for > holding variables. This will become handy in the next patch. There is also > a benefit from a software engineering po

Re: Doc chapter for Hash Indexes

On Fri, Jun 25, 2021 at 4:17 AM Amit Kapila wrote: > > On Fri, Jun 25, 2021 at 1:29 AM Bruce Momjian wrote: > > > > aOn Wed, Jun 23, 2021 at 12:56:51PM +0100, Simon Riggs wrote: > > > On Wed, Jun 23, 2021 at 5:12 AM Amit Kapila > > > wrote: > > > > > > > > On Tue, Jun 22, 2021 at 2:31 PM Simon

Re: Decouple operator classes from index access methods

> In future we could have, for instance, LSM or in-memory B-tree or > other index AM, which could use existing B-tree or hash opclasses. This would be easily possible with my patch: CREATE ACCESS METHOD inmemorybtree TYPE INDEX HANDLER imbthandler IMPLEMENTS (ordering); > But even now, we could

Re: Using indexUnchanged with nbtree

On Fri, Jun 25, 2021 at 2:34 AM Peter Geoghegan wrote: > > On Thu, Jun 24, 2021 at 5:39 AM Simon Riggs > wrote: > > This case occurs when we are doing non-HOT UPDATEs. That command is > > searched, so the scan will already have touched the heap and almost > > certainly the index also, setting any

Re: alter subscription drop publication fixes

On 15.05.21 15:15, vignesh C wrote: Thanks Bharath, that looks good. I have added a commitfest entry at [1] and marked it to Ready For Committer. [1] - https://commitfest.postgresql.org/33/3115/ Committed. I took out some of the code reformatting.

Re: pglz compression performance, take two

On Sat, Mar 20, 2021 at 12:19:45AM -0500, Justin Pryzby wrote: > I think it's still relevant, since many people may not end up with binaries > --with-lz4 (I'm thinking of cloud providers). PGLZ is what existing data > uses, > and people may not want to/know to migrate to shiny new features, but t

Re: Pipeline mode and PQpipelineSync()

Alvaro Herrera writes: > IIUC the problem is that PQgetResult is indeed not prepared to deal with > a result the first time until after the queue has been "prepared", and > this happens on calling PQpipelineSync. But I think the formulation in > the attached patch works too, and the resulting co

Re: Weird use of parentheses in the manual

Le ven. 25 juin 2021 à 08:55, Amit Kapila a écrit : > On Thu, Jun 24, 2021 at 6:38 PM Amit Kapila > wrote: > > > > On Thu, Jun 24, 2021 at 5:27 PM Guillaume Lelarge > > wrote: > > > > > > Really tiny patch attached to fix this if it really is wrong, and > anyone cares enough to fix it :) > > >