[HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Hi, Current pg_dump --exclude-table option excludes partitioned relation and dumps all its child relations and vice versa for --table option, which I think is incorrect. In this case we might need to explore all partitions and exclude or include from dump according to given pg_dump option, attach

Re: [HACKERS] proposal psql \gdesc

Hi 2017-05-07 22:55 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > Sometimes I have to solve the result types of some query. It is invisible >>> in psql. >>> >> > Indeed. My 0.02€ about this patch: > > > About the feature: > > It looks useful to allow to show the resulting types of a query. > > >

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

Hi, On 2017/05/05 9:38, Mark Dilger wrote: > Hackers, > > just FYI, I cannot find any regression test coverage of this part of the > grammar, not > even in the contrib/ directory or TAP tests. I was going to submit a patch > to help out, > and discovered it is not so easy to do, and perhaps th

Re: [HACKERS] Adding support for Default partition in partitioning

+1 for AS DEFAULT syntax if it helps in improving readability specially in following case CREATE TABLE p1 PARTITION OF test AS DEFAULT PARTITION BY LIST(a); Thank you, Rahila Syed On Tue, May 9, 2017 at 1:13 AM, Robert Haas wrote: > On Thu, May 4, 2017 at 4:40 PM, Sven R. Kunze wrote: > > It

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On Tue, May 9, 2017 at 2:07 PM, Peter Eisentraut wrote: > On 5/8/17 23:23, Peter Eisentraut wrote: >> The way this uses RESTRICT and CASCADE appears to be backwards from its >> usual meaning. Normally, CASCADE when dropping an object that is still >> used by others will cause those other objects

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Hi, On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: > Hi, > > Current pg_dump --exclude-table option excludes partitioned relation > and dumps all its child relations and vice versa for --table option, which > I think is incorrect. > > In this case we might need to explore all partitions and ex

[HACKERS] Typos in comments in execMain.c

Hi, Here is a small patch to fix typos in comments for InitResultRelInfo() in execMain.c: s/ResultRelationInfo/ResultRelInfo/ and s/the the/the/. Best regards, Etsuro Fujita diff --git a/src/backend/executor/execMain.c b/src/backend/executor/execMain.c index 5c12fb4..2e9fb0e 100644 --- a/src/

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 09/05/17 07:07, Peter Eisentraut wrote: > On 5/8/17 23:23, Peter Eisentraut wrote: >> The way this uses RESTRICT and CASCADE appears to be backwards from its >> usual meaning. Normally, CASCADE when dropping an object that is still >> used by others will cause those other objects to be dropped.

Re: [HACKERS] snapbuild woes

On 09/05/17 00:03, Erik Rijkers wrote: > On 2017-05-05 02:00, Andres Freund wrote: >> >> Could you have a look? > > Running tests with these three patches: > >> 0001-WIP-Fix-off-by-one-around-GetLastImportantRecPtr.patch+ >> 0002-WIP-Possibly-more-robust-snapbuild-approach.patch + >> fix-stat

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek wrote: > On 09/05/17 07:07, Peter Eisentraut wrote: >> On 5/8/17 23:23, Peter Eisentraut wrote: >>> The way this uses RESTRICT and CASCADE appears to be backwards from its >>> usual meaning. Normally, CASCADE when dropping an object that is still >>> u

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 09/05/17 07:24, Michael Paquier wrote: > On Sat, May 6, 2017 at 12:01 AM, Peter Eisentraut > wrote: >> On 5/2/17 21:44, Noah Misch wrote: I wonder if we should have an --no-subscriptions option, now that they are dumped by default, just like we have --no-blobs, --no-owner, --no-p

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 09/05/17 10:51, Masahiko Sawada wrote: > On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek > wrote: >> On 09/05/17 07:07, Peter Eisentraut wrote: >>> On 5/8/17 23:23, Peter Eisentraut wrote: The way this uses RESTRICT and CASCADE appears to be backwards from its usual meaning. Normally, C

Re: [HACKERS] snapbuild woes

On 2017-05-09 10:50, Petr Jelinek wrote: On 09/05/17 00:03, Erik Rijkers wrote: On 2017-05-05 02:00, Andres Freund wrote: Could you have a look? Running tests with these three patches: 0001-WIP-Fix-off-by-one-around-GetLastImportantRecPtr.patch+ 0002-WIP-Possibly-more-robust-snapbuild-appr

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

In my last email by mistake I attached Amul's patch itself. Please find attached patch extending the fix to inheritance relations. Regards, Jeevan Ladhe On Tue, May 9, 2017 at 1:51 PM, Jeevan Ladhe wrote: > Hi, > > On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: > >> Hi, >> >> Current pg_dump

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Hi Amul, On 2017/05/09 16:13, amul sul wrote: > Hi, > > Current pg_dump --exclude-table option excludes partitioned relation > and dumps all its child relations and vice versa for --table option, which > I think is incorrect. I agree that `pg_dump -t partitioned_table` should dump all of its par

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: > Hi, > > Current pg_dump --exclude-table option excludes partitioned relation > and dumps all its child relations and vice versa for --table option, which > I think is incorrect. > > In this case we might need to explore all partitions and exclude

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On 2017/05/09 17:21, Jeevan Ladhe wrote: > On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: >> Current pg_dump --exclude-table option excludes partitioned relation >> and dumps all its child relations and vice versa for --table option, which >> I think is incorrect. >> >> In this case we might nee

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On Tue, May 9, 2017 at 5:57 PM, Petr Jelinek wrote: > On 09/05/17 10:51, Masahiko Sawada wrote: >> On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek >> wrote: >>> On 09/05/17 07:07, Peter Eisentraut wrote: On 5/8/17 23:23, Peter Eisentraut wrote: > The way this uses RESTRICT and CASCADE appea

Re: [HACKERS] snapbuild woes

On 09/05/17 10:59, Erik Rijkers wrote: > On 2017-05-09 10:50, Petr Jelinek wrote: >> On 09/05/17 00:03, Erik Rijkers wrote: >>> On 2017-05-05 02:00, Andres Freund wrote: Could you have a look? >>> >>> Running tests with these three patches: >>> 0001-WIP-Fix-off-by-one-around-GetLastI

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 09/05/17 11:44, Masahiko Sawada wrote: > On Tue, May 9, 2017 at 5:57 PM, Petr Jelinek > wrote: >> On 09/05/17 10:51, Masahiko Sawada wrote: >>> On Tue, May 9, 2017 at 5:39 PM, Petr Jelinek >>> wrote: On 09/05/17 07:07, Peter Eisentraut wrote: > On 5/8/17 23:23, Peter Eisentraut wrote:

[HACKERS] Issues with replication slots(which created manually) against logical replication

Hi, While testing 'logical replication' against v10 , i encountered couple of issue when created logical/physical slot manually. Case 1 - when used with logical replication slot (which created manually) Publication Server(X) \\ Make sure wal_level is set to logical in postgresql.conf file \\

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 3:13 PM, Amit Langote wrote: > On 2017/05/09 17:21, Jeevan Ladhe wrote: >> On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: >>> Current pg_dump --exclude-table option excludes partitioned relation >>> and dumps all its child relations and vice versa for --table option, whic

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

Hi Amit, Ashutosh, On Tue, May 9, 2017 at 3:29 PM, Ashutosh Bapat < ashutosh.ba...@enterprisedb.com> wrote: > On Tue, May 9, 2017 at 3:13 PM, Amit Langote > wrote: > > On 2017/05/09 17:21, Jeevan Ladhe wrote: > >> On Tue, May 9, 2017 at 12:43 PM, amul sul wrote: > >>> Current pg_dump --exclude-

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 2:59 PM, Amit Langote wrote: > Hi Amul, > > On 2017/05/09 16:13, amul sul wrote: >> Hi, >> >> Current pg_dump --exclude-table option excludes partitioned relation >> and dumps all its child relations and vice versa for --table option, which >> I think is incorrect. > > I agr

[HACKERS] [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Hi, Alvaro and Kevin. I'm Mengxing. This is a “synchronization” email to tell you what I've done and my next plan. I'm looking forward to your advice. According to my proposal, I want to prepare the experimental environment during the community bonding period. As this is the first tim

Re: [HACKERS] snapbuild woes

On 2017-05-09 11:50, Petr Jelinek wrote: On 09/05/17 10:59, Erik Rijkers wrote: On 2017-05-09 10:50, Petr Jelinek wrote: On 09/05/17 00:03, Erik Rijkers wrote: On 2017-05-05 02:00, Andres Freund wrote: Could you have a look? [...] I rebased the above mentioned patch to apply to the patche

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Mon, May 8, 2017 at 7:09 PM, Thomas Munro wrote: > On Fri, May 5, 2017 at 8:29 AM, Thomas Munro > wrote: >> On Fri, May 5, 2017 at 2:40 AM, Robert Haas wrote: >>> On Thu, May 4, 2017 at 4:46 AM, Thomas Munro >>> wrote: On Thu, May 4, 2017 at 4:02 AM, Alvaro Herrera wrote: > R

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

On Tue, May 9, 2017 at 12:48 PM, Amit Langote wrote: > Hi, > > On 2017/05/05 9:38, Mark Dilger wrote: >> Hackers, >> >> just FYI, I cannot find any regression test coverage of this part of the >> grammar, not >> even in the contrib/ directory or TAP tests. I was going to submit a patch >> to he

Re: [HACKERS] Bug in pg_dump --table and --exclude-table for declarative partition table handling.

On Tue, May 9, 2017 at 3:51 PM, Ashutosh Bapat wrote: > On Tue, May 9, 2017 at 2:59 PM, Amit Langote > wrote: >> Hi Amul, >> >> On 2017/05/09 16:13, amul sul wrote: >>> Hi, >>> >>> Current pg_dump --exclude-table option excludes partitioned relation >>> and dumps all its child relations and vice

Re: [HACKERS] Adding support for Default partition in partitioning

>Hi Rahila, >I am not able add a new partition if default partition is further partitioned >with default partition. >Consider example below: >postgres=# CREATE TABLE test ( a int, b int, c int) PARTITION BY LIST (a); >CREATE TABLE >postgres=# CREATE TABLE test_p1 PARTITION OF test FOR VALUES IN(

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Peter Eisentraut writes: > On 5/1/17 08:10, David Rowley wrote: >> OK, so I've created a draft patch which does this. > After reading this patch, I see that > a) The scope of the compatibility break is expanded significantly beyond > what was already affected by the xlog->wal renaming. > b) Gener

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

> On May 9, 2017, at 12:18 AM, Amit Langote > wrote: > > Hi, > > On 2017/05/05 9:38, Mark Dilger wrote: >> Hackers, >> >> just FYI, I cannot find any regression test coverage of this part of the >> grammar, not >> even in the contrib/ directory or TAP tests. I was going to submit a patch >

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > On 5/1/17 08:10, David Rowley wrote: > >> OK, so I've created a draft patch which does this. > > > After reading this patch, I see that > > a) The scope of the compatibility break is expanded significantly beyond > >

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 5/9/17 04:39, Petr Jelinek wrote: >>> What we want to simulate instead is an "auto" dependency of the slot on >>> the subscription. So you can drop the slot separately (subject to other >>> restrictions), and it is dropped automatically when the subscription is >>> dropped. To avoid that, you

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 5/9/17 03:27, Masahiko Sawada wrote: > I think we should change tab-completion support for that as well. > > diff --git a/src/bin/psql/tab-complete.c b/src/bin/psql/tab-complete.c > index 183fc37..046fdd5 100644 > --- a/src/bin/psql/tab-complete.c > +++ b/src/bin/psql/tab-complete.c > @@ -2684,

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

On Fri, May 05, 2017 at 02:20:26PM -0400, Robert Haas wrote: > On Thu, May 4, 2017 at 10:59 AM, Chapman Flack wrote: > > invalid input syntax for integer: "21' && 1=2)) Uni/**/ON > > SEl/**/eCT 0x646665743166657274,0x646665743266657274, > > 0x646665743366657274 -- " > > Now that is choice. I won

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On 5/9/17 04:54, Petr Jelinek wrote: >> I think that it would be nice to fix that even before beta, so >> attached is a patch to add --no-subscriptions to pg_dump, pg_dumpall >> and pg_restore. > > Looks okay to me, it's simple enough patch. Committed, thanks. (There was some inconsistent variab

[HACKERS] export import bytea from psql

Hi This is topic, that I try to solve some longer time. I would to open discussion before summer commitfest. The work with binary data or long text fields (multilines) or long not only utf8 encoded XML is not well supported by psql console. Is not hard to use binary protocol and write custom appl

Re: [HACKERS] logical replication syntax (was DROP SUBSCRIPTION, query cancellations and slot handling)

On 09/05/17 16:28, Peter Eisentraut wrote: > On 5/9/17 04:39, Petr Jelinek wrote: What we want to simulate instead is an "auto" dependency of the slot on the subscription. So you can drop the slot separately (subject to other restrictions), and it is dropped automatically when the s

Re: [HACKERS] proposal psql \gdesc

Hello Pavel, Patch applies cleanly and compiles. Idem for v2. "make check" ok. Tests look good. I would suggest some rewording, maybe: "Show the description of the result of the current query buffer without actually executing it, by considering it a prepared statement." done Ok. If som

Re: [HACKERS] logical replication deranged sender

On 08/05/17 13:47, Petr Jelinek wrote: > On 08/05/17 01:17, Jeff Janes wrote: >> After dropping a subscription, it says it succeeded and that it dropped >> the slot on the publisher. >> >> But the publisher still has the slot, and a full-tilt process described >> by ps as >> >> postgres: wal sende

Re: [HACKERS] Should pg_current_wal_location() become pg_current_wal_lsn()

On 5/9/17 10:00 AM, Stephen Frost wrote: * Tom Lane (t...@sss.pgh.pa.us) wrote: #2: Rename all these functions and columns to "lsn", as in this patch. +1 <...> #2 strikes me as the best option, though that's probably not much of a surprise to anyone whose been following my comments on thi

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

David Fetter writes: > On Fri, May 05, 2017 at 02:20:26PM -0400, Robert Haas wrote: >> On Thu, May 4, 2017 at 10:59 AM, Chapman Flack wrote: >>> invalid input syntax for integer: "21' && 1=2)) Uni/**/ON >>> SEl/**/eCT 0x646665743166657274,0x646665743266657274, >>> 0x646665743366657274 -- " >> No

Re: [HACKERS] Adding support for Default partition in partitioning

On Tue, May 9, 2017 at 9:26 AM, Rahila Syed wrote: >>Hi Rahila, > >>I am not able add a new partition if default partition is further >> partitioned >>with default partition. > >>Consider example below: > >>postgres=# CREATE TABLE test ( a int, b int, c int) PARTITION BY LIST (a); >>CREATE TABLE >

Re: [HACKERS] MSVC odd TAP test problem

On 05/06/2017 08:54 PM, Andrew Dunstan wrote: > > On 05/06/2017 07:41 PM, Craig Ringer wrote: >> >> On 7 May 2017 4:24 am, "Andrew Dunstan" >> > > wrote: >> >> >> I have been working on enabling the remaining TAP tests on MSVC >> build in >> the

Re: [HACKERS] logical replication deranged sender

On Tue, May 9, 2017 at 9:18 AM, Petr Jelinek wrote: > On 08/05/17 13:47, Petr Jelinek wrote: > > On 08/05/17 01:17, Jeff Janes wrote: > >> After dropping a subscription, it says it succeeded and that it dropped > >> the slot on the publisher. > >> > >> But the publisher still has the slot, and a

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

> On May 9, 2017, at 9:48 AM, Tom Lane wrote: > > David Fetter writes: >> On Fri, May 05, 2017 at 02:20:26PM -0400, Robert Haas wrote: >>> On Thu, May 4, 2017 at 10:59 AM, Chapman Flack >>> wrote: invalid input syntax for integer: "21' && 1=2)) Uni/**/ON SEl/**/eCT 0x646665743166657

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Mon, May 8, 2017 at 8:42 PM, Petr Jelinek wrote: > On 08/05/17 11:27, Masahiko Sawada wrote: >> Hi, >> >> I encountered a situation where DROP SUBSCRIPTION got stuck when >> initial table sync is in progress. In my environment, I created >> several tables with some data on publisher. I created

Re: [HACKERS] snapbuild woes

On 2017-05-09 11:50, Petr Jelinek wrote: I rebased the above mentioned patch to apply to the patches Andres sent, if you could try to add it on top of what you have and check if it still fails, that would be helpful. It still fails. With these patches - 0001-WIP-Fix-off-by-one-around-GetLa

Re: [HACKERS] proposal psql \gdesc

2017-05-09 18:15 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > Patch applies cleanly and compiles. >>> >> > Idem for v2. "make check" ok. Tests look good. > > I would suggest some rewording, maybe: >>> >>> "Show the description of the result of the current query buffer without >>> actually execut

Re: [HACKERS] logical replication deranged sender

On 09/05/17 19:13, Jeff Janes wrote: > On Tue, May 9, 2017 at 9:18 AM, Petr Jelinek > mailto:petr.jeli...@2ndquadrant.com>> wrote: > > On 08/05/17 13:47, Petr Jelinek wrote: > > On 08/05/17 01:17, Jeff Janes wrote: > >> After dropping a subscription, it says it succeeded and that it dr

[HACKERS] COMPRESS VALUES feature request

Hi, Following a discussion in the IRC channel, I'd like to suggest a feature request to the ToDo WIKI page . The use case is having a column with strings/floats, where some values are very common and can be compressed, while many other values are unique, mak

Re: [HACKERS] CTE inlining

Ok, it seems that most people in discussion are agree that removing optimization fence is a right thing to do. But so far the main topic was whether it worth to make "inlining" by default, and how we should enable it. Nonetheless I still hoping to discuss the algorithm and its implementation.

Re: [HACKERS] COMPRESS VALUES feature request

On Tue, May 9, 2017 at 8:18 PM, Erez Segal wrote: > In the IRC channel - johto suggested an implementation: > > if you want to get really fancy you could have two columns where > only one of set; one would be the value (if reasonably unique) and the > other the id (if not) > I only suggested ho

Re: [HACKERS] proposal psql \gdesc

Hello Pavel, [...] it is little bit worse. I cannot to distinguish between SELECT\gdesc and TRUNCATE xxx\gdesc . All are valid commands and produce empty result, so result of \gdesc command should be empty result too. postgres=# truncate table xx\gdesc ┌──┬──┐ │ Name │ Type │ ╞══

Re: [HACKERS] Logical replication ApplyContext bloat

On 5/8/17 11:26, Peter Eisentraut wrote: > I think it would make more sense to reset ApplyMessageContext in > apply_dispatch(), so that it is done consistently after every message > (as the name implies), not only some messages. Committed that. > Also, perhaps ApplyMessageContext should be a chil

Re: [HACKERS] snapbuild woes

On 09/05/17 19:54, Erik Rijkers wrote: > On 2017-05-09 11:50, Petr Jelinek wrote: > >> I rebased the above mentioned patch to apply to the patches Andres sent, >> if you could try to add it on top of what you have and check if it still >> fails, that would be helpful. > > It still fails. > > Wit

Re: [HACKERS] proposal psql \gdesc

2017-05-09 20:37 GMT+02:00 Fabien COELHO : > > Hello Pavel, > > [...] it is little bit worse. I cannot to distinguish between SELECT\gdesc >> and TRUNCATE xxx\gdesc . All are valid commands and produce empty result, >> so result of \gdesc command should be empty result too. >> >> postgres=# trunca

Re: [HACKERS] CTE inlining

On 5/5/17 08:43, David Rowley wrote: > How about we get the ball rolling on this in v10 and pull that part > out of the docs. If anything that'll buy us a bit more wiggle room to > change this in v11. > > I've attached a proposed patch. If we just tell them that the thing they might have relied o

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

On Tue, May 09, 2017 at 12:48:01PM -0400, Tom Lane wrote: > David Fetter writes: > > On Fri, May 05, 2017 at 02:20:26PM -0400, Robert Haas wrote: > >> On Thu, May 4, 2017 at 10:59 AM, Chapman Flack > >> wrote: > >>> invalid input syntax for integer: "21' && 1=2)) Uni/**/ON > >>> SEl/**/eCT 0x646

Re: [HACKERS] proposal psql \gdesc

On 5/3/17 02:56, Pavel Stehule wrote: > Sometimes I have to solve the result types of some query. It is > invisible in psql. You have to materialize table or you have to > create view. Now, when we can enhance \g command, we can introduce > query describing > > some like > >

Re: [HACKERS] CTE inlining

On Tue, May 9, 2017 at 12:15 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > On 5/5/17 08:43, David Rowley wrote: > > How about we get the ball rolling on this in v10 and pull that part > > out of the docs. If anything that'll buy us a bit more wiggle room to > > change this in v

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

David Fetter writes: > On Tue, May 09, 2017 at 12:48:01PM -0400, Tom Lane wrote: >> I don't think that's a problem: while psql will remove "--" and everything >> following it until newline, it won't remove the newline. So there's still >> a token boundary there. > We may still need to be careful

Re: [HACKERS] CTE inlining

On Tue, May 9, 2017 at 12:22 PM, David G. Johnston wrote: On Tue, May 9, 2017 at 12:15 PM, Peter Eisentraut < peter.eisentr...@2ndquadrant.com [peter.eisentr...@2ndquadrant.com] > wrote: On 5/5/17 08:43, David Rowley wrote: > How about we get the ball rolling on this in v10 and pull that part >

Re: [HACKERS] proposal psql \gdesc

2017-05-09 21:23 GMT+02:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > On 5/3/17 02:56, Pavel Stehule wrote: > > Sometimes I have to solve the result types of some query. It is > > invisible in psql. You have to materialize table or you have to > > create view. Now, when we

Re: [HACKERS] CTE inlining

"David G. Johnston" writes: > On Tue, May 9, 2017 at 12:15 PM, Peter Eisentraut < > peter.eisentr...@2ndquadrant.com> wrote: >> If we just tell them that the thing they might have relied on might go >> away, without a replacement to suggest, then we're just confusing and >> scaring them, no? > ​W

Re: [HACKERS] Logical replication ApplyContext bloat

> On 9 May 2017, at 21:53, Peter Eisentraut > wrote: > > On 5/8/17 11:26, Peter Eisentraut wrote: >> I think it would make more sense to reset ApplyMessageContext in >> apply_dispatch(), so that it is done consistently after every message >> (as the name implies), not only some messages. > > C

Re: [HACKERS] CTE inlining

On Tue, May 9, 2017 at 12:36 PM, Tom Lane wrote: > Also, considering that this behavior has been there since 8.4, > I think it's sheerest chutzpah to claim that changing the docs in > v10 would materially reduce the backward-compatibility concerns > for whatever we might do in v11. > ​No it won'

Re: [HACKERS] snapbuild woes

On 2017-05-09 21:00, Petr Jelinek wrote: On 09/05/17 19:54, Erik Rijkers wrote: On 2017-05-09 11:50, Petr Jelinek wrote: Ah okay, so this is same issue that's reported by both Masahiko Sawada [1] and Jeff Janes [2]. [1] https://www.postgresql.org/message-id/CAD21AoBYpyqTSw%2B%3DES%2BxXtRGMPK

Re: [HACKERS] CTE inlining

"David G. Johnston" writes: > On Tue, May 9, 2017 at 12:36 PM, Tom Lane wrote: >> Also, considering that this behavior has been there since 8.4, >> I think it's sheerest chutzpah to claim that changing the docs in >> v10 would materially reduce the backward-compatibility concerns >> for whatever

Re: [HACKERS] proposal psql \gdesc

What about detecting the empty result (eg PQntuples()==0?) and writing "Empty result" instead of the strange looking empty table above? That would just mean skipping the PrintQueryResult call in this case? PQntuples == 0 every time - the query is not executed. I meant to test the query which

Re: [HACKERS] export import bytea from psql

Pavel Stehule wrote: > 1. using psql variables - we just need to write commands \setfrom > \setfrombf - this should be very simple implementation. The value can be > used more times. On second hand - the loaded variable can hold lot of > memory (and it can be invisible for user). This cou

Re: [HACKERS] CTE inlining

Ilya Shkuratov writes: > Ok, it seems that most people in discussion are agree that removing > optimization > fence is a right thing to do. > Nonetheless I still hoping to discuss the algorithm and its implementation. Yeah, so far we've mainly discussed whether to do that and how to control it,

[HACKERS] Re: [GSOC 17] Eliminate O(N^2) scaling from rw-conflict tracking in serializable transactions

Hi Mengxing, Mengxing Liu wrote: > Hi, Alvaro and Kevin. I'm Mengxing. > > This is a “synchronization” email to tell you what I've done and my next > plan. I'm looking forward to your advice. Welcome! > According to my proposal, I want to prepare the experimental environment > during the

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Tue, May 9, 2017 at 10:29 PM, Thomas Munro wrote: > In master, the decision to populate transition tables happens in > AfterTriggerSaveEvent (called by the ExecAR* functions) in trigger.c. > It does that if it sees that there are triggers on the > relation-being-modified that have transition ta

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

Thomas Munro wrote: > Recall that transition tables can be specified for statement-level > triggers AND row-level triggers. If you specify them for row-level > triggers, then they can see all rows changed so far each time they > fire. Uhmm ... why do we do this? It seems like a great way to cau

Re: [HACKERS] CTE inlining

On 05/09/2017 04:14 PM, Tom Lane wrote: > > Well, TBH that is pre-judging what (if anything) is going to be changed > by a feature that we don't even have design consensus on, let alone a > patch for. I don't think that's an improvement or a good service to > our users; it's just promoting confu

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

On 05/09/2017 01:25 PM, Mark Dilger wrote: > Consensus, no, but utility, yes. > > In three tier architectures there is a general problem that the database > role used by the middle tier to connect to the database does not entail > information about the user who, such as a visitor to your website,

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

> On May 9, 2017, at 3:14 PM, Chapman Flack wrote: > > On 05/09/2017 01:25 PM, Mark Dilger wrote: > >> Consensus, no, but utility, yes. >> >> In three tier architectures there is a general problem that the database >> role used by the middle tier to connect to the database does not entail >> i

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 10, 2017 at 9:57 AM, Alvaro Herrera wrote: > Thomas Munro wrote: > >> Recall that transition tables can be specified for statement-level >> triggers AND row-level triggers. If you specify them for row-level >> triggers, then they can see all rows changed so far each time they >> fire.

Re: [HACKERS] SUBSCRIPTIONS and pg_upgrade

On Wed, May 10, 2017 at 12:00 AM, Peter Eisentraut wrote: > On 5/9/17 04:54, Petr Jelinek wrote: >>> I think that it would be nice to fix that even before beta, so >>> attached is a patch to add --no-subscriptions to pg_dump, pg_dumpall >>> and pg_restore. >> >> Looks okay to me, it's simple enoug

Re: [HACKERS] no test coverage for ALTER FOREIGN DATA WRAPPER name HANDLER ...

On 2017/05/09 22:52, Mark Dilger wrote: > >> On May 9, 2017, at 12:18 AM, Amit Langote >> wrote: >> >> Hi, >> >> On 2017/05/05 9:38, Mark Dilger wrote: >>> Hackers, >>> >>> just FYI, I cannot find any regression test coverage of this part of the >>> grammar, not >>> even in the contrib/ directo

Re: [HACKERS] Adding support for Default partition in partitioning

On 2017/05/10 2:09, Robert Haas wrote: > On Tue, May 9, 2017 at 9:26 AM, Rahila Syed wrote: >>> Hi Rahila, >> >>> I am not able add a new partition if default partition is further >>> partitioned >>> with default partition. >> >>> Consider example below: >> >>> postgres=# CREATE TABLE test ( a int

Re: [HACKERS] MSVC odd TAP test problem

On Wed, May 10, 2017 at 2:11 AM, Andrew Dunstan wrote: > (After extensive trial and error) Turns out it's not quite that, it's > the kill_kill stuff. I think for now we should just disable it on the > platform. That means not running tests 7 and 8 of the logical_decoding > tests and all of the cra

[HACKERS] Removal of plaintext password type references

Hi All, Following recent removal of support to store password in plain text, modified the code to 1. Remove "PASSWORD_TYPE_PLAINTEXT" macro 2. Instead of using "get_password_type" to retrieve the encryption method AND to check if the password is already encrypted or not, modified the code to a.

[HACKERS] how to shrink pg_attribute table?

Hello, My application creates temp table frequently. Now I find pg_attribute table is growing larger and larger, 90GB now. pgstattuple shows 82% free space, so I restored the db to dev env, and tried vacuum full to shrink it. However, the vacuum full run for 24 hours, and hang there.

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On 2017/05/10 6:51, Thomas Munro wrote: > No such problem exists for partition hierarchies since the tables all > appear as the same type to user code (though conversions may be > happening for technical reasons). To clarify a bit, there may exist differences in the ordering of columns, either bet

Re: [HACKERS] idea: custom log_line_prefix components besides application_name

On 05/09/17 18:48, Mark Dilger wrote: > I don't have any positive expectation that the postgres community will go > along with any of this, but just from my point of view, the cleaner way to > do what you are proposing is something like setting a session variable. > > In your middle tier java app

Re: [HACKERS] Transition tables for triggers on foreign tables and views

On Mon, May 08, 2017 at 12:00:20AM -0700, Noah Misch wrote: > On Sat, May 06, 2017 at 06:58:35PM +, Noah Misch wrote: > > On Tue, May 02, 2017 at 06:06:47PM -0500, Kevin Grittner wrote: > > > On Fri, Apr 28, 2017 at 10:56 PM, Tom Lane wrote: > > > > > > > They will fire if you have an INSTEAD

Re: [HACKERS] delta relations in AFTER triggers

On Sat, May 06, 2017 at 05:33:24AM +, Noah Misch wrote: > On Thu, May 04, 2017 at 09:51:03PM +1200, Thomas Munro wrote: > > On Thu, May 4, 2017 at 9:12 PM, Prabhat Sahu > > wrote: > > > I have been testing this for a while and observed a server crash while > > > referencing table column value

Re: [HACKERS] delta relations in AFTER triggers

On Sat, May 06, 2017 at 05:34:46AM +, Noah Misch wrote: > On Fri, May 05, 2017 at 08:23:33AM +1200, Thomas Munro wrote: > > On Fri, May 5, 2017 at 12:39 AM, Neha Sharma > > wrote: > > > While testing the feature we encountered one more crash,below is the > > > scenario to reproduce. > > > > >

Re: [HACKERS] Get stuck when dropping a subscription during synchronizing table

On Wed, May 10, 2017 at 2:46 AM, Masahiko Sawada wrote: > On Mon, May 8, 2017 at 8:42 PM, Petr Jelinek > wrote: >> On 08/05/17 11:27, Masahiko Sawada wrote: >>> Hi, >>> >>> I encountered a situation where DROP SUBSCRIPTION got stuck when >>> initial table sync is in progress. In my environment, I

Re: [HACKERS] multi-column range partition constraint

On Mon, May 8, 2017 at 2:59 AM, Amit Langote wrote: > Yes, disallowing this in the first place is the best thing to do. > Attached patch 0001 implements that. With the patch: Committed. With regard to 0002, some of the resulting constraints are a bit more complicated than seems desirable: crea

Re: [HACKERS] delta relations in AFTER triggers

On Thu, May 4, 2017 at 5:51 AM, Thomas Munro wrote: > Reproduced here. The stack looks like this: > > frame #3: 0x00010f06f8b0 > postgres`ExceptionalCondition(conditionName="!(readptr->eflags & > 0x0002)", errorType="FailedAssertion", fileName="tuplestore.c", > lineNumber=1237) + 128 at a

Re: [HACKERS] Transition tables for triggers on foreign tables and views

Hi, Since the last one conflicted with recent changes, here's a rebased patch to prevent transition tables on views and foreign tables. -- Thomas Munro http://www.enterprisedb.com prevent-unsupported-transition-tables-v2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (

Re: [HACKERS] delta relations in AFTER triggers

On Thu, May 4, 2017 at 4:23 PM, Thomas Munro wrote: > We can't possibly support transition tables on TRUNCATE (the whole > point of TRUNCATE is not to inspect all the rows so we can't collect > them), and we already reject ROW triggers on TRUNCATE, so we should > reject transition tables on STATEM

Re: [HACKERS] Transition tables for triggers on foreign tables and views

On Tue, May 9, 2017 at 11:24 PM, Thomas Munro wrote: > Since the last one conflicted with recent changes, here's a rebased > patch to prevent transition tables on views and foreign tables. Committed, but I made the new error details more like the existing one that also checks relkind. -- Robert

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Wed, May 10, 2017 at 2:31 PM, Amit Langote wrote: > On 2017/05/10 6:51, Thomas Munro wrote: >> No such problem exists for partition hierarchies since the tables all >> appear as the same type to user code (though conversions may be >> happening for technical reasons). > > To clarify a bit, ther

Re: [HACKERS] transition table behavior with inheritance appears broken (was: Declarative partitioning - another take)

On Tue, May 9, 2017 at 11:40 PM, Thomas Munro wrote: > On Wed, May 10, 2017 at 2:31 PM, Amit Langote > wrote: >> On 2017/05/10 6:51, Thomas Munro wrote: >>> No such problem exists for partition hierarchies since the tables all >>> appear as the same type to user code (though conversions may be >>

Re: [HACKERS] Typos in comments in execMain.c

On Tue, May 9, 2017 at 4:26 AM, Etsuro Fujita wrote: > Here is a small patch to fix typos in comments for InitResultRelInfo() in > execMain.c: s/ResultRelationInfo/ResultRelInfo/ and s/the the/the/. Committed. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Co

  1   2   >