Noah Misch writes:
> On Thu, Sep 01, 2022 at 03:35:52PM -0400, Tom Lane wrote:
>> I think we should reject Aleksander's patch, on the grounds that
>> it's now unnecessary --- or if you want to argue that it's still
>> necessary, then it's woefully inadequate, because there are surely
>> a bunch
On Thu, Sep 01, 2022 at 03:35:52PM -0400, Tom Lane wrote:
> Spyridon Dimitrios Agathos writes:
> > this is to verify that the .patch proposed here:
> > https://www.postgresql.org/message-id/flat/2318797.1638558730%40sss.pgh.pa.us
> > fixes the issue.
>
> > Looking forward to the next steps.
>
>
Spyridon Dimitrios Agathos writes:
> this is to verify that the .patch proposed here:
> https://www.postgresql.org/message-id/flat/2318797.1638558730%40sss.pgh.pa.us
> fixes the issue.
> Looking forward to the next steps.
That's been committed into HEAD and v15, without pushback so far.
So the
Hi all,
this is to verify that the .patch proposed here:
https://www.postgresql.org/message-id/flat/2318797.1638558730%40sss.pgh.pa.us
fixes the issue. I applied the patch and:
1) The build type doesn't affect the result of the query result
2) The valgrind doesn't complain about out of bound
В письме от среда, 13 июля 2022 г. 16:14:39 MSK пользователь Aleksander
Alekseev написал:
Hi! Let me join the review process. Postgres data types is field of expertise I
am interested in.
0. Though it looks like a steady bug, I can't reproduce it. Not using
valgrind, not using ASan (address
Andrew Dunstan writes:
> On 2022-07-13 We 11:11, Tom Lane wrote:
>> I complained about this in [1], but that thread died off before reaching a
>> clear consensus about exactly what to do.
>> [1]
>> https://www.postgresql.org/message-id/flat/2318797.1638558730%40sss.pgh.pa.us
> Looks like the
On 2022-07-13 We 11:11, Tom Lane wrote:
> Aleksander Alekseev writes:
>> Although the bug is easy to fix for this particular case (see the
>> patch) I'm not sure if this solution is general enough. E.g. is there
>> something that generally prevents pg_mblen() from doing out of bound
>> reading
On Wed, 13 Jul 2022 at 09:15, Aleksander Alekseev
wrote:
I can confirm the bug exists in the `master` branch as well and
> doesn't depend on the platform.
>
> Although the bug is easy to fix for this particular case (see the
> patch) I'm not sure if this solution is general enough. E.g. is there
Aleksander Alekseev writes:
> Although the bug is easy to fix for this particular case (see the
> patch) I'm not sure if this solution is general enough. E.g. is there
> something that generally prevents pg_mblen() from doing out of bound
> reading in cases similar to this one? Should we prevent
Hi Spyridon,
> The column "single_byte_col" is supposed to store only 1 byte. Nevertheless,
> the INSERT command implicitly casts the '' text into "char". This means that
> only the first byte of '' ends up stored in the column.
> gdb reports that "pg_mblen(p) = 4" (line 1046), which is
Hi hackers,
While I was writing a test for PSQL, I faced a weird scenario. Depending on
how I build PSQL (enabling or not debug options), I saw different results
for the following query.
Steps to reproduce:
- OS: Ubuntu 20.04
- PSQL version 14.4
CREATE TABLE test (single_byte_col "char");
11 matches
Mail list logo
