FAQ

On 1/06/2011 1:28 AM, Rikard Pavelic wrote:
The following bug has been logged online:

Bug reference: 6046
Logged by: Rikard Pavelic
Email address: rikard.pavelic@zg.htnet.hr
PostgreSQL version: 9.1 beta 1
Operating system: Windows 7 64bit
Description: select current_date crashes postgres
Details:

select current_time
or select current_date

results in postgres crash.
OK. I created the 'crashdumps' directory, gave the 'postgres' account
full control and re-tested. The resulting dump can be debugged in Visual
Studio Express 2008 (not 2010 - they removed that feature - but you can
use windbg) - and shows:
postgres.exe!datebsearch(const char * key=0x005ef004, const datetkn * base=0xffffffff, int nel=-1) Line 3579 C
postgres.exe!DecodeSpecial(int field=0, char * lowtoken=0x005ef004, int * val=0x005eee78) Line 2789 + 0x11 bytes C
postgres.exe!DecodeTimeOnly(char * * field=0x005eef3c, int * ftype=0x005eefa0, int nf=1, int * dtype=0x005eef0c, pg_tm * tm=0x005eef10, int * fsec=0x005eef08, int * tzp=0x005eef00) Line 1921 + 0xf bytes C
postgres.exe!timetz_in(FunctionCallInfoData * fcinfo=0x005ef060) Line 1864 + 0x2b bytes C
postgres.exe!InputFunctionCall(FmgrInfo * flinfo=0x01d122bc, char * str=0x01d14090, unsigned int typioparam=1266, int typmod=-1) Line 1909 + 0x3a bytes C
postgres.exe!ExecEvalCoerceViaIO(CoerceViaIOState * iostate=0x01d12290, ExprContext * econtext=0x01d12198, char * isNull=0x01d12470, ExprDoneCond * isDone=0x01d12508) Line 4064 + 0x10 bytes C
postgres.exe!ExecTargetList(List * targetlist=0x01d124f0, ExprContext * econtext=0x01d12198, unsigned int * values=0x01d12460, char * isnull=0x01d12470, ExprDoneCond * itemIsDone=0x01d12508, ExprDoneCond * isDone=0x005ef310) Line 5107 + 0x27 bytes C
postgres.exe!ExecProject(ProjectionInfo * projInfo=0x01d12480, ExprDoneCond * isDone=0x005ef310) Line 5324 + 0x18 bytes C
postgres.exe!ExecResult(ResultState * node=0x00000000) Line 157 C
postgres.exe!ExecProcNode(PlanState * node=0x01d12110) Line 367 + 0x6 bytes C
postgres.exe!ExecutePlan(EState * estate=0x00000000, PlanState * planstate=0x01d12110, CmdType operation=CMD_SELECT, char sendTuples='', long numberTuples=0, ScanDirection direction=NoMovementScanDirection, _DestReceiver * dest=0x01b1f800) Line 1386 + 0xa bytes C
postgres.exe!standard_ExecutorRun(QueryDesc * queryDesc=0x7ffd7000, ScanDirection direction=6223960, long count=2008331305) Line 318 + 0x15 bytes C
kernel32.dll!@BaseThreadInitThunk@12() + 0x12 bytes
It looks like the issue is that an invalid pointer is passed for `base'.
`base' is used to calculate `position' which is then dereferenced - and
splat!

I suspect - but haven't verified - that the reason `base' is shown as
0xffffffff rather than NULL is that the optimizer has done away with the
'position' variable, instead using the 'base' variable passed as a
parameter. There isn't any 'position' variable in the local stack.

The static global `timezonetktbl' in src\backend\utils\adt\datetime.c is
NULL. The calling function passes 'timezonetktbl' as the 'base' argument
of datebsearch(...). So I'd say that 0xffffffff is just an artifact of
the optimizer's work, and `base' was really passed as NULL.

So - for some reason the time zone tables aren't getting loaded, or
InstallTimeZoneAbbrevs(...) isn't being called to activate them.

Is anyone aware of any changes between 9.0 and 9.1beta that messed with
time zone handling and loading?

--
Craig Ringer

Tech-related writing at http://soapyfrogs.blogspot.com/

Search Discussions

  • Craig Ringer at Jun 1, 2011 at 1:13 am

    On 1/06/2011 9:01 AM, Craig Ringer wrote:

    Is anyone aware of any changes between 9.0 and 9.1beta that messed with
    time zone handling and loading?
    By the way, it looks like using any of:

    SELECT 'now'::timestamp;
    SELECT 'now'::timestamptz;
    SELECT current_time;
    SELECT current_date;
    SELECT localtime;
    SELECT localtimestamp;
    SELECT CAST( now() AS date );

    will also trigger a crash. However, none of these statements do:

    SELECT current_timestamp;
    SELECT now();
    SELECT now() :: timestamptz;
    SELECT now() :: timestamp;

    --
    Craig Ringer

    Tech-related writing at http://soapyfrogs.blogspot.com/
  • Tom Lane at Jun 1, 2011 at 2:53 am

    Craig Ringer writes:
    On 1/06/2011 9:01 AM, Craig Ringer wrote:
    Is anyone aware of any changes between 9.0 and 9.1beta that messed with
    time zone handling and loading?
    By the way, it looks like using any of:
    SELECT 'now'::timestamp;
    SELECT 'now'::timestamptz;
    SELECT current_time;
    SELECT current_date;
    SELECT localtime;
    SELECT localtimestamp;
    SELECT CAST( now() AS date );
    will also trigger a crash.
    This is the known problem with timezone abbreviations not being
    initialized correctly on Windows --- anything involving interpreting a
    "keyword" in datetime input will go belly up. See commits 2e82d0b39,
    e05b86644.

    regards, tom lane

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJun 1, '11 at 1:02a
activeJun 1, '11 at 2:53a
posts3
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Craig Ringer: 2 posts Tom Lane: 1 post

People

Translate

site design / logo © 2022 Grokbase