[HACKERS] Typos in comments

Spotted one “paramter” typo and git grep found two more, patch attached with s/paramter/parameter/ for these. cheers ./daniel typo-paramter.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.pos

Re: [HACKERS] psql - add special variable to reflect the last query status

I have not any other comments. The implementation is trivial. I rerun all tests and tests passed. I'll mark this patch as ready for commiters. Oops, I just noticed a stupid confusion on my part which got through, I was setting "ERROR" as "success", inverting the expected boolean value. Her

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

On Sat, Jun 17, 2017 at 6:57 AM, Peter Eisentraut wrote: > On 6/16/17 10:12, Peter Eisentraut wrote: >> On 6/16/17 06:30, Amit Kapila wrote: >>> How will this compare UTF-8 strings in UTF-8 encoding? It seems to me >>> that ideally, it should use ucol_strcollUTF8 to compare the same, >>> however,

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

On Fri, Jun 16, 2017 at 7:42 PM, Peter Eisentraut wrote: > On 6/16/17 06:30, Amit Kapila wrote: >> How will this compare UTF-8 strings in UTF-8 encoding? It seems to me >> that ideally, it should use ucol_strcollUTF8 to compare the same, >> however, with patch, it will always ucol_strcoll as we n

Re: [HACKERS] Broken hint bits (freeze)

On Fri, Jun 16, 2017 at 11:03 PM, Sergey Burladyan wrote: > Bruce Momjian writes: > >> On Fri, Jun 16, 2017 at 08:10:13PM +0530, Amit Kapila wrote: >> > On Fri, Jun 16, 2017 at 7:03 AM, Sergey Burladyan >> > wrote: >> > > Bruce Momjian writes: >> > > >> > >> ! against the old primary and

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

Hi, On Sat, Jun 17, 2017 at 6:57 AM, Peter Eisentraut wrote: > On 6/16/17 10:12, Peter Eisentraut wrote: >> On 6/16/17 06:30, Amit Kapila wrote: >>> How will this compare UTF-8 strings in UTF-8 encoding? It seems to me >>> that ideally, it should use ucol_strcollUTF8 to compare the same, >>> how

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

Piotr Stefaniak writes: > On 2017-06-17 00:02, Tom Lane wrote: >> What I'm testing with right now has just four differences from your repo: > There are also the "portability fixes" and they're the main problem. Fair enough. > I've simply removed things like capsicum or __FBSDID() because I thou

Re: [HACKERS] how are the rpms configured that are available in PostgreSQL RPM Building Project - Yum Repository

On Fri, Jun 16, 2017 at 12:40 PM, Cook, Malcolm wrote: > Hi, > > > > I am referring to the contents of https://yum.postgresql.org/ > (specifically version 9.6 rpms for CentoOS7) > > > > More specifically I wonder if they are configured:--with-python > --with-tcl --with-pam --with-ldap > > > >

Re: [HACKERS] [BUGS] BUG #14699: Statement trigger and logical replication

On Sat, Jun 17, 2017 at 1:22 PM, Andres Freund wrote: > On 2017-06-16 21:08:44 -0400, Peter Eisentraut wrote: >> On 6/16/17 09:13, Константин Евтеев wrote: >> > 2017-06-13 5:57 GMT+03:00 Peter Eisentraut >> > > > >: >> > >> > I think this is all working

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

On 6/16/17 10:12, Peter Eisentraut wrote: > On 6/16/17 06:30, Amit Kapila wrote: >> How will this compare UTF-8 strings in UTF-8 encoding? It seems to me >> that ideally, it should use ucol_strcollUTF8 to compare the same, >> however, with patch, it will always ucol_strcoll as we never define >> H

Re: [HACKERS] [BUGS] BUG #14699: Statement trigger and logical replication

On 2017-06-16 21:08:44 -0400, Peter Eisentraut wrote: > On 6/16/17 09:13, Константин Евтеев wrote: > > 2017-06-13 5:57 GMT+03:00 Peter Eisentraut > > > >: > > > > I think this is all working correctly and as intended. > > > > But then, why data copy f

Re: [HACKERS] [BUGS] BUG #14699: Statement trigger and logical replication

On 6/16/17 09:13, Константин Евтеев wrote: > 2017-06-13 5:57 GMT+03:00 Peter Eisentraut > >: > > I think this is all working correctly and as intended. > > But then, why data copy for init logical replication fires statement > trigger. May be it is al

Re: [HACKERS] Restrictions of logical replication

On 6/16/17 10:59, Tatsuo Ishii wrote: >> Docs stated "Publications can choose to limit the changes they produce to >> any combination of INSERT, UPDATE, and DELETE". It is clear that only those >> DMLs are supported. > > What about COPY? Sure, added note about that as well. -- Peter Eisentraut

Re: [HACKERS] Restrictions of logical replication

>> Some of that information was sprinkled around, but I have now added a >> new section that collects them all in one place. (section 31.4) > > > Shouldn't we mention that COPY is supported? I think any commands that are not mentioned in the section are considered to be supported. Best regards

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

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 > table, policy of parent is not getting applied. But is

[HACKERS] how are the rpms configured that are available in PostgreSQL RPM Building Project - Yum Repository

Hi, I am referring to the contents of https://yum.postgresql.org/ (specifically version 9.6 rpms for CentoOS7) More specifically I wonder if they are configured:--with-python --with-tcl --with-pam --with-ldap And do they install the Additional Supplied Modules (https://www.postgresql.org/

[HACKERS] Incorrect comment in 001_ssltests.pl

Hi all, I have noticed the following thing: --- a/src/test/ssl/t/001_ssltests.pl +++ b/src/test/ssl/t/001_ssltests.pl @@ -34,8 +34,6 @@ sub run_test_psql # The first argument is a (part of a) connection string, and it's also printed # out as the test case name. It is appended to $common_connstr

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

On 2017-06-17 00:02, Tom Lane wrote: > Piotr Stefaniak writes: >> On 2017-06-16 21:56, Tom Lane wrote: >>> Unless Piotr objects, I propose to add another switch to bsdindent >>> that selects this behavior, and then we can drop entab, removing >>> another impediment to getting pgindent working. >

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

Piotr Stefaniak writes: > On 2017-06-16 21:56, Tom Lane wrote: >> Unless Piotr objects, I propose to add another switch to bsdindent >> that selects this behavior, and then we can drop entab, removing >> another impediment to getting pgindent working. > I understand the reasoning, but this is a v

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

Piotr Stefaniak writes: > On 2017-06-16 20:11, Tom Lane wrote: >> I assume though that Piotr wants an option to preserve that behavior. >> I'm happy to write up a patch for bsdindent that adds a switch >> controlling this, but is there any rhyme or reason to the way its >> switches are named? > I

Re: [HACKERS] Restrictions of logical replication

2017-06-16 11:03 GMT-03:00 Peter Eisentraut < peter.eisentr...@2ndquadrant.com>: > > > Some of that information was sprinkled around, but I have now added a > new section that collects them all in one place. (section 31.4) Shouldn't we mention that COPY is supported? -- Euler Taveira

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

On 2017-06-16 20:11, Tom Lane wrote: > Andres Freund writes: >> On 2017-06-16 13:44:30 -0400, Bruce Momjian wrote: >>> Yes, it is all about <80 column output. The current pgindent does >>> everything possible to accomplish that --- the question is whether we >>> want uglier code to do it. > >> F

Re: [HACKERS] Broken hint bits (freeze)

On Fri, Jun 16, 2017 at 04:44:46PM -0400, Bruce Momjian wrote: > Yes, that is _exactly_ the right place to look. Only in PG 10 do we > restart the new cluster to invalidate hash indexes. In previous > releases we didn't do the restart. > > That didn't matter with the old rsync instructions, but

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

On 2017-06-16 21:56, Tom Lane wrote: > One other thing I'd like to do while we're changing this stuff is > to get rid of the need for entab/detab. Right now, after doing > all the other work, my copy of pgindent is running the code through > detab and then entab so as to match the old decisions ab

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

On Fri, Jun 16, 2017 at 03:56:47PM -0400, Tom Lane wrote: > can be. I managed to tweak bsdindent so that its output matches > what entab would do, by dint of the attached patch, which implements > the rule "use a space instead of a tab if the tab would only move > one column and we don't need anot

Re: [HACKERS] Broken hint bits (freeze)

Bruce Momjian writes: > On Fri, Jun 16, 2017 at 04:33:16AM +0300, Sergey Burladyan wrote: > > Bruce Momjian writes: > > > ! > > > ! Also, if upgrading standby servers, change wal_level > > > ! to replica in the postgresql.conf file on > > > ! the new cluster. > > > > >

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

One other thing I'd like to do while we're changing this stuff is to get rid of the need for entab/detab. Right now, after doing all the other work, my copy of pgindent is running the code through detab and then entab so as to match the old decisions about how to represent whitespace (ie, as space

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

On Fri, Jun 16, 2017 at 11:54:06AM -0700, Andres Freund wrote: > On 2017-06-16 14:42:38 -0400, Bruce Momjian wrote: > > On Fri, Jun 16, 2017 at 02:23:00PM -0400, Tom Lane wrote: > > > Well, that's something we need to discuss. I originally argued for > > > back-patching the new rules, whatever the

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

On 2017-06-16 14:42:38 -0400, Bruce Momjian wrote: > On Fri, Jun 16, 2017 at 02:23:00PM -0400, Tom Lane wrote: > > Well, that's something we need to discuss. I originally argued for > > back-patching the new rules, whatever they are (ie, run the new > > pgindent on the back branches whenever we've

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

On Fri, Jun 16, 2017 at 02:23:00PM -0400, Tom Lane wrote: > Well, that's something we need to discuss. I originally argued for > back-patching the new rules, whatever they are (ie, run the new > pgindent on the back branches whenever we've agreed that the dust > has settled). But I'm starting to

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

Andres Freund writes: > On 2017-06-16 13:34:01 -0400, Tom Lane wrote: >> I do intend to apply the diffs to HEAD in multiple steps, just to >> make them more reviewable. But I think we should probably absorb >> all the changes we want into v10, not leave some for later cycles. > Btw, how much are

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

Andres Freund writes: > On 2017-06-16 13:44:30 -0400, Bruce Momjian wrote: >> Yes, it is all about <80 column output. The current pgindent does >> everything possible to accomplish that --- the question is whether we >> want uglier code to do it. > For me personally the misindentation is way ugl

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

On 2017-06-16 13:34:01 -0400, Tom Lane wrote: > > I could live with both of these proposed > > changes, the selection of the changes you posted looks like it could be > > improved by code changes, but that's obviously a large amount of work. > > In the end, the only thing that fixes this sort of s

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

On 2017-06-16 13:44:30 -0400, Bruce Momjian wrote: > On Fri, Jun 16, 2017 at 01:34:01PM -0400, Tom Lane wrote: > > > I could live with both of these proposed > > > changes, the selection of the changes you posted looks like it could be > > > improved by code changes, but that's obviously a large am

Re: [HACKERS] pg_waldump command line arguments

On 2017-06-15 17:08:23 -0400, Robert Haas wrote: > pg_waldump --help claims that you run it like this: > > Usage: > pg_waldump [OPTION]... [STARTSEG [ENDSEG]] > > And https://www.postgresql.org/docs/10/static/pgwaldump.html agrees. > Since square brackets indicate optional arguments, this sort

Re: [HACKERS] Why forcing Hot_standby_feedback to be enabled when creating a logical decoding slot on standby

Hi, On 2017-06-16 06:31:03 +, sanyam jain wrote: > Isn't XLogRecord carries full information to be decoded in itself?If so a > VACCUM should not be a problem in decoding? First: Please don't full quote emails. Secondly: You've not actually explained what you want to do, nor what your precise

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

On 2017-06-15 09:43:13 -0400, Tom Lane wrote: > Satyanarayana Narlapuram writes: > > As a cloud service, Azure Database for PostgreSQL uses a gateway proxy to > > route connections to a node hosting the actual server. To do that, the > > proxy needs to know the name of the server it tries to loc

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

On Fri, Jun 16, 2017 at 01:34:01PM -0400, Tom Lane wrote: > > I could live with both of these proposed > > changes, the selection of the changes you posted looks like it could be > > improved by code changes, but that's obviously a large amount of work. > > In the end, the only thing that fixes th

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

On Fri, Jun 16, 2017 at 5:31 AM, Marina Polyakova wrote: > And thank you very much for your explanation how and why transactions with > failures should be retried! I'll try to implement all of it. To be clear, part of "retrying from the beginning" means that if a result from one statement is use

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

Andres Freund writes: > I think the current logic is pretty horrible, primarily because it's so > hard to get to manually. Yes, I think that's really the big argument against it: no editor on the face of the planet will indent code that way to start with. > I could live with both of these propos

Re: [HACKERS] Broken hint bits (freeze)

Bruce Momjian writes: > On Fri, Jun 16, 2017 at 08:10:13PM +0530, Amit Kapila wrote: > > On Fri, Jun 16, 2017 at 7:03 AM, Sergey Burladyan > > wrote: > > > Bruce Momjian writes: > > > > > >> ! against the old primary and standby clusters. Verify that the > > >> ! Latest checkpoint l

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

Hi, On 2017-06-16 13:10:50 -0400, Tom Lane wrote: > I experimented with disabling that logic and just always aligning > to the paren indentation. That fixes the weird cases with continued > string literals, but it also makes for a heck of a lot of other changes. > The full diff is too big to post

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

There was some discussion upthread about how we'd like pgindent not to do weird things with string literals that wrap around the end of the line a little bit. I looked into that and found that it's actually a generic behavior for any line that's within parentheses: normally, such a line will get l

[HACKERS] Re: [HACKERS] 答复: GiST API Adancement

2017-06-16 17:06 GMT+03:00 Tom Lane : > Yuan Dong writes: >> ·¢¼þÈË: Andrew Borodin >>> I think there is one more aspect of development: backward >>> compatibility: it's impossible to update all existing extensions. This >>> is not that major feature to ignore them. > >> I should still maintain o

Re: [HACKERS] Broken hint bits (freeze)

On Fri, Jun 16, 2017 at 08:10:13PM +0530, Amit Kapila wrote: > On Fri, Jun 16, 2017 at 7:03 AM, Sergey Burladyan wrote: > > Bruce Momjian writes: > > > >> ! against the old primary and standby clusters. Verify that the > >> ! Latest checkpoint location values match in all clusters. > >

Re: [HACKERS] Broken hint bits (freeze)

On Fri, Jun 16, 2017 at 04:33:16AM +0300, Sergey Burladyan wrote: > Bruce Momjian writes: > > ! > > ! Also, if upgrading standby servers, change wal_level > > ! to replica in the postgresql.conf file on > > ! the new cluster. > > > > > > I am not sure how this hel

Re: [HACKERS] ASOF join

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 refereeing KDB definition: > > http://

Re: [HACKERS] WIP: Data at rest encryption

On Fri, Jun 16, 2017 at 11:06:39AM +0300, Konstantin Knizhnik wrote: > Encryption is much easier to implement than compression, because it is not > changing page size. So I do not see any "complexity and flexibility > challenges" here. > Just for reference I attached to this mail our own encryption

Re: [HACKERS] WIP: Data at rest encryption

On Thu, Jun 15, 2017 at 08:08:05PM -0400, Bruce Momjian wrote: > On Thu, Jun 15, 2017 at 04:56:36PM -0700, Andres Freund wrote: > > how few concerns about this feature's complexity / maintainability > > impact have been raised. > > Yeah, I guess we will just have to wait to see it since other peop

Re: [HACKERS] Restrictions of logical replication

> Docs stated "Publications can choose to limit the changes they produce to > any combination of INSERT, UPDATE, and DELETE". It is clear that only those > DMLs are supported. What about COPY? > However, we should mention that large objects are not > supported. Right. Best regards, -- Tatsuo Is

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

Peter Eisentraut writes: > On 5/19/17 13:31, Alvaro Herrera wrote: >> I favor having indent in a separate repository in our Git server, for >> these reasons > I am also in favor of that. >> 0. it's under our control (so we can change rules as we see fit) >> 1. we can have Piotr as a committer th

Re: [HACKERS] Broken hint bits (freeze)

On Fri, Jun 16, 2017 at 7:03 AM, Sergey Burladyan wrote: > Bruce Momjian writes: > >> ! against the old primary and standby clusters. Verify that the >> ! Latest checkpoint location values match in all clusters. > > For "Log-Shipping only" standby server this cannot be satisfied, becau

Re: [HACKERS] Restrictions of logical replication

> On 6/16/17 03:00, Tatsuo Ishii wrote: >> Maybe I am missing something, but I could not find any description >> that logical replication does not support large objects and TRUNCATE >> in the doc. Do we want to add them to the doc as the restrictions of >> the logical replication? > > Some of tha

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

On 6/16/17 06:30, Amit Kapila wrote: > How will this compare UTF-8 strings in UTF-8 encoding? It seems to me > that ideally, it should use ucol_strcollUTF8 to compare the same, > however, with patch, it will always ucol_strcoll as we never define > HAVE_UCOL_STRCOLLUTF8 flag on Windows. We have a

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

On 6/15/17 13:48, Ashutosh Sharma wrote: >> Maybe just >> >> diff --git a/src/backend/utils/adt/varlena.c >> b/src/backend/utils/adt/varlena.c >> index a0dd391f09..2506f4eeb8 100644 >> --- a/src/backend/utils/adt/varlena.c >> +++ b/src/backend/utils/adt/varlena.c >> @@ -1433,7 +1433,7 @@ varstr_cm

Re: [HACKERS] 答复: GiST API Adancement

Yuan Dong writes: > ·¢¼þÈË: Andrew Borodin >> I think there is one more aspect of development: backward >> compatibility: it's impossible to update all existing extensions. This >> is not that major feature to ignore them. > I should still maintain original API of GiST after modification. To pu

Re: [HACKERS] Restrictions of logical replication

On 6/16/17 03:00, Tatsuo Ishii wrote: > Maybe I am missing something, but I could not find any description > that logical replication does not support large objects and TRUNCATE > in the doc. Do we want to add them to the doc as the restrictions of > the logical replication? Some of that informat

Re: [HACKERS] Restrictions of logical replication

2017-06-16 4:00 GMT-03:00 Tatsuo Ishii : > Maybe I am missing something, but I could not find any description > that logical replication does not support large objects and TRUNCATE > in the doc. Do we want to add them to the doc as the restrictions of > the logical replication? > Docs stated "Pu

Re: [HACKERS] Shortened URLs for commit messages

On Thu, Jun 15, 2017 at 01:05:19PM -0400, Bruce Momjian wrote: > On Tue, May 23, 2017 at 11:25:07PM -0400, Bruce Momjian wrote: > > I have written the following sed script to convert regular Postgres > > email message URLs to their shorter form for commit messages: > > > > sed > > 's;http\(s\?\)

[HACKERS] 答复: GiST API Adancement

Hi Andrey, Thank you for your suggestion. I should still maintain original API of GiST after modification. -- Dong 发件人: Andrew Borodin 发送时间: 2017年6月16日 6:24:03 收件人: Yuan Dong 抄送: pgsql-hackers@postgresql.org 主题: Re: GiST API Adancement Hi, Dong! 2017-0

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On 2017/06/16 19:26, Ashutosh Bapat wrote: On Fri, Jun 16, 2017 at 3:35 PM, Etsuro Fujita Ashutosh mentioned his concern about what I proposed above before [2], but I'm not sure we should address that. And there have been no opinions from him (or anyone else) since then. So, I'd like to leave

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On 2017/06/16 19:26, Ashutosh Bapat wrote: Also, I don't see any discussion about my concern [3] about a parent with child from multiple foreign servers with different FDWs. So, I am not sure whether the patch really fixes the problem in its entirety. The patch would allow child tables to have

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

>> P.S. Does this use case (do not retry transaction with serialization or >> deadlock failure) is most interesting or failed transactions should be >> retried (and how much times if there seems to be no hope of success...)? > > I can't quite parse that sentence, could you restate? The way I read

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

P.S. Does this use case (do not retry transaction with serialization or deadlock failure) is most interesting or failed transactions should be retried (and how much times if there seems to be no hope of success...)? I can't quite parse that sentence, could you restate? The way I read it was

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

On Thu, Jun 15, 2017 at 11:18 PM, Ashutosh Sharma wrote: > Hi, > > On Thu, Jun 15, 2017 at 8:36 PM, Peter Eisentraut > wrote: >> On 6/12/17 00:38, Ashutosh Sharma wrote: >>> PFA patch that fixes the issue described in above thread. As mentioned >>> in the above thread, the crash is basically happ

Re: [HACKERS] WIP Patch: Pgbench Serialization and deadlock errors

Hi, Hello! I think that's a good idea and sorely needed. Thanks, I'm very glad to hear it! - if there were these failures during script execution this "transaction" is marked appropriately in logs; - numbers of "transactions" with these failures are printed in progress, in aggregation l

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On Fri, Jun 16, 2017 at 3:35 PM, Etsuro Fujita wrote: > On 2017/06/16 0:05, Ildus Kurbangaliev wrote: > > > I wrote: > > One approach I came up with to fix this issue is to rewrite the > targetList entries of an inherited UPDATE/DELETE properly using > rewriteTargetListUD, when gen

[HACKERS] GSoC 2017 : Patch for predicate locking in Gist index

Hi, hackers! I have created my first patch for predicate locking in gist index. It includes a test for verification of serialization failures and a test to check false positives. I am submitting my patch little late because there were some issues with "make check" that I was trying to solve. Now,

Re: [HACKERS] Bug in ExecModifyTable function and trigger issues for foreign tables

On 2017/06/16 0:05, Ildus Kurbangaliev wrote: I wrote: One approach I came up with to fix this issue is to rewrite the targetList entries of an inherited UPDATE/DELETE properly using rewriteTargetListUD, when generating a plan for each child table in inheritance_planner. Attached is a WIP patch

Re: [HACKERS] Restrictions of logical replication

Hi Tatsuo, On Fri, Jun 16, 2017 at 04:00:56PM +0900, Tatsuo Ishii wrote: > Maybe I am missing something, but I could not find any description > that logical replication does not support large objects and TRUNCATE > in the doc. Do we want to add them to the doc as the restrictions of > the logical

Re: [HACKERS] pg_waldump command line arguments

On Fri, Jun 16, 2017 at 2:38 AM, Robert Haas wrote: > > A slightly broader concern is whether we need to require the start > position at all. It seems like one could locate the WAL directory > using the existing logic, then search for the earliest file. It might > be a little unclear what "earli

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

On Thu, Jun 15, 2017 at 10:22 AM, Masahiko Sawada wrote: > On Thu, Jun 15, 2017 at 7:35 AM, Petr Jelinek > wrote: >> On 13/06/17 21:49, Peter Eisentraut wrote: >>> On 6/13/17 02:33, Noah Misch wrote: > Steps to reproduce - > X cluster -> create 100 tables , publish all tables (create pub

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

Hello, I'd like to review this but it doesn't fit the master, as Robert said. Especially the interface of predicate_implied_by is changed by the suggested commit. Anyway I have some comment on this patch with fresh eyes. I believe the basic design so my comment below are from a rather micro viewp

Re: [HACKERS] WIP: Data at rest encryption

On 16.06.2017 03:08, Bruce Momjian wrote: Yeah, I guess we will just have to wait to see it since other people are excited about it. My concern is code complexity and usability challenges, vs punting the problem to the operating system, though admittedly there are some cases where that is not

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

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 table, policy of parent is not getting applied. But is this desirable behaviour? I think for partitions, any policy on the root

Re: [HACKERS] logical replication: \dRp+ and "for all tables"

On Thu, Jun 15, 2017 at 11:49 PM, Peter Eisentraut wrote: > On 6/10/17 02:02, Jeff Janes wrote: >> On Fri, Jun 9, 2017 at 10:20 PM, Masahiko Sawada > > wrote: >> >> On Sat, Jun 10, 2017 at 7:29 AM, Jeff Janes > > wrote: >> > If

Re: [HACKERS] Support to COMMENT ON DATABASE CURRENT_DATABASE

On Mon, Jun 5, 2017 at 4:09 AM, Jing Wang wrote: > Hi all, > > The attached patch is to support the feature "COMMENT ON DATABASE > CURRENT_DATABASE". The solution is based on the previous discussion in [2] . > Your patch doesn't cover security labels on databases which have similar issue and con

[HACKERS] Restrictions of logical replication

Maybe I am missing something, but I could not find any description that logical replication does not support large objects and TRUNCATE in the doc. Do we want to add them to the doc as the restrictions of the logical replication? Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://w