On Fri, Nov 14, 2014 at 2:51 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Thu, Nov 13, 2014 at 6:32 PM, Tom Lane wrote:
>> > What's bothering me is that I see this in pg_dumpall output from a 9.4
>> > or earlier database:
>> >
>> > ALTER ROLE postgres WITH SUPERUS
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Nov 13, 2014 at 6:32 PM, Tom Lane wrote:
> > What's bothering me is that I see this in pg_dumpall output from a 9.4
> > or earlier database:
> >
> > ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN
> > REPLICATION NOBYPASS
On Thu, Nov 13, 2014 at 6:32 PM, Tom Lane wrote:
> What's bothering me is that I see this in pg_dumpall output from a 9.4
> or earlier database:
>
> ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN
> REPLICATION NOBYPASSRLS;
What about leaving out NOBYPASSRLS and letting it g
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> What's bothering me is that I see this in pg_dumpall output from a 9.4
> or earlier database:
>
> ALTER ROLE postgres WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN
> REPLICATION NOBYPASSRLS;
Ah, yeah, good point.
> That means that if you do a pg_upgra
On 2014-11-13 18:24:53 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2014-11-13 18:00:45 -0500, Stephen Frost wrote:
> >> Err. That might have come off poorly- I didn't mean that sarcastically
> >> but was really wondering how far back you test (or how far back we
> >> feel pg_dumpall nee
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Actually, I think that code is not just under-tested but poorly thought
>> out. It will dump ALL roles from a pre-9.5 database with NOBYPASSRLS;
>> even superusers.
> Superusers are always considered to have it, regardless of if t
Andres Freund writes:
> On 2014-11-13 18:00:45 -0500, Stephen Frost wrote:
>> Err. That might have come off poorly- I didn't mean that sarcastically
>> but was really wondering how far back you test (or how far back we
>> feel pg_dumpall needs to work against..).
> pg_dump currently errors out b
On 2014-11-13 18:00:45 -0500, Stephen Frost wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > I'm happy to fix it either way (and fix it for 8.1, and back to.. what?
> > Postgres95?)
>
> Err. That might have come off poorly- I didn't mean that sarcastically
> but was really wondering how f
* Stephen Frost (sfr...@snowman.net) wrote:
> I'm happy to fix it either way (and fix it for 8.1, and back to.. what?
> Postgres95?)
Err. That might have come off poorly- I didn't mean that sarcastically
but was really wondering how far back you test (or how far back we
feel pg_dumpall needs to w
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Gilles Darold writes:
> > In the same query there is another bug introduced by commit 491c029
> > that add Row-Level Security Policies. Current master code has a broken
> > pg_dumpall when trying to dump from a backend lower than 8.1.
>
> Actually, I thin
Gilles Darold writes:
> In the same query there is another bug introduced by commit 491c029
> that add Row-Level Security Policies. Current master code has a broken
> pg_dumpall when trying to dump from a backend lower than 8.1.
Actually, I think that code is not just under-tested but poorly tho
Gilles Darold writes:
> There's a segfault when trying to dump global object from a running
> 7.4.27 with a pg_dumpall of version 9.3.5 but also 9.2.9.
Hm ... I make a practice of checking pg_dump's backwards compatibility
from time to time, but I confess I've not tested pg_dumpall lately.
Will t
Hi,
There's a segfault when trying to dump global object from a running
7.4.27 with a pg_dumpall of version 9.3.5 but also 9.2.9.
$ pg_dumpall -g -h localhost -p 5474
column number -1 is out of range 0..12
Segmentation fault (core dumped)
The problem comes from the first columns of the
13 matches
Mail list logo
