how to correctly react on exception in pfree function?

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Julien Rouhaud <rjuju123(at)gmail(dot)com>
Subject: how to correctly react on exception in pfree function?
Date: 2022-10-12 19:35:31
Message-ID: CAFj8pRB2+pVBFsidS-AzhHdZid40OTUspWfXS0vgahHmaWosZQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi

I had a talk with Julien about the correct handling of an exception raised
by pfree function.

Currently, this exception (elog(ERROR, "could not find block containing
chunk %p", chunk);) is not specially handled ever. Because the check of
pointer sanity is executed first (before any memory modification), then it
is safe to repeatedly call pfree (but if I read code correctly, this
behavior is not asserted or tested).

The question is - What is the correct action on this error. In the end,
this exception means detection of memory corruption. One, and probably safe
way is raising FATAL error. But it looks like too hard a solution and not
too friendly. Moreover, this way is not used in the current code base.

The traditional solution is just raising the exception and doing nothing
more. I didn't find code, where the exception from pfree is exactly
handled. Similar issues with the possible exception from pfree can be in
plan cache, plpgsql code cache, partially in implementation of update of
plpgsql variable. Everywhere the implementation is not too strict - just
the exception is raised, but the session continues (although in this moment
we know so some memory is corrupted).

Is it a common strategy in Postgres?

Regards

Pavel

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-10-12 19:50:31 Re: Tracking last scan time
Previous Message Andres Freund 2022-10-12 19:27:54 Re: Summary function for pg_buffercache