Re: Add null termination to string received in parallel apply worker

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add null termination to string received in parallel apply worker
Date: 2023-10-11 15:14:24
Message-ID: 202310111514.soqok7g65vit@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023-Oct-11, Amit Kapila wrote:

> Yeah, it may not be a good idea to modify the buffer pointing to
> shared memory without any lock as we haven't reserved that part of
> memory. So, we can't follow the trick used in exec_bind_message() to
> maintain the convention that StringInfos have a trailing null. David,
> do you see any better way to fix this case?

I was thinking about this when skimming the other StringInfo thread a
couple of days ago. I wondered if it wouldn't be more convenient to
change the convention that all StringInfos are null-terminated: what is
really the reason to have them all be like that? We do keep track of
the exact length of the data in it, so strictly speaking we don't need
the assumption. Maybe there are some routines that are fragile and end
up reading more data thn 'len' if the null terminator is missing; we
could fix those instead. Right now, it seems we're doing some
pstrdup'ing and unconstification just to be able to install a \0 in the
right place.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Use it up, wear it out, make it do, or do without"

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Imseih (AWS), Sami 2023-10-11 15:26:49 Re: Logging parallel worker draught
Previous Message Tommy Pavlicek 2023-10-11 15:11:00 Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges