Re: Improve LWLock tranche name visibility across backends - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: Improve LWLock tranche name visibility across backends
Date
Msg-id CAA5RZ0ve-fHuNYW-ruMwg1y1v7-aCqMm_MiNq1KOdg2Y2-pKDw@mail.gmail.com
Whole thread Raw
In response to Re: Improve LWLock tranche name visibility across backends  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Improve LWLock tranche name visibility across backends
List pgsql-hackers
Thanks for reviewing!

> === 1
>
> We need to check if tranche_name is NULL and report an error if that's the case.
> If not, strlen() would segfault.

Added an error. Good call. The error message follows previously used
convention.

```
+       if (!tranche_name)
+               elog(ERROR, "tranche name cannot be null");
```

> === 2
>
> +       if (tranche_name_length > MAX_NAMED_TRANCHES_NAME_LEN)
> +               elog(ERROR, "tranche name too long");
>
> I think that we should mention in the doc that the tranche name is limited to
> 63 bytes.

Done. I just mentioned NAMEDATALEN -1 in the docs.

> === 3
>
> I was skeptical about using strcpy() while we hold a spinlock. I do see some
> examples with strlcpy() though (walreceiver.c for example), so that looks OK-ish.
>
> Using strcpy() might be OK too, as we already have validated the length, but maybe
> it would be safer to switch to strlcpy(), instead?

OK, since that is the pattern used, I changed to strlcpy. But since we are doing
checks in advance, I think it will be safe either way.

--
Sami

Attachment

pgsql-hackers by date:

Previous
From: Melanie Plageman
Date:
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)
Next
From: Noah Misch
Date:
Subject: Re: Buffer locking is special (hints, checksums, AIO writes)