David Schnur <dnschnur@xxxxxxxxx> writes: > Sure; the function is created programmatically as part of schema creation, > by the same user who owns (almost) everything else in the database. The > definition looks like this: > CREATE OR REPLACE FUNCTION datastore_unpack( > data_times TIMESTAMP WITH TIME ZONE[], > data_values DOUBLE PRECISION[], > OUT data_time TIMESTAMP WITH TIME ZONE, > OUT data_value DOUBLE PRECISION > ) RETURNS SETOF RECORD AS $$ > SELECT $1[rowx] AS data_time, $2[rowx] AS data_value > FROM generate_series(1, array_upper($1, 1)) AS rowx; > $$ LANGUAGE SQL STABLE; No crash observed here. So either we fixed it since 8.3.15 (doesn't seem likely, as I see nothing potentially related in the commit logs), or the trigger for the problem is not (just) this function. It seems entirely plausible that the crash is associated with the next-to-be-dumped object rather than this one, anyway. How about that stack trace? Alternatively, if you have an idea of the next object it might be working on (most likely, the next function in alphabetical order) you might see if loading just that function into an empty database is enough to create a crash. It's also entirely plausible that the crash requires multiple objects to trigger it (for instance it might have something to do with inter-object dependencies). So if you're not eager to burrow into stack traces, you might see if you can strip your standard schema down to something you could post that still triggers the crash starting from an empty database. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin