Re: Fwd: Problems with pg_stat_activity view
От | mgr inż. Jacek Bzdak |
---|---|
Тема | Re: Fwd: Problems with pg_stat_activity view |
Дата | |
Msg-id | CA+FttVMX0BsjkK+RZUDbFHWskFSYEm1zPyW9zjJWXc38rqq4+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: Problems with pg_stat_activity view (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
Hi,
I think that this bug would affect at least couple of other people, but I agree it is not worth to change deep internal mechanisms just for it. SELECT ..., CASE WHEN u.rolname IS NULL THEN 'pg_user_removed` ELSE u.rolname END, ... FROM ....;
This would break existing code only if they use this particular username, which is not probable.
Other option I see is just to document two things:
- How to drop connections connecting to database (there are several questions on Stack Overflow regarding this, so it is worthwile )
- Document this behaviour of pg_stat_activity.
I guess I could try to contribute these changes, but I'm not qualified to decide whether they make sense.
PS. Sorry to be so persistent, but I spent this Friday afternoon and better part of night chasing this bug!
jb:)
2013/11/3 Tom Lane <tgl@sss.pgh.pa.us>
mgr inż. Jacek Bzdak <jbzdak@gmail.com> writes:Meh ... that would result in the usename column being possibly NULL,
> Maybe just fix pg_stat_activity so it uses LEFT JOIN, to cover such case. I
> guess it shouldnt break any code?
which I bet applications aren't expecting either. I'm not necessarily
against this, but I'm not sure it'll make things much better.
Anybody else have an opinion?
(Of course, the real fix would be to prevent dropping user IDs that
correspond to any live session, but that's not terribly easy either,
especially if you think about transient settings such as SET ROLE.
Overall I'm not convinced this is a case worth spending a lot of
effort on.)
regards, tom lane
В списке pgsql-bugs по дате отправления: