Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>>Can you get a stack trace from the core dump? > > >>(gdb) bt >>#0 0x0000000050377ba4 in memcpy () from /usr/lib/libc.so.34.2 >>#1 0x0000000000326efc in hash_search () >>#2 0x0000000000343430 in pg_tzset () >>#3 0x00000000001fbcf0 in assign_timezone () >>#4 0x0000000000330e88 in set_config_option () >>#5 0x000000000029b5b0 in PostgresMain () >>#6 0x000000000026b140 in BackendRun () >>#7 0x000000000026a9f0 in BackendStartup () >>#8 0x00000000002685bc in ServerLoop () >>#9 0x0000000000267b88 in PostmasterMain () >>#10 0x0000000000220cc8 in main () > > >>hmm - maybe one of the timezone patches ? > > > Looks suspicious, doesn't it. How long since you last tested on that > machine?
*argl* - it's not 2PC ... the machine had some issues a week ago or so - but it looks like the problem occured first here: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=spoonbill&dt=2005-06-15%2023:50:04 and in that changeset we have some timezone-patches ... Stefan ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
