Re: [PATCH] Use optimized single-datum tuplesort in ExecSort

Em ter., 6 de jul. de 2021 às 08:25, Ranier Vilela escreveu: > Em ter., 6 de jul. de 2021 às 03:15, Ronan Dunklau > escreveu: > >> Hello, >> >> While testing the patch "Add proper planner support for ORDER BY / >> DISTINCT >> aggregates" [0] I

Re: [PATCH] Use optimized single-datum tuplesort in ExecSort

ttribute, it is "byval" (so as > not > to incur copies which would be hard to track in the execution tree) and > unbound (again, not having to deal with copying borrowed datum anywhere). > > The attached patch is originally by me, with some cleanup by Ranier > Vilela. >

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

Em seg., 5 de jul. de 2021 às 12:07, Ronan Dunklau escreveu: > Le lundi 5 juillet 2021, 16:51:59 CEST Ranier Vilela a écrit : > > >Please find attached a POC patch to do just that. > > > > > >The switch to the single-datum tuplesort is done when there is only one &

Re: Add proper planner support for ORDER BY / DISTINCT aggregates

ranch. 5. I think that you add a invariant inside the loop "if(node->is_single_val)"? Would not be better two fors? For you convenience, I attached a v2 version (with styles changes), please take a look and can you repeat yours tests? regards, Ranier Vilela v2-0001-Allow-Sort-n

Fix possible variable declaration uninitialized (src/backend/utils/adt/varlena.c)

Hi, This is not a live bug. I think this is worth fixing, just for the sake of style and code correctness. As a bonus, we have a reduced scope and standardized return. regards, Ranier Vilela fix_possible_decl_var_uninitialized_varlena.patch Description: Binary data

Re: Numeric multiplication overflow errors

Em seg., 5 de jul. de 2021 às 09:02, David Rowley escreveu: > On Mon, 5 Jul 2021 at 23:07, Ranier Vilela wrote: > > > > Em seg., 5 de jul. de 2021 às 06:44, Dean Rasheed < > dean.a.rash...@gmail.com> escreveu: > >> Note, however, that it won't make any dif

Re: Numeric multiplication overflow errors

Em seg., 5 de jul. de 2021 às 06:44, Dean Rasheed escreveu: > On Fri, 2 Jul 2021 at 19:48, Ranier Vilela wrote: > > > > If you allow me a small suggestion. > > Move the initializations of the variable tmp_var to after check if the > function can run. > > Saves

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

Em qui., 1 de jul. de 2021 às 17:20, Mahendra Singh Thalor < mahi6...@gmail.com> escreveu: > On Fri, 2 Jul 2021 at 01:13, Ranier Vilela wrote: > > > > Hi, > > > > The function FreePageManagerPutInternal can access an uninitialized > variable, > > if

Re: Numeric multiplication overflow errors

we disallow calling when not in aggregate context */ if (!AggCheckCallContext(fcinfo, NULL)) elog(ERROR, "aggregate function called in non-aggregate context"); + init_var(&tmp_var); + regards, Ranier Vilela

Re: Signed vs. Unsigned (some)

= InvalidBlockNumber)); } num_pages = 18446744073709551615 rel_pages = -1 (num_pages == InvalidBlockNumber) => 0 (rel_pages == InvalidBlockNumber) => 0 /* 17:68: warning: comparison between signed and unsigned integer expressions [-Wsign-compare] */ As Kyotaro said: "they might be different if we forget to widen the constant when widening the types" regards, Ranier Vilela

Re: Signed vs. Unsigned (some)

nly use in vac_update_relstats is to mark relpages as invalid (dirty = true). > I'd rather leave it "slightly wrong" for > now so it can be checked again. > Ideally InvalidBlockNumber should be 0. Maybe in the long run this will be fixed. regards, Ranier Vilela

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

he btree. */ FreePageBtreeSearch(fpm, first_page, &result); Assert(!result.found); if (result.index > 0) /* result.index is garbage or invalid here) */ regards, Ranier Vilela fix_unitialized_var_index_freepage.patch Description: Binary data

Re: Pipeline mode and PQpipelineSync()

On 2021-Jun-29, Alvaro Herrera wrote: >Ah, yes it does. I can reproduce this now. I thought PQconsumeInput >was sufficient, but it's not: you have to have the PQgetResult in there >too. Looking ... I think that has an oversight with a719232 return false shouldn't be return 0

Avoid choose invalid number of partitions (src/backend/executor/nodeAgg.c)

partition_info hash_part resultcache reloptions explain compression indexing partition_aggregate partition_join tuplesort partition_prune partition_join ... ok 3013 ms partition_prune ... ok 3959 ms regards, Ranier Vilela avoid_choose_invalid_number_of_partitions.patch Description: Binary data

Re: Fix uninitialized copy_data var (src/backend/commands/subscriptioncmds.c)

path using parse_subscription_options() with this > pattern. Applied on HEAD. > Hi Michael, Thank you for this comitt. regards, Ranier Vilela

Re: Fix uninitialized copy_data var (src/backend/commands/subscriptioncmds.c)

Em dom., 27 de jun. de 2021 às 21:18, Peter Smith escreveu: > On Fri, Jun 25, 2021 at 11:55 PM Ranier Vilela > wrote: > > > > > > > https://github.com/postgres/postgres/commit/3af10943ce21450e299b3915b9cad47cd90369e9 > > fixes some issues with subscriptio

Re: Deparsing rewritten query

;) could not be replaced by sql[0] == '\0'? 2. the error message would not be: "empty statement not allowed"? 3. initStringInfo(&buf) inside a loop, wouldn't it be exaggerated? each time call palloc0. regards, Ranier Vilela v1-0002-Add-pg_get_query_def-to-deparse-and-print-a-rewri.patch Description: Binary data

Re: Fix uninitialized copy_data var (src/backend/commands/subscriptioncmds.c)

Em qua., 23 de jun. de 2021 às 14:38, Ranier Vilela escreveu: > Hi, > > Not per Coverity! > > About comments: > 1. For drop, no "copy data" > 2. Only refresh the added/*dropped* list of publications. (my emphasis) > > The documentation says: >

Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

rer and more elusive comments. If you both agree that the current code is correct, please correct the comments. The current code is much simpler and readable. regards, Ranier Vilela

Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

gt; PopActiveSnapshot(); > -1. That way it's readability is much worse, more complicated and IMHO it generates worse asm. regards, Ranier Vilela

Fix uninitialized copy_data var (src/backend/commands/subscriptioncmds.c)

ack of tests with DROP PUBLICATION WITH (refresh = true). regards, Ranier Vilela fix_use_unitialized_copy_data_subscriptioncmds.patch Description: Binary data

Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

Em qua., 23 de jun. de 2021 às 03:04, Greg Nancarrow escreveu: > On Tue, Jun 22, 2021 at 10:56 PM Ranier Vilela > wrote: > > > > On Mon, Jun 21, 2021 at 04:19:27PM -0700, Jim Nasby wrote: > > > The following generates an assertion failure. Quick testing with start

Re: Assertion failure in HEAD and 13 after calling COMMIT in a stored proc

RE postgres=# CALL build_schema(1,11); CALL postgres=# CALL build_schema(1,11); CALL postgres=# CALL build_schema(1,11); CALL The comments in the function are clear: If expression is mutable OR is a non-read-only function, so need a snapshot. Can you test please? regards, Ranier Vilela fix_segfault_pl_exec.patch Description: Binary data

Out-of-bounds (src/backend/utils/misc/queryjumble.c)

Hi, Per Coverity. 3 out-of-bounds at function AppendJumble. They have the face, smell and color of typo. And we usually increment the character count after a memcpy. Coverity no longer complained after the patch. Thoughts? regards, Ranier Vilela fix_out_of_bounds_queryjumble.patch

Re: Avoid call MaintainOldSnapshotTimeMapping, if old_snapshot_threshold is disabled.

Em qui., 17 de jun. de 2021 às 22:08, Andres Freund escreveu: > Hi, > > On 2021-06-17 21:27:15 -0300, Ranier Vilela wrote: > > While another long thread discusses the situation of > old_snapshot_threshold, > > I believe we can improve procarr

Avoid call MaintainOldSnapshotTimeMapping, if old_snapshot_threshold is disabled.

s function when old snapshot checking is disabled." Well, assert should never be used to validate a condition that certainly occurs at runtime. Since old_snapshot_threshold is -1, it is disabled, so MaintainOldSnapshotTimeMapping doesn't need to be run, right? re

Re: Signed vs. Unsigned (some)

t small defects piling up lead to big problems. I believe Postgres will benefit enormously from enabling all the warnings at compile time, at least the new little bugs will have some chance of not getting into the codebase. regards, Ranier Vilela

Re: [PATCH] Fix buffer not null terminated on (ecpg lib)

Em ter., 15 de jun. de 2021 às 15:48, Andres Freund escreveu: > Hi, > > On 2021-06-15 13:53:08 -0400, Tom Lane wrote: > > Andres Freund writes: > > > On 2021-06-15 07:40:46 -0300, Ranier Vilela wrote: > > >> memcpy would not suffer from it? > > >

Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

Em seg., 14 de jun. de 2021 às 21:01, Ranier Vilela escreveu: > I took it a step further. > > Transactions > > HEAD patched > 1000220710586781 > 1014616710388685 > 100489191059 >

Re: [PATCH] Fix buffer not null terminated on (ecpg lib)

Em sex., 11 de jun. de 2021 às 19:49, Andres Freund escreveu: > Hi, > > On 2020-04-23 14:36:15 +0900, Kyotaro Horiguchi wrote: > > At Thu, 23 Apr 2020 01:21:21 -0300, Ranier Vilela > wrote in > > > Em qua., 22 de abr. de 2020 às 23:27, Kyotaro Horiguchi < > >

Re: Signed vs. Unsigned (some)

Hi Kyotaro, Thanks for taking a look. Em ter., 15 de jun. de 2021 às 05:17, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Fri, 11 Jun 2021 23:05:29 -0300, Ranier Vilela > wrote in > > Hi, > > > > Removing legitimate warnings can it be worth it? &

Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

. regards, Ranier Vilela improve_procarray.patch Description: Binary data

Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

Em dom., 13 de jun. de 2021 às 09:43, Ranier Vilela escreveu: > Hi Andres, thanks for taking a look. > > Em sáb., 12 de jun. de 2021 às 16:27, Andres Freund > escreveu: > >> Hi, >> >> On 2021-06-12 10:55:22 -0300, Ranier Vilela wrote: >> > With the re

Re: Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

Hi Andres, thanks for taking a look. Em sáb., 12 de jun. de 2021 às 16:27, Andres Freund escreveu: > Hi, > > On 2021-06-12 10:55:22 -0300, Ranier Vilela wrote: > > With the recent changes at procarray.c, I take a look in. > > msvc compiler, has some warnings about signed

Signed vs Unsigned (take 2) (src/backend/storage/ipc/procarray.c)

eyond numProcs? - for (size_t pgxactoff = 0; pgxactoff < numProcs; pgxactoff++) + for (int pgxactoff = 0; pgxactoff < numProcs; pgxactoff++) I think no functional behavior changed. Patch attached. best regards, Ranier Vilela reduce_unmatechs_types_procarray.patch Description: Binary data

Signed vs. Unsigned (some)

XLogSegNo (uint64) initialization are zero, but in pg_rewind was used -1? I did not find it InvalidXLogSegNo! Not tested. Trivial patch attached. best regards, Ranier Vilela fix_signed_vs_unsigned.patch Description: Binary data

Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

Em sáb., 5 de jun. de 2021 às 11:16, Ranier Vilela escreveu: > > Alvaro Herrera writes: > > > > Now, while this patch does seem to work correctly, it raises a number > of > > > weird cpluspluscheck warnings, which I think are attributable to the > > > ne

Re: Move pg_attribute.attcompression to earlier in struct for reduced size?

in this >patch requires a cast there. Hi Alvaro. Please, would you mind testing with these changes. I'm curious to see if anything improves or not. 1. Add a const to the attr parameter. 2. Remove the cmid variable (and store it). 3. Add tail cut. regards, Ranier Vilela v2-0002-Re

Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

ole situation and proposing this workaround. I've been studying commits, and on several occasions problems have been fixed like this. But important is the documentation of the problem. best regards, Ranier Vilela

Re: Parallel scan with SubTransGetTopmostTransaction assert coredump

creased the value of PGPROC_MAX_CACHED_SUBXIDS. Once it becomes >more than 120 there are no messages and no failed assertions are >provided any more. Please, avoid using decimal based values. 128 is multiple of 64. See : https://github.com/trevstanhope/scratch/blob/master/C/docs/O%27Reilly%20-%20Practical%20C%20Programming%203rd%20Edition.pdf 15.6.1 The Power of Powers of 2 regards, Ranier Vilela

Re: Possible pointer var TupleDesc rettupdesc used not initialized (src/backend/optimizer/util/clauses.c)

Em ter., 25 de mai. de 2021 às 14:35, Tom Lane escreveu: > Ranier Vilela writes: > > Following the guidelines, I provided a patch. > > Oh, I already pushed a fix, thanks. > No problem! Thank you. regards, Ranier Vilela

Re: Possible pointer var TupleDesc rettupdesc used not initialized (src/backend/optimizer/util/clauses.c)

Em ter., 25 de mai. de 2021 às 13:09, Tom Lane escreveu: > Ranier Vilela writes: > > Possible pointer TupleDesc rettupdesc used not initialized? > > if (!isNull) at line 4346 taking a true branch, the function > > check_sql_fn_retval at line 4448 can use rettupdesc uninitia

Re: Possible pointer var TupleDesc rettupdesc used not initialized (src/backend/optimizer/util/clauses.c)

Em seg., 24 de mai. de 2021 às 23:35, Zhihong Yu escreveu: > > > On Mon, May 24, 2021 at 7:21 PM Ranier Vilela wrote: > >> Em seg., 24 de mai. de 2021 às 22:42, Mark Dilger < >> mark.dil...@enterprisedb.com> escreveu: >> >>> >>> >&

Re: Possible pointer var TupleDesc rettupdesc used not initialized (src/backend/optimizer/util/clauses.c)

Em seg., 24 de mai. de 2021 às 22:42, Mark Dilger < mark.dil...@enterprisedb.com> escreveu: > > > > On May 24, 2021, at 5:37 PM, Ranier Vilela wrote: > > > > Hi, > > > > Possible pointer TupleDesc rettupdesc used not initialized? > > > &g

Possible pointer var TupleDesc rettupdesc used not initialized (src/backend/optimizer/util/clauses.c)

Hi, Possible pointer TupleDesc rettupdesc used not initialized? if (!isNull) at line 4346 taking a true branch, the function check_sql_fn_retval at line 4448 can use rettupdesc uninitialized. regards, Ranier Vilela

Re: Possible memory corruption (src/timezone/zic.c b/src/timezone/zic.c)

Em dom., 16 de mai. de 2021 às 22:37, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Sat, 15 May 2021 11:35:13 -0300, Ranier Vilela > wrote in > > Em sex., 14 de mai. de 2021 às 19:52, Tom Lane > escreveu: > > > > > I wrote: > > > &

Re: Possible memory corruption (src/timezone/zic.c b/src/timezone/zic.c)

f say 4 * MAX_PATH bytes for the > output, and then transfer just the appropriate amount of data to the > caller's buffer. > Following your directions, maybe something like this will solve? regards, Ranier Vilela v2_fix_possible_memory_corruption_zic.patch Description: Binary data

Possible memory corruption (src/timezone/zic.c b/src/timezone/zic.c)

else return false; #endif regards, Ranier Vilela fix_possible_memory_corruption_zic.patch Description: Binary data

Explicit NULL dereference (src/backend/commands/tablecmds.c)

printf("found"); } else { printf("not found"); } } not found! regards, Ranier Vilela fix_null_dereference_tablecmds.patch Description: Binary data

Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

Em seg., 12 de abr. de 2021 às 03:04, Tom Lane escreveu: > Michael Paquier writes: > > On Sun, Apr 11, 2021 at 07:42:20PM -0300, Ranier Vilela wrote: > >> Em dom., 11 de abr. de 2021 às 16:25, Justin Pryzby < > pry...@telsasoft.com> > >>> I think it&#x

Re: Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

Hi Justin, sorry for the delay. Nothing against it, but I looked for similar codes and this is the usual way to initialize HeapTupleData. Perhaps InvalidOid makes a difference. regards, Ranier Vilela Em dom., 11 de abr. de 2021 às 16:25, Justin Pryzby escreveu: > On Sun, Apr 11, 2021 at

Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)

Hi, Per Coverity. It seems to me that some recent commit has failed to properly initialize a structure, in extended_stats.c, when is passed to heap_copytuple. regards, Ranier Vilela fix_uninitialized_var_extend_stats.patch Description: Binary data

re: crash during cascaded foreign key update

kmode=0x7ffe6f236dec) at heapam.c:3560 I have this report from one static analysis tool: heapam.c (9379): Dereferencing of a potential null pointer 'oldtup.t_data' regards, Ranier Vilela

Re: Permission failures with WAL files in 13~ on Windows

chine, Postgres can rename statistics files. regards, Ranier Vilela 1. https://www.postgresql.org/message-id/20200616041018.GR20404%40telsasoft.com fix_windows_rename.patch Description: Binary data

Re: Possible dereference after null check (src/backend/executor/ExecUtils.c)

Em sex., 12 de fev. de 2021 às 13:11, Ranier Vilela escreveu: > Em sex., 12 de fev. de 2021 às 03:28, Kyotaro Horiguchi < > horikyota@gmail.com> escreveu: > >> At Wed, 10 Feb 2021 19:54:46 -0300, Ranier Vilela >> wrote in >> > Hi, >> &g

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Em dom., 14 de fev. de 2021 às 22:28, Michael Paquier escreveu: > On Sun, Feb 14, 2021 at 11:39:47AM -0300, Ranier Vilela wrote: > > What do you think? > > That's not a good idea for two reasons: > 1) There is CRC32 to worry about, which relies on a different logic. >

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Em dom., 14 de fev. de 2021 às 08:22, Michael Paquier escreveu: > On Sat, Feb 13, 2021 at 09:33:48PM -0300, Ranier Vilela wrote: > > Em sáb., 13 de fev. de 2021 às 20:32, Michael Paquier < > mich...@paquier.xyz> > > escreveu: > > > >> You are missing the p

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Em sáb., 13 de fev. de 2021 às 20:32, Michael Paquier escreveu: > On Sat, Feb 13, 2021 at 05:37:32PM -0300, Ranier Vilela wrote: > > IMO there is no necessity in back-patching. > > You are missing the point here. What you are proposing here would not > be backpatched. However

Re: Possible dereference null return (src/backend/replication/logical/reorderbuffer.c)

."))); > > Did you mean this errdetail: > > Top transaction is not running. > Done. Thanks Zhihong. v3 based on your patch, attached. regards, Ranier Vilela reorderbuffer_v3.patch Description: Binary data

Re: Possible dereference null return (src/backend/replication/logical/reorderbuffer.c)

Em sáb., 13 de fev. de 2021 às 17:35, Ranier Vilela escreveu: > > Em sáb., 13 de fev. de 2021 às 01:07, Zhihong Yu > escreveu: > >> Hi, >> How about the following patch ? >> >> ReorderBufferSetBaseSnapshot() can return a bool to indicate whether the >&

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

;manifest_ctx, checksumbuf, > + PG_SHA256_DIGEST_LENGTH) < 0) > Here this could just use sizeof(checksumbuf)? This pattern could be > used elsewhere as well, like in md5_common.c. > Done. Attached a v4 of patch. regards, Ranier Vilela pg_cryptohash_v4.patch Description: Binary data

Re: Possible dereference null return (src/backend/replication/logical/reorderbuffer.c)

he caller can act accordingly. 2. SnapBuildCommitTxn can't ignore a result from ReorderBufferSetBaseSnapshot, even if it never fails. regards, Ranier Vilela reorderbuffer.patch Description: Binary data

Re: Possible dereference after null check (src/backend/executor/ExecUtils.c)

Em sex., 12 de fev. de 2021 às 03:28, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Wed, 10 Feb 2021 19:54:46 -0300, Ranier Vilela > wrote in > > Hi, > > > > Per Coverity. > > > > The functions ExecGetInsertedCols and ExecGetUpdatedCols a

Re: Possible dereference null return (src/backend/replication/logical/reorderbuffer.c)

Em sex., 12 de fev. de 2021 às 03:56, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Wed, 10 Feb 2021 20:12:38 -0300, Ranier Vilela > wrote in > > Hi, > > > > Per Coverity. > > > > If xid is a subtransaction, the setup of base snapshot on

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Em qui., 11 de fev. de 2021 às 09:47, Michael Paquier escreveu: > On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote: > > It is necessary to correct the interfaces. To caller, inform the size of > > the buffer it created. > > Now, the patch you sent has no need t

Re: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)

Em qui., 11 de fev. de 2021 às 14:51, Tom Lane escreveu: > Ranier Vilela writes: > > Em qui., 11 de fev. de 2021 às 01:46, Tom Lane > escreveu: > >> At the same time, I think this code could be improved; but the way > >> to do that is to use strtoint(), rat

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Em qui., 11 de fev. de 2021 às 09:47, Michael Paquier escreveu: > On Wed, Feb 10, 2021 at 09:14:46AM -0300, Ranier Vilela wrote: > > It is necessary to correct the interfaces. To caller, inform the size of > > the buffer it created. > > Well, Coverity likes nannyism, so ea

Re: Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)

Em qui., 11 de fev. de 2021 às 01:46, Tom Lane escreveu: > Ranier Vilela writes: > > *long* 4 *long int*, *signed long int* -2.147.483.648 a 2.147.483.647 > > Therefore long never be > INT_MAX at Windows 64 bits. > > Thus lindex is always false in this expression: &g

Operands don't affect result (CONSTANT_EXPRESSION_RESULT) (src/backend/utils/adt/jsonfuncs.c)

0((path_len - level) * sizeof(enum jbvType)); - long lindex; + int64 lindex; JsonbValue newkey; /* regards, Ranier Vilela jsonfuncs.patch Description: Binary data

Possible dereference null return (src/backend/replication/logical/reorderbuffer.c)

base_snapshot == NULL); txn->base_snapshot = snap; regards, Ranier Vilela reorderbuffer.patch Description: Binary data

Possible dereference after null check (src/backend/executor/ExecUtils.c)

Hi, Per Coverity. The functions ExecGetInsertedCols and ExecGetUpdatedCols at ExecUtils.c only are safe to call if the variable "ri_RangeTableIndex" is != 0. Otherwise a possible Dereference after null check (FORWARD_NULL) can be raised. Exemple: void 1718ExecPartitionCheckEmitError(ResultRel

Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)

Em qua., 10 de fev. de 2021 às 01:44, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > At Tue, 9 Feb 2021 22:01:45 -0300, Ranier Vilela > wrote in > > Hi Hackers, > > > > Per Coverity. > > > > Coverity complaints about pg_cryptohash_final funct

pg_cryptohash_final possible out-of-bounds access (per Coverity)

regards, Ranier Vilela pg_cryptohash.patch Description: Binary data

Re: Windows regress fails (latest HEAD)

Em ter., 10 de nov. de 2020 às 14:16, Russell Foster < russell.foster.cod...@gmail.com> escreveu: > On Tue, Nov 10, 2020 at 12:03 PM Ranier Vilela > wrote: > > > > Em sex., 26 de jun. de 2020 às 08:21, Ranier Vilela > escreveu: > >> > >> Em qui

Re: pgbench stopped supporting large number of client connections on Windows

Em sáb., 7 de nov. de 2020 às 14:55, Marina Polyakova < m.polyak...@postgrespro.ru> escreveu: > On 2020-11-06 23:54, Ranier Vilela wrote: > > Hi Marina, > > Hello! > > 1) If you mean the function pgwin32_select in the file > src/backend/port/win32/socket.c, IIUC

re: pgbench stopped supporting large number of client connections on Windows

t;too many client connections for select()"); >exit(1); >} It seems to me that the limit is hardcode in, src/backend/port/win32/socket.c FD_SETSIZE * 2 that would be 2048? regards, Ranier Vilela

Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)

d even if we > are not waiting on it. > > If we call WaitLatch(OrSocket) that waits on the latch, it immediately > returns because the latch is set. If we called ResetLatch before the > next call to WaitLatch(), it correctly waits on a trigger to be > pulled. > +1 The patch for me is syntactically equal to the code changed and avoids the dereference. regards, Ranier Vilela

Re: Dereference before NULL check (src/backend/storage/ipc/latch.c)

> On Mon, Nov 2, 2020 at 1:49 PM Kyotaro Horiguchi > > > wrote: > > > > At Sat, 31 Oct 2020 11:40:53 -0300, Ranier Vilela < > ranier...@gmail.com> wrote in > > > > > Per Coverity. > > > > > > > > > > If test set->latch aga

Re: Explicit NULL dereference (src/backend/utils/adt/ruleutils.c)

taches does..). > I think that Assert is not the right solution here. For a function that returns NULL twice (SPI_getvalue), it is worth testing the result against NULL. In the future, any modification may cause further dereference. In addition, the static analysis tools would continue to note this snippet either as a bug or as a suspect. Checking "actions" pointer against NULL, and acting appropriately would do. regards, Ranier Vilela

Explicit NULL dereference (src/backend/utils/adt/ruleutils.c)

ot; cannot be either. Solution proposed merely as a learning experience. regards, Ranier Vilela fix_explicit_null_dereference_ruleutils.patch Description: Binary data

Dereference before NULL check (src/backend/storage/ipc/latch.c)

Hi, Per Coverity. If test set->latch against NULL, is why it can be NULL. ResetEvent can dereference NULL. regards, Ranier Vilela fix_dereference_before_null_check_latch.patch Description: Binary data

Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

Em dom., 11 de out. de 2020 às 14:53, David G. Johnston < david.g.johns...@gmail.com> escreveu: > On Sun, Oct 11, 2020 at 3:31 AM Ranier Vilela wrote: > >> Em sáb., 10 de out. de 2020 às 00:11, David G. Johnston < >> david.g.johns...@gmail.com> escreveu: >>

Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

Em sáb., 10 de out. de 2020 às 00:11, David G. Johnston < david.g.johns...@gmail.com> escreveu: > On Fri, Oct 9, 2020 at 6:41 PM Ranier Vilela wrote: > >> The problem is not only in nodeIncrementalSort.c, but in several others >> too, where people are using TupIsNull

Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

> The problem is not only in nodeIncrementalSort.c, but in several others too, where people are using TupIsNull with ExecCopySlot. I would call this a design flaw. If (TupIsNull) ExecCopySlot The callers, think they are using TupIsNotNullAndEmpty. If (TupIsNotNullAndEmpty) ExecCopySlot regards, Ranier Vilela

Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

Em sex., 9 de out. de 2020 às 18:02, Stephen Frost escreveu: > Greetings, > > * Ranier Vilela (ranier...@gmail.com) wrote: > > Em sex., 9 de out. de 2020 às 14:05, Tomas Vondra < > > tomas.von...@2ndquadrant.com> escreveu: > > > > > On Fri, Oct 09, 202

Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

Em sex., 9 de out. de 2020 às 17:58, Peter Geoghegan escreveu: > On Fri, Oct 9, 2020 at 1:28 PM Ranier Vilela wrote: > > Sorry, can't find the thread. > > The author of deduplication claimed that he thinks the problem may be in > IncrementalSort, > > he did not

Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

Em sex., 9 de out. de 2020 às 17:47, Tom Lane escreveu: > Ranier Vilela writes: > > The trap is not on the second part of expression. Is in the first. > > If the pointer is NULL, ExecCopySlot will be called. > > Your initial comment indicated that you were worried about >

Re: Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

Em sex., 9 de out. de 2020 às 14:05, Tomas Vondra < tomas.von...@2ndquadrant.com> escreveu: > On Fri, Oct 09, 2020 at 12:24:16PM -0300, Ranier Vilela wrote: > >I think that TupIsNull macro is no longer appropriate, to protect > >ExecCopySlot. > > > >See at tupt

Possible NULL dereferencing null pointer (src/backend/executor/nodeIncrementalSort.c)

bug reported in the btree deduplication. regards, Ranier Vilela avoid_dereferencing_null_pointer.patch Description: Binary data

Re: Uninitialized var utilized (src/backend/tsearch/spell.c)

Em sex., 9 de out. de 2020 às 11:37, Tom Lane escreveu: > Ranier Vilela writes: > > Em sex., 9 de out. de 2020 às 11:08, Daniel Gustafsson > > escreveu: > >> To help reviewers, your report should contain an explanation of when > that > >> can happen. >

Re: Uninitialized var utilized (src/backend/tsearch/spell.c)

Em sex., 9 de out. de 2020 às 11:08, Daniel Gustafsson escreveu: > > On 9 Oct 2020, at 14:36, Ranier Vilela wrote: > > > At function NIImportAffixes (src/backend/tsearch/spell.c). > > > > If option "flag" is not handled, variable char flag[BUFSIZE] wil

Uninitialized var utilized (src/backend/tsearch/spell.c)

At function NIImportAffixes (src/backend/tsearch/spell.c). If option "flag" is not handled, variable char flag[BUFSIZE] will remain uninitialized. regards, Ranier Vilela fix_uninitialized_var_flag_spell.patch Description: Binary data

Re: [PATCH] ecpg: fix progname memory leak

ivation to "try" to submit a patch. Good lucky Maksim Kita. Thanks for the support John regards, Ranier Vilela

Avoid suspects casts VARHDRSZ (c.h)

g this and avoiding these alerts? Passed 100% with vcregress check and in use in local tests. regards, Ranier Vilela avoid_suspects_cast_VARHDRSZ.patch Description: Binary data

Re: gs_group_1 crashing on 13beta2/s390x

Em sex., 25 de set. de 2020 às 14:36, Ranier Vilela escreveu: > Em sex., 25 de set. de 2020 às 11:30, Christoph Berg > escreveu: > >> Re: Tom Lane >> > > Tom> It's hardly surprising that datumCopy would segfault when given >> a >> > >

Re: gs_group_1 crashing on 13beta2/s390x

tVal = pergroupstate->transValue; > *resultIsNull = pergroupstate->transValueIsNull; > } > > (gdb) p *pergroupstate > $12 = {transValue = 0, transValueIsNull = false, noTransValue = false} > Here transValueIsNull shouldn't be "true"? thus, DatumCopy would be protected, for this test: "!*resultIsNull" regards, Ranier Vilela

Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)

Em seg., 21 de set. de 2020 às 14:24, Tomas Vondra < tomas.von...@2ndquadrant.com> escreveu: > On Sun, Sep 20, 2020 at 01:50:34PM -0300, Ranier Vilela wrote: > >Em seg., 21 de set. de 2020 às 13:37, Tomas Vondra < > >tomas.von...@2ndquadrant.com> escreveu: > > &

Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)

Em seg., 21 de set. de 2020 às 13:37, Tomas Vondra < tomas.von...@2ndquadrant.com> escreveu: > On Mon, Sep 21, 2020 at 08:32:35AM -0300, Ranier Vilela wrote: > >Em dom., 20 de set. de 2020 às 21:10, Tomas Vondra < > >tomas.von...@2ndquadrant.com> escreveu: > > &

Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)

Em dom., 20 de set. de 2020 às 21:10, Tomas Vondra < tomas.von...@2ndquadrant.com> escreveu: > On Sun, Sep 20, 2020 at 08:09:56PM -0300, Ranier Vilela wrote: > >Em sex., 18 de set. de 2020 às 10:37, Tomas Vondra < > >tomas.von...@2ndquadrant.com> escreveu: > > &

Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)

Em sex., 18 de set. de 2020 às 10:37, Tomas Vondra < tomas.von...@2ndquadrant.com> escreveu: > On Thu, Sep 17, 2020 at 06:31:12PM -0300, Ranier Vilela wrote: > >Em qui., 17 de set. de 2020 às 17:09, Tomas Vondra < > >tomas.von...@2ndquadrant.com> escreveu: > > &

<    1   2   3   4   5   6   7   8   9   >