Thread: possible when setting the timezone

possible when setting the timezone

From
Nick Martens
Date:
Hello, I am developing an php application and by mistake a wrong timezone was
set after I initialized the connection, which resulted in a core dump of the
current process.
The postgres version is 8.0.3 running on a freebsd 6.0-RELEASE machine with
the generic kernel.
I tried searching for similar problems but I could not find similar reports.

from /var/log/messages:
Jan 10 17:14:40 dndwebdev01 postgres[17374]: [1-1] ERROR:  unrecognized time
zone name: "America/Indiana"
Jan 10 17:14:40 dndwebdev01 kernel: pid 17374 (postgres), uid 70: exited on
signal 11 (core dumped)
Jan 10 17:14:40 dndwebdev01 postgres[17372]: [1-1] WARNING:  terminating
connection because of crash of another server process
Jan 10 17:14:40 dndwebdev01 postgres[17372]: [1-2] DETAIL:  The postmaster has
commanded this server process to roll back the current transaction and exit,
because another server
Jan 10 17:14:40 dndwebdev01 postgres[17372]: [1-3]  process exited abnormally
and possibly corrupted shared memory.
Jan 10 17:14:40 dndwebdev01 postgres[17372]: [1-4] HINT:  In a moment you
should be able to reconnect to the database and repeat your command.

Nick

Re: possible when setting the timezone

From
Tom Lane
Date:
Nick Martens <nick80@xs4all.nl> writes:
> Jan 10 17:14:40 dndwebdev01 postgres[17374]: [1-1] ERROR:  unrecognized time
> zone name: "America/Indiana"
> Jan 10 17:14:40 dndwebdev01 kernel: pid 17374 (postgres), uid 70: exited on
> signal 11 (core dumped)

Doesn't happen for me:

regression=# set timezone = 'America/Indiana';
ERROR:  unrecognized time zone name: "America/Indiana"
regression=# set timezone = 'America/Indiana';
ERROR:  unrecognized time zone name: "America/Indiana"
regression=# set timezone = 'America/Indiana';
ERROR:  unrecognized time zone name: "America/Indiana"
regression=#

(This is with 8.0.6, but I don't see any related fixes in the CVS logs.)

Can you get a stack trace from the core dump?

            regards, tom lane

Re: possible when setting the timezone

From
Nick Martens
Date:
here it is, including the defenition of the table and view in question, as it
seems it coredumped when it tried to execute a query using a typecast from
timestamptz to timestamp, after setting an invalid timezone, hope it helps.

Nick.

ps. there are some strangely named columns as the db is being translated to
englist at the moment.

#0  0x08224b8c in timesub (timep=0xc0006048, offset=3600, sp=0x82dbfc0,
    tmp=0x82e0bc0) at localtime.c:971
#1  0x08225020 in pg_localtime (timep=0xc0006048) at localtime.c:902
#2  0x081e0024 in timestamp2tm (dt=1136823180, tzp=0xbfbfcfac, tm=0xbfbfcfc0,
    fsec=0xbfbfcfb0, tzn=0xbfbfcfbc) at timestamp.c:1081
#3  0x081e5381 in timestamptz_timestamp (fcinfo=0xc0006048) at
timestamp.c:3939
#4  0x08121e68 in ExecMakeFunctionResult (fcache=0x83ff6f8,
    econtext=0x83ff188, isNull=0xbfbfd14b "", isDone=0x8403d24)
    at execQual.c:1042
#5  0x0812554f in ExecProject (projInfo=0x82dbfc0, isDone=0xbfbfd180)
    at execQual.c:3568
#6  0x0812d913 in ExecNestLoop (node=0x83ff570) at nodeNestloop.c:248
#7  0x08120b4b in ExecProcNode (node=0x83ff570) at execProcnode.c:326
#8  0x0812ec6e in ExecSort (node=0x83ff4e8) at nodeSort.c:102
#9  0x08120b0f in ExecProcNode (node=0x83ff4e8) at execProcnode.c:345
#10 0x0812f33e in ExecLimit (node=0x83ff0b8) at nodeLimit.c:87
#11 0x08120abb in ExecProcNode (node=0x83ff0b8) at execProcnode.c:369
#12 0x0811fa7f in ExecutorRun (queryDesc=0x83ff0b8,
    direction=ForwardScanDirection, count=0) at execMain.c:1060
#13 0x0819bb41 in PortalRunSelect (portal=0x8366018, forward=72 'H', count=0,
    dest=0x83e6fc0) at pquery.c:746
#14 0x0819c18a in PortalRun (portal=0x8366018, count=2147483647,
    dest=0x83e6fc0, altdest=0x83e6fc0, completionTag=0xbfbfd470 "")
    at pquery.c:561
#15 0x081982c0 in exec_simple_query (
    query_string=0x8362018 "SELECT memo_id, memo_title, memo_comment,
memo_date::timestamp, bedrijf_id, persoon_id, initialenachternaam,
bedrijfsnaam FROM v_memos  ORDER BY memo_date DESC LIMIT 30 OFFSET 0") at
postgres.c:933
#16 0x08199adc in PostgresMain (argc=4, argv=0x82f6268,
    username=0x82f6238 "adminuser") at postgres.c:3007
#17 0x0816ecee in ServerLoop () at postmaster.c:2836
#18 0x081704d1 in PostmasterMain (argc=1, argv=0xbfbfed64) at postmaster.c:918
#19 0x0813dc36 in main (argc=1, argv=0xbfbfed64) at main.c:268

v_memos is a view, created using
create or replace view v_memos as select
    memo_id, memo_comment, memo_title, memo_date, memos.bedrijf_id,
    memos.persoon_id,
    v_personen.persoon_initialenachternaam as initialenachternaam,
    bedrijven.bedrijf_naam as bedrijfsnaam
    from bedrijven inner join memos using (bedrijf_id) inner join v_personen
using (persoon_id)
 \d memos;
                                         Table "public.memos"
    Column    |           Type           |                         Modifiers
--------------+--------------------------+------------------------------------------------------------
 memo_id      | integer                  | not null default
nextval('public.memos_memo_id_seq'::text)
 memo_title   | text                     | not null
 memo_comment | text                     | not null
 memo_date    | timestamp with time zone | not null
 bedrijf_id   | bigint                   | not null
 persoon_id   | bigint                   | not null
Indexes:
    "memos_pkey" PRIMARY KEY, btree (memo_id)
Foreign-key constraints:
    "memos_bedrijf_id_fkey" FOREIGN KEY (bedrijf_id) REFERENCES
bedrijven(bedrijf_id)
    "memos_persoon_id_fkey" FOREIGN KEY (persoon_id) REFERENCES
personen(persoon_id)

On Tuesday 10 January 2006 19:23, Tom Lane wrote:
> Nick Martens <nick80@xs4all.nl> writes:
> > Jan 10 17:14:40 dndwebdev01 postgres[17374]: [1-1] ERROR:  unrecognized
> > time zone name: "America/Indiana"
> > Jan 10 17:14:40 dndwebdev01 kernel: pid 17374 (postgres), uid 70: exited
> > on signal 11 (core dumped)
>
> Doesn't happen for me:
>
> regression=# set timezone = 'America/Indiana';
> ERROR:  unrecognized time zone name: "America/Indiana"
> regression=# set timezone = 'America/Indiana';
> ERROR:  unrecognized time zone name: "America/Indiana"
> regression=# set timezone = 'America/Indiana';
> ERROR:  unrecognized time zone name: "America/Indiana"
> regression=#
>
> (This is with 8.0.6, but I don't see any related fixes in the CVS logs.)
>
> Can you get a stack trace from the core dump?
>
>             regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

Re: possible when setting the timezone

From
Tom Lane
Date:
Nick Martens <nick80@xs4all.nl> writes:
> here it is, including the defenition of the table and view in question, as it
> seems it coredumped when it tried to execute a query using a typecast from
> timestamptz to timestamp, after setting an invalid timezone, hope it helps.

Ah, that's the missing bit:

regression=# select now()::timestamp;
            now
----------------------------
 2006-01-10 14:44:31.517463
(1 row)

regression=# set timezone = 'America/Indiana';
ERROR:  unrecognized time zone name: "America/Indiana"
regression=# select now()::timestamp;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.

Seems to work fine in the 7.4, 8.1, and HEAD branches ... but 8.0 is
busted.  Thanks for the report!

            regards, tom lane

Re: possible when setting the timezone

From
Nick Martens
Date:
i just tried the commands from the psql console, and seems to crash then too.

mydb=# SET TimeZone TO 'America/Indiana';
ERROR:  unrecognized time zone name: "America/Indiana"
mydb=# SELECT memo_id, memo_title, memo_comment,
mydb-# memo_date::timestamp, bedrijf_id, persoon_id, initialenachternaam,
mydb-# bedrijfsnaam FROM v_memos  ORDER BY memo_date DESC LIMIT 30 OFFSET 0;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

Re: possible when setting the timezone

From
Tom Lane
Date:
Nick Martens <nick80@xs4all.nl> writes:
> i just tried the commands from the psql console, and seems to crash then too.

It turns out that the problem is specific to referencing a timezone name
that is a directory (rather than an individual datafile) in the timezone
database.  In that case the tzload function manages to clobber some
state before realizing that it's looking at invalid data.  Here's the
patch if you need it.

            regards, tom lane

Index: localtime.c
===================================================================
RCS file: /cvsroot/pgsql/src/timezone/localtime.c,v
retrieving revision 1.9
diff -c -r1.9 localtime.c
*** localtime.c    1 Nov 2004 21:34:44 -0000    1.9
--- localtime.c    10 Jan 2006 20:05:06 -0000
***************
*** 842,862 ****
  bool
  pg_tzset(const char *name)
  {
      if (lcl_is_set && strcmp(lcl_TZname, name) == 0)
          return true;            /* no change */

      if (strlen(name) >= sizeof(lcl_TZname))
          return false;            /* not gonna fit */

!     if (tzload(name, lclptr) != 0)
      {
!         if (name[0] == ':' || tzparse(name, lclptr, FALSE) != 0)
          {
              /* Unknown timezone. Fail our call instead of loading GMT! */
              return false;
          }
      }

      strcpy(lcl_TZname, name);
      lcl_is_set = true;

--- 842,865 ----
  bool
  pg_tzset(const char *name)
  {
+     struct state tmpmem;
+
      if (lcl_is_set && strcmp(lcl_TZname, name) == 0)
          return true;            /* no change */

      if (strlen(name) >= sizeof(lcl_TZname))
          return false;            /* not gonna fit */

!     if (tzload(name, &tmpmem) != 0)
      {
!         if (name[0] == ':' || tzparse(name, &tmpmem, FALSE) != 0)
          {
              /* Unknown timezone. Fail our call instead of loading GMT! */
              return false;
          }
      }

+     memcpy(lclptr, &tmpmem, sizeof(struct state));
      strcpy(lcl_TZname, name);
      lcl_is_set = true;