Re: row filtering for logical replication

On 2018-11-02 02:59, Euler Taveira wrote: Em qui, 1 de nov de 2018 às 05:30, Erik Rijkers escreveu: > I ran pgbench-over-logical-replication with a WHERE-clause and could > not get this to do a correct replication. Below is the output of the > attached test program. > > > $ ./logrep_rowfilter.

Re: COPY FROM WHEN condition

pá 2. 11. 2018 v 3:57 odesílatel Corey Huinker napsal: > > Are you thinking something like having a COPY command that provides >> > results in such a way that they could be referenced in a FROM clause >> > (perhaps a COPY that defines a cursor…)? >> >> That would also be nice, but what I was thin

Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT

On Fri, Nov 02, 2018 at 02:18:04PM +0900, Michael Paquier wrote: > This case is funky. The parent gets dropped at commit time, but it does > not know that it should drop the child as well per their dependencies. > This actually goes into the internals of performDeletion(), which is > scary to touc

Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT

On Fri, Nov 02, 2018 at 01:36:05PM +0900, Amit Langote wrote: > When writing the test, I noticed something to be pointed out. As of > 1c7c317cd9d, partitions of a temporary partition table themselves must be > temporary, but the ON COMMIT action has to be specified for each table > separately. Ma

Re: ToDo: show size of partitioned table

Hi, On 2018/11/01 2:19, Pavel Stehule wrote: > st 31. 10. 2018 v 7:34 odesílatel Amit Langote < > langote_amit...@lab.ntt.co.jp> napsal: >> On 2018/10/31 15:30, Pavel Stehule wrote: >>> st 31. 10. 2018 v 3:27 odesílatel Amit Langote < >>> langote_amit...@lab.ntt.co.jp> napsal: +appendPQEx

Re: bugfix: BUG #15477: Procedure call with named inout refcursor parameter - "invalid input syntax for type boolean"

čt 1. 11. 2018 v 14:31 odesílatel Pavel Stehule napsal: > Cleaned patch with regress tests > > minor cleaning Regards Pavel diff --git a/src/pl/plpgsql/src/expected/plpgsql_call.out b/src/pl/plpgsql/src/expected/plpgsql_call.out index 547ca22a55..8762e1335c 100644 --- a/src/pl/plpgsql/src/expec

Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT

On 2018/11/02 10:51, Michael Paquier wrote: > On Thu, Nov 01, 2018 at 01:04:43PM +0900, Michael Paquier wrote: >> On Thu, Nov 01, 2018 at 12:39:16PM +0900, Amit Langote wrote: >>> Rajkumar pointed out off-list that the patch still remains to be applied. >>> Considering that there is a planned point

Re: WIP Patch: Add a function that returns binary JSONB as a bytea

Christian Ohler writes: > On Wed, Oct 31, 2018 at 7:22 AM Tom Lane wrote: >> If we're going to expose the >> internal format, let's just change the definition of the type's binary >> I/O format, thereby getting a win for purposes like COPY BINARY as well. > How would this work from the driver's

Re: COPY FROM WHEN condition

> > > Are you thinking something like having a COPY command that provides > > results in such a way that they could be referenced in a FROM clause > > (perhaps a COPY that defines a cursor…)? > > That would also be nice, but what I was thinking of was that some > highly restricted subset of cases o

Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal)

On Thu, 1 Nov 2018, David Rowley wrote: I ended up going with: However, this consideration only applies when is minimal for non-partitioned tables as all commands must write WAL otherwise. I've changed this to: Rows will be frozen only if the table being loaded has been cr

Re: WIP Patch: Add a function that returns binary JSONB as a bytea

On Wed, Oct 31, 2018 at 7:22 AM Tom Lane wrote: > If we're going to expose the > internal format, let's just change the definition of the type's binary > I/O format, thereby getting a win for purposes like COPY BINARY as well. > We'd need to ensure that jsonb_recv could tell whether it was seeing

Re: partitioned indexes and tablespaces

Hi, On 2018/11/02 10:27, Michael Paquier wrote: > On Thu, Nov 01, 2018 at 09:31:38PM -0300, Alvaro Herrera wrote: >> A customer reported to us that partitioned indexes are not working >> consistently with tablespaces: > > Let's see... > >> 1. When a CREATE INDEX specifies a tablespace, existing

Re: row filtering for logical replication

Em qui, 1 de nov de 2018 às 05:30, Erik Rijkers escreveu: > > I ran pgbench-over-logical-replication with a WHERE-clause and could > > not get this to do a correct replication. Below is the output of the > > attached test program. > > > > > > $ ./logrep_rowfilter.sh > Erik, thanks for testing. >

Re: CF app feature request

On 11/01/2018 08:40 PM, Michael Paquier wrote: On Thu, Nov 01, 2018 at 05:56:24PM -0400, Andrew Dunstan wrote: On 11/01/2018 05:50 PM, Magnus Hagander wrote: Are you thinking basically another status that's "Withdrawn", but keeping it, or actually removing the records completely? I don't kn

Re: Getting ERROR: could not open file "base/13164/t3_16388" with partition table with ON COMMIT

On Thu, Nov 01, 2018 at 01:04:43PM +0900, Michael Paquier wrote: > On Thu, Nov 01, 2018 at 12:39:16PM +0900, Amit Langote wrote: >> Rajkumar pointed out off-list that the patch still remains to be applied. >> Considering that there is a planned point release on Nov 8, maybe we >> should do somethin

Re: partitioned indexes and tablespaces

On Thu, Nov 01, 2018 at 09:31:38PM -0300, Alvaro Herrera wrote: > A customer reported to us that partitioned indexes are not working > consistently with tablespaces: Let's see... > 1. When a CREATE INDEX specifies a tablespace, existing partitions get > the index in the correct tablespace; howeve

Re: INSTALL file

On Thu, Nov 01, 2018 at 08:42:34PM -0400, Stephen Frost wrote: > If we go down this route, the master branch should probably link to the > regularly built devel documentation, so that if/when we do make such a > change, we'll point people at the updated documentation too. I don't know how others f

Re: CF app feature request

On Thu, Nov 01, 2018 at 05:56:24PM -0400, Andrew Dunstan wrote: > On 11/01/2018 05:50 PM, Magnus Hagander wrote: >> Are you thinking basically another status that's "Withdrawn", but >> keeping it, or actually removing the records completely? > > I don't know enough about the app internals to comme

Re: INSTALL file

Greetings, * Michael Paquier (mich...@paquier.xyz) wrote: > On Thu, Nov 01, 2018 at 01:41:33PM -0400, Stephen Frost wrote: > > I'm not sure that I'm really following this, because we aren't pointing > > to the development documentation, just the 'current' documentation, and > > that seems fine, an

Re: INSTALL file

Greetings, * Andreas 'ads' Scherbaum (a...@pgug.de) wrote: > How about the attached one? Picked up your draft, and cleaned it up a bit. (unsurprisingly) this is looking pretty good to me. A few additional notes: > PostgreSQL Database Management System > = >

Re: More issues with pg_verify_checksums and checksum verification in base backups

On Thu, Nov 01, 2018 at 04:44:40PM +0530, Amit Kapila wrote: > This sounds like a good argument for having a whitelist approach, but > is it really a big problem if a user gets warning for files that the > utility is not able to verify checksums for? I think in some sense > this message can be use

partitioned indexes and tablespaces

Hello A customer reported to us that partitioned indexes are not working consistently with tablespaces: 1. When a CREATE INDEX specifies a tablespace, existing partitions get the index in the correct tablespace; however, the parent index itself does not record the tablespace. So when new partiti

Re: Commitfest 2018-11

On Thu, Nov 01, 2018 at 01:19:20PM +0100, Dmitry Dolgov wrote: > On Thu, 1 Nov 2018 at 13:05, Daniel Gustafsson wrote: >> >> Dmitry: Are you still interested in running this commitfest? > > Yes, I'm still interested. Do I need to have any special permissions > in CF app for that (e.g. now I can't

Re: pg_promote not marked as parallel-restricted in pg_proc.dat

On Thu, Nov 01, 2018 at 12:59:47PM -0400, Robert Haas wrote: > If you do the same analysis for pg_start_backup(), you'll immediately > notice that it calls get_backup_status(), and if you look at that > function, you'll see that it returns the value of a global variable. > If you check parallel.c,

Re: Pluggable Storage - Andres's take

On Wed, Oct 31, 2018 at 9:34 PM Dmitry Dolgov <9erthali...@gmail.com> wrote: > > On Mon, 29 Oct 2018 at 05:56, Haribabu Kommi > wrote: > > > >> This problem couldn't be reproduced on the master branch, so I've tried > to > >> investigate it. It comes from nodeModifyTable.c:1267, when we've got >

Re: INSTALL file

On Thu, Nov 01, 2018 at 01:41:33PM -0400, Stephen Frost wrote: > I'm not sure that I'm really following this, because we aren't pointing > to the development documentation, just the 'current' documentation, and > that seems fine, and there's links on that page to the other versions of > the page fo

Re: INSTALL file

On 01.11.18 18:41, Stephen Frost wrote: Greetings, * Andreas 'ads' Scherbaum (a...@pgug.de) wrote: On 01.11.18 07:26, Michael Paquier wrote: It includes links to the website, as well as the short version of the installation instructions. +The installation instructions are listed on the websit

Re: Compressed TOAST Slicing

Paul Ramsey writes: > On Thu, Nov 1, 2018 at 2:29 PM Stephen Frost wrote: >> and secondly, why we wouldn't consider >> handling a non-zero offset. A non-zero offset would, of course, still >> require decompressing from the start and then just throwing away what we >> skip over, but we're going t

Re: replication_slots usability issue

On Thu, Nov 01, 2018 at 10:54:23AM -0700, Andres Freund wrote: > On 2018-11-01 09:34:05 +0900, Michael Paquier wrote: > That has absolutely nothing to do with the issue at hand though, so I > don't think it'd have made much sense to do it at the same time. Nor do > I think it's particularly importa

Re: PG vs macOS Mojave

I wrote: > Then somebody who wants to build on a different SDK version still needs > to do "make PG_SYSROOT=/proper/path", but only if they're trying to > build PL/Perl or related extensions. So this second way seems uglier > in some sense but less likely to cause problems for most people. > Eith

Re: Compressed TOAST Slicing

On Thu, Nov 1, 2018 at 2:29 PM Stephen Frost wrote: > Greetings, > > * Paul Ramsey (pram...@cleverelephant.ca) wrote: > > The attached patch adds in a code path to do a partial decompression of > the > > TOAST entry, when the requested slice is at the start of the object. > > There two things tha

Re: PG vs macOS Mojave

I wrote: > Peter Eisentraut writes: >> On 01/11/2018 22:17, Tom Lane wrote: >>> The other idea that's occurred to me is to go back to the scheme of >>> commit 68fc227dd, where we inject the sysroot path into just the -I >>> switches used for PL/Perl and PL/Tcl. We could improve on that >>> commit

Re: CF app feature request

Andrew Dunstan writes: > On 11/01/2018 05:50 PM, Magnus Hagander wrote: >> Are you thinking basically another status that's "Withdrawn", but >> keeping it, or actually removing the records completely? > I don't know enough about the app internals to comment. But it probably > shouldn't appear i

Re: PG vs macOS Mojave

Peter Eisentraut writes: > On 01/11/2018 22:17, Tom Lane wrote: >> The other idea that's occurred to me is to go back to the scheme of >> commit 68fc227dd, where we inject the sysroot path into just the -I >> switches used for PL/Perl and PL/Tcl. We could improve on that >> commit by injecting it

Re: PG vs macOS Mojave

On 01/11/2018 22:17, Tom Lane wrote: > The other idea that's occurred to me is to go back to the scheme of > commit 68fc227dd, where we inject the sysroot path into just the -I > switches used for PL/Perl and PL/Tcl. We could improve on that > commit by injecting it symbolically similar to what I

Re: CF app feature request

On 11/01/2018 05:50 PM, Magnus Hagander wrote: On Thu, Nov 1, 2018 at 2:44 PM Andrew Dunstan > wrote: Yesterday Fabien and I submitted the same item to the Commitfest (1859 and 1860). Unfortunately there doesn't seem to be any way for on

Re: Buildfarm failures for hash indexes: buffer leaks

Their commit r265375 fixed the ability to compile itself, but built PostgreSQL binaries remain broken there and thereafter. |...] Thanks a lot for this investigation! I can fill in a gcc bug report. There would be a enormous work to narrow it down to a small test case, it is unclear how they

Re: CF app feature request

On Thu, Nov 1, 2018 at 2:44 PM Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > Yesterday Fabien and I submitted the same item to the Commitfest (1859 > and 1860). Unfortunately there doesn't seem to be any way for one of > these to be withdrawn. "Rejected" and "Returned with Feedback"

Re: Compressed TOAST Slicing

Greetings, * Paul Ramsey (pram...@cleverelephant.ca) wrote: > The attached patch adds in a code path to do a partial decompression of the > TOAST entry, when the requested slice is at the start of the object. Neat! > As usual, doing less work is faster. Definitely. > Interesting note to motiva

Re: PG vs macOS Mojave

So it seems like there are two ways we could go about this. One is to go back to the scheme of adding an -isysroot switch to CPPFLAGS, where it'd have global effects. We could make this slightly less painful for scenarios like Jakob's if we set things up in Makefile.global this way: CPPFLAGS = -

Re: Hash Joins vs. Bloom Filters / take 2

On 11/01/2018 10:06 PM, Thomas Munro wrote: > On Fri, Nov 2, 2018 at 9:23 AM Jim Finnerty wrote: >> I'm very interested in this patch, and particularly in possible >> extensions to push the Bloom filter down on the probe side of the join. I >> made a few small edits to the patch to enable it

Re: Hash Joins vs. Bloom Filters / take 2

On Fri, Nov 2, 2018 at 9:23 AM Jim Finnerty wrote: > I'm very interested in this patch, and particularly in possible > extensions to push the Bloom filter down on the probe side of the join. I > made a few small edits to the patch to enable it to compile on PG11, and can > send it to you if y

Compressed TOAST Slicing

Currently, PG_DETOAST_DATUM_SLICE when run on a compressed TOAST entry will first decompress the whole object, then extract the relevant slice. When the desired slice is at or near the front of the object, this is obviously non-optimal. The attached patch adds in a code path to do a partial decom

Re: Doubts about pushing LIMIT to MergeAppendPath

On 11/01/2018 08:51 PM, Antonin Houska wrote: > Tomas Vondra wrote: > >> On 11/01/2018 12:48 PM, Antonin Houska wrote: >>> Review of [1] made me think of this optimization, currently used only in >>> create_merge_append_path(): >>> >>> /* >>> * Apply query-wide LIMIT if known and path

Re: Remove obsolete pg_attrdef.adsrc column

On 27/10/2018 23:19, Daniel Gustafsson wrote: >> On 27 Oct 2018, at 12:57, Peter Eisentraut >> wrote: >> >> On 23/10/2018 19:48, Daniel Gustafsson wrote: On 23 Oct 2018, at 15:17, Peter Eisentraut wrote: I propose the attached patch to remove the long-unused catalog column >

Re: Doubts about pushing LIMIT to MergeAppendPath

Tomas Vondra wrote: > On 11/01/2018 12:48 PM, Antonin Houska wrote: > > Review of [1] made me think of this optimization, currently used only in > > create_merge_append_path(): > > > > /* > > * Apply query-wide LIMIT if known and path is for sole base relation. > > * (Handling this

Re: Doubts about pushing LIMIT to MergeAppendPath

On 11/01/2018 08:11 PM, Tomas Vondra wrote: > On 11/01/2018 12:48 PM, Antonin Houska wrote: >> Review of [1] made me think of this optimization, currently used only in >> create_merge_append_path(): >> >> /* >> * Apply query-wide LIMIT if known and path is for sole base relation. >>

Re: Parallel threads in query

On 11/01/2018 08:03 PM, Andres Freund wrote: > On 2018-11-01 19:57:17 +0100, Tomas Vondra wrote: I think that very much depends on how expensive the tasks handled by the threads are. It may still be cheaper than a reasonable IPC, and if you don't create/destroy threads, that also sav

Re: Parallel threads in query

Hi, On 2018-11-01 09:17:56 -1000, Darafei "Komяpa" Praliaskouski wrote: > So, do I understand correctly that I need to start a parallel worker that > does nothing for each thread I launch to consume the parallel worker limit? No, I don't think that'd be reasonable. I think what we're saying is th

Re: Parallel threads in query

> > > Because you said "faster than reasonable IPC" - which to me implies that > you don't do full blown IPC. Which using threads in a bgworker is very > strongly implying. What you're proposing strongly implies multiple > context switches just to process a few results. Even before, but > especiall

Re: Doubts about pushing LIMIT to MergeAppendPath

On 11/01/2018 12:48 PM, Antonin Houska wrote: > Review of [1] made me think of this optimization, currently used only in > create_merge_append_path(): > > /* >* Apply query-wide LIMIT if known and path is for sole base relation. >* (Handling this at this low level is a bit kl

Re: Parallel threads in query

On 2018-11-01 19:57:17 +0100, Tomas Vondra wrote: > >> I think that very much depends on how expensive the tasks handled by the > >> threads are. It may still be cheaper than a reasonable IPC, and if you > >> don't create/destroy threads, that also saves quite a bit of time. > > > > I'm not follow

Re: Parallel threads in query

On 11/01/2018 07:50 PM, Andres Freund wrote: > Hi, > > On 2018-11-01 19:44:54 +0100, Tomas Vondra wrote: >> On 11/01/2018 07:40 PM, Andres Freund wrote: >>> On 2018-11-01 19:33:39 +0100, Tomas Vondra wrote: In theory, simulating such global limit should be possible using a bit of shared

Re: Parallel threads in query

Hi, On 2018-11-01 19:44:54 +0100, Tomas Vondra wrote: > On 11/01/2018 07:40 PM, Andres Freund wrote: > > On 2018-11-01 19:33:39 +0100, Tomas Vondra wrote: > >> In theory, simulating such global limit should be possible using a bit > >> of shared memory for the current total, per-process counter an

Re: Parallel threads in query

On 11/01/2018 07:43 PM, Darafei "Komяpa" Praliaskouski wrote: > In theory, simulating such global limit should be possible using a bit > of shared memory for the current total, per-process counter and probably > some simple abort handling (say, just like contrib/openssl does using >

Re: Parallel threads in query

On 11/01/2018 07:40 PM, Andres Freund wrote: > Hi, > > On 2018-11-01 19:33:39 +0100, Tomas Vondra wrote: >> In theory, simulating such global limit should be possible using a bit >> of shared memory for the current total, per-process counter and probably >> some simple abort handling (say, just li

Re: Parallel threads in query

> > In theory, simulating such global limit should be possible using a bit > of shared memory for the current total, per-process counter and probably > some simple abort handling (say, just like contrib/openssl does using > ResourceOwner). > I would expect that this limit is already available and

Re: Parallel threads in query

Hi, On 2018-11-01 19:33:39 +0100, Tomas Vondra wrote: > In theory, simulating such global limit should be possible using a bit > of shared memory for the current total, per-process counter and probably > some simple abort handling (say, just like contrib/openssl does using > ResourceOwner). Right

Re: Parallel threads in query

On 11/01/2018 06:15 PM, Andres Freund wrote: > On 2018-11-01 10:10:33 -0700, Paul Ramsey wrote: >> On Wed, Oct 31, 2018 at 2:11 PM Tom Lane wrote: >> >>> =?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= >>> writes: Question is, what's the best policy to allocate cores so we can play ni

Re: Buildfarm failures for hash indexes: buffer leaks

On 2018-10-27 08:18:12 +0200, Fabien COELHO wrote: > > Hello Jeff, > > > > I suspect the easiest thing to narrow it down would be to bisect the > > > problem in gcc :( > > > > Their commit r265241 is what broke the PostgreSQL build. It also broke the > > compiler itself--at that commit it was n

Re: replication_slots usability issue

On 2018-11-01 09:34:05 +0900, Michael Paquier wrote: > HI Andres, > > On Wed, Oct 31, 2018 at 03:48:02PM -0700, Andres Freund wrote: > > And done. Thanks for the report JD. > > Shouldn't we also switch the PANIC to a FATAL in > RestoreSlotFromDisk()? That has absolutely nothing to do with the i

Re: INSTALL file

Greetings, * Andreas 'ads' Scherbaum (a...@pgug.de) wrote: > On 01.11.18 07:26, Michael Paquier wrote: > >>It includes links to the website, as well as the short version of the > >>installation instructions. > >+The installation instructions are listed on the website: > >+ > >+https://www.postgres

Re: Parallel threads in query

On 2018-11-01 10:10:33 -0700, Paul Ramsey wrote: > On Wed, Oct 31, 2018 at 2:11 PM Tom Lane wrote: > > > =?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= > > writes: > > > Question is, what's the best policy to allocate cores so we can play nice > > > with rest of postgres? > > > > > > Ther

Re: Parallel threads in query

On Wed, Oct 31, 2018 at 2:11 PM Tom Lane wrote: > =?UTF-8?Q?Darafei_=22Kom=D1=8Fpa=22_Praliaskouski?= > writes: > > Question is, what's the best policy to allocate cores so we can play nice > > with rest of postgres? > > There is not, because we do not use or support multiple threads inside >

Re: New vacuum option to do only freezing

On Mon, Oct 1, 2018 at 6:23 AM Masahiko Sawada wrote: > Attached patch adds a new option FREEZE_ONLY to VACUUM command. This > option is same as FREEZE option except for it disables reclaiming dead > tuples. That is, with this option vacuum does pruning HOT chain, > freezing live tuples and mainta

Re: pg_promote not marked as parallel-restricted in pg_proc.dat

On Wed, Oct 31, 2018 at 8:43 PM Michael Paquier wrote: > Okay, but likely we would not want to signal the postmaster > unnecessarily, no? FALLBACK_PROMOTE_SIGNAL_FILE gets discarded if > promotion is triggered more than once, but that does not like a sane > thing to do if not necessary. Uh, what

Re: New vacuum option to do only freezing

Hi, On 10/1/18, 5:23 AM, "Masahiko Sawada" wrote: > Attached patch adds a new option FREEZE_ONLY to VACUUM command. This > option is same as FREEZE option except for it disables reclaiming dead > tuples. That is, with this option vacuum does pruning HOT chain, > freezing live tuples and maintaini

Re: [PATCH][PROPOSAL] Add enum releation option type

В письме от 1 ноября 2018 11:10:14 пользователь Tom Lane написал: > >>> I see you lost the Oxford comma: > >>> > >>> -DETAIL: Valid values are "on", "off", and "auto". > >>> +DETAIL: Valid values are "auto", "on" and "off". > >>> > >>> Please put these back. > >> > >> Actually that's me who h

Re: [PATCH][PROPOSAL] Add enum releation option type

Robert Haas writes: > On Wed, Mar 7, 2018 at 10:23 AM Nikolay Shaplov wrote: >>> I see you lost the Oxford comma: >>> >>> -DETAIL: Valid values are "on", "off", and "auto". >>> +DETAIL: Valid values are "auto", "on" and "off". >>> >>> Please put these back. >> Actually that's me who have los

Re: PG vs macOS Mojave

> On 1 Nov 2018, at 15:53, Tom Lane wrote: > > Daniel Gustafsson writes: >>> On 1 Nov 2018, at 15:14, Tom Lane wrote: >>> Wow ... could it be that it actually varies depending on the combination >>> of compiler and OS versions? That would be weird. > >> Or the version of XCode and the set of

Re: [PATCH][PROPOSAL] Add enum releation option type

On Wed, Mar 7, 2018 at 10:23 AM Nikolay Shaplov wrote: > > I see you lost the Oxford comma: > > > > -DETAIL: Valid values are "on", "off", and "auto". > > +DETAIL: Valid values are "auto", "on" and "off". > > > > Please put these back. > Actually that's me who have lost it. The code with oxford

Re: PG vs macOS Mojave

Daniel Gustafsson writes: >> On 1 Nov 2018, at 15:14, Tom Lane wrote: >> Wow ... could it be that it actually varies depending on the combination >> of compiler and OS versions? That would be weird. > Or the version of XCode and the set of installed SDKs? I only have a single > SDK installed o

Re: POC: Cleaning up orphaned files using undo logs

While I've been involved in the design discussions for this patch set, I haven't looked at any of the code personally in a very long time. I certainly don't claim to be an independent reviewer, and I encourage others to review this work also. That said, here are some review comments. I decided t

Re: PG vs macOS Mojave

> On 1 Nov 2018, at 15:14, Tom Lane wrote: > > Daniel Gustafsson writes: >> Odd. I don’t actually get -isysroot on XCode 10.0 on my 10.13.6 >> installation, >> on 10.12 with XCode 8.3.3 I do however get -isysroot. > > Wow ... could it be that it actually varies depending on the combination >

Re: PG vs macOS Mojave

Daniel Gustafsson writes: > Odd. I don’t actually get -isysroot on XCode 10.0 on my 10.13.6 installation, > on 10.12 with XCode 8.3.3 I do however get -isysroot. Wow ... could it be that it actually varies depending on the combination of compiler and OS versions? That would be weird.

Re: Commitfest 2018-11

> On Thu, 1 Nov 2018 at 15:11, Stephen Frost wrote: > Hmm... Can you try it again? Yep, now I see the administration menu, thanks.

Re: Commitfest 2018-11

Greetings, * Dmitry Dolgov (9erthali...@gmail.com) wrote: > > On Thu, 1 Nov 2018 at 14:11, Stephen Frost wrote: > > I've added you to the 'cf admins' group > > Thanks. > > > so please give it a shot now and let me know if you run into any troubles. > > Hm...I don't see any difference in CF app

Re: zheap: a new storage format for PostgreSQL

On 11/01/2018 07:43 AM, Amit Kapila wrote: You can find the latest code at https://github.com/EnterpriseDB/zheap Seems valgrind complains about a couple of places in the code - nothing major, might be noise, but probably worth a look. regards -- Tomas Vondra http://www.2n

Re: Commitfest 2018-11

> On Thu, 1 Nov 2018 at 14:11, Stephen Frost wrote: > I've added you to the 'cf admins' group Thanks. > so please give it a shot now and let me know if you run into any troubles. Hm...I don't see any difference in CF app, what should be changed?

CF app feature request

Yesterday Fabien and I submitted the same item to the Commitfest (1859 and 1860). Unfortunately there doesn't seem to be any way for one of these to be withdrawn. "Rejected" and "Returned with Feedback" seem wrong. Ideally, there would be a way for someone who submits an item in error to wit

Re: bugfix: BUG #15477: Procedure call with named inout refcursor parameter - "invalid input syntax for type boolean"

Cleaned patch with regress tests diff --git a/src/pl/plpgsql/src/expected/plpgsql_call.out b/src/pl/plpgsql/src/expected/plpgsql_call.out index 547ca22a55..8762e1335c 100644 --- a/src/pl/plpgsql/src/expected/plpgsql_call.out +++ b/src/pl/plpgsql/src/expected/plpgsql_call.out @@ -276,3 +276,43 @@ DR

Re: INSTALL file

On 01.11.18 07:26, Michael Paquier wrote: On Thu, Nov 01, 2018 at 01:32:09AM +0100, Andreas 'ads' Scherbaum wrote: Picking up on this idea, attached is a first draft for changing the README. Why don't you add it to the upcoming commit fest? It would be good to get some traction with a formal r

Re: Commitfest 2018-11

Greetings, * Daniel Gustafsson (dan...@yesql.se) wrote: > > On 1 Nov 2018, at 13:19, Dmitry Dolgov <9erthali...@gmail.com> wrote: > > Do I need to have any special permissions in CF app > > for that (e.g. now I can't "push the button" to start the current one)? > > Yes, I believe either Magnus or

Re: bugfix: BUG #15477: Procedure call with named inout refcursor parameter - "invalid input syntax for type boolean"

čt 1. 11. 2018 v 13:10 odesílatel Pavel Stehule napsal: > > > čt 1. 11. 2018 v 13:00 odesílatel Pavel Stehule > napsal: > >> Hi >> >> The processing of named parameters inside CALL statement is not correct. >> >> It is my code :-/. I am sorry >> >> Attached patch fix it. >> >> This still doesn't

Re: Commitfest 2018-11

> On 1 Nov 2018, at 13:19, Dmitry Dolgov <9erthali...@gmail.com> wrote: > >> On Thu, 1 Nov 2018 at 13:05, Daniel Gustafsson wrote: >> >> Dmitry: Are you still interested in running this commitfest? > > Yes, I'm still interested. Great! > Do I need to have any special permissions in CF app > f

Re: Commitfest 2018-11

> On Thu, 1 Nov 2018 at 13:05, Daniel Gustafsson wrote: > > Dmitry: Are you still interested in running this commitfest? Yes, I'm still interested. Do I need to have any special permissions in CF app for that (e.g. now I can't "push the button" to start the current one)?

Re: bugfix: BUG #15477: Procedure call with named inout refcursor parameter - "invalid input syntax for type boolean"

čt 1. 11. 2018 v 13:00 odesílatel Pavel Stehule napsal: > Hi > > The processing of named parameters inside CALL statement is not correct. > > It is my code :-/. I am sorry > > Attached patch fix it. > > This still doesn't fix INOUT variables with default value - so is not > fully correct, but in

Commitfest 2018-11

We are now in November and the 2018-11 commitfest has started (or rather, will one someone pushes the button) but AFAICT there hasn’t been anyone volunteering to do be CFM this time apart from Dmitry Dolgov who showed an interest (in CA+q6zcWPs5aFUQxZ5qi=wRhbesUSRGD3_r4HSgQKq+G6=ux...@mail.gmail.co

bugfix: BUG #15477: Procedure call with named inout refcursor parameter - "invalid input syntax for type boolean"

Hi The processing of named parameters inside CALL statement is not correct. It is my code :-/. I am sorry Attached patch fix it. This still doesn't fix INOUT variables with default value - so is not fully correct, but in this moment, it can show, where is a core of this issue. Regards Pavel d

Re: PG vs macOS Mojave

> On 1 Nov 2018, at 04:17, Tom Lane wrote: > and on Xcode 10.0 I get Odd. I don’t actually get -isysroot on XCode 10.0 on my 10.13.6 installation, on 10.12 with XCode 8.3.3 I do however get -isysroot. > Right now I think the only plausible > fix is to go back to adding "-isysroot $PG_SYSROOT"

Doubts about pushing LIMIT to MergeAppendPath

Review of [1] made me think of this optimization, currently used only in create_merge_append_path(): /* * Apply query-wide LIMIT if known and path is for sole base relation. * (Handling this at this low level is a bit klugy.) */ if (bms_equal(rel->relids,

Re: CVE-2017-7484-induced bugs, or, btree cmp functions are not leakproof?

On Mon, Oct 29, 2018 at 2:53 PM Amit Langote wrote: > > Thank you for creating the patch. > > On 2018/10/28 20:35, Dilip Kumar wrote: > > On Sat, Oct 27, 2018 at 10:07 AM Dilip Kumar wrote: > >> On Fri, Oct 26, 2018 at 1:12 PM Amit Langote wrote: > >>> On 2018/10/25 19:54, Dilip Kumar wrote: > >>

Re: FETCH FIRST clause WITH TIES option

hi, The attached patch include all the comment given by Tomas and i check sql standard about LIMIT and this feature it did not say anything about it but I think its good idea to include it to LIMIT too and I will add it if we have consensus on it. regards surafel diff --git a/doc/src/sgml/ref/s

Re: More issues with pg_verify_checksums and checksum verification in base backups

On Sun, Oct 21, 2018 at 7:12 PM Michael Paquier wrote: > > Hi all, > > This is a follow-up of the following thread: > https://www.postgresql.org/message-id/20181012010411.re53cwcistcpi...@alap3.anarazel.de > > In a nutshell, b34e84f1 has added TAP tests for pg_verify_checksums, and > the buildfarm

Re: Connection slots reserved for replication

Hi, Attached rebased version patch to the current HEAD and created commit fest entry On Fri, 21 Sep 2018 at 13:43, Alexander Kukushkin wrote: > > Hi, > > On 20 September 2018 at 08:18, Kyotaro HORIGUCHI > wrote: > > > > > Instaed, we can iterally "reserve" connection slots for the > > specific u

Re: FETCH FIRST clause WITH TIES option

On 10/31/2018 06:17 PM, Robert Haas wrote: On Mon, Oct 29, 2018 at 12:48 PM Andrew Gierth wrote: Then FETCH FIRST N WITH TIES becomes "stop when the expression rank() over (order by ...) <= N is no longer true" (where the ... is the existing top level order by) Wouldn't that be wicked expe

Re: pg_promote not marked as parallel-restricted in pg_proc.dat

On Thu, Nov 1, 2018 at 6:14 AM Michael Paquier wrote: > > On Wed, Oct 31, 2018 at 01:09:53PM -0400, Robert Haas wrote: > > There's no rule whatsoever that a parallel worker can't write to the > > disk. pg_start_backup and pg_stop_backup have to be > > parallel-restricted because, when used in non

Re: [HACKERS] generated columns

On 10/30/18, Peter Eisentraut wrote: > 3. Radical alternative: Collapse everything into one new column. We > could combine atthasdef and attgenerated and even attidentity into a new > column. (Only one of the three can be the case.) This would give > client code a clean break, which may or may

Re: Super PathKeys (Allowing sort order through precision loss functions)

On 11/01/2018 02:40 AM, David Rowley wrote: On 1 November 2018 at 12:24, Andres Freund wrote: FWIW, I kind of wonder if we built proper infrastructure to allow to make such inferrences from function calls, whether it could also be made to support the transformation of LIKEs into indexable <= >=

Re: Speeding up INSERTs and UPDATEs to partitioned tables

On 2018/11/01 10:30, David Rowley wrote: > It's great to know the patch is now so perfect that we've only the > macro naming left to debate ;-) I looked over v12 again and noticed a couple minor issues. + * table then we store the index into parenting + * PartitionTupleR

  1   2   >