Re: User-Id Tracking when Portal was started
Kohei KaiGai <kaigai@kaigai.gr.jp>
From: Kohei KaiGai <kaigai@kaigai.gr.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Robert Haas <robertmhaas@gmail.com>, PgHacker <pgsql-hackers@postgresql.org>, Florian Pflug <fgp@phlo.org>
Date: 2012-07-03T16:46:13Z
Lists: 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>