vita-ciberataque-e-vira-heroi-da-internet.shtml>
Congratulations Andres Freund, nice work.
best regards,
Ranier Vilela
PqSendPointer and PqSendStart 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
>
h_buffer, 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_createsubscriber.c
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 argume
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-76so
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" de
(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.
> >
> >
renced
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,
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, lo
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
er 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 Naylor <
>
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 diffic
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
rence, but it would 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
0
tps = 29299.016248
patched:
tps = 27363.364039
tps = 28588.141586
tps = 28669.367300
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
aration,
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
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
ted 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
directly even stronger.
>
> 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
for HEAD 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 enou
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 avoid
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
h
> > 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
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
llocation after the OPENDIR() seems like
> a good practice anyway.
>
Thanks for the commit, Michael.
best regards,
Ranier Vilela
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
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
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
,
> 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 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
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
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 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,
> > >
> >
2.
The correct type of the variable counter is uint32.
Fix by standardizing the int type to uint32.
patch attached.
best regards,
Ranier Vilela
[1]
https://www.postgresql.org/message-id/CAEudQAr_oWHpZk4uumZijYS362gp4KHAah-yUe08CQY4a4SsOQ%40mail.gmail.com
0001-Standardize-type-of-ext
s indeterminate.
The key points are here.
The object is not static storage duration.
The object is struct with "automatic storage duration".
And not all compilers follow the standards,
they tend to vary quite a bit.
regards,
Ranier Vilela
Em qui., 6 de jul. de 2023 às 14:33, Andres Freund
escreveu:
> Hi,
>
> I pushed changing i to uint32 and adding Tom's comment to 11-HEAD.
>
Thank you.
regards,
Ranier Vilela
Em qui., 6 de jul. de 2023 às 13:52, Andres Freund
escreveu:
> Hi,
>
> On 2023-07-06 13:40:00 -0300, Ranier Vilela wrote:
> > I still have doubts about this.
> >
> > see:
> > #include
> > #include
> > #include
> >
> > #define SH_MAX_S
Em qui., 6 de jul. de 2023 às 12:16, Tom Lane escreveu:
> Ranier Vilela writes:
> > See the comments:
> > "Search for the first empty element."
> > If the empty element is not found, startelem has PG_UINT64_MAX value,
> > which do not fit in uint32.
>
Em qui., 6 de jul. de 2023 às 12:00, Daniel Gustafsson
escreveu:
> > On 6 Jul 2023, at 16:42, Ranier Vilela wrote:
> > Em qui., 6 de jul. de 2023 às 11:37, Daniel Gustafsson <mailto:dan...@yesql.se>> escreveu:
>
> > #define SH_MAX_SIZE (((uint64) PG_UINT32_MAX) +
Em qui., 6 de jul. de 2023 às 11:37, Daniel Gustafsson
escreveu:
> > On 6 Jul 2023, at 16:28, Ranier Vilela wrote:
>
> > The function SH_START_ITERATE can trigger some overflow.
> >
> > See:
> > typedef struct SH_ITERATOR
> > {
> > uint32 cur; /* cur
not fit.
Also, the current index is int, which is possibly insufficient
since items can be up to uint32.
Attached a fix.
best regards,
Ranier Vilela
avoid-overflow-with-simplehash-start-iterate.patch
Description: Binary data
use I
> believe the comment above already explains why updating eb.smgr:
>
> * Note that another backend might have extended the relation by the time
> * we get the lock.
>
Ok, but the first comment still ambiguous, I think that could be:
"/* eb.smgr could have been closed while waiting for lock */"
best regards,
Ranier Vilela
0002-avoid-new-struct-with-undefined-fields-ExtendedBufferedWhat.patch
Description: Binary data
s(f->data, fout);
value_overwrite: Overwriting previous write to need_recordsep with value
true.
492need_recordsep = true;
493}
494}
495
> Otherwise, if the goal is to do review the code and make it cleaner, then
> why not get rid of "if (need_recordsep)" there?
>
I don't agree with removing this line, as it is essential to print the
separators, in the footers.
best regards,
Ranier Vilela
t obvious, so I also have doubts about removing this line. If
> someday
> print options are changed, for example to support printing footers and not
> printing headers, or anything else changes in this function, the output
> might
> be unexpected with this line removed.
That part I didn't understand.
How are we going to make this function less readable by removing the
complicating part.
best regards,
Ranier Vilela
Em qui., 29 de jun. de 2023 às 02:50, Alena Rybakina <
lena.riback...@yandex.ru> escreveu:
> Hi!
> On 29.06.2023 04:36, Ranier Vilela wrote:
>
> I don't want to be rude, but this doesn't seem very helpful.
>>
> Sorry, It was not my intention to cause interrup
t;
By no means, your work is excellent and deserves all compliments.
regards,
Ranier Vilela
Em qua., 28 de jun. de 2023 às 18:45, Tomas Vondra <
tomas.von...@enterprisedb.com> escreveu:
> On 6/27/23 20:55, Ranier Vilela wrote:
> > Hi,
> >
> >>I finished writing the code patch for transformation "Or" expressions to
> >>"Any"
lancer and so far the code has
>never fallen.
Thanks for working on this.
I took the liberty of making some modifications to the patch.
I didn't compile or test it.
Please feel free to use them.
regards,
Ranier Vilela
From 56fba3befe4f6b041d097d8884815fe943fb21f9 Mon Sep 17 00:00:00 2001
B ==
/usr/local/pgsql/bin/psql -U postgres -f
/home/ranier/Documentos/benchmarks/bitmapset/create-tables-b.sql
/usr/local/pgsql/bin/psql -U postgres -f
/home/ranier/Documentos/benchmarks/bitmapset/query-b.sql
patched v4:
Time: 1581,317 ms (00:01,581)
Time: 1568,371 ms (00:01,568)
Time: 1468,036 ms (00:01,468)
Time: 1445,698 ms (00:01,446)
patched v8:
Time: 1437,997 ms (00:01,438)
Time: 1437,435 ms (00:01,437)
Time: 1440,422 ms (00:01,440)
Time: 1436,112 ms (00:01,436)
regards,
Ranier Vilela
speeding-up-bitmapset-v8.patch
Description: Binary data
dern ones and with great cache support.
Another question is related to an alleged "spurius test", whose objective
is to avoid test and set instructions for each element of the array.
Again I ran the tests without the test and the performance was worse,
showing its value.
regar
00,802 ms (00:01,801)
Time: 1798,786 ms (00:01,799)
I can see some improvement, would you mind testing v6 and reporting back?
regards,
Ranier Vilela
remove_zero_trailing_words_from_bitmapsets_v6.patch
Description: Binary data
Em qui., 22 de jun. de 2023 às 01:43, David Rowley
escreveu:
> On Thu, 22 Jun 2023 at 00:16, Ranier Vilela wrote:
> > 2. Only compute BITNUM when necessary.
>
> I doubt this will help. The % 64 done by BITNUM will be transformed
> to an AND operation by the compiler which is
er cases?
Just for convenience I made a new version of the patch,
If want to use it.
regards,
Ranier Vilela
remove_zero_trailing_words_from_bitmapsets_v5.patch
Description: Binary data
Em qua., 14 de jun. de 2023 às 13:32, Gurjeet Singh
escreveu:
> On Wed, Jun 14, 2023 at 5:12 AM Ranier Vilela wrote:
> >
> > Em qua., 14 de jun. de 2023 às 06:51, Richard Guo <
> guofengli...@gmail.com> escreveu:
> >>
> >>
> >> On Tue, Jun
;
>
> Yeah, Gurjeet is right. I had a thinko here. eb.rel should not be NULL
> pointer in any case. And as we've acquired the lock for it, it should
> not have been closed. So I think we can remove the check for eb.rel in
> the two places.
>
Ok,
As there is a consensus on remov
Em ter., 13 de jun. de 2023 às 02:51, Gurjeet Singh
escreveu:
> Please see attached v2 of the patch; it includes both occurrences of
> the spurious checks identified in this thread.
>
+1
LGTM.
regards,
Ranier Vilela
Em seg., 5 de jun. de 2023 às 13:42, Bruce Momjian
escreveu:
> On Mon, Jun 5, 2023 at 01:26:00PM -0300, Ranier Vilela wrote:
> > On 05/06/2023 11:18, Tom Lane wrote:
> > > For the record, I think this will be a disaster. There is far too much
> > > code that will g
101 - 200 of 881 matches
Mail list logo
