
Morning all...

	Am looking at a v6.4 system, and if I do:

select relname from pg_class;

	It returns all the relations...but if I do:

select relname,relacl from pg_class;

	It gives me:

pqReadData() -- backend closed the channel unexpectedly.
        This probably means the backend terminated abnormally before or
while processing the request. We have lost the connection to the backend,
so further processing is impossible.  Terminating.

	Still investigating, but if anyone has any suggestions, I'm all
ears...

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Thu, 2 Sep 1999 10:49:47 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Odd problem with pg_class ...

Okay, figured it out...

The problem exists in v6.5.x as well.

Basically, the user had, it seems, accidentally deleted various groups
from pg_group, which he had used to GRANT group permissions on various
tables, causing an error message of:

NOTICE:  get_groname: group 185 not found

to be printed to his errlog.

In v6.5.x, you at least get something out through psql when you do this,
but should we get:

==========================
 | status           | {"=","group keystone=arwR"} |
 +------------------+-----------------------------+
pgsql_keystone=> delete from pg_group where groname='keystone';
DELETE 1
pgsql_keystone=> \z
NOTICE:  get_groname: group 0 not found
pqReadData() -- backend closed the channel unexpectedly.
        This probably means the backend terminated abnormally
        before or while processing the request.
===========================

Doesn't sound very "friendly"...


On Thu, 2 Sep 1999, The Hermit Hacker wrote:

> 
> Morning all...
> 
> 	Am looking at a v6.4 system, and if I do:
> 
> select relname from pg_class;
> 
> 	It returns all the relations...but if I do:
> 
> select relname,relacl from pg_class;
> 
> 	It gives me:
> 
> pqReadData() -- backend closed the channel unexpectedly.
>         This probably means the backend terminated abnormally before or
> while processing the request. We have lost the connection to the backend,
> so further processing is impossible.  Terminating.
> 
> 	Still investigating, but if anyone has any suggestions, I'm all
> ears...
> 
> Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
> Systems Administrator @ hub.org 
> primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 
> 
> 
> ************
> 

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org 
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org 


Thu, 2 Sep 1999 11:13:40 -0300 (ADT)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] Odd problem with pg_class ...
The Hermit Hacker <scrappy@hub.org> writes:
> 	Am looking at a v6.4 system, and if I do:
> select relname from pg_class;
> 	It returns all the relations...but if I do:
> select relname,relacl from pg_class;
> 	It gives me:
> pqReadData() -- backend closed the channel unexpectedly.

I do not see this on my 6.4 setup.  Possibly you have inconsistent
ACL data in your database --- like the example someone saw recently
where deleting a group name that was still referenced by an ACL
would make ACL display crash.  (I think this got fixed post-6.4...
or maybe it's still an outstanding bug?)

			regards, tom lane

Thu, 02 Sep 1999 10:55:29 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Odd problem with pg_class ... 
The Hermit Hacker <scrappy@hub.org> writes:
> NOTICE:  get_groname: group 0 not found
> pqReadData() -- backend closed the channel unexpectedly.

get_groname returns NULL on failure, and it looks like aclitemout
in backend/utils/adt/acl.c isn't checking for that.  Probably
aclitemout ought to produce the decimal equivalent of the group ID
if no name is available.  Compare what it does in the UID case just
above.

BTW, the ifdef'd out elog(NOTICE) in the UID case could be re-enabled
now, because I fixed the FE/BE protocol problem with NOTICEs generated
by type conversion routines...

			regards, tom lane

Thu, 02 Sep 1999 11:03:54 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Odd problem with pg_class ... 
This problem was reported in 08/17/1999 by me and 08/30/1999 by D Herssein.
No answer received.
Both are attached.
---------------- E-mail
08/17 -----------------------------------------------------------
Hi All,

Two weeks ago somebody had reported that drop user don't remove rights from
relacl field of pg_class. This problem is more serious if you delete a group
from pg_group without remoking rigths before. It causes backend terminates
abnormally.

Maybe interesting for others!! Could anybody include DENY sql command in
TODO list.

My problem is: A group have rigths to access some table. I include a new
user in this group, but for three months he will not have rights to access
this table. So, if the new user have no rigths, he will get rights from his
group. I think it would be enough DENY command (deny all on sometable from
newuser) includes something like "NEWUSER=" in relacl field.

Just more one question: Aclitem type have the following rigths: =arwR
(insert, select, update/delete, create rule, I suppose).
How could I grant update and revoke delete permissions on a table ?

Best Regards,

Ricardo Coelho.
----------------------------------------------------------------------------
---------------------
-------------- E-mail
08/30 -------------------------------------------------------------------
Hi Denny,

I solved this problem (backend crashes when we delete a group without
revoking privileges) adding the group again with the same grosysid, revoking
all privileges on all tables and deleting this group.

Best Regards,

Ricardo Coelho.

----- Original Message -----
From: D Herssein <denny@namsi.com>
To: Ricardo Coelho <rcoelho@px.com.br>
Sent: Monday, August 30, 1999 1:03 PM
Subject: HELP Re: pg_group, etc..


> I just read your post AFTER I sent the HELP request to the group.
> I must have deleted the group/user in the wrong order while playing with
> the db trying to learn how to gran group access to users.
> How do I get myself back to normal?
>
>
> --
> Life is complicated. But the simpler alternatives are not very
> desirable. (R' A. Kahn)
>

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

----- Original Message -----
From: Tom Lane <tgl@sss.pgh.pa.us>
To: The Hermit Hacker <scrappy@hub.org>
Cc: <pgsql-hackers@postgreSQL.org>
Sent: Thursday, September 02, 1999 12:03 PM
Subject: Re: [HACKERS] Odd problem with pg_class ...


> The Hermit Hacker <scrappy@hub.org> writes:
> > NOTICE:  get_groname: group 0 not found
> > pqReadData() -- backend closed the channel unexpectedly.
>
> get_groname returns NULL on failure, and it looks like aclitemout
> in backend/utils/adt/acl.c isn't checking for that.  Probably
> aclitemout ought to produce the decimal equivalent of the group ID
> if no name is available.  Compare what it does in the UID case just
> above.
>
> BTW, the ifdef'd out elog(NOTICE) in the UID case could be re-enabled
> now, because I fixed the FE/BE protocol problem with NOTICEs generated
> by type conversion routines...
>
> regards, tom lane
>
> ************
>
>


Thu, 2 Sep 1999 13:35:03 -0300
"Ricardo Coelho" <rcoelho@px.com.br>
Re: [HACKERS] Odd problem with pg_class ... 