Re: [BUGS] Incorrect type in pg_cast causes Postmaster to core dump
От | Tom Lane |
---|---|
Тема | Re: [BUGS] Incorrect type in pg_cast causes Postmaster to core dump |
Дата | |
Msg-id | 12508.1492785375@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [BUGS] Incorrect type in pg_cast causes Postmaster to core dump (Greg Clough <greg.clough@enterprisedb.com>) |
Список | pgsql-bugs |
Greg Clough <greg.clough@enterprisedb.com> writes: > I realise that my types were wrong (function returned an "integer", and > should have returned a "numeric"), and I've fixed that and now it's working > fine... but how can a type mismatch cause the entire cluster to crash? Trivially. You told the system it should use "bool_to_num (boolean) RETURNS integer" to coerce boolean to numeric, so it expected what came out of the function to be numeric --- which is a pass-by-reference type, so the Datum value should be a pointer, which something or other would've tried to dereference. The actual value was just an integer "1" though, which is not a valid pointer, so you got a SIGSEGV. There are no training wheels for Postgres superusers. If you put broken entries into the system catalogs using superuser powers, you can break the database arbitrarily badly. As Michael noted, the type compatibility check that's needed here exists in CREATE CAST, not at runtime. CREATE CAST would have done other essential housekeeping as well, such as creating a pg_depend entry to prevent the function from being dropped out from under the cast. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: