Postgres Pro
Downloads
Home   >   mailing lists

Re: return correct error code from pgtls_init - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: return correct error code from pgtls_init
Date
Msg-id CALNJ-vTrWv7yc7vsriHVvBuVfNoJiW7K7ZZYeV99NHZ_b1dBtg@mail.gmail.com
Whole thread Raw
In response to Re: return correct error code from pgtls_init  (Michael Paquier <michael@paquier.xyz>)
Responses Re: return correct error code from pgtls_init
List pgsql-hackers
Tree view


On Tue, Jun 1, 2021 at 6:14 PM Michael Paquier <michael@paquier.xyz> wrote:
On Tue, Jun 01, 2021 at 10:32:59AM -0700, Zhihong Yu wrote:
> It seems error code checking in pgtls_init() should follow the same
> convention as PG codebase adopts - i.e. the non-zero error code should be
> returned (instead of hard coded -1).
>
> Please see the attached patch.

I don't see the point of changing this.  First, other areas of
fe-secure-openssl.c use a harcoded value of -1 as error codes, so the
current style is more consistent.  Second, if we were to change that,
why are you not changing one call of pthread_mutex_lock()?
--
Michael

Hi,
Looking at the -1 return, e.g.

            pq_lockarray = malloc(sizeof(pthread_mutex_t) * CRYPTO_num_locks()); 

when pq_lockarray is NULL. We can return errno.

I didn't change call to pthread_mutex_lock() because PGTHREAD_ERROR() is used which aborts.

Cheers

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: TAP tests still sensitive to various PG* environment variables
Next
From: Michael Paquier
Date:
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?