BUG #6046: select current_date crashes postgres

The following bug has been logged online:

Bug reference: 6046
Logged by: Rikard Pavelic
Email address: rikard(dot)pavelic(at)zg(dot)htnet(dot)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.

select now()
works

On 1/06/2011 1:28 AM, Rikard Pavelic wrote:

> select current_time
> or select current_date
>
> results in postgres crash.

Ouch. That's not ideal.

Please post the messages output to the postgresql log file from when the
backend crashes. You will find the log file in the pg_log directory
inside your data directory, which by default is under the postgresql
installation directory in Program Files.

Are you running the 32-bit or 64-bit build of PostgreSQL 9.1 beta? Both
will run on 64-bit Windows.

Did you get it from EnterpriseDB
(http://www.enterprisedb.com/products-services-training/pgdevdownload) ?

--
Craig Ringer

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

Ah, never mind. I can reproduce the crash here on my 32-bit win7 with a
32-bit build of Pg. Looking into it now.

--
Craig Ringer

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

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(dot)pavelic(at)zg(dot)htnet(dot)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.

The crash is a segfault:

2011-06-01 08:29:04 WST LOG: server process (PID 2420) was terminated
by exception 0xC0000005

I've got a crash dump and am looking into it now. In the mean time,
what's even more worrying is this:

> 2011-06-01 08:33:18 WST WARNING: terminating connection because of crash of another server process
> 2011-06-01 08:33:18 WST DETAIL: The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
> 2011-06-01 08:33:18 WST HINT: In a moment you should be able to reconnect to the database and repeat your command.
> 2011-06-01 08:33:18 WST LOG: all server processes terminated; reinitializing
> 2011-06-01 08:33:28 WST FATAL: pre-existing shared memory block is still in use
> 2011-06-01 08:33:28 WST HINT: Check if there are any old server processes still running, and terminate them.

It looks like Pg isn't coming back up after the backend crash. There
are no postgres.exe processes hanging around, and I can start PostgreSQL
back up from services.msc without a problem, but it doesn't successfully
re-launch its _self_ after a crash.

--
Craig Ringer

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

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(dot)pavelic(at)zg(dot)htnet(dot)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(dot)dll!(at)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/

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/

Rikard,

I've moved this discussion to the pgsql-hackers mailing list, as I can
reproduce the crash you reported and have been able to get a
useful-looking crash dump to examine.

I removed you from the CC list when I moved the report to -hackers,
because there's often quite a burst of mail in some discussions and I
didn't want to flood you with mail. You can follow it in the
pgsql-hackers mailing list if you like, or ask for people to cc you.
Otherwise, once more is known I'll update you.

Thanks very much for your report, it's greatly appreciated.

--
Craig Ringer

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

Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> 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

So much for my worries about a big long conversation. The short answer
from Tom Lane, who committed the fixes to git:

Tom Lane wrote:
> 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

Those commits have a more detailed explanation, and can be found here:

http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=2e82d0b396473b595a30f68b37b8dfd41c37dff8

http://git.postgresql.org/gitweb?p=postgresql.git;a=commit;h=e05b866447899211a0c2df31bf0671faac4fc3e5

but the short version appears to be "Fixed in the next version".

--
Craig Ringer