Memory leak with CALL to Procedure with COMMIT.

Hi Hackers, While testing with PG procedure, I found a memory leak on HEAD, with below steps: postgres=# CREATE OR REPLACE PROCEDURE proc1(v1 INOUT INT) AS $$ BEGIN commit; END; $$ LANGUAGE plpgsql; CREATE PROCEDURE postgres=# call proc1(10); WARNING: Snapshot reference leak: Snapshot 0x23678e

Re: [WIP] [B-Tree] Retail IndexTuple deletion

13.07.2018 00:00, Peter Geoghegan пишет: One area that might be worth investigating is retail index tuple deletion performed within the executor in the event of non-HOT updates. I will try to use this idea. But now I developed a background worker already (experimental state). It clean an in

Re: [WIP] [B-Tree] Retail IndexTuple deletion

This v5 version of the patch is intended to use with v3-0001-Make-all-nbtree-index-tuples-have-unique-keys patch [1]. [1] https://www.postgresql.org/message-id/CAH2-WzkmTRXh%3DzyMAUHyG3%3DO-QQip6CJc2VyNijRO-vzgPxmoQ%40mail.gmail.com 13.07.2018 00:00, Peter Geoghegan пишет: On Tue, Jul 3, 20

Stored procedures and out parameters

Hi hackers, I've encountered some odd behavior with the new stored procedure feature, when using INOUT parameters, running PostgreSQL 11-beta2. With the following procedure: CREATE OR REPLACE PROCEDURE my_proc(INOUT results text) LANGUAGE 'plpgsql' AS $BODY$ BEGIN select 'test' into results;

Re: code of partition split

On Mon, Jul 23, 2018 at 11:27 AM Chenxi Li wrote: > > Hi, > > Sorry that I misunderstood. The feature is provided in EnterpriseDB version > of Postgresql. > > BTW, do you think it is needed? > It good to have, but for now, I don't think it has any priority because DETACH and ATTACH operation can

Re: code of partition split

Hi, Sorry that I misunderstood. The feature is provided in EnterpriseDB version of Postgresql. BTW, do you think it is needed? Best Regards, Chenxi Li 2018-07-23 13:05 GMT+08:00 amul sul : > On Mon, Jul 23, 2018 at 8:38 AM Chenxi Li wrote: > > > > Hi hackers, > > > > I'm interested in partiti

Re: JIT breaks PostGIS

Hi, On 2018-07-21 23:14:47 +0300, Darafei "Komяpa" Praliaskouski wrote: > Today I spent some time closing PostGIS tickets in preparation to Monday's > release. > > One of the blockers, https://trac.osgeo.org/postgis/ticket/4125, was filed > by Postgres APT repository maintainer Christoph Berg who

Re: code of partition split

On Mon, Jul 23, 2018 at 8:38 AM Chenxi Li wrote: > > Hi hackers, > > I'm interested in partition split and want to figure out how it works. Could > someone tell me where the code is located? Thanks very much. > AFAIK, we don't have this SPLIT partition feature, yet. Regards, Amul

Re: code of partition split

Hi. On 2018/07/23 12:08, Chenxi Li wrote: > Hi hackers, > > I'm interested in partition split and want to figure out how it works. > Could someone tell me where the code is located? Thanks very much. Can you tell what you mean by "partition split"? I don't know of an existing feature / command

Fix calculations on WAL recycling.

I'll register this to the next commitfest. https://www.postgresql.org/message-id/20180719.125117.155470938.horiguchi.kyot...@lab.ntt.co.jp > While considering this, I found a bug in 4b0d28de06, which > removed prior checkpoint from control file. It actually trims the > segments before the last ch

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

On Mon, Jul 23, 2018 at 3:40 PM, Thomas Munro wrote: > I did some testing on 2-node, 4-node and 8-node systems running Linux > 3.10.something (slightly newer but still ancient). Only the 8-node > box (= same one Mithun used) shows the large effect (the 2-node box > may be a tiny bit faster patche

Re: Should contrib modules install .h files?

On 2018-Jul-23, Tom Lane wrote: > Michael Paquier writes: > > On Sun, Jul 22, 2018 at 09:42:08PM -0400, Stephen Frost wrote: > >> So, +1 from me for having a directory for each extension. > > > So, like Stephen, that's a +1 from me. > > Same here. One-file-per-extension is too strongly biased

Re: wrong query result with jit_above_cost= 0

Hi, On 2018-07-22 17:09:37 -0700, Andres Freund wrote: > > Also, I found one suspicious thing, in AGG_PLAIN_TRANS section we don't > > switch the memory context back in the branch with ExecAggTransReparent. I > > never found any consequences of that, but just in case I believe it makes > > sense

Re: Should contrib modules install .h files?

Michael Paquier writes: > On Sun, Jul 22, 2018 at 09:42:08PM -0400, Stephen Frost wrote: >> So, +1 from me for having a directory for each extension. > So, like Stephen, that's a +1 from me. Same here. One-file-per-extension is too strongly biased to tiny extensions (like most of our contrib ex

Re: Non-portable shell code in pg_upgrade tap tests

Michael Paquier writes: > On Sun, Jul 22, 2018 at 02:53:51PM -0400, Tom Lane wrote: >> A quick trawl of the buildfarm logs says most of our animals compute >> SHELL = /bin/sh anyway, and so would be unaffected. There's a sizable >> population that find /bin/bash though, and one active critter tha

Re: Tips on committing

Noah Misch writes: > I agree we won't all want the exact same checklist. Still, it wouldn't hurt > to have a wiki page of checklist entry ideas from which folks cherry-pick the > entries they like. 013f320dc reminds me of something I check for religiously: look for alternative output files for a

Re: Get Columns from Plan

Ed Behn writes: > I'm tinkering with the idea of creating a Procedural Language plugin for > Haskell. As such I'm reading up on the SPI and prepared statements. The > idea is that a statement will be prepared at compile time and executed at > run-time. Therefore, I want to be able to determine the

Re: Possible performance regression in version 10.1 with pgbench read-write tests.

On Sun, Jul 22, 2018 at 8:19 AM, Tom Lane wrote: > Andres Freund writes: >> On 2018-07-20 16:43:33 -0400, Tom Lane wrote: >>> On my RHEL6 machine, with unmodified HEAD and 8 sessions (since I've >>> only got 8 cores) but other parameters matching Mithun's example, >>> I just got > >> It's *really

Re: Non-portable shell code in pg_upgrade tap tests

On Sun, Jul 22, 2018 at 02:53:51PM -0400, Tom Lane wrote: > Oh! Hm, I wonder whether we shouldn't do that, ie add SHELL = @SHELL@ > to Makefile.global.in. That sounds like a good idea to me. > A quick trawl of the buildfarm logs says most of our animals compute > SHELL = /bin/sh anyway, and so w

Re: pgbench: improve --help and --version parsing

On Sun, Jul 22, 2018 at 10:19:50AM -0400, Fabien COELHO wrote: >> Agreed. I have changed handling of the --help and --version options in all >> apps >> where it exhibits the problem described, with the exception for >> pg_archivecleanup >> where getopt is used instead of getopt_long. The separate

Re: Should contrib modules install .h files?

On Sun, Jul 22, 2018 at 09:42:08PM -0400, Stephen Frost wrote: > When I think about the demands of extensions, I tend to consider PostGIS > the prime example and I certainly would understand if they wanted to > install multiple headers (they have some 72 .h files from what I'm > seeing...). > > So

Re: Add SKIP LOCKED to VACUUM and ANALYZE

On Thu, Jul 19, 2018 at 10:54:23AM +0900, Michael Paquier wrote: > If you can get this refactoring done, let's look into getting those two > parts committed first to simplify the next steps. No need to extend the > grammar of cluster either. The set of options for CLUSTER should be a > separate e

code of partition split

Hi hackers, I'm interested in partition split and want to figure out how it works. Could someone tell me where the code is located? Thanks very much. Best Regards, Chenxi li

Re: Get Columns from Plan

On 22 July 2018 at 21:56, Ed Behn wrote: > I'm tinkering with the idea of creating a Procedural Language plugin for > Haskell. As such I'm reading up on the SPI and prepared statements. The > idea is that a statement will be prepared at compile time and executed at > run-time. Therefore, I want t

Get Columns from Plan

I'm tinkering with the idea of creating a Procedural Language plugin for Haskell. As such I'm reading up on the SPI and prepared statements. The idea is that a statement will be prepared at compile time and executed at run-time. Therefore, I want to be able to determine the columns (names and types

Re: Should contrib modules install .h files?

Greetings, * Andrew Gierth (and...@tao11.riddles.org.uk) wrote: > > "Michael" == Michael Paquier writes: > > >> No response to my followup to you in 2+ weeks. Last call? > > Michael> FWIW, I don't have any objections with experimenting on HEAD, > Michael> but I would vote for letting 11

Re: Should contrib modules install .h files?

Greetings, * Andrew Gierth (and...@tao11.riddles.org.uk) wrote: > > "Peter" == Peter Eisentraut writes: > > > On 02.07.18 15:26, Tom Lane wrote: > >> FWIW, I agree with Andres' thought that each contrib module should > >> have its own subdirectory under $(includedir_server). Otherwise >

RE: [bug fix] Produce a crash dump before main() on Windows

From: Robert Haas [mailto:robertmh...@gmail.com] > On Wed, Jul 18, 2018 at 4:38 AM, Tsunakawa, Takayuki > wrote: > > IIRC, the pop up doesn't appear under Windows service. If you start the > database server with pg_ctl start on the command prompt, the pop up will > appear, which I think is not ba

Re: Should contrib modules install .h files?

Hi, On 2018-07-23 02:02:51 +0100, Andrew Gierth wrote: > > "Michael" == Michael Paquier writes: > > >> No response to my followup to you in 2+ weeks. Last call? > > Michael> FWIW, I don't have any objections with experimenting on HEAD, > Michael> but I would vote for letting 11 out of th

Re: JIT breaks PostGIS

Greetings, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Christoph Berg writes: > > The question will be coming up eventually, though, and I think the > > options on the packaging side are: > > > 1) Disable jit completely > > 2) Compile --with-llvm, but disable jit in the config by default > > 3) Com

Re: Should contrib modules install .h files?

> "Michael" == Michael Paquier writes: >> No response to my followup to you in 2+ weeks. Last call? Michael> FWIW, I don't have any objections with experimenting on HEAD, Michael> but I would vote for letting 11 out of this. Why? -- Andrew.

Re: Should contrib modules install .h files?

On Mon, Jul 23, 2018 at 01:48:21AM +0100, Andrew Gierth wrote: > > "Peter" == Peter Eisentraut writes: > >>> Anyone have any objection to putting this into 11beta if it works, >>> as well as 12devel? > > Peter> Yes, I have expressed concerns about this approach elsewhere in > Peter> this t

Re: Should contrib modules install .h files?

> "Peter" == Peter Eisentraut writes: >> Anyone have any objection to putting this into 11beta if it works, >> as well as 12devel? Peter> Yes, I have expressed concerns about this approach elsewhere in Peter> this thread. No response to my followup to you in 2+ weeks. Last call? -- An

Re: More consistency for some file-related error message

On Fri, Jul 20, 2018 at 03:41:08PM +0900, Michael Paquier wrote: > Okay, I just looked again at this point, and among the new messages only > what's in XLogFileCopy has been bothering setting errno to 0 (see > 811b6e3), so let's remove it in this case. So, I have been through the patch set once ag

Re: wrong query result with jit_above_cost= 0

Hi, On 2018-07-07 21:41:05 +0200, Dmitry Dolgov wrote: > Ok, looks like I found the issue. v_aggcontext & v_curaggcontext have nothing > to do here (this change was just masking a problem by changing a memory > context > so that the wrong one will never be used). The problem was that in the > llv

pgbench - remove double declaration of hash functions

I noticed that hash functions appear twice in the list of pgbench functions, although once is enough. The code is functional nevertheless, but it looks silly. This was added by "e51a04840a1" back in March, so should be removed from 11 and 12dev. -- Fabien.diff --git a/src/bin/pgbench/exprpar

Re: [HACKERS] Bug in to_timestamp().

On Sun, Jul 22, 2018 at 6:22 PM David G. Johnston wrote: > On Sat, Jul 21, 2018 at 2:34 PM, Alexander Korotkov > wrote: >> >> So, as I get from this thread, current patch brings these function very >> close to Oracle behavior. The only divergence found yet is related to >> handling of unmatch

Re: patch to allow disable of WAL recycling

On 07/21/2018 12:04 AM, Jerry Jelinek wrote: > Thomas, > > Thanks for your offer to run some tests on different OSes and > filesystems that you have. Anything you can provide here would be much > appreciated. I don't have anything other than our native SmartOS/ZFS > based configurations, but I mig

Re: pgbench-ycsb

Just to clarify - if I understand Anthony correctly, this proposal is not about implementing exactly YCSB as it is, but more about using zipfian distribution for an id in the regular pgbench table structure in conjunction with read/write balance to simulate something similar to it. Ok, I mi

Re: [HACKERS] plpgsql - additional extra checks

On 07/19/2018 02:50 PM, Pavel Stehule wrote: > > > 2018-07-15 1:38 GMT+02:00 Tomas Vondra >: > > Hi, > > I've been looking at the version submitted on Thursday, planning to > commit it, but I think it needs a wee bit more work on the error >

Re: cost_sort() improvements

On 07/12/2018 04:31 PM, Teodor Sigaev wrote: >> At least [1] and [2] hit into to that issues and have an >> objections/questions about correctness of cost sort estimation. >> Suggested patch tries to improve current estimation and solve that >> issues. > > Sorry for long delay but issue was even m

Re: pgbench: improve --help and --version parsing

Hello My 0.02€: Thanks! I made the same modification of src/interfaces/ecpg/preproc/ecpg.c, but in other cases it's either not a problem (as with src/bin/psql/startup.c or src/timezone/zic.c) or the solution is too complex to be added to the current patch: e.g. these tools in src/bin/scripts u

Re: cost_sort() improvements

On 07/12/2018 05:00 PM, Teodor Sigaev wrote: > >> One more thought about estimating the worst case - I wonder if simply >> multiplying the per-tuple cost by 1.5 is the right approach. It does not >> seem particularly principled, and it's trivial simple to construct >> counter-examples defeating

Re: JIT breaks PostGIS

Christoph Berg writes: > The question will be coming up eventually, though, and I think the > options on the packaging side are: > 1) Disable jit completely > 2) Compile --with-llvm, but disable jit in the config by default > 3) Compile --with-llvm, but disable jit for older llvm versions > 4) En

Re: JIT breaks PostGIS

Re: Andres Freund 2018-07-22 <20180722185106.qxc5ie745tqda...@alap3.anarazel.de> > > Does that mean JIT is not ready for prime time yet and should be > > disabled in default installations? Or does it just mean that llvm 4.0 > > is old? > > I don't know yet, it's probably just some small bug. But l

Re: Non-portable shell code in pg_upgrade tap tests

Noah Misch writes: > On Sun, Jul 22, 2018 at 10:46:03AM -0400, Tom Lane wrote: >> The pg_upgrade makefile does in fact use $(SHELL), so it will default to >> whatever shell configure used. > It will not, because we don't set $(SHELL) anywhere. $(SHELL) is not @SHELL@. > In our makefiles, $(SHELL

Re: JIT breaks PostGIS

On 2018-07-22 20:49:51 +0200, Christoph Berg wrote: > Re: To Andres Freund 2018-07-21 <20180721203644.gb10...@msg.df7cb.de> > > That said, I'm just rebuilding postgresql-11 on stretch to use > > llvm-4.0 instead of 3.9. > > This didn't change anything, it's still crashing on the same query > from

Re: JIT breaks PostGIS

Re: To Andres Freund 2018-07-21 <20180721203644.gb10...@msg.df7cb.de> > That said, I'm just rebuilding postgresql-11 on stretch to use > llvm-4.0 instead of 3.9. This didn't change anything, it's still crashing on the same query from tickets.sql. Does that mean JIT is not ready for prime time yet

Re: Non-portable shell code in pg_upgrade tap tests

On Sun, Jul 22, 2018 at 10:46:03AM -0400, Tom Lane wrote: > Noah Misch writes: > > I'd say the right way to fix this is the one specified in > > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/The-Make-Macro-SHELL.html, > > in particular: > > > Using @SHELL@ means that your

Re: pgbench-ycsb

On 2018-07-22 16:56, Fabien COELHO wrote: Just to clarify - if I understand Anthony correctly, this proposal is not about implementing exactly YCSB as it is, but more about using zipfian distribution for an id in the regular pgbench table structure in conjunction with read/write balance to sim

Re: pgbench: improve --help and --version parsing

Fabien COELHO writes: > There seems to be other instances as well Thanks! I made the same modification of src/interfaces/ecpg/preproc/ecpg.c, but in other cases it's either not a problem (as with src/bin/psql/startup.c or src/timezone/zic.c) or the solution is too complex to be added to the curre

Re: [HACKERS] Bug in to_timestamp().

On Sat, Jul 21, 2018 at 2:34 PM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote: > So, as I get from this thread, current patch brings these function very > close to Oracle behavior. The only divergence found yet is related to > handling of unmatched tails of input strings (Oracle throws a

Re: Non-portable shell code in pg_upgrade tap tests

Noah Misch writes: > I'd say the right way to fix this is the one specified in > https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/The-Make-Macro-SHELL.html, > in particular: > Using @SHELL@ means that your makefile will benefit from the same improved > shell, such as bash

Re: pgbench: improve --help and --version parsing

Agreed. I have changed handling of the --help and --version options in all apps where it exhibits the problem described, with the exception for pg_archivecleanup where getopt is used instead of getopt_long. The separate patch will be proposed to address it. The patch is against current master

Re: pgbench-ycsb

Just to clarify - if I understand Anthony correctly, this proposal is not about implementing exactly YCSB as it is, but more about using zipfian distribution for an id in the regular pgbench table structure in conjunction with read/write balance to simulate something similar to it. Ok, I misun

Re: Negotiating the SCRAM channel binding type

On Fri, Jul 20, 2018 at 08:05:04PM +0300, Heikki Linnakangas wrote: > In any case, I'm quite convinced now that we should just remove tls-unique, > and stick to tls-server-end-point. Patch attached, please take a look. You are making good points here. > This removes the scram_channel_binding libp

Re: Remove psql's -W option

It's first on our list of things not to do: https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_psql_-W_or_--password As I recall, when this has been discussed in the past, people objected because they didn't like either (1) the extra server process fork and/or network round trip cause

Re: Reduce amount of WAL generated by CREATE INDEX for gist, gin and sp-gist

On Tue, Jul 10, 2018 at 10:03 PM Heikki Linnakangas wrote: > > On 28/02/18 18:03, Anastasia Lubennikova wrote: > > I want to propose a bunch of patches which allow to reduce WAL traffic > > generated by CREATE INDEX for GiST, GIN and SP-GiST. Similarly to b-tree > > and RUM, we can now log index p

Re: pgbench: improve --help and --version parsing

Tom Lane writes: > Andres Freund writes: > > On July 21, 2018 11:15:51 PM PDT, Tom Lane wrote: > > > This is, in fact, how it's done in all PG apps. > > Think there's a fair argument that we should improve that at some point... > Perhaps.  Peter E. might remember why it's like that. It was done

Re: pgbench-ycsb

> On Sat, 21 Jul 2018 at 22:41, Fabien COELHO wrote: > > >> Could you provide a link to the specification? > >> > >> I cannot find something simple, and I was kind of hoping to avoid diving > >> into the source code of the java tool on github:-) In particular, I'm > >> looking for a description of

Re: Non-portable shell code in pg_upgrade tap tests

On Fri, Jul 20, 2018 at 11:09:13AM -0400, Tom Lane wrote: > Victor Wagner writes: > > Tom Lane wrote: > >> Please send a patch. Most of us do not have access to old shells > > > Here it goes. Previous letter was written before fixed tests were > > completed, because this old machine is slow. >

Re: pgbench: improve --help and --version parsing

On July 21, 2018 11:52:05 PM PDT, Tom Lane wrote: >But I'm dubious >about changing it in only one app. Agreed. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.