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
to postpone the function call until when it is
actually necessary.
best regards,
Ranier Vilela
avoid-call-expensive-function-varlena.patch
Description: Binary data
Em seg., 4 de mar. de 2024 às 03:18, Andrey M. Borodin
escreveu:
>
>
> > On 14 Jan 2024, at 18:55, John Naylor wrote:
> >
> > On Sat, Jan 13, 2024 at 9:36 PM Ranier Vilela
> wrote:
> >>
> >> Em ter., 9 de jan. de 2024 às 06:31, John
Em seg., 26 de fev. de 2024 às 02:28, Michael Paquier
escreveu:
> On Thu, Feb 22, 2024 at 04:42:37PM -0300, Ranier Vilela wrote:
> > Can you share exactly script used to create a table?
>
> Stressing the internals of array_out() for the area of the patch is
> not that dif
Hi,
On 2024-02-17 17:48:23 +0100, Laurenz Albe wrote:
> As a test case, I created a table with 1 rows, each of which
> had an array of 1 uuids. The table resided in shared buffers.
Can you share exactly script used to create a table?
best regards,
Ranier Vilela
Em ter., 20 de fev. de 2024 às 00:18, Andrei Lepikhov <
a.lepik...@postgrespro.ru> escreveu:
> On 19/2/2024 19:53, Ranier Vilela wrote:
> > v17-0002
> > 1) move the vars *arrayconst and *dest, to after if, to avoid makeNode
> > (palloc).
> > + Const *arraycons
ould be good to avoid, I
think.
v17-0002
1) move the vars *arrayconst and *dest, to after if, to avoid makeNode
(palloc).
+ Const *arrayconst;
+ ScalarArrayOpExpr *dest;
+
+ pd = (PredicatesData *) lfirst(lc);
+ if (pd->elems == NIL)
+ /* The index doesn't participate in this operation */
+ continue;
+ arrayconst = lsecond_node(Const, saop->args);
+ dest = makeNode(ScalarArrayOpExpr);
best regards,
Ranier Vilela
; 21d9c3ee4ef7 outlines better how long SMgrRelation pointers should
> live, no?
>
Correct Micheal, the best thing would be to remove the patch now.
Since it has completely lost its meaning.
Best regards,
Ranier Vilela
negative value.
fdopen cannot receive negative parameters, in this case fail and return
EBADF.
This can be confusing for the user, who will be trying to figure out what's
wrong.
Better abort and report the correct failure to the user.
Patch attached.
Best regards,
Ranier Vilela
abort-if-dup-fail
00
To my complete surprise, the change is slower.
I can't say how, with fewer instructions, gcc makes the binary worse.
best regards,
Ranier Vilela
Em seg., 29 de jan. de 2024 às 16:32, Nathan Bossart <
nathandboss...@gmail.com> escreveu:
> On Mon, Jan 29, 2024 at 01:30:47PM -0300, Ranier Vilela wrote:
> > IMO I believe that bitmapset can obtain an optimization in the
> calculation
> > of the WORDNUM and BITNUM mac
tion,
You know all about the vars in the function.
Best regards,
Ranier Vilela
WORD PTR [rbp-20]
and eax, 63
mov DWORD PTR [rbp-4], eax
As you can see, when calculations are done in unsigned,
the generated instructions are optimized.
Patch attached.
Best regards,
Ranier Vilela
diff --git a/src/backend/nodes/bitmapset.c b/src/backend/nodes/bitmapset.c
ind
Em qua., 17 de jan. de 2024 09:54, Daniel Gustafsson
escreveu:
> > On 17 Jan 2024, at 07:26, Michael Paquier wrote:
> > On Tue, Jan 16, 2024 at 05:25:39PM -0300, Ranier Vilela wrote:
>
> >> Do you have plans or should I register for a commitfest?
> >
> >
Em seg., 15 de jan. de 2024 às 09:43, Daniel Gustafsson
escreveu:
> > On 13 Jan 2024, at 22:38, Ranier Vilela wrote:
>
> > In the pgwin32_socket function (src/backend/port/win32/socket.c), there
> is a possible socket leak if the socket cannot be made non-blocking.
>
> I
regards,
Ranier Vilela
[1] Re: Windows sockets (select missing events?)
<https://www.postgresql.org/message-id/CA%2BhUKGKSLgxFhSP8%2BdqQqHsuZvrRRU3wZ6ytLOcno-mdGvckHg%40mail.gmail.com>
fix-socket-leak-windows.patch
Description: Binary data
Em ter., 9 de jan. de 2024 às 06:31, John Naylor
escreveu:
> On Thu, Dec 28, 2023 at 7:58 PM Ranier Vilela wrote:
> > I think it would be more productive to initialize the entire array with
> -1, and avoid flagging, one by one, the items that should be -1.
>
> This just moves
Em sáb., 30 de dez. de 2023 19:19, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
> On 12/29/23 18:02, Ranier Vilela wrote:
> >
> > ...
> >
> > As I wrote, the new patch version was for consideration.
> > It seems more like a question of style, so i
Em qui., 28 de dez. de 2023 às 14:45, Ranier Vilela
escreveu:
> Hi,
>
> The type of field fd_count is defined in winsock.h:
> typedef unsigned intu_int;
>
> So in the struct fd_set,
> the field fd_count is unsigned int.
>
> The pgwin32_select function has loop
group.org/onlinepubs/009604599/functions/closedir.html>
The commit affected is dc21234
<http://dc212340058b4e7ecfc5a7a81ec50e7a207bf288>
Trivial patch attached.
Best regards,
Ranier Vilela
fix-resource-leak-pg_combinebackup.patch
Description: Binary data
Hi,
Per Coverity.
The function StartLogStreamer in (src/bin/pg_basebackup/pg_basebackup.c)
Has a copy and paste error.
The commit affected is dc212340058b4e7ecfc5a7a81ec50e7a207bf288
<http://dc21234>
Trivial patch attached.
Best regards,
Ranier Vilela
fix-copy-and-paste
Em sex., 29 de dez. de 2023 às 08:53, Ranier Vilela
escreveu:
> Em qui., 28 de dez. de 2023 às 22:16, Tomas Vondra <
> tomas.von...@enterprisedb.com> escreveu:
>
>>
>>
>> On 12/27/23 12:37, Ranier Vilela wrote:
>> > Em ter., 26 de dez. de 2023 às
Em sex., 29 de dez. de 2023 às 10:33, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
>
>
> On 12/29/23 12:53, Ranier Vilela wrote:
> > Em qui., 28 de dez. de 2023 às 22:16, Tomas Vondra
> > mailto:tomas.von...@enterprisedb.com>>
> > escreveu:
> &
Em qui., 28 de dez. de 2023 às 22:16, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
>
>
> On 12/27/23 12:37, Ranier Vilela wrote:
> > Em ter., 26 de dez. de 2023 às 19:07, Tomas Vondra
> > mailto:tomas.von...@enterprisedb.com>>
> > escreveu:
> &
?
If not, It would be a good prevention practice, using the correct type,
right?
Patch attached.
best regards,
Ranier Vilela
001-fix-socket-select-events.patch
Description: Binary data
I think it would be more productive to initialize the entire array with -1,
and avoid flagging, one by one, the items that should be -1.
Patch attached.
best regards,
Ranier Vilela
001-tidy-fill-htsv-array.patch
Description: Binary data
Em ter., 26 de dez. de 2023 às 19:07, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
>
>
> On 12/26/23 19:10, Ranier Vilela wrote:
> > Hi,
> >
> > The commit b437571 <http://b437571714707bc6466abde1a0af5e69aaade09c> I
> > think has an overs
fected is:
buildstate->bs_spool = (BrinSpool *) palloc0(sizeof(BrinSpool));
- buildstate->bs_spool->heap = buildstate->bs_spool->heap;
- buildstate->bs_spool->index = buildstate->bs_spool->index;
+ buildstate->bs_spool->heap = heap;
+ buildstate->bs_spool->index = inde
Em qua., 27 de set. de 2023 às 22:28, David Rowley
escreveu:
> On Thu, 28 Sept 2023 at 02:37, Ranier Vilela wrote:
> >> Please check [1] for the mention of:
> >>
> >> "The fastest way to get your patch rejected is to make unrelated
> >> changes. Refor
Em qua., 27 de set. de 2023 às 04:35, David Rowley
escreveu:
> On Wed, 27 Sept 2023 at 06:10, Ranier Vilela wrote:
> > As suggested, casting is the best option that does not add any overhead
> and improves the robustness of the find_base_rel function.
> > I propose patch v1, w
Em ter., 26 de set. de 2023 às 09:30, Ranier Vilela
escreveu:
> Em ter., 26 de set. de 2023 às 07:34, Ashutosh Bapat <
> ashutosh.bapat@gmail.com> escreveu:
>
>> On Tue, Sep 26, 2023 at 3:32 PM David Rowley
>> wrote:
>> >
>> > find_base_rel
er.
>
> I am curious, is the overhead in find_base_rel() impacting overall
> performance?
>
It seems to me that it adds a LEA instruction.
https://godbolt.org/z/b4jK3PErE
Although it doesn't seem like much,
I believe the solution (casting to unsigned) seems better.
So +1.
best regards,
Ranier Vilela
Em seg., 25 de set. de 2023 às 08:23, Ashutosh Bapat <
ashutosh.bapat@gmail.com> escreveu:
> On Sat, Sep 23, 2023 at 7:29 PM Ranier Vilela wrote:
> >
> > Hi,
> >
> > Per Coverity.
> > CID 1518088 (#2 of 2): Improper use of negative value
regards,
Ranier Vilela
0001-Avoid-possible-out-of-bounds-access.patch
Description: Binary data
Em ter., 19 de set. de 2023 às 05:07, Peter Eisentraut
escreveu:
> On 10.07.23 13:08, Ranier Vilela wrote:
> >
> > Em seg., 10 de jul. de 2023 às 03:27, Kyotaro Horiguchi
> > mailto:horikyota@gmail.com>> escreveu:
> >
> > At Fri, 7
Em qua., 13 de set. de 2023 às 22:32, Michael Paquier
escreveu:
> On Wed, Sep 13, 2023 at 08:14:11AM -0700, Jeff Davis wrote:
> > Looks good to me, thank you.
>
> Applied, then. Thanks.
>
Thank you Michael, for the commit.
best regards,
Ranier Vilela
EAD and REL_16_STABLE.
>
> One question: would it make sense to use __func__?
>
According to the msvc documentation, __func__ requires C++11.
https://learn.microsoft.com/en-us/cpp/cpp/func?view=msvc-170
I think that is not a good idea.
best regards,
Ranier Vilela
Em seg., 11 de set. de 2023 às 21:03, Michael Paquier
escreveu:
> On Mon, Sep 11, 2023 at 12:15:49PM -0700, Jeff Davis wrote:
> > That's fine with me.
>
> Okay. Then, please find attached a v4 for HEAD and REL_16_STABLE.
>
LGTM.
best regards,
Ranier Vilela
Em sex., 8 de set. de 2023 às 03:24, Michael Paquier
escreveu:
> On Wed, Sep 06, 2023 at 07:57:03AM -0300, Ranier Vilela wrote:
> > I think no one objected.
>
> Looking closer, there is much more inconsistency in this file
> depending on the routine called. How about som
Em seg., 4 de set. de 2023 às 11:27, Ranier Vilela
escreveu:
> Em dom., 3 de set. de 2023 às 22:01, Michael Paquier
> escreveu:
>
>> On Sat, Sep 02, 2023 at 09:13:11AM -0300, Ranier Vilela wrote:
>> > I tried to keep the same behavior as before.
>> &g
Em dom., 3 de set. de 2023 às 22:01, Michael Paquier
escreveu:
> On Sat, Sep 02, 2023 at 09:13:11AM -0300, Ranier Vilela wrote:
> > I tried to keep the same behavior as before.
> > Note that if the locale equals COLLPROVIDER_LIBC,
> > the message to the
Em sex., 1 de set. de 2023 às 17:17, Robert Haas
escreveu:
> On Fri, Sep 1, 2023 at 11:47 AM Ranier Vilela wrote:
> > If a null locale is reached in these paths.
> > elog will dereference a null pointer.
>
> True. That's sloppy coding.
>
> I don't know enough about t
Hi,
If a null locale is reached in these paths.
elog will dereference a null pointer.
best regards,
Ranier Vilela
0001-Avoid-a-possible-dereference-a-null-pointer.patch
Description: Binary data
Em qui., 31 de ago. de 2023 às 12:12, Dagfinn Ilmari Mannsåker <
ilm...@ilmari.org> escreveu:
> Ranier Vilela writes:
>
> > Em qui., 31 de ago. de 2023 às 10:12, Dagfinn Ilmari Mannsåker <
> > ilm...@ilmari.org> escreveu:
> >
> >> Andrew Dunstan wri
Em qui., 31 de ago. de 2023 às 10:12, Dagfinn Ilmari Mannsåker <
ilm...@ilmari.org> escreveu:
> Andrew Dunstan writes:
>
> > On 2023-08-31 Th 07:41, John Naylor wrote:
> >>
> >> On Thu, Aug 31, 2023 at 6:07 PM Ranier Vilela
> wrote:
> >> >
&
Em qui., 31 de ago. de 2023 às 09:51, Andrew Dunstan
escreveu:
>
> On 2023-08-31 Th 07:41, John Naylor wrote:
>
>
> On Thu, Aug 31, 2023 at 6:07 PM Ranier Vilela wrote:
> >
> > Em qui., 31 de ago. de 2023 às 00:22, Michael Paquier <
> mich...@paquier.xyz>
Em qui., 31 de ago. de 2023 às 08:41, John Naylor <
john.nay...@enterprisedb.com> escreveu:
>
> On Thu, Aug 31, 2023 at 6:07 PM Ranier Vilela wrote:
> >
> > Em qui., 31 de ago. de 2023 às 00:22, Michael Paquier <
> mich...@paquier.xyz> escreveu:
> >>
>
Em qui., 31 de ago. de 2023 às 00:22, Michael Paquier
escreveu:
> On Wed, Aug 30, 2023 at 03:00:13PM -0300, Ranier Vilela wrote:
> > cstring_to_text has a small overhead, because call strlen for
> > pointer to char parameter.
> >
> > Is it worth the effort to a
Hi,
cstring_to_text has a small overhead, because call strlen for
pointer to char parameter.
Is it worth the effort to avoid this, where do we know the size of the
parameter?
best regards,
Ranier Vilela
0003-Avoid-unecessary-calls-to-strlen-function.patch
Description: Binary data
> watermark number of free pages is pretty small. Even still, I agree
> > with your conclusion. There is really no reason to not be consistent
> > here.
>
> Postgres 16 RC1 is now tagged, so applied down to 13.
>
Thank you, Michael.
best regards,
Ranier Vilela
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 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
1 - 100 of 812 matches
Mail list logo
