Re: Postgres 9.0 crash on win7

Hi,

I'm using usually
Postgres 8.4.4 (32bit) + Postgis 1.5.1 on Windows7 64bit.

Now I try-ing the last
Postgres 9.0 (32bit) + Postgis 1.5.2 on the same machine (win7 64bit).

I experience a

crash of Postgres while it is running a huge load of data.

This is the report of log.

2010-10-01 22:38:55 CEST LOG: last completed transaction was at log time
2010-10-01 22:23:51.389+02
2010-10-01 22:38:56 CEST LOG: autovacuum launcher started
2010-10-01 22:38:56 CEST LOG: database system is ready to accept
connections
2010-10-01 22:44:20 CEST LOG: server process (PID 2540) was terminated by
exception 0xC0000005
2010-10-01 22:44:20 CEST HINT: See C include file "ntstatus.h" for a
description of the hexadecimal value.
2010-10-01 22:44:20 CEST LOG: terminating any other active server processes
2010-10-01 22:44:20 CEST WARNING: terminating connection because of crash
of another server process
2010-10-01 22:44:20 CEST 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.
2010-10-01 22:44:20 CEST HINT: In a moment you should be able to reconnect
to the database and repeat your command.
2010-10-01 22:44:20 CEST WARNING: terminating connection because of crash
of another server process
2010-10-01 22:44:20 CEST 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.
2010-10-01 22:44:20 CEST HINT: In a moment you should be able to reconnect
to the database and repeat your command.
2010-10-01 22:44:20 CEST LOG: all server processes terminated;
reinitializing
2010-10-01 22:44:31 CEST FATAL: pre-existing shared memory block is still
in use
2010-10-01 22:44:31 CEST HINT: Check if there are any old server processes
still running, and terminate them.

The tablespace where I load the data is new create from postgres9.0

After seeing this.
I try load the same data load procedure (on the same windows machine) using
the postgres 8.4.4 istance and all terminated without any problem.

The procedure is substantially only a huge list of
string sql like

insert into(....)

executed one by one in many tables and with autocommit.

Andrea Peri.

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

On 2/10/2010 9:08 PM, Andrea Peri wrote:
> Hi,
>
> I'm using usually
> Postgres 8.4.4 (32bit) + Postgis 1.5.1 on Windows7 64bit.
>
> Now I try-ing the last
> Postgres 9.0 (32bit) + Postgis 1.5.2 on the same machine (win7 64bit).
>
> I experience a
>
> crash of Postgres while it is running a huge load of data.

Does that include PostGIS datatypes?

> 2010-10-01 22:44:20 CEST LOG: server process (PID 2540) was terminated
> by exception 0xC0000005

That's invalid memory access - like a UNIX segfault (sig11).

Can you show your schema - the definition of the table(s) involved in
the INSERT and any triggers on them? The output of:

\d+ tablename

from psql would do the trick.

Truly, the most helpful thing at this point would be to collect a
backtrace showing where in the postgresql server it crashed. There are
instructions on how to do that here:

http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows

In your case, as the backend is crashing you will want to use windbg or
Visual Studio Express Edition to collect the crash data; process
explorer will not be enough.

--
Craig Ringer

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

Hi, thx for response.

>Does that include PostGIS datatypes?

yes, but after some email with the guys of Posgis team , I think the problem
is related to postgres.

(see this thread on postgis ML):
http://postgis.refractions.net/pipermail/postgis-users/2010-October/027841.html

The postgis team was using a my script sql (about 10mbyte, 1Mb compress)
that always crash a PG9 32bit on windows7 64 bit.

Using that script and setting the verbosity as Postgis team suggest I see
this report:

--- start log ---
2010-10-03 10:46:53 CEST LOG: 00000: database system was shut down at
2010-10-03 10:46:37 CEST
2010-10-03 10:46:53 CEST LOCATION: StartupXLOG,
.\src\backend\access\transam\xlog.c:5713
2010-10-03 10:46:53 CEST FATAL: 57P03: the database system is starting up
2010-10-03 10:46:53 CEST LOCATION: ProcessStartupPacket,
.\src\backend\postmaster\postmaster.c:1818
2010-10-03 10:46:54 CEST LOG: 00000: autovacuum launcher started
2010-10-03 10:46:54 CEST LOCATION: AutoVacLauncherMain,
.\src\backend\postmaster\autovacuum.c:404
2010-10-03 10:46:54 CEST LOG: 00000: database system is ready to accept
connections
2010-10-03 10:46:54 CEST LOCATION: reaper,
.\src\backend\postmaster\postmaster.c:2402
--- --- the script start here at 10:48 ----
2010-10-03 10:48:51 CEST LOG: 00000: server process (PID 5076) was
terminated by exception 0xC0000005
2010-10-03 10:48:51 CEST HINT: See C include file "ntstatus.h" for a
description of the hexadecimal value.
2010-10-03 10:48:51 CEST LOCATION: LogChildExit,
.\src\backend\postmaster\postmaster.c:2835
2010-10-03 10:48:51 CEST LOG: 00000: terminating any other active server
processes
2010-10-03 10:48:51 CEST LOCATION: HandleChildCrash,
.\src\backend\postmaster\postmaster.c:2659
2010-10-03 10:48:51 CEST WARNING: 57P02: terminating connection because of
crash of another server process
2010-10-03 10:48:51 CEST 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.
2010-10-03 10:48:51 CEST HINT: In a moment you should be able to reconnect
to the database and repeat your command.
2010-10-03 10:48:51 CEST LOCATION: quickdie,
.\src\backend\tcop\postgres.c:2626
2010-10-03 10:48:51 CEST LOG: 00000: all server processes terminated;
reinitializing
2010-10-03 10:48:51 CEST LOCATION: PostmasterStateMachine,
.\src\backend\postmaster\postmaster.c:3079
2010-10-03 10:49:01 CEST FATAL: XX000: pre-existing shared memory block is
still in use
2010-10-03 10:49:01 CEST HINT: Check if there are any old server processes
still running, and terminate them.
2010-10-03 10:49:01 CEST LOCATION: PGSharedMemoryCreate,
.\src\backend\port\win32_shmem.c:194
----- the script take 1 minute and after it was terminate, 35 seconds
after postgres 9.0 crash. ----
--- at the 10:50 I restart the service PostgresSql. and see other
information about the crash----
2010-10-03 10:50:54 CEST LOG: 00000: database system was interrupted; last
known up at 2010-10-03 10:46:53 CEST
2010-10-03 10:50:54 CEST LOCATION: StartupXLOG,
.\src\backend\access\transam\xlog.c:5737
2010-10-03 10:50:54 CEST LOG: 00000: database system was not properly shut
down; automatic recovery in progress
2010-10-03 10:50:54 CEST LOCATION: StartupXLOG,
.\src\backend\access\transam\xlog.c:5962
2010-10-03 10:50:54 CEST LOG: 00000: consistent recovery state reached at
0/2557DA0
2010-10-03 10:50:54 CEST LOCATION: CheckRecoveryConsistency,
.\src\backend\access\transam\xlog.c:6566
2010-10-03 10:50:54 CEST LOG: 00000: redo starts at 0/2557DA0
2010-10-03 10:50:54 CEST LOCATION: StartupXLOG,
.\src\backend\access\transam\xlog.c:6154
2010-10-03 10:50:54 CEST FATAL: 57P03: the database system is starting up
2010-10-03 10:50:54 CEST LOCATION: ProcessStartupPacket,
.\src\backend\postmaster\postmaster.c:1818
2010-10-03 10:50:55 CEST FATAL: 57P03: the database system is starting up
2010-10-03 10:50:55 CEST LOCATION: ProcessStartupPacket,
.\src\backend\postmaster\postmaster.c:1818
2010-10-03 10:50:57 CEST FATAL: 57P03: the database system is starting up
2010-10-03 10:50:57 CEST LOCATION: ProcessStartupPacket,
.\src\backend\postmaster\postmaster.c:1818
2010-10-03 10:50:58 CEST FATAL: 57P03: the database system is starting up
2010-10-03 10:50:58 CEST LOCATION: ProcessStartupPacket,
.\src\backend\postmaster\postmaster.c:1818
2010-10-03 10:50:59 CEST FATAL: 57P03: the database system is starting up
2010-10-03 10:50:59 CEST LOCATION: ProcessStartupPacket,
.\src\backend\postmaster\postmaster.c:1818
2010-10-03 10:51:00 CEST LOG: 00000: record with zero length at 0/331FFC8
2010-10-03 10:51:00 CEST LOCATION: ReadRecord,
.\src\backend\access\transam\xlog.c:3765
2010-10-03 10:51:00 CEST LOG: 00000: redo done at 0/331FF88
2010-10-03 10:51:00 CEST LOCATION: StartupXLOG,
.\src\backend\access\transam\xlog.c:6253
2010-10-03 10:51:00 CEST LOG: 00000: last completed transaction was at log
time 2010-10-03 10:48:50.977+02
2010-10-03 10:51:00 CEST LOCATION: StartupXLOG,
.\src\backend\access\transam\xlog.c:6258
2010-10-03 10:51:00 CEST FATAL: 57P03: the database system is starting up
2010-10-03 10:51:00 CEST LOCATION: ProcessStartupPacket,
.\src\backend\postmaster\postmaster.c:1818
2010-10-03 10:51:01 CEST LOG: 00000: autovacuum launcher started
2010-10-03 10:51:01 CEST LOCATION: AutoVacLauncherMain,
.\src\backend\postmaster\autovacuum.c:404
2010-10-03 10:51:01 CEST LOG: 00000: database system is ready to accept
connections
2010-10-03 10:51:01 CEST LOCATION: reaper,
.\src\backend\postmaster\postmaster.c:2402
---- end of log ----

>Can you show your schema - the definition of the table(s) involved in the
INSERT and any triggers on them? The output of:
>
>\d+ tablename
>
>from psql would do the trick.

If you like I can send you the script.
It create may tables and start to populate using many inserts.

The real script is more big then this, but this 10mbytes is sufficient to
crash PG9.

However the main table involved is this:

Table
"public.linee_elementari"
Column | Type |
Modifiers | Storage | Description
-------------------+---------------------------+----------------------------------------------------------------+----------+-------------
codlinea | character varying(35) | not
null | extended |
codctr | character varying(35)
| | extended
|
codvisibilita | character varying(35)
| | extended
|
codbreakline | character varying(35)
| | extended
|
codclasse | character varying(35)
| | extended
|
codlatovestizione | character varying(35)
| | extended
|
codoriginelinea | character varying(35)
| | extended
|
codmodifica | character varying(35)
| | extended
|
poslist | character varying(200000)
| | extended
|
lung_poslist | integer
| | plain
|
num_vertex | integer
| | plain
|
idedge | character varying(35)
| | extended
|
srsname | character varying(35)
| | extended
|
dimension | character varying(1)
| | extended
|
coord_n1 | character varying(50)
| | extended
|
coord_n2 | character varying(50)
| | extended
|
geom | geometry
| | main
|
oid | integer | not null default
nextval('linee_elementari_oid_seq'::regclass) | plain |
Indexes:
"linee_elementari_pkey" PRIMARY KEY, btree (codlinea)
Check constraints:
"enforce_dims_geom" CHECK (st_ndims(geom) = 2)
"enforce_geotype_geom" CHECK (geometrytype(geom) = 'LINESTRING'::text OR
geom IS NULL)
"enforce_srid_geom" CHECK (st_srid(geom) = 3003)
Has OIDs: no

>Truly, the most helpful thing at this point would be to collect a backtrace
showing where in the postgresql server it crashed. There are instructions on
how to do that here:
>
>http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows<http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows>
>
>In your case, as the backend is crashing you will want to use windbg or
Visual Studio Express Edition to collect the crash data; process explorer
will not be enough.

ok, now I try to do this backtrace.

Regards,

Andrea.

2010/10/3 Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>

> On 2/10/2010 9:08 PM, Andrea Peri wrote:
>
>> Hi,
>>
>> I'm using usually
>> Postgres 8.4.4 (32bit) + Postgis 1.5.1 on Windows7 64bit.
>>
>> Now I try-ing the last
>> Postgres 9.0 (32bit) + Postgis 1.5.2 on the same machine (win7 64bit).
>>
>> I experience a
>>
>> crash of Postgres while it is running a huge load of data.
>>
>
> Does that include PostGIS datatypes?
>
>
> 2010-10-01 22:44:20 CEST LOG: server process (PID 2540) was terminated
>> by exception 0xC0000005
>>
>
> That's invalid memory access - like a UNIX segfault (sig11).
>
>
> Can you show your schema - the definition of the table(s) involved in the
> INSERT and any triggers on them? The output of:
>
> \d+ tablename
>
> from psql would do the trick.
>
>
>
> Truly, the most helpful thing at this point would be to collect a backtrace
> showing where in the postgresql server it crashed. There are instructions on
> how to do that here:
>
>
> http://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Windows
>
> In your case, as the backend is crashing you will want to use windbg or
> Visual Studio Express Edition to collect the crash data; process explorer
> will not be enough.
>
> --
> Craig Ringer
>
> Tech-related writing at http://soapyfrogs.blogspot.com/
>

--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------

On 10/03/2010 05:11 PM, Andrea Peri wrote:
> Hi, thx for response.
>
> >Does that include PostGIS datatypes?
>
> yes, but after some email with the guys of Posgis team , I think the
> problem is related to postgres.
>
> (see this thread on postgis ML):
> http://postgis.refractions.net/pipermail/postgis-users/2010-October/027841.html
>
> The postgis team was using a my script sql (about 10mbyte, 1Mb compress)
> that always crash a PG9 32bit on windows7 64 bit.

While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
been able to get a backtrace yet. I thought it'd be trivial given the
ease of reproducing the crash - but the process that's crashing isn't
the backend running the query.

It looks like it's one of the helpers like the stats collector, autovac,
bgwriter, etc. I'm unsure which yet. I've had to go to work, so I won't
be able to pick it up again until much later today. When I get back I'll
turn the logging right up, set windbg up as the post-mortem debugger and
catch it that way.

I'm currently testing to see if I can reproduce the issue under linux as
well.

--
Craig Ringer

Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
> While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
> been able to get a backtrace yet. I thought it'd be trivial given the
> ease of reproducing the crash - but the process that's crashing isn't
> the backend running the query.

> It looks like it's one of the helpers like the stats collector, autovac,
> bgwriter, etc. I'm unsure which yet.

I'd bet on autovacuum. You might be able to reproduce the crash in the
foreground process by issuing a manual VACUUM or ANALYZE.

regards, tom lane

On 04/10/10 10:56, Tom Lane wrote:
> Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
>> While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
>> been able to get a backtrace yet. I thought it'd be trivial given the
>> ease of reproducing the crash - but the process that's crashing isn't
>> the backend running the query.
>
>> It looks like it's one of the helpers like the stats collector, autovac,
>> bgwriter, etc. I'm unsure which yet.
>
> I'd bet on autovacuum. You might be able to reproduce the crash in the
> foreground process by issuing a manual VACUUM or ANALYZE.

Thanks for the tip.

I can't reproduce this under Linux, so it'll be back to the Windows
gaming/testing desktop when I get home to see if I can catch it there.

--
Craig Ringer

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

Hi,

I have do some other test.

I set
autovacuum = off.
With this setting the server don't crash.

But certainly something go bad.
Infact
if (after run the query) I connect with posql as user 'postgres' and try
a single command
VACUUM;

nothing happened.

But if I try a
single command
ANALYZE;
the server crash istantly.

After this I restart the server and
re-try reconnecting to PG9 but without re-run the query script.

again
if a run
ANALYZE the server crash.

I think the script has insert write something wrong in a table and after
this insert.
Always time someone (autovacuum or user) try an analyze
this cause the crash.

however seem to be the analyze to do the crash, not the vacuum.

Perhaps to problem is in the INSERT INTO.
that put sometime that the old PG8.4.4 can understand and use, meanwhile
PG) don't understand or is not capable to use.

for example, I use often some field of big size:
VARCHAR(200000)

the next try I do is to remove the postgis components to see if again
this happened.

Andrea.

Il 04/10/2010 04:56, Tom Lane ha scritto:
> Craig Ringer<craig(at)postnewspapers(dot)com(dot)au> writes:
>> While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
>> been able to get a backtrace yet. I thought it'd be trivial given the
>> ease of reproducing the crash - but the process that's crashing isn't
>> the backend running the query.
>> It looks like it's one of the helpers like the stats collector, autovac,
>> bgwriter, etc. I'm unsure which yet.
> I'd bet on autovacuum. You might be able to reproduce the crash in the
> foreground process by issuing a manual VACUUM or ANALYZE.
>
> regards, tom lane
>

On 4/10/2010 10:56 AM, Tom Lane wrote:
> Craig Ringer<craig(at)postnewspapers(dot)com(dot)au> writes:
>> While it's consistently crashing my Pg 9 on win7 32-bit, too, I haven't
>> been able to get a backtrace yet. I thought it'd be trivial given the
>> ease of reproducing the crash - but the process that's crashing isn't
>> the backend running the query.
>
>> It looks like it's one of the helpers like the stats collector, autovac,
>> bgwriter, etc. I'm unsure which yet.
>
> I'd bet on autovacuum. You might be able to reproduce the crash in the
> foreground process by issuing a manual VACUUM or ANALYZE.

Thanks. I wasn't able to get the backend running the script to crash
initially, even with an explicit VACUUM, ANALYZE, or VACUUM ANALYZE.
After turning autovacuum off completely, though, it does crash when
ANALYZE is run.

> postgres.exe!pfree(void * pointer=0x68f08610) Line 591 + 0x3 bytes C
> postgres.exe!examine_attribute(RelationData * onerel=0x00000000, int attnum=5, Node * index_expr=0x00000000) Line 877 C
> postgres.exe!do_analyze_rel(RelationData * onerel=0x01747b48, VacuumStmt * vacstmt=0x01690580, char update_reltuples='
', char inh=0) Line 357 + 0xa bytes C
> postgres.exe!analyze_rel(unsigned int relid=131097, VacuumStmt * vacstmt=0x01690580, BufferAccessStrategyData * bstrategy=0x018fc0f0, char update_reltuples='
') Line 232 C
> postgres.exe!vacuum(VacuumStmt * vacstmt=0x01690580, unsigned int relid=0, char do_toast='
', BufferAccessStrategyData * bstrategy=0x018fc0f0, char for_wraparound=0, char isTopLevel='
') Line 248 C
> postgres.exe!standard_ProcessUtility(Node * parsetree=0x01690580, const char * queryString=0x0168fc78, ParamListInfoData * params=0x00000000, char isTopLevel='
', _DestReceiver * dest=0x01690730, char * completionTag=0x004ff998) Line 1012 + 0x13 bytes C
> postgres.exe!PortalRunUtility(PortalData * portal=0x00000000, Node * utilityStmt=0x00000000, char isTopLevel='
', _DestReceiver * dest=0x01690730, char * completionTag=0x004ff998) Line 1199 C
> postgres.exe!PortalRunMulti(PortalData * portal=0x00000000, char isTopLevel='
', _DestReceiver * dest=0x01690730, _DestReceiver * altdest=0x01690730, char * completionTag=0x004ff998) Line 1298 + 0x11 bytes C
> postgres.exe!PortalRun(PortalData * portal=0x016dd028, long count=2147483647, char isTopLevel='
', _DestReceiver * dest=0x01690730, _DestReceiver * altdest=0x01690730, char * completionTag=0x004ff998) Line 823 + 0x17 bytes C
> postgres.exe!exec_simple_query(const char * query_string=0x00000000) Line 1059 C
> postgres.exe!PostgresMain(int argc=2, char * * argv=0x01635220, const char * username=0x009780b0) Line 3871 C
> postgres.exe!BackendRun(Port * port=0x00000002) Line 3550 + 0x17 bytes C
> postgres.exe!SubPostmasterMain(int argc=3, char * * argv=0x00972878) Line 4042 + 0x8 bytes C
> postgres.exe!main(int argc=3, char * * argv=0x00972878) Line 165 + 0x7 bytes C
> postgres.exe!__tmainCRTStartup() Line 586 + 0x17 bytes C
> kernel32(dot)dll!(at)BaseThreadInitThunk@12() + 0x12 bytes
> ntdll(dot)dll!___RtlUserThreadStart(at)8() + 0x27 bytes
> ntdll(dot)dll!__RtlUserThreadStart(at)8() + 0x1b bytes

It's crashing in pfree, as called by examine_attribute here:

if (!ok || stats->compute_stats == NULL || stats->minrows <= 0)
{
pfree(stats->attrtype);
pfree(stats->attr); <-- crash
pfree(stats);
return NULL;
}

... which is palloc'd earlier in examine_attribute.

VC++ is having trouble examining the locals in examine_attribute(); I'm
unsure if this is an optimization issue, lack of full debug info, or
something wrong with the state of the stack.

It's definitely crashing while analyzing the relation "suolo" - not only
do the logs show analysis beginning, but onerel->rd_rel->relname is
"suolo". At the time of the crash it seems to have already added the
column with attr->attname = "codpoligono" to vacattrstats and is
examining the column with attnum=5 when it crashes. A quick look at
pg_class and pg_attribute shows that this is (surprise!) the "geom"
column of type "geometry".

PostGIS on Windows is a bit outside my depth, especially as it's not a
neat crash in the analyze function its self. Hopefully this'll give the
PostGIS folks something to go on, though. Andrea: please pass it on.

--
Craig Ringer

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

Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> writes:
> After turning autovacuum off completely, though, it does crash when
> ANALYZE is run.

>> postgres.exe!pfree(void * pointer=0x68f08610) Line 591 + 0x3 bytes C
>> postgres.exe!examine_attribute(RelationData * onerel=0x00000000, int attnum=5, Node * index_expr=0x00000000) Line 877 C
>> postgres.exe!do_analyze_rel(RelationData * onerel=0x01747b48, VacuumStmt * vacstmt=0x01690580, char update_reltuples='
', char inh=0) Line 357 + 0xa bytes C

Hmm. That is suspiciously close to the location of some last-minute
changes in Postgres 9.0. I wonder whether Andrea is using a version of
PostGIS that was compiled against pre-9.0RC1 Postgres sources. If they
weren't accounting for this patch:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=67becf8d41a082eaaf6db6e0860d49409b79e32b
then we could easily have a crash right about here --- in fact it looks
like this is exactly what you'd get, because the extension would think
that the compute_stats field is where attrtype now is, so the
"pfree(stats->attrtype)" would be trying to pfree a function address.

In short, what we've got here is a version skew problem. That doubtless
explains why Craig couldn't duplicate it on his Linux machine.

regards, tom lane

On 5/10/2010 10:02 AM, Tom Lane wrote:
> Craig Ringer<craig(at)postnewspapers(dot)com(dot)au> writes:
>> After turning autovacuum off completely, though, it does crash when
>> ANALYZE is run.
>
>>> postgres.exe!pfree(void * pointer=0x68f08610) Line 591 + 0x3 bytes C
>>> postgres.exe!examine_attribute(RelationData * onerel=0x00000000, int attnum=5, Node * index_expr=0x00000000) Line 877 C
>>> postgres.exe!do_analyze_rel(RelationData * onerel=0x01747b48, VacuumStmt * vacstmt=0x01690580, char update_reltuples='
', char inh=0) Line 357 + 0xa bytes C
>
> Hmm. That is suspiciously close to the location of some last-minute
> changes in Postgres 9.0. I wonder whether Andrea is using a version of
> PostGIS that was compiled against pre-9.0RC1 Postgres sources.

If so, I am to and it's the latest PostGIS binary from their website.

> In short, what we've got here is a version skew problem. That doubtless
> explains why Craig couldn't duplicate it on his Linux machine.

Yep, 'cos I built PostGIS directly against the installed Pg on my linux box.

I'm about to head for work. When I get back I'll build PostGIS locally
and see if the problem conveniently goes away.

--
Craig Ringer

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