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"
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 |