Re: max_slot_wal_keep_size comment in postgresql.conf

2020-05-27 Thread Michael Paquier
On Wed, May 27, 2020 at 04:35:51PM +0900, Michael Paquier wrote: > On Wed, May 27, 2020 at 04:21:59PM +0900, Kyotaro Horiguchi wrote: > > I don't oppose to full-spelling. How about the attached? > > No problem from me. And applied this one as of 55ca50d. -- Michael signature.asc Description: P

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Peter Eisentraut
On 2020-05-27 23:42, Christopher Browne wrote: d) systemd is a Controversial System; the folk that seem particularly irate about it seem to be "Old Bearded Sysadmins" that hate the idea of redoing their understandings of how Unix systems initialize. Personally, my feelings are ambivalent; I'm u

Re: [HACKERS] Restricting maximum keep segments by repslots

2020-05-27 Thread Kyotaro Horiguchi
Thank you for looking this and trouble rebasing! At Mon, 30 Mar 2020 20:03:27 -0300, Alvaro Herrera wrote in > I rebased this patch; it's failing to apply due to minor concurrent > changes in PostgresNode.pm. I squashed the patches in a series that > made the most sense to me. > > I have a qu

Re: Just for fun: Postgres 20?

2020-05-27 Thread Jiří Fejfar
On 26.05.2020 3:55, Bruce Momjian wrote: On Mon, May 25, 2020 at 11:05:09AM +0200, Jiří Fejfar wrote: On 15.02.2020 1:18, Tom Lane wrote: The idea that 13 is unlucky is Western, and maybe even only common in English-speaking countries. Number 13 (especially Friday 13) is also considered unluck

SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762

2020-05-27 Thread Vladimir Sitnikov
Hi, Pgjdbc test suite identified a SIGSEGV in the recent HEAD builds of PostgreSQL, Ubuntu 14.04.5 LTS Here's a call stack: https://travis-ci.org/github/pgjdbc/pgjdbc/jobs/691794110#L7484 The crash is consistent, and it reproduces 100% of the cases so far. The CI history shows that HEAD was good

Re: future pg+llvm compilation is broken

2020-05-27 Thread Fabien COELHO
Hello Justin, llvmjit_inline.cpp:59:10: fatal error: llvm/IR/CallSite.h: No such file or directory Seems to be the same as here: https://www.postgresql.org/message-id/flat/CAGf%2BfX4sDP5%2B43HBz_3fjchawO6boqwgbYVfuFc1D4gbA6qQxw%40mail.gmail.com#540c3746c79c0f13360b35c9c369a887 Definitely

Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table.

2020-05-27 Thread amul sul
On Wed, May 27, 2020 at 12:53 PM Amit Langote wrote: > On Fri, May 22, 2020 at 9:09 PM amul sul wrote: > > I tried similar things on inherit partitioning as follow and that looks > fine: > > > > DROP TABLE tbl; > > CREATE TABLE tbl (c1 INT,c2 TEXT); > > CREATE TABLE tbl_null(check (c1 is NULL))

Re: Explain Analyze (Rollback off) Suggestion

2020-05-27 Thread David G. Johnston
On Wed, May 27, 2020 at 5:31 PM Tom Lane wrote: > Robert Haas writes: > > I think the only way to make the effects of an EXPLAIN ANALYZE > > statement be automatically rolled back would be to wrap the entire > > operation in a subtransaction. While we could certainly implement > > that, it might

Re: Warn when parallel restoring a custom dump without data offsets

2020-05-27 Thread David Gilman
I've attached the latest patches after further review from Justin Pryzby. -- David Gilman :DG< https://gilslotd.com >From 90e06cbb724f6f6a244dfc69f3d59ca2e7d29c01 Mon Sep 17 00:00:00 2001 From: David Gilman Date: Wed, 20 May 2020 22:49:28 -0400 Subject: [PATCH 1/4] Scan all TOCs when restoring

Re: Explain Analyze (Rollback off) Suggestion

2020-05-27 Thread Tom Lane
Robert Haas writes: > I think the only way to make the effects of an EXPLAIN ANALYZE > statement be automatically rolled back would be to wrap the entire > operation in a subtransaction. While we could certainly implement > that, it might have its own share of surprises; for example, it would > co

Re: tablespace_map code cleanup

2020-05-27 Thread Kyotaro Horiguchi
At Wed, 27 May 2020 07:57:38 -0400, Robert Haas wrote in > On Wed, May 13, 2020 at 10:43 PM Kyotaro Horiguchi > wrote: > > About 0002, > > > > + boolsendtblspclinks = true; > > > > The boolean seems to me useless since it is always the inverse of > > opt->sendt

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Mark Dilger
> On May 27, 2020, at 2:42 PM, Christopher Browne wrote: > > There is merit to having a new, harmonious set of "pg commands." But it's > eminently easy to get into trouble (and get people mad) by changing things > that have been working fine for many years. Half the battle (against the >

Re: BufFileRead() error signalling

2020-05-27 Thread Alvaro Herrera
On 2020-May-28, Thomas Munro wrote: > My indecision on the back-patching question has been resolved by your > crash report and a search on codesearch.debian.org. Great news! > BufFileRead() and BufFileWrite() aren't referenced by any of the > extensions they package, so by that standard it's OK

Re: BufFileRead() error signalling

2020-05-27 Thread Thomas Munro
On Thu, May 28, 2020 at 4:16 AM Alvaro Herrera wrote: > On 2020-Jan-27, Robert Haas wrote: > > OK, now that I've waxed eloquent on that topic, let me have a go at > > your actual questions. Regarding back-patching, I don't mind > > back-patching error handling patches like this, but I don't feel i

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Christopher Browne
On Wed, 27 May 2020 at 16:49, Isaac Morland wrote: > On Wed, 27 May 2020 at 16:00, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: > > >> Also consider some practical concerns with the command structure you >> describe: Tab completion of commands wouldn't work anymore, unless you >>

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Isaac Morland
On Wed, 27 May 2020 at 16:00, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > Also consider some practical concerns with the command structure you > describe: Tab completion of commands wouldn't work anymore, unless you > supply custom tab completion setups. The direct association

Re: future pg+llvm compilation is broken

2020-05-27 Thread Justin Pryzby
On Wed, May 27, 2020 at 07:40:27PM +0200, Fabien COELHO wrote: > llvmjit_inline.cpp:59:10: fatal error: llvm/IR/CallSite.h: No such file or Seems to be the same as here: https://www.postgresql.org/message-id/flat/CAGf%2BfX4sDP5%2B43HBz_3fjchawO6boqwgbYVfuFc1D4gbA6qQxw%40mail.gmail.com#540c3746c79

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Peter Eisentraut
On 2020-05-27 01:19, Mark Dilger wrote: Attached is a patch for a `pg' command that consolidates various PostgreSQL functionality into a single command, along the lines of how `git' commands are run from a single 'git' executable. In other words, `pg upgrade` # instead of `pg_upgrade`

Re: Failure to create GiST on ltree column

2020-05-27 Thread Victor Yegorov
пн, 25 мая 2020 г. в 18:25, Justin Pryzby : > I wonder if/how that fails if you create the index before adding data: > > CREATE TABLE test_path(path ltree); > CREATE INDEX ON test_path USING GIST(path); > INSERT INTO test_path SELECT * FROM comments.mp_comments; > > Does that fail on a particular

future pg+llvm compilation is broken

2020-05-27 Thread Fabien COELHO
Hello devs, commit 2c24051bacd2d0eb7141fc4adb870281aec4e714 Author: Craig Topper Date: Fri Apr 24 22:12:21 2020 -0700 [CallSite removal] Rename CallSite.h to AbstractCallSite.h. NFC The CallSite and ImmutableCallSite were removed in a previous commit. So rename the file to m

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Isaac Morland
On Wed, 27 May 2020 at 12:35, Robert Haas wrote: > Ugh, yeah, please don't do that. Renaming them just to make it "look more > modern" helps nobody, really. Especially if the suggestion is people should > be using the shared-launcher binary anyway. > > The way things like 'git' work is that 'git

Re: segmentation fault using currtid and partitioned tables

2020-05-27 Thread Alvaro Herrera
On 2020-May-26, Michael Paquier wrote: > On Mon, May 25, 2020 at 06:29:10PM +0900, Michael Paquier wrote: > > Perhaps you are right though, and that we don't need to spend this > > much energy into improving the error messages so I am fine to discard > > this part. At the end, in order to remove

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Robert Haas
On Wed, May 27, 2020 at 4:51 AM Magnus Hagander wrote: >> For that reason, I did not change the names of the executables, merely their >> location. During conversations with Robert off-list, we discussed renaming >> the executables to things like 'pg-ctl' (hyphen rather than underscore), >> mo

Re: BufFileRead() error signalling

2020-05-27 Thread Robert Haas
On Wed, May 27, 2020 at 12:16 PM Alvaro Herrera wrote: > I do have evidence of postgres crashes because of a problem that could > be explained by this bug, so I +1 backpatching this to all supported > branches. > > (The problem I saw is a hash-join spilling data to temp tablespace, > which fills u

Re: BufFileRead() error signalling

2020-05-27 Thread Alvaro Herrera
On 2020-Jan-27, Robert Haas wrote: > OK, now that I've waxed eloquent on that topic, let me have a go at > your actual questions. Regarding back-patching, I don't mind > back-patching error handling patches like this, but I don't feel it's > necessary if we have no evidence that data is actually g

Re: Explain Analyze (Rollback off) Suggestion

2020-05-27 Thread Robert Haas
On Wed, May 27, 2020 at 10:48 AM David G. Johnston wrote: > The recent discussion about EXPLAIN and the possible inclusion of > default-specifying GUCs raised a behavior that I did not fully appreciate nor > find to be self-evident. Running EXPLAIN ANALYZE results in any side-effects > of the

Re: BufFileRead() error signalling

2020-05-27 Thread Alvaro Herrera
On 2020-Jan-29, Michael Paquier wrote: > On Tue, Jan 28, 2020 at 03:51:54PM -0500, Robert Haas wrote: > > I quickly reread that thread and I don't see that there's any firm > > consensus there in favor of "read %d of %zu" over "read only %d of %zu > > bytes". Now, if most people prefer the former,

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Robert Haas
On Wed, May 27, 2020 at 4:51 AM Magnus Hagander wrote: > As mentioned at least once before, the "pg" name is already taken in posix. > Granted it has been removed now, but it was removed from posix in 2018, which > I think is nowhere near soon enough to "steal. See for example > https://en.wiki

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Christoph Moench-Tegeder
## Magnus Hagander (mag...@hagander.net): > Ugh, yeah, please don't do that. Renaming them just to make it "look more > modern" helps nobody, really. Especially if the suggestion is people should > be using the shared-launcher binary anyway. Quick, let's invent a fancy name like "microcommand" fo

Re: Fix compilation failure against LLVM 11

2020-05-27 Thread Jesse Zhang
Hi Andres, On the mensiversary of the last response, what can I do to help move this along (aside from heeding the advice "don't use LLVM HEAD")? Michael Paquier expressed concerns over flippant churn upthread: On Mon, Apr 27, 2020 at 10:19 PM Andres Freund wrote: AF> On 2020-04-28 13:56:23 +0900

Explain Analyze (Rollback off) Suggestion

2020-05-27 Thread David G. Johnston
The recent discussion about EXPLAIN and the possible inclusion of default-specifying GUCs raised a behavior that I did not fully appreciate nor find to be self-evident. Running EXPLAIN ANALYZE results in any side-effects of the explained and analyzed statement being permanently written to the curr

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Dave Page
On Wed, May 27, 2020 at 3:00 PM Mark Dilger wrote: > > > > On May 26, 2020, at 4:59 PM, David G. Johnston < > david.g.johns...@gmail.com> wrote: > > > > On Tue, May 26, 2020 at 4:19 PM Mark Dilger < > mark.dil...@enterprisedb.com> wrote: > > I'd also appreciate +1 and -1 votes on the overall idea

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Mark Dilger
> On May 27, 2020, at 1:50 AM, Magnus Hagander wrote: > > On Wed, May 27, 2020 at 1:19 AM Mark Dilger > wrote: > Hackers, > > Attached is a patch for a `pg' command that consolidates various PostgreSQL > functionality into a single command, along the lines of how `git' commands > are run

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Mark Dilger
> On May 27, 2020, at 1:13 AM, Dave Page wrote: > > Hi > > On Wed, May 27, 2020 at 12:19 AM Mark Dilger > wrote: > > I think it makes sense that packagers could put the LIBEXECDIR in the PATH so > that 3rd-party scripts which call pg_ctl, initdb, etc. continue to work. > > Having packa

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Mark Dilger
> On May 26, 2020, at 4:59 PM, David G. Johnston > wrote: > > On Tue, May 26, 2020 at 4:19 PM Mark Dilger > wrote: > I'd also appreciate +1 and -1 votes on the overall idea, in case this entire > feature, regardless of implementation, is simply something the community does > not want. >

Re: password_encryption default

2020-05-27 Thread Stephen Frost
Greetings, * Jonathan S. Katz (jk...@postgresql.org) wrote: > On 5/27/20 9:13 AM, Michael Paquier wrote: > > On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote: > >> Seems like the better choice yeah. Since we're changing the default anyway, > >> maybe now is the time to do that? Or i

Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.

2020-05-27 Thread Andy Fan
On Wed, May 27, 2020 at 8:01 PM Ashutosh Bapat < ashutosh.ba...@2ndquadrant.com> wrote: > > > On Wed, 27 May 2020 at 04:43, Andy Fan wrote: > >> You can use the attached sql to reproduce this issue, but I'm not sure >> you can >> get the above result at the first time that is because when optimiz

Re: password_encryption default

2020-05-27 Thread Jonathan S. Katz
On 5/27/20 9:13 AM, Michael Paquier wrote: > On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote: >> Seems like the better choice yeah. Since we're changing the default anyway, >> maybe now is the time to do that? Or if not, maybe have it log an explicit >> deprecation warning when it l

Re: password_encryption default

2020-05-27 Thread Jonathan S. Katz
On 5/26/20 4:25 AM, Peter Eisentraut wrote: > On 2020-05-25 17:57, Jonathan S. Katz wrote: >> I took a look over, it looks good. One question on the initdb.c diff: >> >> -    if (strcmp(authmethodlocal, "scram-sha-256") == 0 || >> -    strcmp(authmethodhost, "scram-sha-256") == 0) >> -    { >>

Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table.

2020-05-27 Thread Amit Langote
On Wed, May 27, 2020 at 9:11 PM Ashutosh Bapat wrote: > On Wed, May 27, 2020 at 12:53 PM Amit Langote wrote: > > On Fri, May 22, 2020 at 9:09 PM amul sul wrote: > > > I tried similar things on inherit partitioning as follow and that looks > > > fine: > > > > > > DROP TABLE tbl; > > > CREATE TAB

Re: password_encryption default

2020-05-27 Thread Michael Paquier
On Wed, May 27, 2020 at 02:56:34PM +0200, Magnus Hagander wrote: > Seems like the better choice yeah. Since we're changing the default anyway, > maybe now is the time to do that? Or if not, maybe have it log an explicit > deprecation warning when it loads a config with it? Not sure that's worth it

Re: password_encryption default

2020-05-27 Thread Magnus Hagander
On Wed, May 27, 2020 at 8:29 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 2020-05-27 08:00, Michael Paquier wrote: > > On Tue, May 26, 2020 at 10:25:25AM +0200, Peter Eisentraut wrote: > >> Yeah, I was too enthusiastic about removing that. Here is a better > patch. > > > >

Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table.

2020-05-27 Thread Ashutosh Bapat
On Wed, May 27, 2020 at 12:53 PM Amit Langote wrote: > > On Fri, May 22, 2020 at 9:09 PM amul sul wrote: > > I tried similar things on inherit partitioning as follow and that looks > > fine: > > > > DROP TABLE tbl; > > CREATE TABLE tbl (c1 INT,c2 TEXT); > > CREATE TABLE tbl_null(check (c1 is NUL

Re: Make the qual cost on index Filter slightly higher than qual cost on index Cond.

2020-05-27 Thread Ashutosh Bapat
On Wed, 27 May 2020 at 04:43, Andy Fan wrote: > You can use the attached sql to reproduce this issue, but I'm not sure you > can > get the above result at the first time that is because when optimizer > think the > 2 index scan have the same cost, it will choose the first one it found, > the orde

Re: tablespace_map code cleanup

2020-05-27 Thread Robert Haas
On Wed, May 13, 2020 at 10:43 PM Kyotaro Horiguchi wrote: > About 0002, > > + boolsendtblspclinks = true; > > The boolean seems to me useless since it is always the inverse of > opt->sendtblspcmapfile when it is used. Well, I think it might have some documentatio

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

2020-05-27 Thread Mahendra Singh Thalor
On Tue, 26 May 2020 at 16:46, Amit Kapila wrote: > > On Tue, May 26, 2020 at 2:44 PM Dilip Kumar wrote: > > > > On Tue, May 26, 2020 at 10:27 AM Amit Kapila wrote: > > > > > > > > > > > 2. There is a bug fix in handling the stream abort in 0008 (earlier it > > > > was 0006). > > > > > > > > > >

Re: Inlining of couple of functions in pl_exec.c improves performance

2020-05-27 Thread Amit Khandekar
On Tue, 26 May 2020 at 09:06, Amit Khandekar wrote: > > On Sat, 23 May 2020 at 23:24, Pavel Stehule wrote: > > > >FOR counter IN 1..180 LOOP > > id = 0; id = 0; id1 = 0; > > id2 = 0; id3 = 0; id1 = 0; id2 = 0; > > id3 = 0; id = 0; id = 0; id1 = 0; > > id2 = 0; id3

Re: Default gucs for EXPLAIN

2020-05-27 Thread Vik Fearing
On 5/27/20 7:27 AM, David G. Johnston wrote: > On Tuesday, May 26, 2020, David Rowley wrote: > >> On Tue, 26 May 2020 at 23:59, Vik Fearing wrote: >>> Are you saying we should have all new EXPLAIN options off forever into >>> the future because apps won't know about the new data? I guess we >>>

Re: Trouble with hashagg spill I/O pattern and costing

2020-05-27 Thread Tomas Vondra
On Tue, May 26, 2020 at 06:42:50PM -0700, Melanie Plageman wrote: On Tue, May 26, 2020 at 5:40 PM Jeff Davis wrote: On Tue, 2020-05-26 at 21:15 +0200, Tomas Vondra wrote: > > As for the tlist fix, I think that's mostly ready too - the one thing > we > should do is probably only doing it for AG

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Magnus Hagander
On Wed, May 27, 2020 at 1:19 AM Mark Dilger wrote: > Hackers, > > Attached is a patch for a `pg' command that consolidates various > PostgreSQL functionality into a single command, along the lines of how > `git' commands are run from a single 'git' executable. In other words, > > `pg upgrade`

Re: New 'pg' consolidated metacommand patch

2020-05-27 Thread Dave Page
Hi On Wed, May 27, 2020 at 12:19 AM Mark Dilger wrote: > > I think it makes sense that packagers could put the LIBEXECDIR in the PATH > so that 3rd-party scripts which call pg_ctl, initdb, etc. continue to > work. Having packages that futz with the PATH is generally a bad idea, especially thos

Re: max_slot_wal_keep_size comment in postgresql.conf

2020-05-27 Thread Michael Paquier
On Wed, May 27, 2020 at 04:21:59PM +0900, Kyotaro Horiguchi wrote: > I don't oppose to full-spelling. How about the attached? No problem from me. -- Michael signature.asc Description: PGP signature

Re: repeat() function, CHECK_FOR_INTERRUPTS(), and unlikely()

2020-05-27 Thread Michael Paquier
On Mon, May 25, 2020 at 11:14:39AM -0400, Tom Lane wrote: > Perhaps I'm an optimist, but I think that eventually we will figure out > how to make unlikely() work for MSVC. In the meantime we might as well > let it work for gcc-on-Windows builds. I am less optimistic than that, but there is hope.

Re: Getting ERROR with FOR UPDATE/SHARE for partitioned table.

2020-05-27 Thread Amit Langote
On Fri, May 22, 2020 at 9:09 PM amul sul wrote: > I tried similar things on inherit partitioning as follow and that looks fine: > > DROP TABLE tbl; > CREATE TABLE tbl (c1 INT,c2 TEXT); > CREATE TABLE tbl_null(check (c1 is NULL)) INHERITS (tbl); > CREATE TABLE tbl_1 (check (c1 > 0 and c1 < 4)) INHE

Re: max_slot_wal_keep_size comment in postgresql.conf

2020-05-27 Thread Kyotaro Horiguchi
At Wed, 27 May 2020 15:11:00 +0900, Michael Paquier wrote in > On Wed, May 27, 2020 at 10:46:27AM +0900, Kyotaro Horiguchi wrote: > > Agreed. It should be a leftover at the time the unit was changed > > (before committed) to MB from bytes. The default value makes the > > confusion worse. > > >

Re: race condition when writing pg_control

2020-05-27 Thread Michael Paquier
On Tue, May 26, 2020 at 07:30:54PM +, Bossart, Nathan wrote: > While an assertion in UpdateControlFile() would not have helped us > catch the problem I initially reported, it does seem worthwhile to add > it. I have attached a patch that adds this assertion and also > attempts to fix XLogRepor

Re: max_slot_wal_keep_size comment in postgresql.conf

2020-05-27 Thread Fujii Masao
On 2020/05/27 15:11, Michael Paquier wrote: On Wed, May 27, 2020 at 10:46:27AM +0900, Kyotaro Horiguchi wrote: Agreed. It should be a leftover at the time the unit was changed (before committed) to MB from bytes. The default value makes the confusion worse. Is the following works? #max_slo