Re: User-Id Tracking when Portal was started
От | Kohei KaiGai |
---|---|
Тема | Re: User-Id Tracking when Portal was started |
Дата | |
Msg-id | CADyhKSX+Btth0dJa5L1niFO8d-+ZprO+61jLyE64En5oVwcgfA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: User-Id Tracking when Portal was started (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: User-Id Tracking when Portal was started
|
Список | pgsql-hackers |
2012/7/3 Tom Lane <tgl@sss.pgh.pa.us>: > Kohei KaiGai <kaigai@kaigai.gr.jp> writes: >> 2012/7/3 Tom Lane <tgl@sss.pgh.pa.us>: >>> Um... what should happen if there was a SET SESSION AUTHORIZATION >>> to the portal's userId? This test will think nothing happened. > >> In my test, all the jobs by SET SESSION AUTHORIZATION was cleaned-up... >> It makes nothing happen from viewpoint of users. > > My point is that it seems like a bug that the secContext gets restored > in one case and not the other, depending on which user ID was specified > in SET SESSION AUTHORIZATION. > Sorry, the above description mention about a case when it does not use the marker to distinguish a case to switch user-id from a case not to switch. (I though I was asked the behavior if this logic always switches / restores ids.) The patch itself works correctly, no regression test failed even though several tests switches user-id using SET SESSION AUTHORIZATION. Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: