Re: [HACKERS] BUG: pg_dump generates corrupted gzip file in Windows

Hi, On Mon, Jun 19, 2017 at 12:25 PM, Amit Kapila wrote: > On Mon, Jun 19, 2017 at 11:42 AM, Ashutosh Sharma > wrote: >> Hi, >> >> On Fri, Mar 24, 2017 at 10:16 PM, Robert Haas wrote: >>> On Fri, Mar 24, 2017 at 6:44 AM, Kuntal Ghosh >>> wrote: > ASAICU, if we use binary mode, output is s

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

On 2017/06/16 14:16, Ashutosh Bapat wrote: > On Fri, Jun 16, 2017 at 12:48 AM, Robert Haas wrote: >> On Thu, Jun 15, 2017 at 12:54 PM, Ashutosh Bapat >> wrote: >>> Some more comments on the latest set of patches. >>> >>> In heap_drop_with_catalog(), we heap_open() the parent table to get the >>>

[HACKERS] Phantom segment upon promotion causing troubles.

Hi, Greg Burek from Heroku (CCed) reported a weird issue on IM, that was weird enough to be interesting. What he'd observed was that he promoted some PITR standby, and early clones of that node work, but later clones did not, failing to read some segment. The problems turns out to be the followi

Re: [HACKERS] Phantom segment upon promotion causing troubles.

Hi, On 2017-06-19 00:30:26 -0700, Andres Freund wrote: > There seems to be a larger question ehre though: Why does > XLogFileReadAnyTLI() probe all timelines even if they weren't a parent > at that period? That seems like a bad idea, especially in more > complicated scenarios where some precursor

Re: [HACKERS] transition table behavior with inheritance appears broken

On 2017/06/19 7:59, Andrew Gierth wrote: >> "Andrew" == Andrew Gierth writes: > > (Any preferences for whether it should be one commit or 3 separate ones?) For my 2c, it would be nice to keep at least the inheritance one (or all of them actually) separate. Thanks, Amit -- Sent via pgsql-

Re: [HACKERS] Refreshing subscription relation state inside a transaction block

On Thu, Jun 15, 2017 at 11:49 PM, Petr Jelinek wrote: > On 15/06/17 15:52, Peter Eisentraut wrote: >> On 6/15/17 02:41, Petr Jelinek wrote: >>> Hmm, forcibly stopping currently running table sync is not what was >>> intended, I'll have to look into it. We should not be forcibly stopping >>> anythi

Re: [HACKERS] RLS policy not getting honer while pg_dump on declarative partition

On 2017/06/17 9:20, Stephen Frost wrote: > Greetings, > > * Rushabh Lathia (rushabh.lat...@gmail.com) wrote: >> While doing some testing I noticed that RLS policy not getting honer >> while pg_dump on declarative partition. >> >> I can understand that while doing SELECT on individual child >> tabl

[HACKERS] Rules on table partitions

Currently we allow rules to be defined on table partitions, but these rules only fire when the partition is accessed directly, not when it is accessed via the parent: CREATE TABLE t1(a int, b int) PARTITION BY RANGE(a); CREATE TABLE t1_p PARTITION OF t1 FOR VALUES FROM (1) TO (10); INSERT INTO t1

Re: [HACKERS] ASOF join

On 16.06.2017 19:07, David Fetter wrote: On Fri, Jun 16, 2017 at 11:51:34AM +1200, Thomas Munro wrote: On Fri, Jun 16, 2017 at 4:20 AM, Konstantin Knizhnik wrote: I wonder if there were some discussion/attempts to add ASOF join to Postgres (sorry, may be there is better term for it, I am ref

Re: [HACKERS] Making server name part of the startup message

-Original Message- From: Andres Freund [mailto:and...@anarazel.de] Sent: Friday, June 16, 2017 10:48 AM To: Tom Lane Cc: Satyanarayana Narlapuram ; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Making server name part of the startup message On 2017-06-15 09:43:13 -0400, Tom Lane

[HACKERS] psql's \d and \dt are sending their complaints to different output files

Hello Hackers, I wonder if it is intentional that \d complains on stderr if it cannot find relations to match, but \dt prints the message to the current output file? postgres=# \d xxx Did not find any relation named "xxx". postgres=# \dt xxx No matching relations found. I've noticed the differen

[HACKERS] drop operator class..using .. left dependency behind.

Hi, I have observed that even after dropping operator class, not able to drop schema containing it. below is a example. postgres=# CREATE SCHEMA sch_test; CREATE SCHEMA postgres=# SET search_path TO 'sch_test'; SET postgres=# CREATE OR REPLACE FUNCTION sch_test.dummy_hashint4_39779(a int4) RETURN

Re: [HACKERS] RLS policy not getting honer while pg_dump on declarative partition

Amit, * Amit Langote (langote_amit...@lab.ntt.co.jp) wrote: > On 2017/06/17 9:20, Stephen Frost wrote: > > I think we could certainly consider if this behavior is desirable in a > > system which includes partitioning instead of inheritance, > > Do we want CREATE POLICY foo ON parent creating the

Re: [HACKERS] Directory pg_replslot is not properly cleaned

On Sun, Jun 18, 2017 at 11:32 PM, Andres Freund wrote: > > Hi, > > On 2017-06-07 15:46:45 -0300, Fabrízio de Royes Mello wrote: > > > >> Just adding Dimitriy to conversation... previous email I provided was > > > >wrong. > > > >> > > > > > > > >Does anyone have some thought about this critical iss

Re: [HACKERS] Setting pd_lower in GIN metapage

On Mon, Jun 19, 2017 at 11:37 AM, Amit Langote wrote: > What are some arguments against setting pd_lower in the GIN metapage as > follows? > > GinMetaPageData *metad = GinPageGetMeta(page); > > ((PageHeader) page)->pd_lower = > ((char *) metad + sizeof(GinMetaPageData)) - (char *) page; > > I

Re: [HACKERS] Directory pg_replslot is not properly cleaned

On Mon, Jun 19, 2017 at 10:58 PM, Fabrízio de Royes Mello wrote: > Do you know when the next minor versions will be released? Because depending > of the schedule I'll patch the current customer version because we need the > "pglogical" running stable. The next round is planned for the 10th of Aug

Re: [HACKERS] Directory pg_replslot is not properly cleaned

On Mon, Jun 19, 2017 at 11:02 AM, Michael Paquier wrote: > > On Mon, Jun 19, 2017 at 10:58 PM, Fabrízio de Royes Mello > wrote: > > Do you know when the next minor versions will be released? Because depending > > of the schedule I'll patch the current customer version because we need the > > "pgl

Re: [HACKERS] drop operator class..using .. left dependency behind.

Rajkumar Raghuwanshi writes: > I have observed that even after dropping operator class, not able to drop > schema containing it. below is a example. You didn't read the error message closely: > *postgres=# DROP SCHEMA sch_test;ERROR: cannot drop schema sch_test > because other objects depend on

Re: [HACKERS] Setting pd_lower in GIN metapage

Amit Kapila writes: > On Mon, Jun 19, 2017 at 11:37 AM, Amit Langote > wrote: >> What are some arguments against setting pd_lower in the GIN metapage as >> follows? > Actually, hash index also has similar code (See _hash_init_metabuffer) > and I see no harm in doing this at similar other places.

Re: [HACKERS] BUG: pg_dump generates corrupted gzip file in Windows

Ashutosh Sharma writes: > On Mon, Jun 19, 2017 at 12:25 PM, Amit Kapila wrote: >> On Mon, Jun 19, 2017 at 11:42 AM, Ashutosh Sharma >> wrote: >>> On Fri, Mar 24, 2017 at 10:16 PM, Robert Haas wrote: Why not? I mean, if there's code there to force the output into binary mode, does th

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

On Mon, Jun 19, 2017 at 6:30 PM, Oleksandr Shulgin wrote: > I think can be helpful, though rarely, to be able to send the output of \d* > commands to a file. At the same time it would be nice to see the message on > stderr instead of appending to the output file, in case the relation was not > fo

Re: [HACKERS] BUG: pg_dump generates corrupted gzip file in Windows

I wrote: > That patch looks reasonable to me, will push. On closer inspection, the patch did contain a bug: it tested for compression being active with "compression > 0", which is the wrong thing --- everyplace else in pg_dump tests with "compression != 0". This is important because Z_DEFAULT_COMP

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

Dilip Kumar writes: > On Mon, Jun 19, 2017 at 6:30 PM, Oleksandr Shulgin > wrote: >> I think can be helpful, though rarely, to be able to send the output of \d* >> commands to a file. At the same time it would be nice to see the message on >> stderr instead of appending to the output file, in ca

Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

On Mon, Jun 19, 2017 at 5:20 PM, Artus de benque wrote: > postgres=# UPDATE test_table SET field = 'hi' WHERE id = 1; > UPDATE 0 > test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1; > UPDATE 1 > test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1; > UPDA

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

On Sat, Jun 17, 2017 at 5:41 PM, Peter Eisentraut wrote: > On 6/16/17 10:51, Tom Lane wrote: >> So I'm back to the position that we ought to stick the indent >> code under src/tools/ in our main repo. Is anyone really >> seriously against that? > > I think it would be better to have it separate.

Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

Dilip Kumar writes: > On Mon, Jun 19, 2017 at 5:20 PM, Artus de benque > wrote: >> postgres=# UPDATE test_table SET field = 'hi' WHERE id = 1; >> UPDATE 0 >> test_db=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1; >> UPDATE 1 >> test_db=# UPDATE test_table SET field = rpad('', 2

Re: [HACKERS] Decimal64 and Decimal128

On Sun, Jun 18, 2017 at 6:28 PM, Thomas Munro wrote: > I speculate that decNumber in-tree would be the path of least > resistance (assuming the "ICU 1.8.1 and later" license[4] would be > acceptable -- to my untrained eye it looks rather BSD-ish -- and > 20kloc isn't viewed as excessive), and furt

Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote: >> Seems like in "suppress_redundant_updates_trigger" we are comparing >> toasted tuple with the new tuple and that is the cause of the bug. > > I don't think it's a bug, I think it's an intentional design tradeoff. > To suppress an update in this

[HACKERS] GSoC 2017 weekly progress reports (week 3)

Project: Explicitly support predicate locks in index AMs besides b-tree Hi, During this week, I continued my work on testing and created my first patch for gist index. I have also started working on the hash index. In summary, I have done following things in this week. 1) updated tests to check

Re: [HACKERS] Decimal64 and Decimal128

Robert Haas writes: > On Sun, Jun 18, 2017 at 6:28 PM, Thomas Munro > wrote: >> I speculate that decNumber in-tree would be the path of least >> resistance (assuming the "ICU 1.8.1 and later" license[4] would be >> acceptable -- to my untrained eye it looks rather BSD-ish -- and >> 20kloc isn't v

Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

Robert Haas writes: > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote: >> I don't think it's a bug, I think it's an intentional design tradeoff. >> To suppress an update in this case, the trigger would have to grovel >> through the individual fields and detoast them before comparing. >> That wou

Re: [HACKERS] WIP: Data at rest encryption

On Thu, Jun 15, 2017 at 7:51 PM, Alvaro Herrera wrote: > I thought we called it "incremental development". From the opposite > point of view, would you say we should ban use of passphrase-protected > SSL key files because the current user interface for them is bad? I think that we've got a numbe

Re: [HACKERS] WIP: Data at rest encryption

On Mon, Jun 19, 2017 at 12:30 PM, Robert Haas wrote: > On Thu, Jun 15, 2017 at 7:51 PM, Alvaro Herrera > wrote: >> I thought we called it "incremental development". From the opposite >> point of view, would you say we should ban use of passphrase-protected >> SSL key files because the current us

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 12:18 PM, Tom Lane wrote: > It would be interesting to get some handle on the performance differences > between decNumber and our existing NUMERIC implementation. I'm a little > skeptical that they'd be so enormous as to make this an interesting > project, but I could be w

Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

Hi, It looks like you know what is happening, but I found that I have made an error in my original assumption: (while the steps to reproduce are still valid) The size of the string at which the trigger does not work as expected varies, depending on the size of the other fields in the row. The 'l

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 10:00 AM, Robert Haas wrote: > I've never been very happy with the performance of numeric, so I guess > I'm a bit more optimistic about the chances of doing better. Aside > from any computational optimizations, the fact that the datatype could > be pass-by-value rather tha

Re: [HACKERS] [BUGS] Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

Tom Lane wrote: > Robert Haas writes: > > On Mon, Jun 19, 2017 at 11:59 AM, Tom Lane wrote: > >> I don't think it's a bug, I think it's an intentional design tradeoff. > >> To suppress an update in this case, the trigger would have to grovel > >> through the individual fields and detoast them bef

Re: [HACKERS] GSoC 2017 weekly progress reports (week 3)

Shubham Barai wrote: > Project: Explicitly support predicate locks in index AMs besides b-tree > > Hi, > > > During this week, I continued my work on testing and created my first patch > for gist index. Please post it. -- Álvaro Herrerahttps://www.2ndQuadrant.com/ PostgreSQL D

[HACKERS] CREATE SUBSCRIPTION documentation

https://www.postgresql.org/docs/devel/static/sql-createsubscription.html Has the note: See Section 26.2.5.1 for details on how to configure access control between the subscription and the publica

Re: [HACKERS] GSoC 2017 weekly progress reports (week 3)

Hi , On 19 June 2017 at 22:49, Alvaro Herrera wrote: > Shubham Barai wrote: > > Project: Explicitly support predicate locks in index AMs besides b-tree > > > > Hi, > > > > > > During this week, I continued my work on testing and created my first > patch > > for gist index. > > Please post it. >

Re: [HACKERS] INSERT ... ON CONFLICT () SELECT

On Sun, Jun 18, 2017 at 9:21 PM, Peter Geoghegan wrote: > Returning rows with duplicate values seems rather unorthodox. > Ok, then option 2 it is. In summary, this is what I am going to (attempt to) implement for the new syntax: INSERT ... ON CONFLICT (...) DO SELECT RETURNING ... 1. Rows

[HACKERS] Optional message to user when terminating/cancelling backend

When terminating, or cancelling, a backend it’s currently not possible to let the signalled session know *why* it was dropped. This has nagged me in the past and now it happened to come up again, so I took a stab at this. The attached patch implements the ability to pass an optional text message

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

* Robert Haas (robertmh...@gmail.com) wrote: > On Sat, Jun 17, 2017 at 5:41 PM, Peter Eisentraut > wrote: > > On 6/16/17 10:51, Tom Lane wrote: > >> So I'm back to the position that we ought to stick the indent > >> code under src/tools/ in our main repo. Is anyone really > >> seriously against t

Re: [HACKERS] Optional message to user when terminating/cancelling backend

2017-06-19 20:24 GMT+02:00 Daniel Gustafsson : > When terminating, or cancelling, a backend it’s currently not possible to > let > the signalled session know *why* it was dropped. This has nagged me in the > past and now it happened to come up again, so I took a stab at this. The > attached patc

[HACKERS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

On 06/19/2017 11:40 AM, Dilip Kumar wrote: > ... Artus de benque ... wrote: >> ...=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1; > > Seems like in "suppress_redundant_updates_trigger" we are comparing > toasted tuple with the new tuple and that is the cause of the bug. Somethi

Re: [HACKERS] Optional message to user when terminating/cancelling backend

+1. This really helps PostgreSQL Azure service as well. When we are doing the upgrades to the service, instead of abruptly terminating the sessions we can provide this message. Thanks, Satya From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Pave

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 1:10 PM, Peter Geoghegan wrote: > On Mon, Jun 19, 2017 at 10:00 AM, Robert Haas wrote: >> I've never been very happy with the performance of numeric, so I guess >> I'm a bit more optimistic about the chances of doing better. Aside >> from any computational optimizations,

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

Stephen Frost writes: > * Robert Haas (robertmh...@gmail.com) wrote: >> On Sat, Jun 17, 2017 at 5:41 PM, Peter Eisentraut >> wrote: >>> On 6/16/17 10:51, Tom Lane wrote: So I'm back to the position that we ought to stick the indent code under src/tools/ in our main repo. Is anyone real

Re: [HACKERS] Preliminary results for proposed new pgindent implementation

* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Robert Haas (robertmh...@gmail.com) wrote: > >> On Sat, Jun 17, 2017 at 5:41 PM, Peter Eisentraut > >> wrote: > >>> On 6/16/17 10:51, Tom Lane wrote: > So I'm back to the position that we ought to stick the indent > co

Re: [HACKERS] Decimal64 and Decimal128

On Mon, Jun 19, 2017 at 12:19 PM, Robert Haas wrote: > I don't have a specific use case in mind. However, datumCopy() is > sure to be a lot faster when typByVal is true, and see also the > documentation changes in commit > 8472bf7a73487b0535c95e299773b882f7523463. Fair enough. I ask because at

Re: [HACKERS] Regression in join selectivity estimations when using foreign keys

David Rowley writes: > On 22 May 2017 at 16:10, David Rowley wrote: >> I also just noticed that I don't think I've got ANTI join cases >> correct in the patch I sent. I'll look at that now. > I've attached an updated patch. > This one is much less invasive than my original attempt. Sorry for no

Re: [HACKERS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

J Chapman Flack writes: > On 06/19/2017 11:40 AM, Dilip Kumar wrote: >> ... Artus de benque ... wrote: >>> ...=# UPDATE test_table SET field = rpad('', 2001, 'a') WHERE id = 1; >> Seems like in "suppress_redundant_updates_trigger" we are comparing >> toasted tuple with the new tuple and that is

Re: [BUGS] [HACKERS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

Tom Lane wrote: > As I mentioned upthread, it'd certainly be possible for the trigger > to iterate through the fields in a datatype-aware fashion and undo > compression or out-of-lineing before the comparison. But that would > eat a lot more cycles than the current implementation, and it seems >

Re: [HACKERS] Getting server crash on Windows when using ICU collation

On 6/19/17 00:42, Ashutosh Sharma wrote: >> If we don't find unconv, isn't it better to fall back to non-UTF8 >> version rather than saying command not found? > Well, if any of the ICU package is installed on our system then we > will certainly find uconv command. The only case where we can see suc

Re: [HACKERS] Rules on table partitions

On 6/19/17 07:19, Dean Rasheed wrote: > Currently we allow rules to be defined on table partitions, but these > rules only fire when the partition is accessed directly, not when it > is accessed via the parent That's what I would have expected, but I realize that there are always multiple ways to

Re: [BUGS] [HACKERS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

Alvaro Herrera writes: > Tom Lane wrote: >> ... If the trigger is succeeding (ie, >> detecting a no-op update) often enough that it would be worth that, >> you've really got an application-stupidity problem to fix. > ISTM the whole point of suppress_redundant_updates_trigger is to cope > with app

Re: [BUGS] [HACKERS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

On Mon, Jun 19, 2017 at 2:10 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Tom Lane wrote: >>> ... If the trigger is succeeding (ie, >>> detecting a no-op update) often enough that it would be worth that, >>> you've really got an application-stupidity problem to fix. > >> ISTM the whole point o

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

On 6/19/17 09:00, Oleksandr Shulgin wrote: > I wonder if it is intentional that \d complains on stderr if it cannot > find relations to match, but \dt prints the message to the current > output file? > > postgres=# \d xxx > Did not find any relation named "xxx". > postgres=# \dt xxx > No matching

Re: [BUGS] [HACKERS] Re: Postgresql bug report - unexpected behavior of suppress_redundant_updates_trigger

On 06/19/2017 05:19 PM, David G. Johnston wrote: > At first glance I think I'd rather have it do the correct thing all of > the time, even if it takes longer, so that my only trade-off decision > is whether to improve performance by fixing the application. > > Ideally if the input tuple wouldn't

Re: [HACKERS] CREATE SUBSCRIPTION documentation

On 6/19/17 13:28, Jeff Janes wrote: > I think it would be better to instead reference: > > https://www.postgresql.org/docs/devel/static/logical-replication-security.html > > And on that page, it says: > > "The role used for the replication connection must have > the |REPLICATION| attribute" > >

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

Peter Eisentraut writes: > On 6/19/17 09:00, Oleksandr Shulgin wrote: >> postgres=# \d xxx >> Did not find any relation named "xxx". >> postgres=# \dt xxx >> No matching relations found. > I think this is intentional. > The first command is "show me relation xxx", and that gives an error > messa

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

On Mon, Jun 19, 2017 at 2:25 PM, Peter Eisentraut wrote: > On 6/19/17 09:00, Oleksandr Shulgin wrote: >> I wonder if it is intentional that \d complains on stderr if it cannot >> find relations to match, but \dt prints the message to the current >> output file? >> >> postgres=# \d xxx >> Did not f

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

"David G. Johnston" writes: > The docs also indicate that we don't include materialized views as > part of "\d" which seems like an oversight somewhere. Where are you reading that? Experimentation shows that "\d" does include matviews, and that matches the code, which has this as the default exp

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Okay, so major breakthrough. *Updates:* - The operator @>(anyarray, anyelement) is now functional - The segmentation fault was due to applying PG_FREE_IF_COPY on a datum when it should only be applied on TOASTed inputs - The only problem now is if for example you apply the op

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

On Mon, Jun 19, 2017 at 2:53 PM, Tom Lane wrote: > "David G. Johnston" writes: >> The docs also indicate that we don't include materialized views as >> part of "\d" which seems like an oversight somewhere. > > Where are you reading that? https://www.postgresql.org/docs/9.6/static/app-psql.html

Re: [HACKERS] UPDATE of partition key

On Fri, Jun 16, 2017 at 5:36 AM, Amit Khandekar wrote: > There is another issue I discovered. The row-movement works fine if > the destination leaf partition has different attribute ordering than > the root : the existing insert-tuple-routing mapping handles that. But > if the source partition has

Re: [HACKERS] psql's \d and \dt are sending their complaints to different output files

"David G. Johnston" writes: > On Mon, Jun 19, 2017 at 2:53 PM, Tom Lane wrote: >> Where are you reading that? > https://www.postgresql.org/docs/9.6/static/app-psql.html > First sentence: > "For each relation (table, view, index, sequence, or foreign table) or > composite type matching the patte

Re: [HACKERS] UPDATE of partition key

On Thu, Jun 15, 2017 at 1:36 PM, Amit Khandekar wrote: > Attached patch v10 fixes the above. In the existing code, where it > builds WCO constraints for each leaf partition; with the patch, that > code now is applicable to row-movement-updates as well. I guess I don't see why it should work like

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Mark Rofail wrote: > Okay, so major breakthrough. > > *Updates:* > >- The operator @>(anyarray, anyelement) is now functional > - The segmentation fault was due to applying PG_FREE_IF_COPY on a > datum when it should only be applied on TOASTed inputs > - The only problem now

Re: [HACKERS] transition table behavior with inheritance appears broken

On Sun, Jun 18, 2017 at 6:59 PM, Andrew Gierth wrote: > (Any preferences for whether it should be one commit or 3 separate ones?) If I were doing it, I would commit them separately. But I'm not doing it, so I won't complain about what you decide to do. -- Robert Haas EnterpriseDB: http://www.e

Re: [HACKERS] Broken hint bits (freeze)

On Sat, Jun 17, 2017 at 08:34:47AM +0530, Amit Kapila wrote: > On Fri, Jun 16, 2017 at 11:03 PM, Sergey Burladyan > wrote: > >> > Yeah, we have ensured that all the transactions before shutdown > >> > checkpoint got archived. It is done in commit > >> > 2e6107cb621d003dcab0df53ac8673ea67c4e467.

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 2017-04-05 15:45:26 -0700, Andres Freund wrote: > Hi, > > On 2017-04-05 17:00:42 +1000, Vaishnavi Prabakaran wrote: > > Regarding test patch, I have corrected the test suite after David Steele's > > comments. > > Also, I would like to mention that a companion patch was submitted by David > > St

Re: [HACKERS] REPLICA IDENTITY FULL

On 6/18/17 23:11, Tatsuo Ishii wrote: > While playing around with logical replication, I am confused by the > behavior of REPLICA IDENTITY FULL. > However, if a table has text columns, UPDATE/DELETE replication does > not work any more. Am I missing something? This is apparently because for repli

Re: [HACKERS] REPLICA IDENTITY FULL

> This is apparently because for replica identity full the comparison of > the search key against the tuple value goes through datumIsEqual(), > which doesn't work for TOAST values. > > We might be able to refine that, but there is a general problem that > without an index and an operator class, w

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On Tue, Jun 20, 2017 at 8:49 AM, Andres Freund wrote: > On 2017-04-05 15:45:26 -0700, Andres Freund wrote: > > Hi, > > > > On 2017-04-05 17:00:42 +1000, Vaishnavi Prabakaran wrote: > > > Regarding test patch, I have corrected the test suite after David > Steele's > > > comments. > > > Also, I wou

Re: [HACKERS] Broken hint bits (freeze)

20 июн. 2017 г. 1:21 пользователь "Bruce Momjian" написал: We are saying that Log-Shipping should match "Latest checkpoint location", but the WAL for that will not be sent to the standby, so it will not match, but that is OK since the only thing in the non-shipped WAL file is the checkpoint reco

Re: [HACKERS] Something is rotten in publication drop

If there are no new insights, I plan to proceed with the attached patch tomorrow. This leaves the existing view and function alone, adds pg_relation_is_publishable() and uses that in psql. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote D

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On 20 June 2017 at 06:49, Andres Freund wrote: > On 2017-04-05 15:45:26 -0700, Andres Freund wrote: >> Hi, >> >> On 2017-04-05 17:00:42 +1000, Vaishnavi Prabakaran wrote: >> > Regarding test patch, I have corrected the test suite after David Steele's >> > comments. >> > Also, I would like to menti

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

On 6/16/17 04:16, Masahiko Sawada wrote: > A subscription relation state may have been removed already when we > try to update it. SetSubscriptionRelState didn't emit an error in such > case but with this patch we end up with an error. Since we shouldn't > ignore such error in UpdateSubscriptionRel

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-20 09:45:27 +0800, Craig Ringer wrote: > I frequently want to be able to use REPLICA IDENTITY DEFAULT, but also > record the whole old tuple not just keys, so they can be used in > conflict processing etc. What stops you from automatically using a candidate key if available? - Andres

Re: [HACKERS] REPLICA IDENTITY FULL

On 20 June 2017 at 06:53, Peter Eisentraut wrote: > On 6/18/17 23:11, Tatsuo Ishii wrote: >> While playing around with logical replication, I am confused by the >> behavior of REPLICA IDENTITY FULL. > >> However, if a table has text columns, UPDATE/DELETE replication does >> not work any more. Am

Re: [HACKERS] REPLICA IDENTITY FULL

On 20 June 2017 at 09:47, Andres Freund wrote: > On 2017-06-20 09:45:27 +0800, Craig Ringer wrote: >> I frequently want to be able to use REPLICA IDENTITY DEFAULT, but also >> record the whole old tuple not just keys, so they can be used in >> conflict processing etc. > > What stops you from autom

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

On 6/1/17 13:37, Petr Jelinek wrote: > On 01/06/17 17:32, Masahiko Sawada wrote: >> On Thu, May 25, 2017 at 5:29 PM, tushar >> wrote: >>> After applying all your patches, drop subscription no more hangs while >>> dropping subscription but there is an error "ERROR: tuple concurrently >>> upda

Re: [HACKERS] Something is rotten in publication drop

Peter Eisentraut writes: > If there are no new insights, I plan to proceed with the attached patch > tomorrow. This leaves the existing view and function alone, adds > pg_relation_is_publishable() and uses that in psql. Hm, patch looks okay, but while eyeballing it I started to wonder why in the

Re: [HACKERS] Rules on table partitions

Hi Dean, On 2017/06/19 20:19, Dean Rasheed wrote: > Currently we allow rules to be defined on table partitions, but these > rules only fire when the partition is accessed directly, not when it > is accessed via the parent: Yeah, the same thing as will happen with an inheritance setup, but I guess

Re: [HACKERS] PATCH: Batch/pipelining support for libpq

On Tue, Jun 20, 2017 at 10:43 AM, Craig Ringer wrote: > Especially with a 6-week-old baby now Congratulations! -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] REPLICA IDENTITY FULL

> Nothing, and that's what I do. I just think it's a bit fuzzy. Maybe > I'm misunderstanding the purpose of REPLICA IDENTITY, but I read it as > saying "this is the replication key for this relation". Yes, that's my understanding too. However, the feature may or may not work depending on the data

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-20 11:29:06 +0900, Tatsuo Ishii wrote: > > Nothing, and that's what I do. I just think it's a bit fuzzy. Maybe > > I'm misunderstanding the purpose of REPLICA IDENTITY, but I read it as > > saying "this is the replication key for this relation". > > Yes, that's my understanding too. How

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

On Tue, Jun 20, 2017 at 10:47 AM, Peter Eisentraut wrote: > On 6/16/17 04:16, Masahiko Sawada wrote: >> A subscription relation state may have been removed already when we >> try to update it. SetSubscriptionRelState didn't emit an error in such >> case but with this patch we end up with an error.

Re: [HACKERS] REPLICA IDENTITY FULL

>> Yes, that's my understanding too. However, the feature may or may not >> work depending on the data types of columns, probably I will not >> recommend users/my customers to use it. > > I'm not sure how datatypes are playing into this? For example, if the table consists of only INT types, REPLI

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-20 11:46:13 +0900, Tatsuo Ishii wrote: > >> Yes, that's my understanding too. However, the feature may or may not > >> work depending on the data types of columns, probably I will not > >> recommend users/my customers to use it. > > > > I'm not sure how datatypes are playing into this?

Re: [HACKERS] REPLICA IDENTITY FULL

>> For example, if the table consists of only INT types, REPLICA IDENTITY >> FULL works with UPDATE/DELETE (i.e. replicated), but if some of them >> are TEXT types, then UPDATE/DELETE does not work. >> >> See up thread for more details. > > Right, but that's just a bug, nothing else. If my under

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

On Tue, Jun 20, 2017 at 10:55 AM, Peter Eisentraut wrote: > On 6/1/17 13:37, Petr Jelinek wrote: >> On 01/06/17 17:32, Masahiko Sawada wrote: >>> On Thu, May 25, 2017 at 5:29 PM, tushar >>> wrote: After applying all your patches, drop subscription no more hangs while dropping subscri

Re: [HACKERS] Broken hint bits (freeze)

On Tue, Jun 20, 2017 at 03:50:29AM +0300, Sergey Burladyan wrote: > 20 июн. 2017 г. 1:21 пользователь "Bruce Momjian" написал:  > > > We are saying that Log-Shipping should match "Latest checkpoint > location", but the WAL for that will not be sent to the standby, so it > will not ma

[HACKERS] Fix a typo in partition.c

Hi, Attached patch for $subject. s/opreator/operator/ Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center fix_typo_in_partition_c.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] Broken hint bits (freeze)

On Mon, Jun 19, 2017 at 10:59:19PM -0400, Bruce Momjian wrote: > On Tue, Jun 20, 2017 at 03:50:29AM +0300, Sergey Burladyan wrote: > > 20 июн. 2017 г. 1:21 пользователь "Bruce Momjian" > > написал:  > > > > > > We are saying that Log-Shipping should match "Latest checkpoint > > location

Re: [HACKERS] Getting server crash on Windows when using ICU collation

Hi, On Tue, Jun 20, 2017 at 2:36 AM, Peter Eisentraut wrote: > On 6/19/17 00:42, Ashutosh Sharma wrote: >>> If we don't find unconv, isn't it better to fall back to non-UTF8 >>> version rather than saying command not found? >> Well, if any of the ICU package is installed on our system then we >>

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-20 11:52:10 +0900, Tatsuo Ishii wrote: > If my understanding is correct, it would not be easy to fix, no? > > > We might be able to refine that, but there is a general problem that > > without an index and an operator class, we are just doing our random > > best to match the values. I

Re: [JDBC] [HACKERS] Channel binding support for SCRAM-SHA-256

On Tue, Jun 6, 2017 at 3:40 PM, Michael Paquier wrote: > As far as I can see, there are a couple of things that I still need to > work on to make people happy: > - Rework the generic APIs for TLS finish and endpoint so as any > implementation can use channel binding without inducing any extra code

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

Hi Surafel, >Your patch doesn't cover security labels on databases which have similar issue >and consider dividing the patch into two one for adding CURRENT_DATABASE as a >database specifier and the other for adding database-level information to pg_dump output >in a way that allows to load a dump

  1   2   >