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);
hat *var_digits can be const too.
+ const NumericDigit *var_digits = var->digits;
Typo In the comments:
- by procssing
+ by processing
best regards,
Ranier Vilela
se the parameter
ExtensionInfo extinfo.
getExtensions does not have another caller, Is it really necessary?
best regards,
Ranier Vilela
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
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:
>>
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 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
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 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.
>>
>>
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
ase, 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 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 <
&
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, J
= 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 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
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
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 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, even be
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 modern compil
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 use memcpy with
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-
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 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:
> >
> >>
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
g. 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
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.
>>
ry but I'm on Windows -> meson.
Double checked with:
ninja clean
ninja
ninja install
best regards,
Ranier Vilela
n
> 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
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
* Distributed under the B
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
>
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
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
ped 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
ompute 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 =
+ }
best regards,
Ranier Vilela
eAsFileTime((FILETIME*) );
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, );
#endif
return (ts.tv_sec * 10L) + ts.tv_nsec;
}
best regards,
Ranier Vilela
names 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
e 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
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
CREATE-DATABASE-induced checkpoints.
>
> Thoughts?
>
Why not use it too, if not binary_upgrade?
else
{
appendPQExpBuffer(creaQry, "CREATE DATABASE %s WITH TEMPLATE = template0
STRATEGY = FILE_COPY",
qdatname);
}
It seems to me that it also improves in any use.
best regards,
Ranier Vilela
Em qua., 5 de jun. de 2024 às 02:04, Michael Paquier
escreveu:
> On Wed, Jun 05, 2024 at 01:12:41PM +0900, Kyotaro Horiguchi wrote:
> > At Mon, 27 May 2024 11:31:24 -0300, Ranier Vilela
> wrote in
> >> The function *plpgsql_inline_handler* can use uninitialized
> >&
Em qua., 5 de jun. de 2024 às 01:12, Kyotaro Horiguchi <
horikyota@gmail.com> escreveu:
> At Mon, 27 May 2024 11:31:24 -0300, Ranier Vilela
> wrote in
> > Hi.
> >
> > The function *plpgsql_inline_handler* can use uninitialized
> > variable retval, if
concern now is that when the structure is saved to disk,
what are the padding fields like?
But enough noise.
Thanks for taking a look.
best regards,
Ranier Vilela
Em sex., 31 de mai. de 2024 às 05:03, Daniel Gustafsson
escreveu:
> > On 27 May 2024, at 16:52, Ranier Vilela wrote:
>
> > In the function *PQprint*, the variable po->fieldName can be NULL.
>
> Yes.
>
> > See the checks a few lines up.
>
> Indeed, let's
se use of structs with padding values is unspecified.
Fix by explicitly initializing with memset to avoid this.
best regards,
Ranier Vilela
avoid-undefined-compares-two-structs-with-padding-bytes-pg_rewind.patch
Description: Binary data
t; > improvements should be grouped into the same commit with an actual
> > bugfix.
>
> I have pushed the fix for the calloc check for now.
>
Thanks Daniel.
best regards,
Ranier Vilela
Em seg., 27 de mai. de 2024 às 13:47, Jelte Fennema-Nio
escreveu:
> On Mon, 27 May 2024 at 18:16, Ranier Vilela wrote:
> > Is it mandatory to call PQcancelFinish in case PQcancelCreate fails?
>
>
> Yes, see the following line in the docs:
>
> Note that when PQcancelC
Em seg., 27 de mai. de 2024 às 12:40, Jelte Fennema-Nio
escreveu:
> On Mon, 27 May 2024 at 16:06, Ranier Vilela wrote:
> > Em seg., 27 de mai. de 2024 às 10:23, Daniel Gustafsson
> escreveu:
> >> > On 27 May 2024, at 14:25, Ranier Vilela wrote:
> >> > I
Hi.
In the function *PQprint*, the variable po->fieldName
can be NULL.
See the checks a few lines up.
for (numFieldName = 0;
po->fieldName && po->fieldName[numFieldName];
numFieldName++)
So, I think that must be checked, when used,
in the loop below.
best regards,
Ranier Vile
Hi.
The function *plpgsql_inline_handler* can use uninitialized
variable retval, if PG_TRY fails.
Fix like function*plpgsql_call_handler* wich declare retval as
volatile and initialize to (Datum 0).
best regards,
Ranier Vilela
fix-use-uninitialized-retval-variable-pl_handler.patch
Description
Hi Daniel,
Em seg., 27 de mai. de 2024 às 10:23, Daniel Gustafsson
escreveu:
> > On 27 May 2024, at 14:25, Ranier Vilela wrote:
>
> > I think that commit 61461a3, left some oversight.
> > The function *PQcancelCreate* fails in check,
> > return of *calloc* fu
If any allocation fails, all allocations must be cleared.
Or is the current behavior acceptable?
best regards,
Ranier Vilela
fix-calloc-check-oom-PQcancelCreate.patch
Description: Binary data
with these two routines as well. The result
>> would be the same in terms of runtime validity checks.
>>
>
> PFA patch using those two routines.
>
The function *get_attname* palloc the result name (pstrdup).
Isn't it necessary to free the memory here (pfree)?
best regards,
Ranier Vilela
Em qui., 23 de mai. de 2024 às 06:27, Ashutosh Bapat <
ashutosh.bapat@gmail.com> escreveu:
>
>
> On Thu, May 23, 2024 at 5:52 AM Michael Paquier
> wrote:
>
>> On Wed, May 22, 2024 at 03:28:48PM -0300, Ranier Vilela wrote:
>> > 1. Another concern is t
Hi Micheal,
Em qua., 22 de mai. de 2024 às 21:21, Michael Paquier
escreveu:
> On Wed, May 22, 2024 at 03:28:48PM -0300, Ranier Vilela wrote:
> > 1. Another concern is the function *get_partition_ancestors*,
> > which may return NIL, which may affect *llast_oid*, which does not
Em qua., 22 de mai. de 2024 às 13:09, Ranier Vilela
escreveu:
> Em qua., 22 de mai. de 2024 às 11:44, Ranier Vilela
> escreveu:
>
>> Hi.
>>
>> Per Coverity.
>>
>> 2. returned_null: SearchSysCacheAttName returns NULL (checked 20 out of
>> 21 times
Em qua., 22 de mai. de 2024 às 11:44, Ranier Vilela
escreveu:
> Hi.
>
> Per Coverity.
>
> 2. returned_null: SearchSysCacheAttName returns NULL (checked 20 out of
> 21 times).
> 3. var_assigned: Assigning: ptup = NULL return value from
> SearchSysCacheAttName.
&g
,
left an oversight.
Fixed by the patch attached, a change of style, unfortunately, was
necessary.
best regards,
Ranier Vilela
fix-catalog-cache-search-check.patch
Description: Binary data
ities easier to use, avoiding hand-editing
> pg_config_manual.h and having to recompile.
>
Although there are some developer users.
I believe that anything that is not useful for common users and is not used
for production
should not be compiled at runtime.
best regards,
Ranier Vilela
called clonefile [1] and Linux exists
another called FICLONE.[2]
So perhaps it should be treated here as a copy and not a clone?
Leaving it open, is the possibility of implementing a true clone api?
Thoughts?
best regards,
Ranier Vilela
[1] clonefile <https://www.unix.com/man-page/mojave/2/clonefile/>
[2] ioctl_ficlonerange
<https://www.unix.com/man-page/linux/2/ioctl_ficlonerange/>
>
> --
> Regards,
> Nazir Bilal Yavuz
> Microsoft
>
ttings like
> log_parser_stats in the main code path, so it doesn't seem to be a concern.
>
> - Access control? I have these settings as PGC_USERSET for now. Maybe
> they should be PGC_SUSET?
>
> Another thought: Do we really need three separate settings?
>
What is the use for production use?
best regards,
Ranier Vilela
st int32 *b)
+sort_int32_desc_cmp(const int32 *a, const int32 *b)
We must use const in all parameters that can be const.
best regards,
Ranier Vilela
t;> Nice timing, I was actually rebasing them today to get them committed.
> >
> > Looks sensible seen from here, as these paths could use a LOG or rely
> > on a memory context permanent to the backend causing junk to be
> > accumulated. It's not that much, still that would accumulate.
>
> Pushed.
>
Thanks Daniel.
best regards,
Ranier Vilela
Em qua., 10 de abr. de 2024 às 15:33, Daniel Gustafsson
escreveu:
> On 10 Apr 2024, at 20:31, Ranier Vilela wrote:
>
> Em ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson
> escreveu:
>
>> > On 2 Apr 2024, at 20:13, Ranier Vilela wrote:
>>
>> > Fix by
so
> I'd rather fix the issue than dismiss it in HEAD.
>
Thanks for the commit, Tom.
best regards,
Ranier Vilela
Em qua., 8 de mai. de 2024 às 10:06, Nazir Bilal Yavuz
escreveu:
> Hi,
>
> On Wed, 8 May 2024 at 15:23, Ranier Vilela wrote:
> >
> > Em qua., 8 de mai. de 2024 às 08:42, Nazir Bilal Yavuz <
> byavu...@gmail.com> escreveu:
> >>
> >> Hi,
> >&g
Em qua., 8 de mai. de 2024 às 08:42, Nazir Bilal Yavuz
escreveu:
> Hi,
>
> On Wed, 8 May 2024 at 14:16, Ranier Vilela wrote:
> >
> >
> > Em qua., 8 de mai. de 2024 às 04:37, Nazir Bilal Yavuz <
> byavu...@gmail.com> escreveu:
> >>
g/onlinepubs/009696699/functions/open.html>
O_TRUNC signals the OS to forget the current contents of the file, if it
happens to exist.
In other words, there will be no seeks, only and exclusively writes.
> But it should be already checked if the destination directory already
> exists in dbcommands.c file in createdb() function [2], so this should
> not happen.
>
I'm not sure what you're referring to here.
best regards,
Ranier Vilela
UNC | 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
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
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 c
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
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
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'.
> >
, 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 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
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 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_
st regards,
Ranier Vilela
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
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 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 ter., 2 de abr. de 2024 às 15:31, Daniel Gustafsson
escreveu:
> > On 2 Apr 2024, at 20:13, Ranier Vilela wrote:
>
> > Fix by freeing the pointer, like pclose_check (src/common/exec.c)
> similar case.
>
> Off the cuff, seems reasonable when loglevel is LOG.
>
ReorderBufferSetBaseSnapshot,
fixed passing true as argument to always return
a valid ReorderBufferTXN pointer.
In the function ReorderBufferXidHasBaseSnapshot,
fixed by checking if the pointer is NULL.
best regards,
Ranier Vilela
fix-possible-dereference-null-pointer-reorderbuffer.patch
Description: Binary
it is needed,
so the code is already correct.
best regards,
Ranier Vilela
t; > size_t. There's a line that does "PqSendBufferSize = required;". It
> > kinda looks like they both should be size_t. Am I missing something
> > that you've thought about?
>
>
> You and Ranier are totally right (I missed this assignment). Attached is
> v8.
>
+1
LGTM.
best regards,
Ranier Vilela
e-e-vira-heroi-da-internet.shtml>
Congratulations Andres Freund, nice work.
best regards,
Ranier Vilela
qSendStart were changed in the v5 patch,
so for the sake of style and consistency, I understand that it is better
not to mix the types.
The compiler will promote PqSendBufferSize to size_t in all comparisons.
And finally the correct type to deal with char * variables is size_t.
Best regards,
Ranier Vilela
> Greetings,
>
> Andres Freund
>
fer, the variables named
*bufptr* and *bufend* could be const char * type, like:
static int
internal_flush_buffer(const char *s, size_t *start, size_t *end)
{
static int last_reported_send_errno = 0;
const char *bufptr = s + *start;
const char *bufend = s + *end;
best regards,
Ranier Vilela
Em qua., 3 de abr. de 2024 às 08:36, Ranier Vilela
escreveu:
>
> Em ter., 2 de abr. de 2024 às 18:13, Tom Lane
> escreveu:
>
>> Ranier Vilela writes:
>> > While I working in [1], Coverity reported some errors:
>> > src/bin/pg_basebackup/pg_createsubscribe
Em ter., 2 de abr. de 2024 às 18:13, Tom Lane escreveu:
> Ranier Vilela writes:
> > While I working in [1], Coverity reported some errors:
> > src/bin/pg_basebackup/pg_createsubscriber.c
> > CID 1542690: (#1 of 2): Out-of-bounds access (OVERRUN)
> > alloc_strlen: All
Hi,
Per Coverity.
Coverity reported a resource leak at the function
run_ssl_passphrase_command.
7. alloc_fn: Storage is returned from allocation function
wait_result_to_str.["show details"]
8. noescape: Assuming resource wait_result_to_str(pclose_rc) is not freed
or pointed-to as ellipsis
Em seg., 1 de abr. de 2024 às 14:52, Tom Lane escreveu:
> "Euler Taveira" writes:
> > On Wed, Mar 27, 2024, at 8:50 PM, Ranier Vilela wrote:
> >> Coverity has some reports in the new code
> >> pg_createsubscriber.c
> >> I think that Coverity is righ
(*s == quote_char || (!as_ident && *s == '\\'))
{
*rp++ = *s;
*rp++ = *s;
}
Patch attached.
Best regards,
Ranier Vilela
[1] Re: Fix some resources leaks
(src/bin/pg_basebackup/pg_createsubscriber.c)
<https://www.postgresql.org/message-id/CAEudQAqQHGrhmY3%2BrgdqJLM-76sozLm__0_NSJ
Em qua., 27 de mar. de 2024 às 23:08, Euler Taveira
escreveu:
> On Wed, Mar 27, 2024, at 8:50 PM, Ranier Vilela wrote:
>
> Coverity has some reports in the new code
> pg_createsubscriber.c
> I think that Coverity is right.
>
>
> It depends on your "right&quo
(RESOURCE_LEAK)
leaked_storage: Variable conn going out of scope leaks the storage it
points to.
3.
CID 1542691: (#1 of 1): Resource leak (RESOURCE_LEAK)
leaked_storage: Variable str going out of scope leaks the storage it points
to.
Patch attached.
best regards,
Ranier Vilela
fix-some-issues
Em qua., 27 de mar. de 2024 às 14:35, Nathan Bossart <
nathandboss...@gmail.com> escreveu:
> On Wed, Mar 27, 2024 at 01:47:38PM -0300, Ranier Vilela wrote:
> > Em qua., 27 de mar. de 2024 às 13:41, Nathan Bossart <
> > nathandboss...@gmail.com> escreveu:
> >>
Em qua., 27 de mar. de 2024 às 13:41, Nathan Bossart <
nathandboss...@gmail.com> escreveu:
> On Wed, Mar 27, 2024 at 01:21:23PM -0300, Ranier Vilela wrote:
> > Nathan Bossart writes:
> >>Committed with that change. Thanks for the guidance on this one.
> >
>
eferenced
in the main loop of the function roles_is_member_of and
worst, IMO, can be destroying aleatory memory?
First, is a better shortcut test to check if admin_role is NOT NULL.
Second, !OidIsValid(*admin_role), It doesn't seem necessary anymore.
Or am I losing something?
best regards,
Rani
Em seg., 4 de mar. de 2024 às 20:28, Tom Lane escreveu:
> Michael Paquier writes:
> > On Mon, Mar 04, 2024 at 03:08:03PM -0300, Ranier Vilela wrote:
> >> I can't see any user validation at the function
> pg_newlocale_from_collation.
>
> > Matthias is right, look cl
Em seg., 4 de mar. de 2024 às 14:54, Matthias van de Meent <
boekewurm+postg...@gmail.com> escreveu:
> On Mon, 4 Mar 2024 at 18:39, Ranier Vilela wrote:
> >
> > Hi,
> >
> > The function var_strcmp is a critical function.
> > Inside the function, there is
1 - 100 of 863 matches
Mail list logo
