From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>, "gabriele(dot)bartolini" <gabriele(dot)bartolini(at)2ndquadrant(dot)it> |
Subject: | Re: Assertion failure on reload of GUC_SUPERUSER_ONLY parms |
Date: | 2009-10-03 15:54:21 |
Message-ID: | 1020.1254585261@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> It looks to me like the correct fix would be to use
> GetUserIdAndContext() instead, though I would suggest inventing
> GetUserIdIfAny() which would skip the assertion test for use in
> superuser().
You are thinking at the wrong abstraction level. Even to ask if
the user is superuser is inappropriate in the postmaster, since
there is no user. So I think the bug is that GetConfigOption
is calling superuser() when it is now possible for it to be used
in the postmaster.
The quick & dirty fix would be to add IsUnderPostmaster to the
check in GetConfigOption. Or we could refactor things so that
the GUC_SUPERUSER_ONLY check is applied at some higher level;
but that's probably more work than it's worth.
It looks to me like the pstrdup that was added in guc-file.l
represents a permanent memory leak in the postmaster, too :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2009-10-04 01:04:46 | Re: BUG #5083: Problem create account. |
Previous Message | Simon Riggs | 2009-10-03 14:41:18 | Assertion failure on reload of GUC_SUPERUSER_ONLY parms |