From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Andrew Geery <andrew(dot)geery(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: BUG #5669: server process was terminated by exception 0xC0000005 |
Date: | 2010-09-22 17:03:06 |
Message-ID: | 27650.1285174986@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of mi sep 22 12:39:24 -0400 2010:
>> As far as a fix for the crash goes, I'm not sure if it'd be better to
>> try to make show_session_authorization() return some sort of default
>> value in this scenario, or to try to ensure that the variable has been
>> set to something valid before we start running user-supplied code.
>> In either case the problem is potentially wider than this one function
>> and variable. Thoughts anyone?
> My first thought is that the weird encoding of
> session_authorization_string should better be contained in as few places
> as possible, so we shouldn't try to initialize it to something
> valid-looking. Seems easier to have show_session_authorization() cope
> with a NULL value.
Yeah, coping with a NULL seems like the best thing to me too after
further reflection: the other way couldn't possibly cope with scenarios
like "show_session_authorization gets called before we got around to
initializing the variable".
> But what would this default value be?
Wouldn't an empty string be acceptable? SQL doesn't allow zero-length
identifiers, so this couldn't be confused with any really-valid value.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-09-22 17:04:50 | Re: UNLISTEN bug |
Previous Message | Alvaro Herrera | 2010-09-22 16:56:04 | Re: BUG #5669: server process was terminated by exception 0xC0000005 |