Re: [HACKERS] Allow pg_dumpall to work without pg_authid

On Sun, 19 Feb 2017 at 10:08 Stephen Frost wrote: > If anything, it should use pg_roles, not pg_user. > > I don't really like the "--avoid-pgauthid" option, but "--no-passwords" > would probably work. > > Am sorry, I meant pg_roles (FWIW, the github URL given earlier uses

Re: [HACKERS] pg_get_object_address() doesn't support composites

On 2/17/17 9:53 PM, Alvaro Herrera wrote: Jim Nasby wrote: See below. ISTM that pg_get_object_address should support everything pg_identify_object_as_address can output, no? I'm guessing the answer here is to have pg_identify_object_as_address complain if you ask it for something that's not

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Sun, Feb 19, 2017 at 9:50 AM, Michael Paquier wrote: > I have been poking at it, and yeah... I missed the fact that > pg_subcription is not a view. I thought that check_conninfo was being > called in this context only.. Still, storing plain passwords in system

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Sun, Feb 19, 2017 at 8:05 AM, Petr Jelinek wrote: > It's not a view it's system catalog which actually stores the data, how > would it hide anything? I have been poking at it, and yeah... I missed the fact that pg_subcription is not a view. I thought that

Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.

On Sun, Feb 19, 2017 at 12:27 PM, Thomas Munro wrote: > On Sun, Feb 19, 2017 at 11:27 AM, Tom Lane wrote: >> Thomas Munro writes: >>> On Sat, Feb 18, 2017 at 5:41 AM, Tom Lane wrote:

Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.

On Sun, Feb 19, 2017 at 11:27 AM, Tom Lane wrote: > Thomas Munro writes: >> On Sat, Feb 18, 2017 at 5:41 AM, Tom Lane wrote: >>> Robert Haas writes: I'm thinking we should change this to look

Re: [HACKERS] Allow pg_dumpall to work without pg_authid

Greetings, * Robins Tharakan (thara...@gmail.com) wrote: > I would like to work on a patch to accommodate restricted environments > (such as AWS RDS Postgres) which don't allow pg_authid access since their > definition of Superuser is just a regular user with extra permissions. > > Would you

Re: [HACKERS] logical replication access control patches

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > 0002 Add PUBLICATION privilege > > Add a new privilege kind to tables to determine whether they can be > added to a publication. I'm not convinced that it really makes sense to have PUBLICATION of a table be independent from

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On 19/02/17 00:02, Michael Paquier wrote: > On Sat, Feb 18, 2017 at 11:57 PM, Petr Jelinek > wrote: >> On 15/02/17 05:56, Michael Paquier wrote: >>> I thought that this was correctly clobbered... But... No that's not >>> the case by looking at the code. And honestly

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On Sat, Feb 18, 2017 at 11:57 PM, Petr Jelinek wrote: > On 15/02/17 05:56, Michael Paquier wrote: >> I thought that this was correctly clobbered... But... No that's not >> the case by looking at the code. And honestly I think that it is >> unacceptable to show

Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.

Thomas Munro writes: > On Sat, Feb 18, 2017 at 5:41 AM, Tom Lane wrote: >> Robert Haas writes: >>> I'm thinking we should change this to look more like the >>> MemoryContextAlloc interface. >> +1 > Maybe something like

Re: [HACKERS] Keeping pg_recvlogical's "feTimestamp" separate from TimestampTz

I wrote: > I propose that what we need to do is get rid of the dangerous and > none-too-readable-anyway use of "int64" to declare replication-protocol > timestamps, and instead declare them as, say, > typedef struct RPTimestamp > { > int64 rptimestamp; > } RPTimestamp;

[HACKERS] Replication vs. float timestamps is a disaster

Both the streaming replication and logical replication areas of the code are, approximately, utterly broken when !HAVE_INT64_TIMESTAMPS. (The fact that "make check-world" passes anyway is an indictment of the quality of the regression tests.) I started poking around in this area after Thomas

Re: [HACKERS] [COMMITTERS] pgsql: Add new function dsa_allocate0.

On Sat, Feb 18, 2017 at 5:41 AM, Tom Lane wrote: > Robert Haas writes: >> I'm thinking we should change this to look more like the >> MemoryContextAlloc interface. Let's have DSA_ALLOC_HUGE, >> DSA_ALLOC_NO_OOM, and DSA_ALLOC_ZERO, just like the

[HACKERS] Allow pg_dumpall to work without pg_authid

Hi, I would like to work on a patch to accommodate restricted environments (such as AWS RDS Postgres) which don't allow pg_authid access since their definition of Superuser is just a regular user with extra permissions. Would you consider a patch to add a flag to work around this restriction,

Re: [HACKERS] Instability in select_parallel regression test

Robert Haas writes: > On Fri, Feb 17, 2017 at 9:57 PM, Amit Kapila wrote: >>> That seems like a seriously broken design to me, first because it can make >>> for a significant delay in the slots becoming available (which is what's >>> evidently

Re: [HACKERS] new gcc 7.0.1 warnings

2017-02-18 18:35 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > float.c:382:5: note: ‘snprintf’ output between 2 and 311 bytes into a > > destination of size 65 > > float.c:618:5: note: ‘snprintf’ output between 2 and 311 bytes into a > >

Re: [HACKERS] new gcc 7.0.1 warnings

Pavel Stehule writes: > float.c:382:5: note: ‘snprintf’ output between 2 and 311 bytes into a > destination of size 65 > float.c:618:5: note: ‘snprintf’ output between 2 and 311 bytes into a > destination of size 129 That's kind of annoying. I suppose the point is that

Re: [HACKERS] Instability in select_parallel regression test

On Fri, Feb 17, 2017 at 9:57 PM, Amit Kapila wrote: >> That seems like a seriously broken design to me, first because it can make >> for a significant delay in the slots becoming available (which is what's >> evidently causing these regression failures), and second

Re: [HACKERS] Parallel bitmap heap scan

On Fri, Feb 17, 2017 at 2:01 AM, Robert Haas wrote: > + * in order to share relptrs of the chunk and the pages arrays and other > + * TBM related information with other workers. > > No relptrs any more. Fixed > > +dsa_pointer dsapagetable;/* dsa_pointer to the

[HACKERS] Suppressing that pesky warning with older flex versions

While experimenting with enabling -Werror in the buildfarm, I got annoyed about the fact that we have to apply -Wno-error while building some of the flex scanners, because with flex versions before 2.5.36 you get scan.c: In function 'yy_try_NUL_trans': scan.c:10317: warning: unused variable 'yyg'

Re: [HACKERS] "SQL sentence"?

On 2/17/17 10:46 PM, Alvaro Herrera wrote: Sure. We have the extension that turned the command into JSON. It's still an unfinished patch, sadly, even though Alex Shulgin spent a lot of effort trying to get it finished. It is still missing a nontrivial amount of work, but within reach ISTM.

Re: [HACKERS] Provide list of subscriptions and publications in psql's completion

On 15/02/17 05:56, Michael Paquier wrote: > On Wed, Feb 15, 2017 at 3:18 AM, Jim Nasby wrote: >> Why not do what we do for pg_stat_activity.current_query and leave it NULL >> for non-SU? > > If subcriptions are designed to be superuser-only, it seems fair to me > to do

Re: [pgsql-www] [HACKERS] Small issue in online devel documentation build

Hello Magnus, It turns out the "c2" class is added by tidy. The reason is this: http://api.html-tidy.org/tidy/quickref_5.0.0.html#clean I've removed the flag for the devel docs build for now (or - for any XML based docs build). I've also forced another docs load, so the results can be

Re: [HACKERS] Logical replication existing data copy

On 18/02/17 14:17, Erik Rijkers wrote: > On 2017-02-16 00:43, Petr Jelinek wrote: >> On 13/02/17 14:51, Erik Rijkers wrote: >>> On 2017-02-11 11:16, Erik Rijkers wrote: On 2017-02-08 23:25, Petr Jelinek wrote: > 0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch >

Re: [HACKERS] Logical replication existing data copy

On 18/02/17 14:24, Erik Rijkers wrote: >> >> Maybe add this to the 10 Open Items list? >> https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items >> >> It may garner a bit more attention. >> > > Ah sorry, it's there already. Hmm that's interesting given that it's not even committed yet :)

Re: [HACKERS] Logical replication existing data copy

On 2017-02-11 11:16, Erik Rijkers wrote: On 2017-02-08 23:25, Petr Jelinek wrote: 0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch 0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch 0003-Fix-after-trigger-execution-in-logical-replication-v2.patch

Re: [HACKERS] Logical replication existing data copy

Maybe add this to the 10 Open Items list? https://wiki.postgresql.org/wiki/PostgreSQL_10_Open_Items It may garner a bit more attention. Ah sorry, it's there already. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription:

Re: [HACKERS] Logical replication existing data copy

On 2017-02-16 00:43, Petr Jelinek wrote: On 13/02/17 14:51, Erik Rijkers wrote: On 2017-02-11 11:16, Erik Rijkers wrote: On 2017-02-08 23:25, Petr Jelinek wrote: 0001-Use-asynchronous-connect-API-in-libpqwalreceiver-v2.patch 0002-Always-initialize-stringinfo-buffers-in-walsender-v2.patch

Re: [HACKERS] Gather Merge

On Fri, Feb 17, 2017 at 6:27 PM, Rushabh Lathia wrote: > On Fri, Feb 17, 2017 at 4:47 PM, Amit Kapila > wrote: >> >> Are you suggesting that commit 0c2070ce has helped to improve >> performance if so, I don't think that has been proved? I guess

Re: [HACKERS] Help text for pg_basebackup -R

On Fri, Feb 17, 2017 at 5:21 PM, Tom Lane wrote: > Stephen Frost writes: > > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > >> Magnus Hagander wrote: > >>> I'm guessing if we backpatch something like that, it would cause > issues for > >>>

[HACKERS] [PATCH] Incremental sort (was: PoC: Partial sort)

Hi all! I decided to start new thread for this patch for following two reasons. * It's renamed from "Partial sort" to "Incremental sort" per suggestion by Robert Haas [1]. New name much better characterizes the essence of algorithm. * I think it's not PoC anymore. Patch received several