[BUGS] Assertion failure on reload of GUC_SUPERUSER_ONLY parms

2009-10-03 Thread Simon Riggs 

TRAP: BadState("!(((bool) ((CurrentUserId) != ((Oid) 0", File:
"miscinit.c", Line: 295)

Gabriele Bartolini originally reported this to me as a bug in Hot
Standby, though I have now been able to reproduce in CVS head. We were
just unlucky enough to hit it while doing thorough HS testing.

backtrace
#0  0x2b7beafd2b45 in raise () from /lib64/libc.so.6
#1  0x2b7beafd40e0 in abort () from /lib64/libc.so.6
#2  0x006c016d in ExceptionalCondition (
conditionName=, errorType=, 
fileName=, lineNumber=)
at assert.c:57
#3  0x006ccf4d in GetUserId () at miscinit.c:295
#4  0x006db1b9 in superuser () at superuser.c:48
#5  0x006d5a2b in GetConfigOption (name=0xb2b6e8 "log_filename")
at guc.c:5226
#6  0x006d8a2c in ProcessConfigFile (context=PGC_SIGHUP)
at guc-file.l:319
#7  0x005e49e2 in SIGHUP_handler (
postgres_signal_arg=) at postmaster.c:2062
#8  
#9  0x2b7beb060bc3 in select () from /lib64/libc.so.6
#10 0x005e1bf7 in ServerLoop () at postmaster.c:1360
#11 0x005e2b14 in PostmasterMain (argc=3, argv=0xb246a0)
at postmaster.c:1065

It turns out that when you modify a GUC_SUPERUSER_ONLY parameter, such
as log_filename, in postgresql.conf and then reload you will get the
assertion failure.

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().

-- 
 Simon Riggs   www.2ndQuadrant.com


-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] Assertion failure on reload of GUC_SUPERUSER_ONLY parms

2009-10-03 Thread Tom Lane 
Simon Riggs  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

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Re: [BUGS] BUG #5083: Problem create account.

2009-10-03 Thread Robert Haas 
On Sun, Sep 27, 2009 at 5:29 PM, Jesper  wrote:
>
> The following bug has been logged online:
>
> Bug reference:      5083
> Logged by:          Jesper
> Email address:      sol...@hotmail.com
> PostgreSQL version: 8,3
> Operating system:   Vista
> Description:        Problem create account.
> Details:
>
> Hello.
>
> I've been trying create an account with you.
> I need to get holdem manager to work.
>
> But when I create it cancel when I try to install.
>
> error " Account already created " or " could't create" I have vista. Does it
> not work then ?

This doesn't sound like a bug; I'm guessing you've done something
wrong, but I don't know what it is.  You might want to contact whoever
supports holdem manager and/or try this question (with more details)
on pgsql-novice or pgsql-general.

...Robert

-- 
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs