RE: [PATCH][BUG FIX] Unsafe access pointers. - Mailing list pgsql-hackers

From Ranier Vilela
Subject RE: [PATCH][BUG FIX] Unsafe access pointers.
Date
Msg-id MN2PR18MB292780E1F07F3C4E7FE9D63DE3700@MN2PR18MB2927.namprd18.prod.outlook.com
Whole thread Raw
In response to Re: [PATCH][BUG FIX] Unsafe access pointers.  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
Hi,
Thank you for the explanation.

Best regards.
Ranier Vilela
________________________________________
De: Daniel Gustafsson <daniel@yesql.se>
Enviado: sexta-feira, 15 de novembro de 2019 11:58
Para: Ranier Vilela
Cc: pgsql-hackers@lists.postgresql.org
Assunto: Re: [PATCH][BUG FIX] Unsafe access pointers.

> On 15 Nov 2019, at 12:25, Ranier Vilela <ranier_gyn@hotmail.com> wrote:

> It's probably not happening, but it can happen, I think.

I don't think it can, given how elog() works.

> -     if (!HeapTupleIsValid(classtup))
> +     if (!HeapTupleIsValid(classtup)) {
>               elog(ERROR, "cache lookup failed for operator class %u", opclassoid);
> +        return false;

elog or ereport with a severity of ERROR or higher will never return.

> -     if (!HeapTupleIsValid(familytup))
> +     if (!HeapTupleIsValid(familytup)) {
>               elog(ERROR, "cache lookup failed for operator family %u", opfamilyoid);
> +         ReleaseSysCache(classtup);
> +        return false;
> +    }

Not only will elog(ERROR ..) not return to run this, the errorhandling
machinery will automatically release resources and clean up.

cheers ./daniel



pgsql-hackers by date:

Previous
From: Martin Liška
Date:
Subject: Re: segfault in geqo on experimental gcc animal
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] [WIP] Effective storage of duplicates in B-tree index.