Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

ic improvement. > But, these same arguments apply to Designated Initializers [1]. like: struct foo a = { .i = 0, .b = 0, }; That is slowly being introduced and IMHO brings the same problems with padding bits. regards, Ranier Vilela [1] https://interrupt.memfault.com/blog/c-struct-padding-initialization

re: Change pfree to accept NULL argument

g. I took the liberty of making a v1, attached. regards, Ranier Vilela v1-0004-Remove-unneeded-null-pointer-checks-before-PQfreemem.patch Description: Binary data

Re: Fix typo with logical connector (src/backend/commands/vacuumparallel.c)

h this to PG15 as this won't lead > > > to any incorrect behavior. > > > > If that code only exists in HEAD and v15 then I'd backpatch. > > It's a very low-risk change and it might avoid merge problems > > for future backpatches. > > > > Okay, done that way. Thanks! > Thank you. regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

to use, which is the case here. For example, something like the attached one which is focusing on the > pageinspect extension only. > Surely you did, but it has to be said, it was compiled and tested with at least a make check. Looks like it's ok, LTGM. regards, Ranier Vilela >

Re: Fix typo with logical connector (src/backend/commands/vacuumparallel.c)

Em sáb., 20 de ago. de 2022 às 01:03, Amit Kapila escreveu: > On Fri, Aug 19, 2022 at 7:45 PM Ranier Vilela wrote: > > > > Em sex., 19 de ago. de 2022 às 10:28, Tom Lane > escreveu: > >> > >> Ranier Vilela writes: > >> > At function parallel_v

Re: Use array as object (src/fe_utils/parallel_slot.c)

Em sex., 19 de ago. de 2022 às 16:22, Justin Pryzby escreveu: > On Fri, Aug 19, 2022 at 03:52:36PM -0300, Ranier Vilela wrote: > > Em qui., 11 de ago. de 2022 às 09:52, Ranier Vilela > escreveu: > > > > > Hi, > > > > > > One other case suspicious,

Re: Use array as object (src/fe_utils/parallel_slot.c)

Em qui., 11 de ago. de 2022 às 09:52, Ranier Vilela escreveu: > Hi, > > One other case suspicious, which I think deserves a conference. > At function wait_on_slots (src/fe_utils/parallel_slot.c) > The variable "slots" are array, but at function call SetCancelConn, > &

Re: Fix typo with logical connector (src/backend/commands/vacuumparallel.c)

Em sex., 19 de ago. de 2022 às 10:28, Tom Lane escreveu: > Ranier Vilela writes: > > At function parallel_vacuum_process_all_indexes there is > > a typo with a logical connector. > > I think that correct is &&, because both of the operators are > > bool t

Fix typo with logical connector (src/backend/commands/vacuumparallel.c)

Hi, At function parallel_vacuum_process_all_indexes there is a typo with a logical connector. I think that correct is &&, because both of the operators are bool types [1]. As a result, parallel vacuum workers can be incorrectly enabled. Attached a trivial fix. regards, Ranier Vi

Re: [PATCH] Optimize json_lex_string by batching character copying

Em seg., 15 de ago. de 2022 às 15:34, Ranier Vilela escreveu: > Hi, > > I ran this test. > > DROP TABLE IF EXISTS long_json_as_text; > CREATE TABLE long_json_as_text AS > with long as ( > select repeat(description, 11) > from pg_description > ) > select (select

Re: [PATCH] Optimize json_lex_string by batching character copying

; select 1 from long_json_as_text where t::json is null; head: Time: 161,741ms v5: Time: 270,298 ms ubuntu 64 bits gcc 9.4.0 Am I missing something? regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qui., 11 de ago. de 2022 às 09:23, Julien Rouhaud escreveu: > On Thu, Aug 11, 2022 at 08:51:53AM -0300, Ranier Vilela wrote: > > Em qui., 11 de ago. de 2022 às 08:48, Alvaro Herrera < > > alvhe...@alvh.no-ip.org> escreveu: > > > > > On 2022-Aug-11, Ranier V

Use array as object (src/fe_utils/parallel_slot.c)

onn wouldn't that be the correct argument? regards, Ranier Vilela 001-fix-cancel-conn.patch Description: Binary data

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qui., 11 de ago. de 2022 às 08:48, Alvaro Herrera < alvhe...@alvh.no-ip.org> escreveu: > On 2022-Aug-11, Ranier Vilela wrote: > > > According to: > > https://interrupt.memfault.com/blog/c-struct-padding-initialization > > Did you actually read i

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qui., 11 de ago. de 2022 às 07:38, Peter Eisentraut < peter.eisentr...@enterprisedb.com> escreveu: > On 01.08.22 19:08, Ranier Vilela wrote: > > Like how > > > https://github.com/postgres/postgres/commit/9fd45870c1436b477264c0c82eb195df52bc0919 > > < >

Allocator sizeof operand mismatch (src/backend/regex/regcomp.c)

Hi, About the error: Result of 'malloc' is converted to a pointer of type 'char', which is incompatible with sizeof operand type 'struct guts' The patch attached tries to fix this. regards, Ranier Vilela diff --git a/src/backend/regex/regcomp.c b/src/backend/re

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

l cases. The point here is, this is only possible when using memset. > Are the cases for which the optimization is done consistent across all the > compilers? > Of course not. But it does not matter. regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em seg., 1 de ago. de 2022 às 22:19, Peter Smith escreveu: > On Tue, Aug 2, 2022 at 3:09 AM Ranier Vilela wrote: > > > > Em sáb., 16 de jul. de 2022 às 16:54, Ranier Vilela > escreveu: > >> > >> > >> > >> Em sáb, 16 de jul de 2022 2:58 AM,

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

enthusiasm in changing procarray.c, I believe it is best to reject it. regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em sáb., 16 de jul. de 2022 às 16:54, Ranier Vilela escreveu: > > > Em sáb, 16 de jul de 2022 2:58 AM, Peter Eisentraut < > peter.eisentr...@enterprisedb.com> escreveu: > >> On 11.07.22 21:06, Ranier Vilela wrote: >> > Em qui., 7 de jul. de 2022 às 14:

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em sáb, 16 de jul de 2022 2:58 AM, Peter Eisentraut < peter.eisentr...@enterprisedb.com> escreveu: > On 11.07.22 21:06, Ranier Vilela wrote: > > Em qui., 7 de jul. de 2022 às 14:01, Ranier Vilela > <mailto:ranier...@gmail.com>> escreveu: > > > > Attache

Re: Reducing Memory Consumption (aset and generation)

e here. > I saw the numbers at [2], 17% is very impressive. How you need the context in the block, 001 and 003, they are more of a hindrance than a help. So, feel free to incorporate 002 into your patch if you wish. The best thing to do here is to close and withdraw from commitfest. regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qui., 7 de jul. de 2022 às 14:01, Ranier Vilela escreveu: > Attached the v1 of your patch. > I think that all is safe to switch MemSet by {0}. > Here the rebased patch v2, against latest head. regards, Ranier Vilela v2-0001-WIP-Replace-MemSet-calls-with-struct-initializat

Re: Reducing Memory Consumption (aset and generation)

Em seg., 11 de jul. de 2022 às 09:25, Ranier Vilela escreveu: > Hi, > Thanks for take a look. > > Em seg., 11 de jul. de 2022 às 05:48, Matthias van de Meent < > boekewurm+postg...@gmail.com> escreveu: > >> On Tue, 7 Jun 2022 at 03:09, Ranier Vilela wrote: &g

Re: Reducing Memory Consumption (aset and generation)

Hi, Thanks for take a look. Em seg., 11 de jul. de 2022 às 05:48, Matthias van de Meent < boekewurm+postg...@gmail.com> escreveu: > On Tue, 7 Jun 2022 at 03:09, Ranier Vilela wrote: > > > > Let's restart this, to simplify the review and commit work. > > The pa

Fix gcc warning in sync.c (usr/src/backend/storage/sync/sync.c)

equest has been canceled */ } PendingUnlinkEntry; The patch tries to fix this. regards, Ranier Vilela diff --git a/src/backend/storage/sync/sync.c b/src/backend/storage/sync/sync.c index 59210a451d..b5071663c3 100644 --- a/src/backend/storage/sync/sync.c +++ b/src/backend/storage/sync/sync.c

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

, wait a minute, I will produce a new version of your patch, with some changes for your review. regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

RD PTR [rbp-4], 1 .L2: cmp DWORD PTR [rbp-4], 3 jle .L3 mov eax, 1 leave ret Only one line using {0}. +1 regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

issing paths in this commit. Despite having included the attached patch, there is no need to credit me as the author, just as a report. regards, Ranier Vilela 001-avoid-unecessary-MemSet-calls.patch Description: Binary data

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qui., 30 de jun. de 2022 às 19:37, Peter Eisentraut < peter.eisentr...@enterprisedb.com> escreveu: > On 19.05.22 18:09, Ranier Vilela wrote: > > Taking it a step further. > > Created a new patch into commitfest, targeting 16 version. > > https://commitfest.postgre

Re: Reducing Memory Consumption (aset and generation)

Em seg., 6 de jun. de 2022 às 21:14, Ranier Vilela escreveu: > Em seg., 6 de jun. de 2022 às 20:37, David Rowley > escreveu: > >> On Mon, 6 Jun 2022 at 07:28, Ranier Vilela wrote: >> > 4) 004-generation-reduces-memory-consumption-BUG.patch >> > Same to the (2),

Re: Reducing Memory Consumption (aset and generation)

Em seg., 6 de jun. de 2022 às 20:37, David Rowley escreveu: > On Mon, 6 Jun 2022 at 07:28, Ranier Vilela wrote: > > 4) 004-generation-reduces-memory-consumption-BUG.patch > > Same to the (2), but with BUG. > > It only takes a few tweaks to completely remove the field bl

Reducing Memory Consumption (aset and generation)

HI hackers, I thought it would be better to start a new thread to discuss. While working with sorting patch, and read others threads, I have some ideas to reduces memory consumption by aset and generation memory modules. I have done basic benchmarks, and it seems to improve performance. I think i

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

od, but robustness comes first. As soon as I have some time. regards, Ranier Vilela

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em sáb., 28 de mai. de 2022 às 09:35, Tomas Vondra < tomas.von...@enterprisedb.com> escreveu: > On 5/28/22 02:36, Ranier Vilela wrote: > > Em sex., 27 de mai. de 2022 às 18:22, Andres Freund > <mailto:and...@anarazel.de>> escreveu: > > > > Hi, > >

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em sáb., 28 de mai. de 2022 às 09:00, Tomas Vondra < tomas.von...@enterprisedb.com> escreveu: > On 5/28/22 02:15, Ranier Vilela wrote: > > > > > > Em sex., 27 de mai. de 2022 às 18:08, Andres Freund > <mailto:and...@anarazel.de>> escreveu: > > > &g

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em sex., 27 de mai. de 2022 às 18:22, Andres Freund escreveu: > Hi, > > On 2022-05-27 10:35:08 -0300, Ranier Vilela wrote: > > Em qui., 26 de mai. de 2022 às 22:30, Tomas Vondra < > > tomas.von...@enterprisedb.com> escreveu: > > > >

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em sex., 27 de mai. de 2022 às 18:08, Andres Freund escreveu: > Hi, > > On 2022-05-27 03:30:46 +0200, Tomas Vondra wrote: > > On 5/27/22 02:11, Ranier Vilela wrote: > > > ./pgbench -M prepared -c $conns -j $conns -T 60 -S -n -U postgres > > > > > >

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em qui., 26 de mai. de 2022 às 22:30, Tomas Vondra < tomas.von...@enterprisedb.com> escreveu: > On 5/27/22 02:11, Ranier Vilela wrote: > > > > ... > > > > Here the results with -T 60: > > Might be a good idea to share your analysis / interpretation of the

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em qua., 25 de mai. de 2022 às 08:26, Ranier Vilela escreveu: > Em qua., 25 de mai. de 2022 às 07:13, Tomas Vondra < > tomas.von...@enterprisedb.com> escreveu: > >> >> >> On 5/25/22 11:07, Ranier Vilela wrote: >> > Em qua., 25 de mai. de 20

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em qua., 25 de mai. de 2022 às 07:13, Tomas Vondra < tomas.von...@enterprisedb.com> escreveu: > > > On 5/25/22 11:07, Ranier Vilela wrote: > > Em qua., 25 de mai. de 2022 às 00:46, Andres Freund > <mailto:and...@anarazel.de>> escreveu: > > >

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em qua., 25 de mai. de 2022 às 00:56, Andres Freund escreveu: > Hi, > > On 2022-05-24 13:23:43 -0300, Ranier Vilela wrote: > > It certainly helps, but I trust that's not the only reason, in all the > > tests I did, there was an improvement in performance, even bef

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em qua., 25 de mai. de 2022 às 00:46, Andres Freund escreveu: Hi Andres, thank you for taking a look. > > On 2022-05-24 12:28:20 -0300, Ranier Vilela wrote: > > Linux Ubuntu 64 bits (gcc 9.4) > > ./pgbench -M prepared -c $conns -j $conns -S -n -U postgres > > &g

Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

Em ter., 24 de mai. de 2022 às 13:06, Robert Haas escreveu: > On Tue, May 24, 2022 at 11:28 AM Ranier Vilela > wrote: > > I think that I got something. > > You might have something, but it's pretty hard to tell based on > looking at this patch. Whatever relevant cha

Improving connection scalability (src/backend/storage/ipc/procarray.c)

ious gains. patch attached. regards, Ranier Vilela 001-improve-scability-procarray.patch Description: Binary data

Re: PG15 beta1 sort performance regression due to Generation context change

re why or how to fix it, but this > makes it much harder to follow the discussion. > > On 5/22/22 21:11, Ranier Vilela wrote: > > Hi David, > > > >>Over the past few days I've been gathering some benchmark results > >>together to show the sort performance i

Re: PG15 beta1 sort performance regression due to Generation context change

AllocSetContextCreate(state->sortcontext, "Caller tuples", ALLOCSET_DEFAULT_SIZES); else state->tuplecontext = GenerationContextCreate(state->sortcontext, "Caller tuples", ALLOCSET_DEFAULT_SIZES); I took a look and tried some improvements to see if I had a bette

Re: check for null value before looking up the hash function

Em sáb., 21 de mai. de 2022 às 13:13, Tom Lane escreveu: > Ranier Vilela writes: > > Em sáb., 21 de mai. de 2022 às 12:05, Tomas Vondra < > > tomas.von...@enterprisedb.com> escreveu: > >> That's a quite bold claim, and yet you haven't supported it by

Re: check for null value before looking up the hash function

Em sáb., 21 de mai. de 2022 às 12:05, Tomas Vondra < tomas.von...@enterprisedb.com> escreveu: > > > On 5/21/22 15:06, Ranier Vilela wrote: > >>Zhihong Yu writes: > >>> I was looking at the code in hash_record() > >>> of src/backend/utils/adt/r

Re: check for null value before looking up the hash function

Em sáb., 21 de mai. de 2022 às 10:06, Ranier Vilela escreveu: > >Zhihong Yu writes: > >> I was looking at the code in hash_record() > >> of src/backend/utils/adt/rowtypes.c > >> It seems if nulls[i] is true, we don't need to look up the hash > function.

Re: check for null value before looking up the hash function

how likely is that? I disagree. I think that is worth changing. The fact of complicating the logic is irrelevant. But maybe the v2 attached would be a little better. My doubt is the result calc when nulls are true. regards, Ranier Vilela v2-hash-record-check-null-first.patch Description: Binary data

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qua., 18 de mai. de 2022 às 19:57, David Rowley escreveu: > On Thu, 19 May 2022 at 02:08, Ranier Vilela wrote: > > That would initialize the content at compilation and not at runtime, > correct? > > Your mental model of compilation and run-time might be flawed here. > He

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qua., 18 de mai. de 2022 às 20:20, Tom Lane escreveu: > zeroing > relatively small, known-aligned node structs is THE use case. > Currently, especially on 64-bit Windows, MemSet can break alignment. regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em qua., 18 de mai. de 2022 às 19:57, David Rowley escreveu: > On Thu, 19 May 2022 at 02:08, Ranier Vilela wrote: > > That would initialize the content at compilation and not at runtime, > correct? > > Your mental model of compilation and run-time might be flawed here. > He

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

buffer is not a multiple of the element size of the type 'long'." message from PVS-Studio static analysis tool. regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

when you read the line of MemSet, you know what kind type is filled. > For the case where the variable is a pointer, the developer could write > 'sizeof(*variable)' instead of being forced to specify the type name, > for example (just a random one): > Could have used this style to make the patch. But the intention was to correct a possible misinterpretation, which in this case, showed that I was totally wrong. Sorry by the noise. regards, Ranier Vilela

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em ter., 17 de mai. de 2022 às 20:18, Justin Pryzby escreveu: > On Tue, May 17, 2022 at 07:52:30PM -0300, Ranier Vilela wrote: > > I found, I believe, a serious problem of incorrect usage of the memset > api. > > Historically, people have relied on using memset or MemSet, usin

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em ter., 17 de mai. de 2022 às 10:33, Ranier Vilela escreveu: > Em seg., 16 de mai. de 2022 às 20:26, David Rowley > escreveu: > >> On Sun, 15 May 2022 at 09:47, Ranier Vilela wrote: >> > At function load_relcache_init_file, there is an unnecessary function >

Re: Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

Em seg., 16 de mai. de 2022 às 20:26, David Rowley escreveu: > On Sun, 15 May 2022 at 09:47, Ranier Vilela wrote: > > At function load_relcache_init_file, there is an unnecessary function > call, > > to initialize pgstat_info pointer to NULL. > > > > MemSet(&a

Avoid unecessary MemSet call (src/backend/utils/cache/relcache.c)

*rel->pgstat_info)); Initialize with sizeof of Struct size, not with sizeof pointer size. But so it breaks. Attached a tiny patch. regards, Ranier Vilela avoid_unecessary_memset_call.patch Description: Binary data

Re: support for MERGE

Em ter., 12 de abr. de 2022 às 10:47, Alvaro Herrera < alvhe...@alvh.no-ip.org> escreveu: > On 2022-Apr-02, Ranier Vilela wrote: > > > Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera < > alvhe...@alvh.no-ip.org> > > escreveu: > > > IMHO, actually the

Re: shared-memory based stats collector

Hi, Per Coverity. pgstat_reset_entry does not check if lock it was really blocked. I think if shared_stat_reset_contents is called without lock, is it an issue not? regards, Ranier Vilela 0001-avoid-reset-stats-without-lock.patch Description: Binary data

logical decoding and replication of sequences

9630a1266> . RelationIdGetRelation can return NULL, then it is necessary to check the return. regards, Ranier Vilela 0001-avoid-dereference-null-relation.patch Description: Binary data

Re: support for MERGE

Em sáb., 2 de abr. de 2022 às 12:01, Alvaro Herrera escreveu: > On 2022-Mar-31, Daniel Gustafsson wrote: > > > > On 31 Mar 2022, at 19:38, Ranier Vilela wrote: > > > > > I think that there is an oversight at 7103ebb > > > There is no chance of Assert

support for MERGE

and >make sure to handle the case where there isn't one. Hi, I think that there is an oversight at 7103ebb <https://github.com/postgres/postgres/commit/7103ebb7aae8ab8076b7e85f335ceb8fe799097c> There is no chance of Assert preventing this bug. regards, Ranier Vilela 0001-avo

[PATCH] Avoid dereference null relation pointer (src/backend/replication/logical/reorderbuffer.c)

Hi hackers, Minor oversight with commit 0da92dc <https://github.com/postgres/postgres/commit/0da92dc530c9251735fc70b20cd004d9630a1266> . RelationIdGetRelation can return NULL, then it is necessary to check the return. regards, Ranier Vilela 0001-avoid-dereference-null-relation

Re: Uniforms the errors msgs at tuplestore paths

Em dom., 20 de fev. de 2022 às 22:45, Ranier Vilela escreveu: > Em dom., 20 de fev. de 2022 às 22:08, Michael Paquier > escreveu: > >> On Sun, Feb 20, 2022 at 11:37:33AM -0300, Ranier Vilela wrote: >> > I can't see: >> > plperl.c >> > pl_exec.c &

Re: Uniforms the errors msgs at tuplestore paths

Em dom., 20 de fev. de 2022 às 22:08, Michael Paquier escreveu: > On Sun, Feb 20, 2022 at 11:37:33AM -0300, Ranier Vilela wrote: > > I can't see: > > plperl.c > > pl_exec.c > > pttcl.c > > > > Only jsonfuncs.c, but the error about "materialize

Re: Uniforms the errors msgs at tuplestore paths

Em dom., 20 de fev. de 2022 às 11:30, Justin Pryzby escreveu: > On Sun, Feb 20, 2022 at 11:12:42AM -0300, Ranier Vilela wrote: > > Like how the commit > > > https://github.com/postgres/postgres/commit/07daca53bfcad59618a9c6fad304e380cc9d2bc1 > > The are some paths that

Uniforms the errors msgs at tuplestore paths

appropriately. The error about materialize mode required, is missed. -At pl_exec.c The error mgs do not report about the materialize mode -At pltcl.c: The function pltcl_init_tuple_store does not check rsi appropriately. Patch attached. regards, Ranier Vilela v1-0001-uniform-error-msgs

Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)

Em qui., 17 de fev. de 2022 às 10:18, Daniel Gustafsson escreveu: > > On 17 Feb 2022, at 13:59, Ranier Vilela wrote: > > > > Em qui., 17 de fev. de 2022 às 09:52, Daniel Gustafsson <mailto:dan...@yesql.se>> escreveu: > > > On 17 Feb 2022, at 13:19, Ranier

Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)

Em qui., 17 de fev. de 2022 às 09:52, Daniel Gustafsson escreveu: > > On 17 Feb 2022, at 13:19, Ranier Vilela wrote: > > > 1. One #ifdef with a mistake, the correct is _WIN32 and not WIN32. > > Can you elaborate on this, we are using WIN32 pretty extensively in the > cod

[PATCH] Fix possible minor memory leak (src/backend/catalog/heap.c)

Hi, Per Coverity. Maybe this is a mistake, but, Is it necessary or not to free the memory allocated by nodeToString? If yes, the patch attached fixes this. regards, Ranier Vilela fix_minor_memory_leak_heap.patch Description: Binary data

Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)

if Why does this ifdef exist? If the correct is this? #define DEF_ENC2NAME(name, codepage) { #name, PG_##name, codepage } 2. This path: #define DEF_ENC2NAME(name, codepage) { #name, PG_##name } DEF_ENC2NAME(EUC_JP, 20932), What happens if pg_encoding_max_length is called with Database->encoding equals 20932 ? Can you test the v2 of the patch? regards, Ranier Vilela v2_fix_out_of_bounds_wchar.patch Description: Binary data

Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)

Em qui., 17 de fev. de 2022 às 05:25, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Thu, 17 Feb 2022 15:50:09 +0800, Julien Rouhaud > wrote in > > On Thu, Feb 17, 2022 at 03:51:26PM +0900, Kyotaro Horiguchi wrote: > > > So, the function doesn't return 63 for all registered names and

Re: [PATCH] Fix out-of-bouds access (src/common/wchar.c)

Em qua., 16 de fev. de 2022 às 00:12, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Tue, 15 Feb 2022 09:17:34 -0300, Ranier Vilela > wrote in > > Per Coverity. > > Thanks for the source:) > > > Like the function pg_encoding_max_length_sql &g

[PATCH] Fix out-of-bouds access (src/common/wchar.c)

&filePath=%2Fdll%2Fpostgres%2Fpostgres%2Fsrc%2Fbackend%2Futils%2Fmb%2Fmbutils.c&fileStart=1546&fileEnd=1605> ] 633retval = pg_verify_mbstr_len(src_encoding, src_str, len, false); 634 Trivial patch attached. regards, Ranier Vilela fix_out_of_bounds_wchar.patch Description: Binary data

Re: Postgres 14.2 Windows can't rename temporary statistics file

Em seg., 14 de fev. de 2022 às 22:58, Thomas Munro escreveu: > On Tue, Feb 15, 2022 at 2:09 PM Ranier Vilela wrote: > > Em seg., 14 de fev. de 2022 às 21:58, Justin Pryzby < > pry...@telsasoft.com> escreveu: > >> On Mon, Feb 14, 2022 at 09:19:54PM -0300, Ranie

Re: Postgres 14.2 Windows can't rename temporary statistics file

Em seg., 14 de fev. de 2022 às 21:58, Justin Pryzby escreveu: > On Mon, Feb 14, 2022 at 09:19:54PM -0300, Ranier Vilela wrote: > > I've reported this issue, but without success in fixing it. > > It'd be helpful to provide a link to the prior discussions, and

Postgres 14.2 Windows can't rename temporary statistics file

12.215 db_25214.stat 14/02/2022 21:15 1.335 global.stat 3 arquivo(s) 15.220 bytes The point is we can not relies on the "rename" function at Windows Side. The local installation is made with user with full rights and permissions, but Postgres Windows

Re: Possible uninitialized use of the variables (src/backend/access/transam/twophase.c)

dPrepare() anymore if there is no origin data, no? It would be good > > to comment that these are filled in EndPrepare(), I guess, once you do > > the initialization in StartPrepare(). > > That still looked better on a fresh look in terms of consistency, so > applied this way. > Thanks. regards, Ranier Vilela

Re: [PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)

Em dom., 13 de fev. de 2022 às 18:43, Andres Freund escreveu: > Hi, > > On 2022-02-13 18:21:38 -0300, Ranier Vilela wrote: > > Why open and lock the table Extended Statistics if it is not the owner. > > Check and return to avoid this. > > I was about to say that this

[PATCH] Avoid open and lock the table Extendend Statistics (src/backend/commands/statscmds.c)

, Ranier Vilela avoid_open_and_lock_table_if_not_owner.patch Description: Binary data

Re: [PATCH] Dereference null return value (NULL_RETURNS) (src/backend/commands/statscmds.c)

Em ter., 25 de ago. de 2020 às 12:42, Ranier Vilela escreveu: > Hi Tom, > > Per Coverity. > > The SearchSysCache1 allows return NULL and at function AlterStatistics, > has one mistake, lack of, check of return, which enables a dereference > NULL pointer, > at fu

Re: Signed vs. Unsigned (some)

Em sex., 11 de jun. de 2021 às 23:05, Ranier Vilela escreveu: > Hi, > > Removing legitimate warnings can it be worth it? > > -1 CAST can be wrong, when there is an invalid value defined > (InvalidBucket, InvalidBlockNumber). > I think depending on the compiler -1 CAST

Re: Plug minor memleak in pg_dump

Em qui., 10 de fev. de 2022 às 10:57, Daniel Gustafsson escreveu: > > On 10 Feb 2022, at 12:14, Ranier Vilela wrote: > > Em qua., 9 de fev. de 2022 às 23:16, Michael Paquier < > mich...@paquier.xyz <mailto:mich...@paquier.xyz>> escreveu: > > > This patch ma

Re: Plug minor memleak in pg_dump

Em qui., 10 de fev. de 2022 às 08:14, Ranier Vilela escreveu: > Em qua., 9 de fev. de 2022 às 23:16, Michael Paquier > escreveu: > >> On Wed, Feb 09, 2022 at 02:48:35PM -0300, Ranier Vilela wrote: >> > IMO I think that still have troubles here. >> > >> &g

Re: Plug minor memleak in pg_dump

Em qua., 9 de fev. de 2022 às 23:16, Michael Paquier escreveu: > On Wed, Feb 09, 2022 at 02:48:35PM -0300, Ranier Vilela wrote: > > IMO I think that still have troubles here. > > > > ReadStr can return NULL, so the fix can crash. > > - sscanf(tmp, &q

Re: [PATCH] Improve function toast_delete_external (src/backend/access/table/toast_helper.c)

Em qua., 9 de fev. de 2022 às 20:10, Dong Wook Lee escreveu: > Yes, now I understand it. > Thank you for letting me know about that. > You are welcome. Best regards, Ranier Vilela

Re: Plug minor memleak in pg_dump

>No, but I was distracted by other things leaving this on the TODO list. It's >been pushed now. Hi, IMO I think that still have troubles here. ReadStr can return NULL, so the fix can crash. regards, Ranier Vilela v1_fix_possible_null_dereference_pg_backup_archiver.patch Descript

Possible uninitialized use of the variables (src/backend/access/transam/twophase.c)

think thay forgot initialize these fields in the function StartPrepare because, when calling function save_state_data(&hdr, sizeof(TwoPhaseFileHeader)); I have one report about possible uninitialized usage of the variables. Best regards, Ranier Vi

[PATCH] Improve function toast_delete_external (src/backend/access/table/toast_helper.c)

Hi, I think this change can improve this particular function by avoiding touching value if not needed. Test if not isnull is cheaper than test TupleDescAttr is -1. best regards, Ranier Vilela v1_tiny_improvemnt_toast_helper.patch Description: Binary data

Re: Eval expression R/O once time (src/backend/executor/execExpr.c)

Em ter., 2 de nov. de 2021 às 15:33, Andres Freund escreveu: > On 2021-11-02 13:43:46 -0400, Tom Lane wrote: > > Ranier Vilela writes: > > > It seems that 1ec7679f1b67e84be688a311dce234eeaa1d5de8 caused the > problem. > > > > Indeed. Fix pushed. > > T

Re: Fix uninitialized variable access (src/backend/utils/mmgr/freepage.c)

Em sex., 1 de out. de 2021 às 16:24, David Zhang escreveu: > On 2021-08-18 1:29 a.m., Kyotaro Horiguchi wrote: > > 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

Re: Eval expression R/O once time (src/backend/executor/execExpr.c)

Em sex., 1 de out. de 2021 às 06:55, Artur Zakirov escreveu: > On Wed, Sep 22, 2021 at 1:12 AM Ranier Vilela wrote: > > Anyway, the v1 patch fixes only the expression eval. > > The patch looks good to me. > > It seems that initially the code looked similar to your pa

Re: jsonb crash

GIN_ARRAY && v. val.array.rawScalar) ? &v : NULL); regards, Ranier Vilela

Re: [BUG] failed assertion in EnsurePortalSnapshotExists()

Em qua., 29 de set. de 2021 às 15:01, Tom Lane escreveu: > Alvaro Herrera writes: > > On 2021-Sep-29, Ranier Vilela wrote: > >> Em qua., 29 de set. de 2021 às 08:12, Drouvot, Bertrand < > bdrou...@amazon.com> > >> escreveu: > >> Duplicating functio

Re: [BUG] failed assertion in EnsurePortalSnapshotExists()

Em qua., 29 de set. de 2021 às 08:12, Drouvot, Bertrand escreveu: > Hi, > On 9/29/21 12:59 PM, Ranier Vilela wrote: > > > Em qua., 29 de set. de 2021 às 06:55, Drouvot, Bertrand < > bdrou...@amazon.com> escreveu: > >> I'm also inclined to #1. >&g

Re: [BUG] failed assertion in EnsurePortalSnapshotExists()

fragile --- do we assume as_snap is > > unique for any other purpose? > > > > That being the case, I'm now leaning to #1. Thoughts? > > I'm also inclined to #1. > I have a stupid question, why duplicate PushActiveSnapshot? Wouldn't one function be better? PushActiveSnapshot(Snapshot snap, int as_level); Sample calls: PushActiveSnapshot(GetTransactionSnapshot(), GetCurrentTransactionNestLevel()); PushActiveSnapshot(queryDesc->snapshot, GetCurrentTransactionNestLevel()); PushActiveSnapshot(GetTransactionSnapshot(), portal->createSubid); regards, Ranier Vilela

Re: Empty string in lexeme for tsvector

Em sex., 24 de set. de 2021 às 09:39, Jean-Christophe Arnu escreveu: > > > Le ven. 24 sept. 2021 à 13:03, Ranier Vilela a > écrit : > >> >> Comments are more than welcome! >>> >> 1. Would be better to add this test-and-error before tsvector

<    1   2   3   4   5   6   7   8   9   >