Обсуждение: Odd problem with pg_class ...
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
beforeor
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
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
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
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
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 > > ************ > >