Обсуждение: Two pg_dump ugly bugs :-(

Поиск
Список
Период
Сортировка

Two pg_dump ugly bugs :-(

От
Constantin Teodorescu
Дата:
Found today two ugly bugs in pg_dump :

Environment : Linux i386 RedHat 5.2, 2.0.36 kernel, Pentium 233 MMX
Pg version  : PostgreSQL 6.4

1. It's easy reproductible :

(login as user teo, createdb rights granted)
$ createdb test
$ psql test
psql=> create table people (id int4, name text);
psql=> grant select on people to teo;
psql=> \q
$ pg_dump -z test
\connect - teo
CREATE TABLE "people" (       "id" "int4",       "name" "text");
REVOKE ALL on "people" from PUBLIC;
GRANT SELECT on "people" to "people";
...

The error is on the last line : grant select on people to PEOPLE ? Not
to teo ?

My pg_hba.conf is :
local  all                                  trust
host   all  127.0.0.1      255.255.255.255  trust
host   all  133.210.115.4  255.255.255.255  password
host   all  133.210.115.9  255.255.255.255  password 

---------------------------------------------------

2. Got a medium size database (640 Kb dumped) that I have recently moved
to Pg 6.4. After grant-ing and revoke-ing rights to various people,
dumping with :

pg_dump -z showroom >showroom.dmp

is dumping also core :-)

Looking into the showroom.dmp I noticed that it is dumping core when it
should start dumping data from tables.
Table structures (also table rights) , functions and sequences are
dumped corectly, when it should begin with table data, it dumpes core.
pg_dump without -z is working fine, database showroom is not broken,
everything is ok.


All the best and happy bug hunting !

Constantin Teodorescu
FLEX Consulting Braila, ROMANIA


Re: [HACKERS] Two pg_dump ugly bugs :-(

От
Tom Lane
Дата:
Constantin Teodorescu <teo@flex.ro> writes:
> Found today two ugly bugs in pg_dump :
> REVOKE ALL on "people" from PUBLIC;
> GRANT SELECT on "people" to "people";
> The error is on the last line : grant select on people to PEOPLE ? Not
> to teo ?

I fixed that one a week or so ago.

> pg_dump -z showroom >showroom.dmp
> is dumping also core :-)

Karl Auer reported the same thing, but I don't see it here.  Can you
provide a gdb backtrace, or perhaps a small sample database that
provokes the problem?
        regards, tom lane