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

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

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

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

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

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 > > wrote: > > On 08/05/17 13:47, Petr Jelinek wrote: > > On 08/05/17 01:17, Jeff Janes wrote: > >> After dropping a subscription, it

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

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

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

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 -

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

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

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

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. > >

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

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

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

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] 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.

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'

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

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

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

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

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]

[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,

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] 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)

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

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

[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

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 >

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

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

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

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

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

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

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

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

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+

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 + >>

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

[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 ---

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

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

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

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

[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,

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

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

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

[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.

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 >>>

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

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 >

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

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:

Re: [HACKERS] Remove pre-10 compatibility code in hash index

On Tue, May 9, 2017 at 1:41 AM, Amit Kapila wrote: > Commit ea69a0dead5128c421140dc53fac165ba4af8520 has bumped the hash > index version and obviates the need for backward compatibility code > added by commit 293e24e507838733aba4748b514536af2d39d7f2. The same > has been

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

[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

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

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

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

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 > >

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 > > >

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",

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

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 >>>

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

On Wed, May 10, 2017 at 11:22 AM, Thomas Munro wrote: > 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

Re: [HACKERS] Declarative partitioning - another take

On Sun, May 7, 2017 at 9:44 PM, Amit Langote wrote: > I think that makes sense. Modified it to read: "A statement that targets > a parent table in a inheritance or partitioning hierarchy..." in the > attached updated patch. LGTM. Committed. -- Robert Haas

[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

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

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

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=#

Re: [HACKERS] May cause infinite loop when initializing rel-cache contains partitioned table

On Mon, May 8, 2017 at 5:07 AM, Amit Langote wrote: > Thanks for bringing it to the notice. The above code should follow what's > done for other fields that are initialized by > RelationCacheInitializePhase3(). Although, since none of the entries in > the relcache

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

On Tue, May 9, 2017 at 11:48 PM, Thomas Munro wrote: > Hmm. DB2 has transition tables (invented them maybe?) and it allows > OLD/NEW TABLE on row-level triggers: > >

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

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

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

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

[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

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 >>

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

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

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: >>>

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

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

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

[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

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

Re: [HACKERS] Declarative partitioning - another take

On Tue, May 9, 2017 at 11:54 PM, Thomas Munro wrote: > +A statement that targets a parent table in a inheritance or partitioning > > A tiny typo: s/a inheritance/an inheritance/ Now he tells me. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The

Re: [HACKERS] Removal of plaintext password type references

On Wed, May 10, 2017 at 10:51 AM, Vaishnavi Prabakaran wrote: > 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

Re: [HACKERS] [BUGS] Concurrent ALTER SEQUENCE RESTART Regression

On 5/7/17 19:43, Andres Freund wrote: > 3. Keep the catalog, make ALTER properly transactional, blocking >concurrent nextval()s. This resolves the issue that nextval() can't >see the changed definition of the sequence. This was the intended choice. I think I have more clarity about the

[HACKERS] [doc fix] PG10: wroing description on connect_timeout when multiple hosts are specified

Hello, Robert I found a wrong sentence here in the doc. I'm sorry, this is what I asked you to add... https://www.postgresql.org/docs/devel/static/libpq-connect.html#libpq-paramkeywords connect_timeout Maximum wait for connection, in seconds (write as a decimal integer string). Zero or not

Re: [HACKERS] Declarative partitioning - another take

On Wed, May 10, 2017 at 3:51 PM, Robert Haas wrote: > On Sun, May 7, 2017 at 9:44 PM, Amit Langote > wrote: >> I think that makes sense. Modified it to read: "A statement that targets >> a parent table in a inheritance or partitioning

Re: [HACKERS] .pgpass's behavior has changed

At Mon, 1 May 2017 11:34:41 -0400, Robert Haas wrote in > On Fri, Apr 28, 2017 at 3:54 AM, Kyotaro HORIGUCHI > wrote: > > But the above also leaves a bug so I sent

  1   2   >