650 nanoseconds (6.85551 times faster than byte per
> byte)
> SIMD v10: done in 136413 nanoseconds (21.9441 times faster than byte per
> byte)
> SIMD v11: done in 155474 nanoseconds (19.2538 times faster than byte per
> byte)
>
gcc -march=native -O2 v1_allzeros_small.c -o v1_allzer
Hi.
Per Coverity.
The function *determineNotNullFlags* has a little oversight.
The struct field *notnull_islocal* is an array.
I think this is a simple typo.
Fix using array notation access.
Trivial patch attached.
best regards,
Ranier Vilela
fix_array_access_pg_dump.patch
Description
Em ter., 12 de nov. de 2024 às 16:11, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2024-Nov-12, Ranier Vilela wrote:
>
> > Per Coverity.
> >
> > The function *determineNotNullFlags* has a little oversight.
> > The struct field *notnull_islocal* is
0000-0000---'::uuid)
-> Bitmap Index Scan on idx (cost=0.00..1.07 rows=9
width=0)
Index Cond: (u =
'----'::uuid)
(8 rows)
best regards,
Ranier Vilela
x27;t know if it's
safe though.
results with v3_allzeros_small.c attached:
WITH 8192 BLCKSZ
Ubuntu 22.04 64 bits
gcc -march=native -O2 v3_allzeros_small.c -o v3_allzeros_small ;
./v3_allzeros_small
byte per byte: done in 5027744 nanoseconds
size_t: done in 382521 nanoseconds (13.1437 times fast
Em sex., 15 de nov. de 2024 às 11:43, Bertrand Drouvot <
bertranddrouvot...@gmail.com> escreveu:
> Hi,
>
> On Fri, Nov 15, 2024 at 09:54:33AM -0300, Ranier Vilela wrote:
> > There is a tiny typo with V13.
> > + /* "len" in the [sizeof(size_t) * 8, inf] rang
it worth mentioning that pg_memory_is_all_zeros does not work correctly
on 32-bit systems?
(63 < (size_t) * 8) /* 63 - 32*/
Or do we adjust magic constants according to 32/64 bit?
best regards,
Ranier Vilela
Em qui., 14 de nov. de 2024 às 08:58, Bertrand Drouvot <
bertranddrouvot...@gmail.com> escreveu:
> Hi,
>
> On Thu, Nov 14, 2024 at 08:22:23AM -0300, Ranier Vilela wrote:
> > Em qui., 14 de nov. de 2024 ąs 07:09, Bertrand Drouvot <
> > bertranddrouvot...@gma
Em sáb., 16 de nov. de 2024 às 11:40, Ranier Vilela
escreveu:
>
> Em sex., 15 de nov. de 2024 às 11:43, Bertrand Drouvot <
> bertranddrouvot...@gmail.com> escreveu:
>
>> Hi,
>>
>> On Fri, Nov 15, 2024 at 09:54:33AM -0300, Ranier Vilela wrote:
>> >
believe that in testing, you need to set it to BUFFERS OFF,
because of the recent change made to ANALYZE.
The tests are failing, like this:
QUERY PLAN
-
Nested Loop Semi Join (actual rows=2 loops=1)
+ Buffers: local hit=7
gt; if (cheapset == NULL || bms(PATH_REQ_OUTER(cheapset), required_outer))
> return cheapest;
>
I think no in this case.
If cheapset is NULL, the logic is to continue the find.
What cannot happen is passing a null pointer to bms(PATH_REQ_OUTER.
best regards,
Ranier Vilela
Hi.
Em qua., 5 de fev. de 2025 às 14:08, Daniel Gustafsson
escreveu:
> > On 5 Jan 2025, at 00:29, Ranier Vilela wrote:
> >
> > Hi.
> >
> > Per Coverity.
> >
> > All call sites of function *get_cheapest_path_for_pathkeys* checks
> > for NULL r
Hi.
Em qua., 5 de fev. de 2025 às 13:51, Ilia Evdokimov <
ilya.evdoki...@tantorlabs.com> escreveu:
>
> On 05.01.2025 02:29, Ranier Vilela wrote:
> > Hi.
> >
> > Per Coverity.
> >
> > All call sites of function *get_cheapest_path_for_pathkeys* checks
>
Em qua., 5 de fev. de 2025 às 15:56, Tom Lane escreveu:
> So I don't
> find it to be an improvement.
>
Ok, I'm withdrawing this patch.
Thanks to everyone who contributed to the thread.
best regards,
Ranier Vilela
Postgres API.
According to the documentation:
libpq-exec <https://www.postgresql.org/docs/current/libpq-exec.html>
The correct function to free memory when using PQescapeLiteral and
PQescapeIdentifier would be PQfreemem.
Trivial fixes attached.
best regards,
Ranier Vilela
fix-resourc
Hi.
Per Coverity.
CID 1591288: (#1 of 1): Resource leak (RESOURCE_LEAK)
10. leaked_storage: Variable sysidentifier going out of scope leaks the
storage it points to.
Trivial patch attached.
best regards,
Ranier Vilela
fix-resource-leak-pg_receivewal.patch
Description: Binary data
lled once per database in
> setup_subscriber(), and we are not going to have millions of them in
> this list. We don't usually care for such short-lived things, but as
> the original commit did the effort in d44032d01463, I don't see why we
> cannot do it here, either.
>
Thanks Michael.
best regards,
Ranier Vilela
rs_cindex. I think to make this clear we would have to add another
> special case for backwards and no movement scan.
>
> For now, I've committed the version of the patch I proposed above (v3).
>
What happens if *rs_tuples* equal to zero in function
*SampleHeapTupleVisible*?
end =
644
--- a/src/backend/access/heap/heapam_handler.c
+++ b/src/backend/access/heap/heapam_handler.c
@@ -2574,7 +2574,7 @@ SampleHeapTupleVisible(TableScanDesc scan, Buffer
buffer,
if (scan->rs_flags & SO_ALLOW_PAGEMODE)
{
- uint32 start,
+ int64 start,
end;
if (hscan->rs_ntuples == 0)
@@ -2594,7 +2594,7 @@ SampleHeapTupleVisible(TableScanDesc scan, Buffer
buffer,
while (start <= end)
{
- uint32 mid = (start + end) / 2;
+ int64 mid = (start + end) >> 1;
OffsetNumber curoffset = hscan->rs_vistuples[mid];
if (tupoffset == curoffset)
best regards
Ranier Vilela
>
> - Melanie
>
Hi.
Sorry for not responding quickly.
I have been without communication until now.
Em qua., 18 de dez. de 2024 às 17:13, Melanie Plageman <
melanieplage...@gmail.com> escreveu:
> On Wed, Dec 18, 2024 at 1:23 PM Ranier Vilela wrote:
> >
> > Hi.
> >
> > Em
> end = mid - 1;
> + }
> else
> start = mid + 1;
> }
>
> Alternatively, we can revert 'start' and 'end' to signed int as they
> were before.
>
How would it be *signed*?
Wouldn't overflow happen in this case?
rs_tuples now can be
UINT_MAX = 4294967295
best regards,
Ranier Vilela
t32 start,
end;
- if (hscan->rs_ntuples == 0)
- return false;
-
/*
* In pageatatime mode, heap_prepare_pagescan() already did visibility
* checks, so just look at the info it left in rs_vistuples[].
@@ -2590,17 +2587,17 @@ SampleHeapTupleVisible(TableScanDesc scan, Buffer
buffer,
* gain to justify the restriction.
*/
start = 0;
- end = hscan->rs_ntuples - 1;
+ end = hscan->rs_ntuples;
- while (start <= end)
+ while (start < end)
{
- uint32 mid = (start + end) / 2;
+ uint32 mid = (start + end) >> 1;
OffsetNumber curoffset = hscan->rs_vistuples[mid];
if (tupoffset == curoffset)
return true;
else if (tupoffset < curoffset)
- end = mid - 1;
+ end = mid;
else
start = mid + 1;
}
best regards,
Ranier Vilela
one of these has kernel access.
You should be careful about:
Old antivirus software
Kernel storage incompative drivers
Third-party drivers
Hardware failure
best regards,
Ranier Vilela
.
best regards,
Ranier Vilela
fix-possible-null-dereference-allpatchs.patch
Description: Binary data
dcdddedfe0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff"
;
+static const char hextbl[512] =
"000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f303132333435363738393a3b3c3d3e3f404142434445464748494a4b4c4d4e4f505152535455565758595a5b5c5d5e5f606162636465666768696a6b6c6d6e6f707172737475767778797a7b7c7d7e7f808182838485868788898a8b8c8d8e8f909192939495969798999a9b9c9d9e9fa0a1a2a3a4a5a6a7a8a9aaabacadaeafb0b1b2b3b4b5b6b7b8b9babbbcbdbebfc0c1c2c3c4c5c6c7c8c9cacbcccdcecfd0d1d2d3d4d5d6d7d8d9dadbdcdddedfe0e1e2e3e4e5e6e7e8e9eaebecedeeeff0f1f2f3f4f5f6f7f8f9fafbfcfdfeff"
;
best regards,
Ranier Vilela
re WALWriteLock is waited and the
> holder is running WAIT_EVENT_WAL_INIT_WRITE.
>
Can you report the benchmark difference with false (disabled)?
Maybe It's worth considering leaving false as the default.
best regards,
Ranier Vilela
ther calls check the return, In this case it could not be different.
Fix by checking the return and reporting a message to the user,
in case of failure.
best regards,
Ranier Vilela
[0] I think the most correct would be *or* not *and* word?
fix-misuse-function-pg_b64_encode.patch
Description: Binary data
Em qui., 16 de jan. de 2025 às 05:07, Peter Eisentraut
escreveu:
> On 16.01.25 02:12, Ranier Vilela wrote:
> > Per Coverity.
> >
> > CID 1590024:(CHECKED_RETURN)
> > Calling "pg_b64_encode" without checking return value (as is done
> > elsewhe
Em sex., 17 de jan. de 2025 às 05:11, Peter Eisentraut
escreveu:
> On 16.01.25 11:23, Ranier Vilela wrote:
> >
> >
> > Em qui., 16 de jan. de 2025 às 05:07, Peter Eisentraut
> > mailto:pe...@eisentraut.org>> escreveu:
> >
> > On 16.01.25 02:12,
Em qua., 12 de fev. de 2025 às 18:17, Tom Lane escreveu:
> Ranier Vilela writes:
> > Coverity has some reports about pg_createsubcriber.
>
> > CID 1591322: (#1 of 1): Resource leak (RESOURCE_LEAK)
> > 10. leaked_storage: Variable dbname going out of scope leaks the st
Hi.
Coverity complained about possible dereference null pointer
in *reindex_one_database* function.
That's not really true.
But the logic is unnecessarily complicated.
Let's simplify it to humans and machines.
patch attached.
Best regards,
Ranier Vilela
simplifies-reindex-on
Em qui., 13 de fev. de 2025 às 16:05, Tom Lane escreveu:
> Ranier Vilela writes:
> > Interesting, Coverity has some new reports regarding PQescapeIdentifier.
>
> > CID 1591290: (#1 of 1): Out-of-bounds access (OVERRUN)
> > 2. alloc_strlen: Allocating insufficient memory
> len.
>
Interesting, Coverity has some new reports regarding PQescapeIdentifier.
CID 1591290: (#1 of 1): Out-of-bounds access (OVERRUN)
2. alloc_strlen: Allocating insufficient memory for the terminating null of
the string. [Note: The source code implementation of the function has been
overridden by a builtin model.]
Until now, I was in disbelief.
best regards,
Ranier Vilela
Em seg., 17 de mar. de 2025 às 16:17, Ranier Vilela
escreveu:
> Em sex., 7 de mar. de 2025 às 16:14, Ranier Vilela
> escreveu:
>
>>
>>
>> Em sex., 7 de mar. de 2025 às 16:01, Álvaro Herrera <
>> alvhe...@alvh.no-ip.org> escreveu:
>>
>>> On 2
case of
> > duplicated clause in regression tests.
> >
> > I've changed 'inner' and 'outer' vise versa in
> > remove_self_joins_one_group() for better readability (I believe that
> > was discussed upthread but lost). Also, I did a round of improvement
> > for comments and commit message.
>
> I've corrected some spelling error reported by Alexander Lakhin
> privately to me. Also, I've revised comments around ChangeVarNodes()
> and ChangeVarNodesExtended(). I'm going to continue nitpicking this
> patch during next couple days then push it if no objections.
>
I think a small optimization is possible here.
The whole block that append *rinfo* to exprs is controlled by extra_clause
not NULL.
So It's worth moving the test to the beginning of the block and avoiding it
altogether if that's the case.
trivial patch attached.
best regards,
Ranier Vilela
avoid-expensive-function-indxpath.patch
Description: Binary data
Em seg., 17 de mar. de 2025 às 16:17, Ranier Vilela
escreveu:
> Em sex., 7 de mar. de 2025 às 16:14, Ranier Vilela
> escreveu:
>
>>
>>
>> Em sex., 7 de mar. de 2025 às 16:01, Álvaro Herrera <
>> alvhe...@alvh.no-ip.org> escreveu:
>>
>>> On 2
Em sex., 7 de mar. de 2025 às 16:14, Ranier Vilela
escreveu:
>
>
> Em sex., 7 de mar. de 2025 às 16:01, Álvaro Herrera <
> alvhe...@alvh.no-ip.org> escreveu:
>
>> On 2025-Mar-07, Álvaro Herrera wrote:
>>
>> > Anyway, my version of this is attached.
t makes queries of pg_stat_io a bit cheaper. Will fix in a bit.
>
Thank you Michael.
best regards,
Ranier Vilela
<http://a051e71e28a12342a4fb39a3c149a197159f9c46>
I think it left an oversight.
Copy and past thinko?
Attached a trivial patch.
best regards,
Ranier Vilela
fix-possible-copy-and-paste-thinko.patch
Description: Binary data
Em qua., 9 de abr. de 2025 às 10:27, Matthias van de Meent <
boekewurm+postg...@gmail.com> escreveu:
> On Wed, 9 Apr 2025 at 15:01, Ranier Vilela wrote:
> >
> > Hi.
> >
> > Per Coverity.
> >
> > CID 1608872: (#1 of 1): Improper use of negative valu
fdw.c
Function: postgresBeginForeignScan
Check the return of bms_next_member and abort if fail.
Function: postgresExplainForeignScan
Check the return of bms_next_member and abort if fail.
The patchs are attempts, not definitive fixes.
best regards,
Ranier Vilela
avoid-miuse-api-bms_next_member-equivclass.patch
Descr
. ruleutils.c
best regards,
Ranier Vilela
postpone_string_buffer_creation_pg_overexplain.patch
Description: Binary data
postpone_string_buffer_creation_ruleutils.patch
Description: Binary data
.com
>
> Thanks Andrew for the updated patches.
>
> Here, I am attaching a delta patch with some more TAP-test cases.
>
>
> Here, I am attaching an updated delta patch which has some more TAP
> tests. Please include these tests also. This patch can be applied on
&g
Em ter., 1 de abr. de 2025 às 15:39, Noah Misch
escreveu:
> On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> > Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier <
> mich...@paquier.xyz>
> > escreveu:
> >
> > > On Tue, Feb 25, 2025 a
Em ter., 1 de abr. de 2025 às 15:39, Noah Misch
escreveu:
> On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> > Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier <
> mich...@paquier.xyz>
> > escreveu:
> >
> > > On Tue, Feb 25, 2025 a
Thanks Michael, for looking at this.
Em sex., 11 de abr. de 2025 às 02:09, Michael Paquier
escreveu:
> On Thu, Apr 10, 2025 at 03:10:02PM -0300, Ranier Vilela wrote:
> > While it is arguable that this is a false warning, there is a benefit in
> > moving the initialization of th
Em sex., 11 de abr. de 2025 às 02:37, Tom Lane escreveu:
> Michael Paquier writes:
> > On Thu, Apr 10, 2025 at 03:10:02PM -0300, Ranier Vilela wrote:
> >> While it is arguable that this is a false warning, there is a benefit in
> >> moving the initialization of the s
1244}
There a common pattern in the source code:
value = (Datum) 0;
null = true;
So I believe it is worth changing to the standard used.
patch attached.
best regards,
Ranier Vilela
fix_read_unitialized_variable_tablecmds.patch
Description: Binary data
fix-uninitialized-read-variable-tablespace.
Em sex., 11 de abr. de 2025 às 08:27, Ranier Vilela
escreveu:
> Thanks Michael, for looking at this.
>
>
> Em sex., 11 de abr. de 2025 às 02:09, Michael Paquier
> escreveu:
>
>> On Thu, Apr 10, 2025 at 03:10:02PM -0300, Ranier Vilela wrote:
>> > While it is argu
and *nulls* should also be released.
While there, move the creation of stringdata, to ensure that in case of
failure, the buf.data variable is released correctly.
Attached a path.
best regards,
Ranier Vilela
fix-resource-leak-rowtypes.patch
Description: Binary data
Hi Andrew.
I just saw the fix commit.
My fault.
I'm sorry.
best regards,
Ranier Vilela
Em seg., 14 de abr. de 2025 às 09:46, Ranier Vilela
escreveu:
> Hi Michael.
>
> Em dom., 13 de abr. de 2025 às 21:36, Michael Paquier
> escreveu:
>
>> Hi all,
>>
>> One thing that's been lacking in injection points is the possibility
>> to look at
e FREE() call is reached only if
> the JSONLEX_FREE_STRUCT flag is set, which it should not be for these
> call sites.
See the function *makeJsonLexContextCstringLen* (line 400)
The JSONLEX_FREE_STRUCT is enabled, no?
fe-auth-oauth.c (line 507)
makeJsonLexContextCstringLen(&lex, msg, msglen, PG_UTF8, true);
Worst, on a second call, with lex not NULL, the flags is reseted
and the struct will no longer be released?
best regards,
Ranier Vilela
Em seg., 14 de abr. de 2025 às 18:11, Tom Lane escreveu:
> Robert Haas writes:
> > On Sun, Apr 13, 2025 at 7:34 PM Ranier Vilela
> wrote:
> >> The function *record_in* has a new report about resource leak.
> >> I think Coverity is right.
>
> > I agree,
Em qui., 10 de abr. de 2025 às 15:58, Andrew Dunstan
escreveu:
>
> On 2025-04-10 Th 2:38 PM, Ranier Vilela wrote:
>
>
>>
>> Thanks. I have pushed these now with a few further small tweaks.
>>
> Sorry if it is not the right place.
> Coverity has another re
Em qui., 10 de abr. de 2025 20:09, Andrew Dunstan
escreveu:
>
> On 2025-04-10 Th 5:45 PM, Ranier Vilela wrote:
>
>
> Em qui., 10 de abr. de 2025 às 15:58, Andrew Dunstan
> escreveu:
>
>>
>> On 2025-04-10 Th 2:38 PM, Ranier Vilela wrote:
>>
>>
>&
Em seg., 14 de abr. de 2025 às 16:59, Robert Haas
escreveu:
> On Sun, Apr 13, 2025 at 7:34 PM Ranier Vilela wrote:
> > CID 1608916: (#1 of 1): Resource leak (RESOURCE_LEAK)
> > 52. leaked_storage: Variable buf going out of scope leaks the storage
> buf.data points to.
&g
Em ter., 18 de fev. de 2025 13:21, Tom Lane escreveu:
> Ranier Vilela writes:
> > There are some reports that Postgres does not handle correctly cleaning
> the
> > files used when it crashes. [1]
> > I think that function *fcloseall* can help a little bit.
> > M
files created by tmpfile
function.
*/
patch attached.
best regards,
Ranier Vilela
[1]
https://www.postgresql.org/message-id/CAE9k0Pno%3DMns7J5HA4%2BbbXzb%3DyCZnCtSF_wf1ZipCQxardKDjA%40mail.gmail.com
improve-cleaning-on-fatal-and-panic-elog.patch
Description: Binary data
Hi.
Similar to commit 5b94e27 <http://5b94e2753439b699b78aacbb53e89bf0e814becc>
[1]
The correct function when freeing memory in the frontend,
using the function PQescapeIdentifier, must be
PQfreemem.
Trivial patch attached.
best regards,
Ranier Vilela
[1]
https://www.postgresql.org/mess
Em ter., 18 de fev. de 2025 às 13:29, Ranier Vilela
escreveu:
>
> Em ter., 18 de fev. de 2025 13:21, Tom Lane escreveu:
>
>> Ranier Vilela writes:
>> > There are some reports that Postgres does not handle correctly cleaning
>> the
>> > files used when it
Em qua., 19 de fev. de 2025 às 14:48, Ranier Vilela
escreveu:
> Em ter., 18 de fev. de 2025 às 13:29, Ranier Vilela
> escreveu:
>
>>
>> Em ter., 18 de fev. de 2025 13:21, Tom Lane escreveu:
>>
>>> Ranier Vilela writes:
>>> > There are some
; failed to do what we expect and did not set per_buffer_data,
> > we'd be certain to get a null-pointer core dump rather than
> > accessing data from a previous buffer.
>
> Done and pushed. Thanks!
>
Per Coverity.
CID 1592454: (#1 of 1): Explicit null dereferenced (FORW
de espacios en blanco.
>
>
> Anyway, my version of this is attached. It fixes the problems with your
> patch, but not Orlov's fundamental bug. Without fixing that bug, this
> program does not deserve this supposedly parallel mode that doesn't
> actually deliver. I wonder if we shouldn't just revert 47f99a407de2
> completely.
>
> You, on the other hand, really need to be much more careful with the
> patches you submit.
>
Yes of course, thank you for making the necessary corrections.
best regards,
Ranier Vilela
Em qui., 6 de mar. de 2025 às 15:51, Álvaro Herrera
escreveu:
> On 2025-Feb-28, Ranier Vilela wrote:
>
> > v2 attached, please comment if you have any further objections.
>
> I think running the tests would have been a good idea, as would checking
> for compiler warnin
nfig('search_path', '', false);
REINDEX INDEX public.bar1;
RESET search_path;
SELECT c.relname, ns.nspname
FROM pg_catalog.pg_class c, pg_catalog.pg_namespace ns
WHERE c.relnamespace OPERATOR(pg_catalog.=) ns.oid
AND c.oid OPERATOR(pg_catalog.=) 'public.bar2'::pg_catalog.regclass;
SELECT pg_catalog.set_config('search_path', '', false);
REINDEX INDEX public.bar2;
best regards,
Ranier Vilela
's no guarantee that the index scan
> found the same row version that table_tuple_lock() will lock, if the TID
> alone doesn't uniquely identify it. But that's still OK as long as the
> key column hasn't changed, like with heapam's HOT updates. I couldn't
> convince myself that it's broken nor that it's guaranteed to be correct
> with other AMs.
>
Just for curiosity.
*RelationFindReplTupleSeq* on the same source, does not suffer
from the same issue?
PushActiveSnapshot(GetLatestSnapshot());
res = table_tuple_lock(rel, &(outslot->tts_tid), GetLatestSnapshot(),
best regards,
Ranier Vilela
Em seg., 10 de mar. de 2025 às 13:52, Heikki Linnakangas
escreveu:
> On 10/03/2025 18:20, Ranier Vilela wrote:
> > Just for curiosity.
> > *RelationFindReplTupleSeq* on the same source, does not suffer
> > from the same issue?
> >
> > PushActiveSnapshot(
used when per buffer data is used. Adding a check
> for
> > per_buffer_data and assigning something to it is nonsensical.
>
Perhaps.
But the fast path and the parameter void **per_buffer_data,
IMHO, is a serious risk in my opinion.
Of course, when in runtime.
best regards,
Ranier Vilela
Em qui., 27 de fev. de 2025 às 22:19, Michael Paquier
escreveu:
> On Thu, Feb 27, 2025 at 10:23:31AM -0300, Ranier Vilela wrote:
> > Yeah, I also think it would look good like this.
>
> It's the least confusing option, indeed. I've reduced a bit the diffs
> and d
Hi Álvaro.
Em qui., 27 de fev. de 2025 às 16:50, Álvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2025-Feb-14, Ranier Vilela wrote:
>
> > Attached is the prototype version v1.
> > What do you think?
>
> I think this is still a bit confused. The new function
Hi Álvaro.
Em qui., 13 de fev. de 2025 às 18:38, Álvaro Herrera <
alvhe...@alvh.no-ip.org> escreveu:
> On 2025-Feb-13, Ranier Vilela wrote:
>
> > Hi.
> >
> > Coverity complained about possible dereference null pointer
> > in *reindex_one_database* function.
done under extreme time
> pressure. I wonder if they have any other issues. More eyes on those
> patches would be welcome, now that they are public.
>
Passes on standard tests at Windows 64 bits, msvc 2022 64 bits.
best regards,
Ranier Vilela
Em sex., 14 de fev. de 2025 às 09:13, Ranier Vilela
escreveu:
> Hi Álvaro.
>
> Em qui., 13 de fev. de 2025 às 18:38, Álvaro Herrera <
> alvhe...@alvh.no-ip.org> escreveu:
>
>> On 2025-Feb-13, Ranier Vilela wrote:
>>
>> > Hi.
>> >
>> >
patch attached.
Another *dat->amcheck_schema* is it not worth the effort,
since the memory is not released at any point?
Trivial patch attached.
best regards,
Ranier Vilela
fix-api-misuse-pg_amcheck.patch
Description: Binary data
Em sex., 14 de fev. de 2025 às 10:19, Ranier Vilela
escreveu:
> Em sex., 14 de fev. de 2025 às 09:13, Ranier Vilela
> escreveu:
>
>> Hi Álvaro.
>>
>> Em qui., 13 de fev. de 2025 às 18:38, Álvaro Herrera <
>> alvhe...@alvh.no-ip.org> escreveu:
>
nd_encoding(void)
locale->db_locale,
strlen(locale->db_locale));
else
- datlocale_literal = pg_strdup("NULL");
+ datlocale_literal = PQescapeLiteral(conn_new_template1,
+ "NULL",
+ strlen("NULL"));
best regards,
Ranier Vilela
avoid-mix-api-pg_upgrade.patch
Description: Binary data
Em qui., 27 de fev. de 2025 às 02:08, Michael Paquier
escreveu:
> On Wed, Feb 26, 2025 at 07:04:25PM +0530, vignesh C wrote:
> > On Tue, 18 Feb 2025 at 18:18, Ranier Vilela wrote:
> >> Similar to commit 5b94e27 [1]
> >> The correct function when freeing memory in t
Em qui., 27 de fev. de 2025 às 02:51, Michael Paquier
escreveu:
> On Tue, Feb 25, 2025 at 08:54:31AM -0300, Ranier Vilela wrote:
> > @@ -455,7 +455,9 @@ set_locale_and_encoding(void)
> > locale->db_locale,
> > strlen(locale->db_locale));
> > else
> >
initialize the *result* field.
2. result_one can be reduced scope.
best regards,
Ranier Vilela
Em qui., 3 de abr. de 2025 às 15:35, Andres Freund
escreveu:
> Hi,
>
> On 2025-04-03 13:46:39 -0300, Ranier Vilela wrote:
> > Em qua., 2 de abr. de 2025 às 08:58, Andres Freund
> > escreveu:
> >
> > > Hi,
> > >
> > > I've pushed fixes
dae11ee5da8318b646b9d47129c>
left a minor oversight.
Typo comparison?
a trivial fix attached.
best regards,
Ranier Vilela
fix-typo-comparison-variables.patch
Description: Binary data
Coverity alert is valid.
The function never returns 0.
best regards,
Ranier Vilela
rebased heapam.c and heapam_handler.c
best regards,
Ranier Vilela
v1-heapam_set_tuple_block_once.patch
Description: Binary data
v1-heapam_handler_set_tuple_block_once.patch
Description: Binary data
_visibility.c
contrib/pgstattuple/pgstatapprox.c
src/backend/access/heap/heapam.c
src/backend/access/heap/heapam_handler.c
src/backend/access/heap/pruneheap.c
src/backend/access/heap/vacuumlazy.c
src/backend/commands/dbcommands.c
Attached all patchs.
best regards,
Ranier Vilela
[1] Re: AIO writes vs h
Em qua., 18 de jun. de 2025 às 07:29, Etsuro Fujita
escreveu:
> On Tue, Jun 17, 2025 at 11:03 PM Fujii Masao
> wrote:
> > On 2025/06/17 20:37, Ranier Vilela wrote:
> > > Em ter., 17 de jun. de 2025 às 06:09, Etsuro Fujita <
> etsuro.fuj...@gmail.com <mailto:etsu
Em ter., 17 de jun. de 2025 às 10:42, Daniel Gustafsson
escreveu:
> > On 17 Jun 2025, at 15:40, Ranier Vilela wrote:
>
> > In the function *PQcancelCreate* there is a copy-and-past thinko.
> > The pointer that must be checked is cancelConn.
> >
> > Trivial pat
Hi.
In the function *estimate_path_cost_size* the parameter
fpextra can be NULL.
It is necessary to always check its validity,
as is already done in other parts of the source.
patch attached.
Best regards,
Ranier Vilela
fix-possible-dereference-null-pointer-postgres_fdw.patch
Description
Hi.
The function *ScanPgRelation* can return a invalid tuple.
It is necessary to check the function's return,
as is already done in other parts of the source.
patch attached.
Best regards,
Ranier Vilela
fix-possible-dereference-null-pointer-relcache.patch
Description: Binary data
ll paths, this check is done, why would this be the only exception?
best regards,
Ranier Vilela
nsus that there will not be a segfault.
If a segfault will never occur, ok.
IMO, this is not a query-dependent issue.
But the table in question is never corrupted or invalid.
best regards,
Ranier Vilela
es in fpinfo so we don't need to do it again to generate the
* basic foreign path.
*/
estimate_path_cost_size(root, baserel, NIL, NIL, NULL,
&fpinfo->rows, &fpinfo->width,
&fpinfo->disabled_nodes,
&fpinfo->startup_cost, &fpinfo->total_cost);
best regards,
Ranier Vilela
Em ter., 17 de jun. de 2025 às 10:42, Daniel Gustafsson
escreveu:
> > On 17 Jun 2025, at 15:40, Ranier Vilela wrote:
>
> > In the function *PQcancelCreate* there is a copy-and-past thinko.
> > The pointer that must be checked is cancelConn.
> >
> > Trivial pat
t adding a "elog(ERROR)" here would be misleading, as
> it implies it's something we expect. And mostly pointless. I can imagine
> adding an Assert, but I don't quite see how is that better than just
> hitting a segfault a couple lines later.
>
To me this is a contradiction, whether you consider waiting for a segfault
or consider adding an Assert.
For the user it is better to have a log, where he can quickly find the
problem, rather than having to investigate on his own.
best regards,
Ranier Vilela
Hi.
In the function *PQcancelCreate* there is a copy-and-past thinko.
The pointer that must be checked is cancelConn.
Trivial patch attached.
best regards,
Ranier Vilela
fix-copy-and-past-thinko-fe-cancel.patch
Description: Binary data
can rest assured.
> Since this code doesn't crash.
No, you can't be sure.
> I suspect this is
> one of such cases. Unless you are aware of a specific scenario that
> makes the code crash of course.
>
ScanPgRelation really can fail, better make sure.
best regards,
Ranier Vilela
.
Patches attached.
best regards,
Ranier Vilela
fix-connection-api-miuse-connect_utils.patch
Description: Binary data
fix-connection-api-miuse-ecpg.patch
Description: Binary data
fix-connection-api-miuse-pg_rewind.patch
Description: Binary data
fix-connection-api-miuse-psql.patch
Description
901 - 997 of 997 matches
Mail list logo
