Em sex., 16 de jul. de 2021 às 09:41, Ranier Vilela
escreveu:
> Em sex., 16 de jul. de 2021 às 09:05, Aleksander Alekseev <
> aleksan...@timescale.com> escreveu:
>
>> Hi Rainer,
>>
>> > Here are the two patches.
>> > As suggested, reclassified as re
Em qua., 21 de jul. de 2021 às 07:44, David Rowley
escreveu:
> On Tue, 20 Jul 2021 at 10:49, Ranier Vilela wrote:
> > There are some places, where strlen can have an overhead.
> > This patch tries to fix this.
>
> I'm with Michael and David on this.
>
>
eapTupleIsValid(tuple))
+ {
+ elog(ERROR, "cache lookup failed for operator family %u",
pathkey->pk_opfamily);
+ }
4. Assertion not ok here?
+ em = find_em_for_rel(pathkey->pk_eclass, baserel);
+ em_expr = em->em_expr;
Assert(em_expr != NULL);
find_em_for_rel function can return
Em qua., 21 de jul. de 2021 às 09:28, Ranier Vilela
escreveu:
> Em qua., 21 de jul. de 2021 às 07:44, David Rowley
> escreveu:
>
>> On Tue, 20 Jul 2021 at 10:49, Ranier Vilela wrote:
>> > There are some places, where strlen can have an overhead.
>> > This p
Em qui., 22 de jul. de 2021 às 04:00, Ronan Dunklau
escreveu:
> Le jeudi 22 juillet 2021, 02:16:52 CEST Ranier Vilela a écrit :
> > Unfortunately your patch does not apply clear into the head.
> > So I have a few suggestions on v2, attached with the .txt extension to
> > avo
too. I'm attaching both patches to trigger
> cfbot and to double-check them.
>
Thanks Aleksander, for reviewing this.
regards,
Ranier Vilela
ope.
No need to backpatch.
regards,
Ranier Vilela
fix_memory_leak_postgres_fdw.patch
Description: Binary data
Em sex., 23 de jul. de 2021 às 11:32, Tom Lane escreveu:
> Ranier Vilela writes:
> > This is a minor leak, oversight in
> >
> https://github.com/postgres/postgres/commit/4526951d564a7eed512b4a0ac3b5893e0a115690#diff-e399f5c029192320f310a79f18c20fb18c8e916fee993237f6f82f05da
We really ought to just remove every single use of long.
>
> I have no objection to that as a long-term goal. But I'm not volunteering
> to do all the work, and in any case it wouldn't be a back-patchable fix.
>
I'm a volunteer, if you want to work together.
I think int64 is in most cases the counterpart of *long* on Windows.
regards,
Ranier Vilela
Em dom., 25 de jul. de 2021 às 15:53, Tom Lane escreveu:
> Ranier Vilela writes:
> > I think int64 is in most cases the counterpart of *long* on Windows.
>
> I'm not particularly on board with s/long/int64/g as a universal
> solution.
Sure, not a universal solution, I m
Em qua., 28 de jul. de 2021 às 21:25, Tom Lane escreveu:
> I wrote:
> > Andres Freund writes:
> >> Hm. It seems we should be able to guarantee that the recovery path can
> print
> >> something, at least in the PGconn case. Is it perhaps worth pre-sizing
> >> PGConn->errorMessage so it'd fit an e
Em qui., 29 de jul. de 2021 às 00:40, Tom Lane escreveu:
> Ranier Vilela writes:
> > IMO, I think that "char *msg" is unnecessary, isn't it?
>
> > + if (!PQExpBufferBroken(errorMessage))
> > + res->errMsg = pqResultStrdup(res, errorMessage->data);
&
r will expand:
res->errMsg = msg ? msg : libpq_gettext("out of memory\n");
to
if (msg)
res->errMsg = msg;
else
res->errMsg = libpq_gettext("out of memory\n");
What IMHO is much more readable.
regards,
Ranier Vilela
;
> Next I think I'll run microbenchmarks on int64s with the test harness you
> attached earlier, and experiment with the qsort parameters a bit.
>
> I'm also attaching your tuplesort patch so others can see what exactly I'm
> comparing.
>
The patch attached does not apply cleanly,
please can fix it?
error: patch failed: src/backend/utils/sort/tuplesort.c:4776
error: src/backend/utils/sort/tuplesort.c: patch does not apply
regards,
Ranier Vilela
n (libc.so.6)
> #14 0x00485e3e _start (postgres)
>
> Is there a bug in the commit 41c6a5be? Please confirm it.
>
Did you test it on the HEAD too?
regards,
Ranier Vilela
Therefore when `tb->size == SH_MAX_SIZE/2` and we call `SH_GROW(tb,
> tb->size * 2)`,
> then SH_GROW(tb, 0) is called due to truncation.
> And SH_COMPUTE_PARAMETERS is also accepts `uint32 newsize`.
>
> Ahh... ok, patch is updated to fix this as well.
>
It seems that we need to fix the function prototype too.
/* void _grow(_hash *tb) */
-SH_SCOPE void SH_GROW(SH_TYPE * tb, uint32 newsize);
+SH_SCOPE void SH_GROW(SH_TYPE * tb, uint64 newsize);
regards,
Ranier Vilela
sizemask = tb->size - 1;
> > > > + tb->sizemask = (uint32)(size - 1);
> > >
> > > ISTM using ~0 would be nicer here?
> >
> > I don't think so.
> > To be rigid it should be `~(uint32)0`.
> > But I believe it doesn't differ from `tb->sizemask = (uint32)(size - 1)`
> > that is landed with patch, therefore why `if` is needed?
>
> Personally I find it more obvious to understand the intended behaviour
> with ~0 (i.e. all bits set) than with a width truncation.
>
https://godbolt.org/z/57WcjKqMj
The generated code is identical.
regards,
Ranier Vilela
nal process are created or is this an expected behavior.
>
This is a normal and expected behavior.
pgsql-hackers@, is not an appropriate place to such questions.
regards,
Ranier Vilela
o
> > knows if there end up being some unintentional side-effects...
>
> Because it'd allow us to run more tests as part of cfbot and other CI
> efforts, I'd like to push this forward. So I'm planning to commit this
> to master soon-ish, unless somebody wants to take
ing with postgres on Windows).
>
It seems good to me.
Please, take a look at the new version attached.
If possible can you review the tests if there is an overflow at
pg_hex_encode and pg_hex_decode functions?
regards,
Ranier Vilela
0001-improve-hex-functions-handling.patch
Description: Binary data
Em seg., 16 de ago. de 2021 às 13:19, Hans Buschmann
escreveu:
> --
> *Von:* Ranier Vilela
> *Gesendet:* Montag, 16. August 2021 17:04
> *An:* Hans Buschmann
> *Cc:* pgsql-hack...@postgresql.org
> *Betreff:* Re: PG14: Avoid checking output-buffe
Em ter., 17 de ago. de 2021 às 00:43, Michael Paquier
escreveu:
> On Mon, Aug 16, 2021 at 02:06:31PM -0300, Ranier Vilela wrote:
> > uint64 and size_t in 64 bits are equivalents.
> > uint64 and size_t in 32 bits can be weird, but anyway size_t at 32 bits
> can
> >
Em ter., 17 de ago. de 2021 às 05:04, Michael Paquier
escreveu:
> On Fri, Jul 02, 2021 at 06:22:56PM -0300, Ranier Vilela wrote:
> > Em qui., 1 de jul. de 2021 às 17:20, Mahendra Singh Thalor <
> > mahi6...@gmail.com> escreveu:
> >> Please can we try to hit this r
Em ter., 17 de ago. de 2021 às 10:22, Greg Nancarrow
escreveu:
> On Tue, Aug 17, 2021 at 9:13 PM Ranier Vilela wrote:
> >
> > If that's conditions happen, all *result.index* touches are garbage.
> >
>
> The patch looks valid to me, as the "index" mem
Em qua., 18 de ago. de 2021 às 05:30, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Tue, 17 Aug 2021 17:04:44 +0900, Michael Paquier
> wrote in
> > On Fri, Jul 02, 2021 at 06:22:56PM -0300, Ranier Vilela wrote:
> > > Em qui., 1 de jul. de 2021 às 1
easing NAMEDATALEN for maybe 128 bytes in future
> releases.
>
+1 once that Oracle Database 12.2 and higher, has support for 128 bytes
names.
What possibly, in the future, could impact some migration from Oracle to
Postgres.
regards,
Ranier Vilela
Em qua., 18 de ago. de 2021 às 09:33, Laurenz Albe
escreveu:
> On Wed, 2021-08-18 at 08:16 -0300, Ranier Vilela wrote:
> > Em qua., 18 de ago. de 2021 às 08:08, Денис Романенко <
> deromane...@gmail.com> escreveu:
> > > Hello dear hackers. I understand the position of
)
>>
>> --
>> Best regards,
>> Alexander Pyhalov,
>> Postgres Professional
>
> Hi,
> For 0001 patch:
>
> + if ((s->op != SVFOP_CURRENT_TIMESTAMP) &&
> + (s->op != SVFOP_CURRENT_TIMESTAMP_N) &&
> + (s->op != SVFOP_CURRENT_TIME) &&
> ...
>
> The above check appears more than once. If extracted into a helper method,
> it would help reduce duplicate and make the code more readable.
>
Perhaps in a MACRO?
regards,
Ranier Vilela
_OK) < 0)
> ```
> 4. https://github.com/citusdata/citus/pull/3181
> 5. https://github.com/citusdata/pg_auto_failover/pull/266
> 6. https://github.com/JelteF/postgres/pull/2
> 7.
> ```patch
> @@ -2863,7 +2886,8 @@ palloc_btree_page(BtreeCheckState *state,
> BlockNumber blocknum)
> * longer than we must.
> */
> Buffer buffer = ReadBufferExtended(state->rel, MAIN_FORKNUM, blocknum,
> RBM_NORMAL,
> - state->checkstrategy);
> + state->checkstrategy);
> +
> LockBuffer(buffer, BT_READ);
>
> /*
> ```
> 8. https://github.com/XAMPPRocky/tokei
>
>
> Obligatory jokes:
> 1. https://xkcd.com/1171/
> 2. https://xkcd.com/208/
> 3. https://stackoverflow.com/a/1732454/2570866 (and serious response to
> it
> https://neilmadden.blog/2019/02/24/why-you-really-can-parse-html-and-anything-else-with-regular-expressions/
> )
>
-1 in short.
C needs readability, not fewer lines.
Aside from horrible code, it doesn't improve 0.1% on anything.
I think it's a bad idea and I'm strongly against it.
regards,
Ranier Vilela
temp read=171 written=171
> I/O Timings: temp read=0.487 write=2.073
> Planning Time: 0.041 ms
> Execution Time: 59.928 ms
> (8 rows)
>
> Feedback is very welcome.
>
The presentation seems a little confusing, wouldn't it be better?
I/O Timings: shared/local read= write=xxx temp read=0.487 write=2.073
I think can remove this lines:
+ if (has_temp_timing)
+ appendStringInfoChar(es->str, ',');
regards,
Ranier Vilela
Em sex., 20 de ago. de 2021 às 04:13, Alexander Pyhalov <
a.pyha...@postgrespro.ru> escreveu:
> Hi.
>
> Ranier Vilela писал 2021-08-19 14:01:
> > Em qui., 19 de ago. de 2021 às 07:50, Zhihong Yu
> >> Hi,
> >> For 0001 patch:
> >>
> >&
Em sex., 20 de ago. de 2021 às 09:18, Alexander Pyhalov <
a.pyha...@postgrespro.ru> escreveu:
> Ranier Vilela писал 2021-08-20 14:19:
>
> > Another question:
> > For 0002 patch:
> >
> > + if (node->funcid == F_NOW)
> > + {
> > + SQLValueFunction
g and assertions at the top of the function,
instead of having to put declarations in front of it. This makes it clear
which invariants hold for the function.
And you can easily forget to validate some variable you're not seeing is
several lines down.
There is a reason why GMs Brian Kernighan and Dennis Ritchie made the C89,
less buggy.
IMHO C99 makes it easy to make more mistakes.
One more step and we won't even need to declare a variable.
regards,
Ranier Vilela
Em sáb., 21 de ago. de 2021 às 12:02, Andrew Dunstan
escreveu:
>
> On 8/20/21 12:30 PM, Ranier Vilela wrote:
> >
> >
> > There is a reason why GMs Brian Kernighan and Dennis Ritchie made the
> > C89, less buggy.
> > IMHO C99 makes it easy to make more mist
Em ter., 24 de ago. de 2021 às 03:11, Masahiko Sawada
escreveu:
> On Mon, Aug 23, 2021 at 10:46 AM Masahiko Sawada
> wrote:
> >
> > On Thu, Aug 19, 2021 at 10:52 PM Ranier Vilela
> wrote:
> > >
> > > Em qui., 19 de ago. de 2021 às 09:21, Masahiko Saw
would greatly appreciate your input.
>
list_copy_tail actually makes a new copy.
But callers of addRangeTableEntryForJoin,
expects to handle a list or NIL, if we free the memory,
Shouldn't I set the variable *colnames* to NIL, too?
best regards,
Ranier Vilela
I free the lists.
>
Seems like a better style.
Now you need to analyze whether the memory in question is not managed by a
Context and released in a block,
which would make this release useless.
best regards,
Ranier Vilela
use of colnames after calling addRangeTableEntryForJoin.
Better free at the end of the function, like 0002.
Tip 0001, 0002, 0003 numerations are to different patchs.
v1, v2, v3 are new versions of the same patch.
best regards,
Ranier Vilela
sec = mts.tv_nsec;
#eldef _WIN32_
struct timespec ts { long tv_sec; long tv_nsec; };
__int64 wintime;
GetSystemTimeAsFileTime((FILETIME*) &wintime);
wintime -= 1164447360i64; // 1jan1601 to 1jan1970
ts.tv_sec = wintime / 1000i64; // seconds
ts.tv_nsec = wintime % 1000i64 * 100; // nano-seconds
#else
struct timespec ts;
clock_gettime(CLOCK_MONOTONIC, &ts);
#endif
return (ts.tv_sec * 10L) + ts.tv_nsec;
}
best regards,
Ranier Vilela
socketPoll(int sock, int forRead, int forWrite,
time_t end_time)
FD_SET(sock, &except_mask);
/* Compute appropriate timeout interval */
- if (end_time == ((time_t) -1))
+ if (end_time_ns == -1)
ptr_timeout = NULL;
+ else if (end_time_ns == 0)
+ {
+ timeout.tv_sec = 0;
+ timeout.tv_usec = 0;
+
+ ptr_timeout = &timeout;
+ }
best regards,
Ranier Vilela
shipped by default with postgres at some
> point in the future.
>
If you want to have any hope, the license must be BSD.
GPL is incompatible.
best regards,
Ranier Vilela
gt; that behavior.
>
Thanks.
>
> * Ranier also suggested using clock_gettime instead of gettimeofday,
> but I see no reason to do that. libpq already relies on gettimeofday,
> but not on clock_gettime, and anyway post-beta1 isn't a great time to
> start experimenting with portability-relevant changes.
>
I agree.
For v18, it would be a case of thinking about not using it anymore
gettimeofday, as it appears to be deprecated.
best regards,
Ranier Vilela
ach host name
or IP address. For example, if you specify two hosts and connect_timeout is
5, each host will time out if no connection is made within 5 seconds, so
the total time spent waiting for a connection might be up to 10 seconds.
"
The comments says that timeout = 0, means *Timeout is immediate (no
blocking)*
Does the word "indefinitely" mean infinite?
If yes, connect_timeout = -1, mean infinite?
best regards,
Ranier Vilela
Em qui., 13 de jun. de 2024 às 12:25, Tom Lane escreveu:
> Ranier Vilela writes:
> > I'm unsure if the documentation matches the code?
> > " connect_timeout #
> > <
> https://www.postgresql.org/docs/current/libpq-connect.html#LIBPQ-CONNECT-CONNECT-TIMEOUT
implementation of strsep, it seems lighter to me.
I will attach it for consideration, however, I have not done any testing.
best regards,
Ranier Vilela
/* strsep.h
*
* Provides the 4.4BSD strsep(3) function for those that don't have it.
*
* Copyright 2011 Michael Thomas Greer
* Distri
ts, like the pg_privileges system view suggested in
> the
> related discussion.
>
> Tests and docs are added.
>
Hi,
For some reason, the function pg_get_acl, does not exist in generated
fmgrtab.c
So, when install postgres, the function does not work.
postgres=# SELECT pg_get_acl('pg_class'::regclass, 'atest2'::regclass::oid);
ERROR: function pg_get_acl(regclass, oid) does not exist
LINE 1: SELECT pg_get_acl('pg_class'::regclass, 'atest2'::regclass::...
^
HINT: No function matches the given name and argument types. You might
need to add explicit type casts.
best regards,
Ranier Vilela
, sorry but I'm on Windows -> meson.
Double checked with:
ninja clean
ninja
ninja install
best regards,
Ranier Vilela
Em qua., 19 de jun. de 2024 às 10:28, Ranier Vilela
escreveu:
> Em qua., 19 de jun. de 2024 às 10:26, Joel Jacobson
> escreveu:
>
>> Hi Ranier,
>>
>> Thanks for looking at this.
>>
>> I've double-checked the patch I sent, and it works fine.
&g
via the first mapping. The bypass
for these false positives is to use Memcheck's client requests
VALGRIND_MAKE_MEM_DEFINED and VALGRIND_MAKE_MEM_UNDEFINED to inform
Memcheck about what your program does (or what another process does) to
these shared memory mappings. "
best regards,
Ranier Vilela
t knows that the result of vector8_highbit_mask is
> only partly defined.
I wouldn't be surprised if *RT_NODE_16_GET_INSERTPOS*
(src/include/lib/radixtree.h),
does not suffer from the same problem?
Even with Assert trying to protect.
Does the fix not apply here too?
best regards,
Ranier Vilela
Em qui., 20 de jun. de 2024 às 08:54, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
>
>
> On 6/20/24 13:32, Ranier Vilela wrote:
> > Em qui., 20 de jun. de 2024 às 07:28, Tomas Vondra <
> > tomas.von...@enterprisedb.com> escreveu:
> >
> >>
ult, "LABEL: %s\n", state->name);
To fix, copy strlen size plus one byte, to include the null-termination.
Trivial patch attached.
best regards,
Ranier Vilela
avoid-incomplete-copy-string-do_pg_backup_start.patch
Description: Binary data
Em dom., 23 de jun. de 2024 às 21:08, Fabrízio de Royes Mello <
fabriziome...@gmail.com> escreveu:
>
> On Sun, 23 Jun 2024 at 20:51 Ranier Vilela wrote:
>
>> Hi.
>>
>> In src/include/access/xlogbackup.h, the field *name*
>> has one byte extra to store null-
ame is fixed with MAXPGPATH + 1, so it would
> be a better practice to use strlcpy() with sizeof(name) anyway?
>
It's not critical code, so I think it's ok to use strlen, even because the
result of strlen will already be available using modern compilers.
So, I think it's ok to u
Em dom., 23 de jun. de 2024 às 21:54, Michael Paquier
escreveu:
> On Sun, Jun 23, 2024 at 09:34:45PM -0300, Ranier Vilela wrote:
> > It's not critical code, so I think it's ok to use strlen, even because
> the
> > result of strlen will already be available using mod
Em dom., 23 de jun. de 2024 às 22:05, Ranier Vilela
escreveu:
> Em dom., 23 de jun. de 2024 às 21:54, Michael Paquier
> escreveu:
>
>> On Sun, Jun 23, 2024 at 09:34:45PM -0300, Ranier Vilela wrote:
>> > It's not critical code, so I think it's ok to use strlen,
Em dom., 23 de jun. de 2024 às 22:14, Ranier Vilela
escreveu:
> Em dom., 23 de jun. de 2024 às 22:05, Ranier Vilela
> escreveu:
>
>> Em dom., 23 de jun. de 2024 às 21:54, Michael Paquier <
>> mich...@paquier.xyz> escreveu:
>>
>>> On Sun, Jun 23, 202
Em dom., 23 de jun. de 2024 às 23:56, Richard Guo
escreveu:
> On Mon, Jun 24, 2024 at 7:51 AM Ranier Vilela wrote:
> > In src/include/access/xlogbackup.h, the field *name*
> > has one byte extra to store null-termination.
> >
> > But, in the function *do_pg_backup_st
Em seg., 24 de jun. de 2024 às 00:27, Yugo NAGATA
escreveu:
> On Sun, 23 Jun 2024 22:34:03 -0300
> Ranier Vilela wrote:
>
> > Em dom., 23 de jun. de 2024 às 22:14, Ranier Vilela >
> > escreveu:
> >
> > > Em dom., 23 de jun. de 2024 às 22:05
,
> message_id = 0x7f77cffdf022 0x7f77cffdf022>, schema_name = 0x0, table_name = 0x0, column_name = 0x0,
> datatype_name = 0x0, constraint_name = 0x0, cursorpos = 0, internalpos =
> 0,
> internalquery = 0x0, saved_errno = 2, assoc_context = 0x29fdb20}
>
> lineno = 843 matches the expected error location in int4_div().
>
Did you mean *int4div*, right?
Since there is no reference to int4_div in *.c or *.h
best regards,
Ranier Vilela
Em qui., 27 de jun. de 2024 às 01:01, Yugo NAGATA
escreveu:
> On Mon, 24 Jun 2024 08:25:36 -0300
> Ranier Vilela wrote:
>
> > Em dom., 23 de jun. de 2024 às 23:56, Richard Guo <
> guofengli...@gmail.com>
> > escreveu:
> >
> > > On Mon, Jun 24, 2024
Em qui., 27 de jun. de 2024 às 08:48, Ranier Vilela
escreveu:
> Em qui., 27 de jun. de 2024 às 01:01, Yugo NAGATA
> escreveu:
>
>> On Mon, 24 Jun 2024 08:25:36 -0300
>> Ranier Vilela wrote:
>>
>> > Em dom., 23 de jun. de 2024 às 23:56, Richard Guo <
&
efore executing xact cleanup.
In this case, I think that these fields, in struct definition struct
ErrorData (src/include/utils/elog.h)
should be changed too?
from const char * to char*
best regards,
Ranier Vilela
Em seg., 1 de jul. de 2024 às 06:20, Daniel Gustafsson
escreveu:
> > On 27 Jun 2024, at 13:50, Ranier Vilela wrote:
>
> > Now with file patch really attached.
>
> - if (strlen(backupidstr) > MAXPGPATH)
> + if (strlcpy(state->name, backupidstr, sizeof(s
Em seg., 1 de jul. de 2024 às 14:35, Ranier Vilela
escreveu:
> Em seg., 1 de jul. de 2024 às 06:20, Daniel Gustafsson
> escreveu:
>
>> > On 27 Jun 2024, at 13:50, Ranier Vilela wrote:
>>
>> > Now with file patch really attached.
>>
>> - if (s
Em seg., 1 de jul. de 2024 às 16:15, Alvaro Herrera
escreveu:
> On 2024-Jul-01, Ranier Vilela wrote:
>
> > > - charname[MAXPGPATH + 1];
> > > + charname[MAXPGPATH];/* backup label name */
> > >
> > > With the introduce
Em seg., 1 de jul. de 2024 às 16:20, Daniel Gustafsson
escreveu:
> > On 1 Jul 2024, at 21:15, Alvaro Herrera wrote:
> > On 2024-Jul-01, Ranier Vilela wrote:
>
> >>> - charname[MAXPGPATH + 1];
> >>> + char
kward-compatibility here, even if I suspect
> > there is close to nobody relying on backup label names of this size.
>
> I suspect so too, and it might be a good project for someone to go over
> such
> buffers to see if there is reason grow or contract. Either way, pushed the
> strlcpy part.
>
Thanks Daniel.
best regards,
Ranier Vilela
Em qui., 18 de abr. de 2024 às 14:43, Ranier Vilela
escreveu:
>
>
> Em qui., 18 de abr. de 2024 às 14:16, Andres Freund
> escreveu:
>
>> Hi,
>>
>> On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote:
>> > On 18/04/2024 00:39, Andres Freund wrote:
>>
scope for TupleDescAttr array dereference.
11. Remove useless duplicate test in ruleutils.
This is already checked at line 4566.
12. Remove useless duplicate test in string_utils.
This is already checked at line 982.
best regards,
Ranier Vilela
avoid-dereference-iss_SortSupport-array-if-has
not use the parameter
ExtensionInfo extinfo.
getExtensions does not have another caller, Is it really necessary?
best regards,
Ranier Vilela
ul_var_int.patch better.
I think that *var_digits can be const too.
+ const NumericDigit *var_digits = var->digits;
Typo In the comments:
- by procssing
+ by processing
best regards,
Ranier Vilela
Em qui., 4 de jul. de 2024 às 05:18, Daniel Gustafsson
escreveu:
> > On 3 Jul 2024, at 13:29, Ranier Vilela wrote:
>
> > With the function *getPublications* I think it would be good to free up
> the allocated memory?
> >
> > }
> > + pg_free(pubinfo);
securely initialize the default value for variable
*winstate->grouptail_ptr*
in *else* part.
if ((frameOptions & (FRAMEOPTION_EXCLUDE_GROUP |
FRAMEOPTION_EXCLUDE_TIES)) &&
node->ordNumCols != 0)
winstate->grouptail_ptr =
tuplestore_alloc_read_pointer(winstate->buffer, 0);
}
+ else
+ winstate->grouptail_ptr = -1;
best regards,
Ranier Vilela
Em seg., 10 de jul. de 2023 às 03:27, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Fri, 7 Jul 2023 11:29:16 -0700, Gurjeet Singh wrote
> in
> > On Fri, Jul 7, 2023 at 6:12 AM Ranier Vilela
> wrote:
> > >
> > > Hi,
> > >
> >
Hi Alena,
Em seg., 10 de jul. de 2023 às 05:38, Alena Rybakina <
lena.riback...@yandex.ru> escreveu:
> I agreed with the changes. Thank you for your work.
>
> I updated patch and added you to the authors.
>
> I specified Ranier Vilela as a reviewer.
>
Is a good habit wh
Em seg., 10 de jul. de 2023 às 09:03, Ranier Vilela
escreveu:
> Hi Alena,
>
> Em seg., 10 de jul. de 2023 às 05:38, Alena Rybakina <
> lena.riback...@yandex.ru> escreveu:
>
>> I agreed with the changes. Thank you for your work.
>>
>> I updated patc
Em ter., 11 de jul. de 2023 às 09:29, Alena Rybakina <
lena.riback...@yandex.ru> escreveu:
> Hi!
> On 10.07.2023 15:15, Ranier Vilela wrote:
>
> Em seg., 10 de jul. de 2023 às 09:03, Ranier Vilela
> escreveu:
>
>> Hi Alena,
>>
>> Em seg., 1
,
> then
> > output will be unexpected.
>
> I agree with Karina here. Either this patch should keep the
> "need_recordsep = true;" line, thus removing the no-op assignment to
> false and making the code slightly less unreadable; or the entire
> function should be ref
Em sex., 21 de jul. de 2023 às 09:13, Karina Litskevich <
litskevichkar...@gmail.com> escreveu:
>
>
> On Wed, Jul 12, 2023 at 1:46 AM Ranier Vilela wrote:
>
>> As there is consensus to keep the no-op assignment,
>> I will go ahead and reject the patch.
>>
&g
Hi,
Per Coverity.
rmtree function can leak 64 bytes per call,
when it can't open a directory.
patch attached.
best regards,
Ranier Vilela
0003-Avoid-possible-memory-leak-64-bytes-per-rmtree-call-.patch
Description: Binary data
regards,
Ranier Vilela
[1]
https://learn.microsoft.com/en-us/cpp/intrinsics/bitscanreverse-bitscanreverse64?view=msvc-170
0001-Avoid-undefined-behavior-with-msvc-compiler.patch
Description: Binary data
llocation after the OPENDIR() seems like
> a good practice anyway.
>
Thanks for the commit, Michael.
best regards,
Ranier Vilela
NSION" .
./src/backend/utils/activity/wait_event_types.h: WAIT_EVENT_EXTENSION =
PG_WAIT_EXTENSION
./src/include/utils/wait_event.h: WAIT_EVENT_EXTENSION = PG_WAIT_EXTENSION,
./src/include/utils/wait_event.h: WAIT_EVENT_EXTENSION_FIRST_USER_DEFINED
Not sure if this is really a mistake in my environment.
regards,
Ranier Vilela
Em ter., 1 de ago. de 2023 às 21:34, Masahiro Ikeda <
ikeda...@oss.nttdata.com> escreveu:
> On 2023-08-02 08:38, Ranier Vilela wrote:
> > Hi,
> >
> > On Tue, Aug 01, 2023 at 11:51:35AM +0900, Masahiro Ikeda wrote:
> >> Thanks for committing the main patch.
&g
Hi,
nFreeBlocks stores the number of free blocks and
your type is *long*.
At Function ltsGetFreeBlock is locally stored in
heapsize wich type is *int*
With Windows both *long* and *int* are 4 bytes.
But with Linux *long* is 8 bytes and *int* are 4 bytes.
patch attached.
best regards,
Ranier
Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas
escreveu:
> On 10/04/2024 21:07, Ranier Vilela wrote:
> > Hi,
> >
> > Per Coverity.
> >
> > The function ReorderBufferTXNByXid,
> > can return NULL when the parameter *create* is false.
> >
>
Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas
escreveu:
> On 11/04/2024 15:03, Ranier Vilela wrote:
> > Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas
> > mailto:hlinn...@iki.fi>> escreveu:
> >
> > On 10/04/2024 21:07, R
Em sáb., 13 de abr. de 2024 às 04:16, Heikki Linnakangas
escreveu:
> On 11/04/2024 16:37, Ranier Vilela wrote:
> > Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas
> > mailto:hlinn...@iki.fi>> escreveu:
> >
> > On 11/04/2024 15:03, Ranier Vilela wro
.
best regards,
Ranier Vilela
Em dom., 14 de abr. de 2024 às 20:38, David Rowley
escreveu:
> On Mon, 15 Apr 2024 at 11:17, Ranier Vilela wrote:
> > Coverity has reported some out-of-bounds bugs
> > related to the GetCommandTagName function.
> >
> > The size of the array is defined by COMMAND_
Em dom., 14 de abr. de 2024 às 23:12, David Rowley
escreveu:
> On Mon, 15 Apr 2024 at 12:12, Ranier Vilela wrote:
> >
> > Em dom., 14 de abr. de 2024 às 20:38, David Rowley
> escreveu:
> >> You seem to have forgotten to attach it, but my comments above were
>
Em dom., 14 de abr. de 2024 às 21:29, Michael Paquier
escreveu:
> On Sat, Apr 13, 2024 at 10:40:35AM -0300, Ranier Vilela wrote:
> > This sounds a little confusing to me.
> > Is the project policy to *tolerate* dereferencing NULL pointers?
> > If this is the case, no proble
In these places, I believe it is safe to add static,
allowing the compiler to transform into read-only, definitively.
Patch 005
best regards,
Ranier Vilela
0004-static-const-convert-plpython.patch
Description: Binary data
0005-const-convert-static-const.patch
Description: Binary data
Em qui., 18 de abr. de 2024 às 14:16, Andres Freund
escreveu:
> Hi,
>
> On 2024-04-18 09:07:43 -0300, Ranier Vilela wrote:
> > On 18/04/2024 00:39, Andres Freund wrote:
> > >There are lots of places that could benefit from adding 'static
> > >const'.
ary).
The function DisconnectDatabase effectively writes the ParallelSlot.AH.
So the call in the function archive_close_connection:
if (slot->AH)
DisconnectDatabase(&(slot->AH->public));
It should also be protected on Windows, correct?
Patch attached.
best regards,
Ranier Vilela
f
early.
Patch attached.
best regards,
Ranier Vilela
[1] terminate-tlsv1-3-handshake-if-alpn-is-missing
<https://stackoverflow.com/questions/77271498/terminate-tlsv1-3-handshake-if-alpn-is-missing>
terminate-tls-handshake-if-no-alpn.patch
Description: Binary data
Em seg., 29 de abr. de 2024 às 14:56, Heikki Linnakangas
escreveu:
> On 29/04/2024 20:10, Ranier Vilela wrote:
> > Hi,
> >
> > With TLS 1.3 and others there is possibly a security flaw using ALPN [1].
> >
> > It seems to me that the ALPN protocol can be by
Em seg., 29 de abr. de 2024 às 15:36, Heikki Linnakangas
escreveu:
> On 29/04/2024 21:06, Ranier Vilela wrote:
> > Em seg., 29 de abr. de 2024 às 14:56, Heikki Linnakangas
> > mailto:hlinn...@iki.fi>> escreveu:
> >
> > On 29/04/2024 20:10, R
O_TRUNC | O_EXCL |
PG_BINARY);
The flags:
O_WRONLY | O_TRUNC
Allow the OS to make some optimizations, if you deem it possible.
The flag O_RDWR indicates that the file can be read, which is not true in
this case.
The destination file will just be written.
best regards,
Ranier Vilela
501 - 600 of 997 matches
Mail list logo
