The following bug has been logged on the website:
Bug reference: 7881
Logged by: Andrew Gierth
Email address: andrew@tao11.riddles.org.uk
PostgreSQL version: 9.2.3
Operating system: any
Description: =
The range type code accepts SQL functions for subtype_diff, but stores the
flinfo in a long-lived context (typcache).
The SQL function handler, fmgr_sql, isn't prepared to deal with the
possibility that the fcache entry may be left over from a previous query
that failed.
The combination of these two allows a non-superuser to provoke at least an
assertion failure as follows:
create or replace function inet_subdiff(inet,inet) returns float8 language
sql immutable as $f$ select ($2 - $1)::float8; $f$;
create type inetrange as range (subtype =3D inet, subtype_diff =3D
inet_subdiff);
create table inetr as select
format('[%s::,%s::]',to_hex(i),to_hex(i+1))::inetrange as r from
generate_series(0,65534) i;
postgres=3D# create index inetr_idx on inetr using gist (r);
ERROR: result is out of range
CONTEXT: SQL function "inet_subdiff" statement 1
postgres=3D# create index inetr_idx on inetr using gist (r);
TRAP: FailedAssertion("!(snapshot->regd_count > 0)", File: "snapmgr.c",
Line: 557)
I'm inclined to think this is fmgr_sql's fault for apparently assuming that
if an error is thrown that it'll never see the fcache entry again, but in
this example that's clearly not true.
