, indexId, indexOK, snapshot,
nkeys, key);
htup = systable_getnext(scan);
if (HeapTupleIsValid(htup))
tid = &htup->t_self;
else
tid = NULL;
systable_endscan(scan);
return tid;
}
regards,
Ranier Vilela
m still investigating.
regards,
Ranier Vilela
Em qua., 6 de mai. de 2020 às 10:21, Ranier Vilela
escreveu:
> Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
> escreveu:
>
>> On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner wrote:
>> > I agree, it is better.
>>
>> Thanks, applied and back-patc
Em qua., 6 de mai. de 2020 às 10:25, Ranier Vilela
escreveu:
> Em qua., 6 de mai. de 2020 às 10:21, Ranier Vilela
> escreveu:
>
>> Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
>> escreveu:
>>
>>> On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagne
Em qua., 6 de mai. de 2020 às 14:14, Victor Wagner
escreveu:
> В Wed, 6 May 2020 10:21:41 -0300
> Ranier Vilela пишет:
>
> > Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
> > escreveu:
> >
> > > On Tue, May 05, 2020 at 10:16:23AM +0300, Victor Wagner
Em qua., 6 de mai. de 2020 às 15:19, Ranier Vilela
escreveu:
> Em qua., 6 de mai. de 2020 às 14:14, Victor Wagner
> escreveu:
>
>> В Wed, 6 May 2020 10:21:41 -0300
>> Ranier Vilela пишет:
>>
>> > Em qua., 6 de mai. de 2020 às 09:53, Michael Paquier
>&g
is. No problem for me, I already got around
the difficulty.
regards,
Ranier Vilela
Em qua., 6 de mai. de 2020 às 21:14, Michael Paquier
escreveu:
> On Wed, May 06, 2020 at 03:58:15PM -0300, Ranier Vilela wrote:
> > Hacking pgbison.pl, to print PATH, shows that the path inside pgbison.pl
> ,
> > returned to being the original, without the addition of
&g
Em qui., 7 de mai. de 2020 às 02:04, Victor Wagner
escreveu:
> В Thu, 7 May 2020 09:14:33 +0900
> Michael Paquier пишет:
>
> > On Wed, May 06, 2020 at 03:58:15PM -0300, Ranier Vilela wrote:
> > > Hacking pgbison.pl, to print PATH, shows that the path inside
> > &
gt;
> Which file? File name should be printed too like in the error check for
> cfopen_read a few lines above.
>
Can suggest improvements?
1. free (398 line) must be pg_free(buf)';
2. %m, is a format to parameter, right?
But what parameter? Both fatal call, do not pass this para
Em sex., 8 de mai. de 2020 às 19:02, Tomas Vondra <
tomas.von...@2ndquadrant.com> escreveu:
> On Thu, Apr 23, 2020 at 04:12:34PM -0400, James Coleman wrote:
> >On Thu, Apr 23, 2020 at 8:38 AM Ranier Vilela
> wrote:
> >>
> >> Hi,
> >>
> >> P
if (fullsortGroupInfo->groupCount == 0)
> + {
> + Assert(prefixsortGroupInfo->groupCount ==
> 0);
> continue;
> + }
>
I agree, asserts always help.
regards,
Ranier Vilela
fix_division_by_zero_explain_v2.patch
Description: Binary data
Em sáb., 9 de mai. de 2020 às 14:44, Tomas Vondra <
tomas.von...@2ndquadrant.com> escreveu:
> On Sat, May 09, 2020 at 06:48:59AM -0300, Ranier Vilela wrote:
> >Em sáb., 9 de mai. de 2020 às 01:45, Tom Lane
> escreveu:
> >
> >> James Coleman writes:
> &g
Em sáb., 9 de mai. de 2020 às 17:48, Tomas Vondra <
tomas.von...@2ndquadrant.com> escreveu:
> On Sat, May 09, 2020 at 02:51:50PM -0300, Ranier Vilela wrote:
> >Em sáb., 9 de mai. de 2020 às 14:44, Tomas Vondra <
> >tomas.von...@2ndquadrant.com> escreveu:
> >
&
> > Why is that necessary? A static variable is defined by C to start off
> > as zeroes.
>
> Because SLRUStats is not a static variable. No?
>
IMHO, BgWriterStats have the same problem, shouldn't the same be done?
/* Initialize BgWriterStats to zero */
MemSet(&B
are any more comments/objections.
> >
> > The "quiet period" is over as soon as the tags appear in git.
> >
>
> Pushed.
>
Thank you for the commit.
regards,
Ranier Vilela
t would be good to seize the
opportunity.
regards,
Ranier Vilela
001_fix_outside_scope_t_ctid.patch
Description: Binary data
Em qui., 14 de mai. de 2020 às 15:03, Mark Dilger <
mark.dil...@enterprisedb.com> escreveu:
>
>
> > On May 14, 2020, at 10:40 AM, Ranier Vilela wrote:
> >
> > Hi,
> > ItemPointerData, on the contrary, from what the name says,
> > it is not a point
Em qui., 14 de mai. de 2020 às 15:07, Tom Lane escreveu:
> Ranier Vilela writes:
> > The patch is primarily intended to correct the use of ItemPointerData.
>
> What do you think is being "corrected" here? It looks to me like
> just some random code rearrangements th
Em qui., 14 de mai. de 2020 às 19:23, Mark Dilger <
mark.dil...@enterprisedb.com> escreveu:
>
>
> > On May 14, 2020, at 11:34 AM, Ranier Vilela wrote:
> >
> > htup->t_ctid = target_tid;
> > htup->t_ctid = newtid;
> > Both target_tid and newt
Em qui., 14 de mai. de 2020 às 19:49, Mark Dilger <
mark.dil...@enterprisedb.com> escreveu:
>
>
> > On May 14, 2020, at 11:34 AM, Ranier Vilela wrote:
> >
> > Certainly.
> > In the same file you can find the appropriate use of the API.
> > ItemPo
g a consistent result of 3 secs, with a modified version
(exec_stmt_call) of your patch.
But my notebook is (Core 5, 8GB and SSD), could it be a difference in the
testing hardware?
regards,
Ranier Vilela
Em sáb., 16 de mai. de 2020 às 00:07, Pavel Stehule
escreveu:
>
>
> so 16. 5. 2020 v 0:34 odesílatel Ranier Vilela
> napsal:
>
>> Em dom., 10 de mai. de 2020 às 17:21, Pavel Stehule <
>> pavel.steh...@gmail.com> escreveu:
>>
>>> Hi
>>>
Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule
escreveu:
>
>
> so 16. 5. 2020 v 5:55 odesílatel Ranier Vilela
> napsal:
>
>> Em sáb., 16 de mai. de 2020 às 00:07, Pavel Stehule <
>> pavel.steh...@gmail.com> escreveu:
>>
>>>
>>>
>&
Em sáb., 16 de mai. de 2020 às 09:35, Pavel Stehule
escreveu:
>
>
> so 16. 5. 2020 v 13:40 odesílatel Ranier Vilela
> napsal:
>
>> Em sáb., 16 de mai. de 2020 às 01:10, Pavel Stehule <
>> pavel.steh...@gmail.com> escreveu:
>>
>>>
>&g
Em sáb., 16 de mai. de 2020 às 11:07, Pavel Stehule
escreveu:
>
>
> so 16. 5. 2020 v 15:24 odesílatel Ranier Vilela
> napsal:
>
>> Em sáb., 16 de mai. de 2020 às 09:35, Pavel Stehule <
>> pavel.steh...@gmail.com> escreveu:
>>
>>>
>>
t; actually improves performance ...
>
This is not related to your latest patch.
But I believe I can improve the performance.
So:
1. If killedsomething is false
2. Any killtuple is true and (not ItemIdIsDead(iid)) is false
3. Nothing to be done.
So why do all the work and then discard it.
We can eli
d ()
2.! AutoVacuumingActive ()
3. New exclusive configuration variable option to activate the lock?
Masahiko reported that it occurs only when (autovacuum_enabled = off);
regards,
Ranier Vilela
avoid_killing_btree_items_already_dead_v2.patch
Description: Binary data
sing.
>
Again, I see problems with the types declared in Postgres.
1. pq_sendint32 (StringInfo buf, uint32 i)
2. extern void pq_sendbytes (StringInfo buf, const char * data, int
datalen);
Wouldn't it be better to declare outputlen (0002) as uint32?
To avoid converting from (int) to (uint32), even if afterwards there is a
conversion from (uint32) to (int)?
regards,
Ranier Vilela
count
---
2
(1 row)
Time: 32645,448 ms (00:32,645)
How display " -> execution time 5.2s, average read size ="?
regards,
Ranier VIlela
Em qua., 20 de mai. de 2020 às 18:49, Thomas Munro
escreveu:
> On Wed, May 20, 2020 at 11:03 PM Ranier Vilela
> wrote:
> > Time: 47767,916 ms (00:47,768)
> > Time: 32645,448 ms (00:32,645)
>
> Just to make sure kernel caching isn't helping here, maybe try making
>
Em qua., 20 de mai. de 2020 às 20:48, Thomas Munro
escreveu:
> On Thu, May 21, 2020 at 11:15 AM Ranier Vilela
> wrote:
> > postgres=# set max_parallel_workers_per_gather = 0;
> > Time: 227238,445 ms (03:47,238)
> > postgres=# set max_parallel_workers_per_gather = 1;
>
Em qua., 20 de mai. de 2020 às 21:03, Thomas Munro
escreveu:
> On Thu, May 21, 2020 at 11:51 AM Ranier Vilela
> wrote:
> > Em qua., 20 de mai. de 2020 às 20:48, Thomas Munro <
> thomas.mu...@gmail.com> escreveu:
> >> On Thu, May 21, 2020 at 11:15 AM Ranier Vilela
knowing whether such regressions actually exist or if
it is a failure of how the tests were done.
But it would be nice to have arguments to counter, for the sake of
Postgres' promotion.
I'm using the development version (latest), and for now, it seems to be
faster than version 12.
regards,
Ran
Em dom., 24 de mai. de 2020 às 14:34, Peter Geoghegan escreveu:
> On Sun, May 24, 2020 at 2:52 AM Ranier Vilela wrote:
> > There was news in Phoronix about the Beta 1 Release of Postgres (1).
> > Unfortunately for Postgres advocacy it does not bring good news,
> > it is s
Em seg., 25 de mai. de 2020 às 03:57, Michael Paquier
escreveu:
> On Sun, May 24, 2020 at 02:50:08PM -0300, Ranier Vilela wrote:
> > Em dom., 24 de mai. de 2020 às 14:34, Peter Geoghegan
> escreveu:
> >> It looks like they're only running pgbench for 60 second runs
gres \ src \ tools \ msvc
/ Mkvcbuild.pm line 842.
Question:
Will Postgres continue to support 32-bit client?
regards,
Ranier Vilela
ortunately, i will have to live with 32 bits clients for a long time yet.
I still have customers using Windows XP yet ...
best regards,
Ranier Vilela
Em seg., 10 de fev. de 2020 às 10:53, Craig Ringer
escreveu:
> On Mon, 10 Feb 2020 at 20:14, Ranier Vilela wrote:
> >
> > "adminpack.obj : error LNK2019: sφmbolo externo indefinido
> _Int64GetDatum referenciado na funτπo _pg_file_write
> [C:\dll\postgres\adminp
Em ter., 11 de fev. de 2020 às 18:08, Andrew Dunstan <
andrew.duns...@2ndquadrant.com> escreveu:
>
> On 2/10/20 7:13 AM, Ranier Vilela wrote:
> >
> >
> > Unfortunately, i will have to live with 32 bits clients for a long
> > time yet.
> > I
makes more sense to do the basic checks, only to start communicating
with the server afterwards.
These changes are passing the regression tests and are in use in libpq.dll,
used in production by my customers.
regards,
Ranier Vilela
libpq.patch
Description: Binary data
Em qua., 12 de fev. de 2020 às 22:25, Tom Lane escreveu:
> Ranier Vilela writes:
> > Coverity detected a dead code in the src / interfaces / libpq / fe-auth.c
> > file, to correct it, a simplification was made and the oom_error goto was
> > removed, since it is clea
Em sex., 14 de fev. de 2020 às 03:13, Michael Paquier
escreveu:
> On Thu, Feb 13, 2020 at 02:22:36PM -0300, Ranier Vilela wrote:
> > I just kept it, even if I duplicated the error message, the style was
> kept
> > and in my opinion it is much more coherent and readable.
> &
Hi,
I'm sending this report from DrMemory, which shows some leaks from the
current postgres.
DrMemory is it is a reliable tool, but it is not perfect. (
https://drmemory.org/)
regards,
Ranier Vilela
Dr. Memory version 2.2.0 build 1 built on Jul 1 2019 00:42:20
Windows version: WinVer=10
e is a waste if possible, resetting
it.
By analogy, I have code with arrays where, I reuse them, with only one
line, instead of reconstructing them.
a->nelts = 0; / * reset array * /
If possible, doing the same for hashtables would be great.
regards,
Ranier Vilela
d be then.
+ if (numObjs <= 0)
+ return NULL;
+
regards,
Ranier Vilela
Hi,
read_binary_file seems a bit complicated when we want to read the rest of
the file (-1 for bytes_to_read).
This version, it seems, has no opposite effects, someone can confirm?
regards,
Ranier Vilela
v1-0001-simplified_read_binary_file.patch
Description: Binary data
Em sex., 11 de set. de 2020 às 14:01, Alvaro Herrera <
alvhe...@2ndquadrant.com> escreveu:
> On 2020-Sep-11, Ranier Vilela wrote:
>
> > Hi,
> >
> > read_binary_file seems a bit complicated when we want to read the rest of
> > the file (-1 for bytes_to_re
Em sex., 11 de set. de 2020 às 15:09, Andres Freund
escreveu:
> On 2020-09-11 14:10:31 -0300, Ranier Vilela wrote:
> > Em sex., 11 de set. de 2020 às 14:01, Alvaro Herrera <
> > alvhe...@2ndquadrant.com> escreveu:
> > > On 2020-Sep-11, Ranier Vilela wrote:
>
New version, with support to read Virtual File (pipe, FIFO and socket).
With assert, in case, erroneous, of trying to read a pipe, with offset.
regards,
Ranier Vilela
v2-0001-simplified_read_binary_file.patch
Description: Binary data
Em sex., 11 de set. de 2020 às 17:44, Tom Lane escreveu:
> Ranier Vilela writes:
> > New version, with support to read Virtual File (pipe, FIFO and socket).
> > With assert, in case, erroneous, of trying to read a pipe, with offset.
>
> Really, could you do a little more th
Em dom., 13 de set. de 2020 às 22:46, Michael Paquier
escreveu:
> On Sat, Sep 12, 2020 at 12:40:49PM +0200, Julien Rouhaud wrote:
> > agreed.
>
> Ok, done as ac673a1 then.
>
Thanks Michael.
regards,
Ranier Vilela
abort the loop?
regards,
Ranier Vilela
v1-0001-fix_overflow_wchar2char.patch
Description: Binary data
Em seg., 14 de set. de 2020 às 10:53, Daniel Gustafsson
escreveu:
> > On 14 Sep 2020, at 14:41, Ranier Vilela wrote:
>
> > 1. wchar2char has a mistake when checking the return of
> WideCharToMultiByte call.
> > result variable is unsigned, therefore, cannot be less than
endid
o?) [C:\dll\postgres\postgres.vcxproj]
1 Warning(s)
0 Error(s)
"result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift
intended?)"
regards,
Ranier Vilela
Em seg., 14 de set. de 2020 às 15:33, Tom Lane escreveu:
> Ranier Vilela writes:
> > msvc 2019 (64 bits), is worried about it:
> > C:\dll\postgres\src\backend\utils\adt\dbsize.c(630,20): warning C4334:
> > '<<': resultado de 32-bit shift convertido im
Em sex., 11 de set. de 2020 às 17:44, Tom Lane escreveu:
> Ranier Vilela writes:
> > New version, with support to read Virtual File (pipe, FIFO and socket).
> > With assert, in case, erroneous, of trying to read a pipe, with offset.
>
> I do agree that it might be worth ski
Em sex., 11 de set. de 2020 às 18:43, Ranier Vilela
escreveu:
> Em sex., 11 de set. de 2020 às 17:44, Tom Lane
> escreveu:
>
>> Ranier Vilela writes:
>> > New version, with support to read Virtual File (pipe, FIFO and socket).
>> > With assert, in case, er
e function.
setvbuf, does the same as read function low level, copies directly to the
final buffer.
regards,
Ranier Vilela
Hi,
In case gd->any_hashable is FALSE, grouping_is_hashable is never called.
In this case, the planner could use HASH for groupings, but will never know.
Apparently gd pointer, will never be NULL there, verified with Assert(gd !=
NULL).
regards,
Ranier Vilela
v1-0
\usr\src\tests\stat>crt_stat
File size : 6427512517
Drive : C:
Time modified : Tue Aug 18 16:51:47 2020
regards,
Ranier Vilela
// crt_stat.c
// This program uses the _stat function to
// report information about the file named crt_stat.c.
#include
#include
#include
#include
#
Em qui., 17 de set. de 2020 às 17:09, Tomas Vondra <
tomas.von...@2ndquadrant.com> escreveu:
> On Thu, Sep 17, 2020 at 02:12:12PM -0300, Ranier Vilela wrote:
> >Hi,
> >
> >In case gd->any_hashable is FALSE, grouping_is_hashable is never called.
> >In this
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:
> >
&
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:
> >
&
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:
> >
&
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:
> >
&
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
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
>> > >
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
ivation to "try" to submit a patch.
Good lucky Maksim Kita.
Thanks for the support John
regards,
Ranier Vilela
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
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
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.
>
bug reported in the btree deduplication.
regards,
Ranier Vilela
avoid_dereferencing_null_pointer.patch
Description: Binary data
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
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
>
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
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
>
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
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
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:
>>
Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut
escreveu:
> On 10.10.24 14:59, Ranier Vilela wrote:
> > Please look at the SCRAM secret, which breaks parse_scram_secret(),
> > perhaps because strsep() doesn't return NULL where strtok() did:
> >
>
Em ter., 15 de out. de 2024 às 09:00, Alexander Lakhin
escreveu:
> Hello Ranier and Peter,
>
> 15.10.2024 14:44, Ranier Vilela wrote:
>
>
>
> Em ter., 15 de out. de 2024 às 03:45, Peter Eisentraut <
> pe...@eisentraut.org> escreveu:
>
>>
>> Thanks
Em ter., 8 de out. de 2024 às 18:28, Nathan Bossart <
nathandboss...@gmail.com> escreveu:
> On Tue, Oct 08, 2024 at 04:09:00PM -0300, Ranier Vilela wrote:
> > The port function *bsearch_arg* mimics the C function
> > *bsearch*.
> >
> > The API signature is:
>
Thanks Michael.
Em seg., 7 de out. de 2024 às 22:53, Michael Paquier
escreveu:
> On Tue, Jul 02, 2024 at 02:39:20PM -0300, Ranier Vilela wrote:
> > This is a series of patches to change styles, in assorted sources.
> > IMO, this improves a tiny bit and is worth trying.
&
the entire string **stringp*, and **stringp* is made
NULL.
"
So, it is necessary to check the *stringp* against NULL too.
I tried the patch attached and your test case works.
CREATE ROLE r PASSWORD
postgres-#
'SCRAM-SHA-256$4096:hpFyHTUsSWcR7O9P$LgZFIt6Oqdo27ZFKbZ2nV+=vtnYM99
nmemb greater than INT_MAX is possible.
Internally the code uses the *int* type to iterate through the number of
members, which makes overflow possible.
Trivial fix attached.
best regards,
Ranier Vilela
avoid-possible-overflow-bsearch_arg.patch
Description: Binary data
Em qua., 16 de out. de 2024 às 04:45, Peter Eisentraut
escreveu:
> On 15.10.24 14:07, Ranier Vilela wrote:
> > I also wonder, if other places touched by 5d2e1cc11 need corrections
> > too.
> > I played with
> > PG_COLOR=always PG_COLORS="error=01;3
Em qui., 17 de out. de 2024 às 07:30, Alexander Lakhin
escreveu:
> Hello Ranier,
>
> 16.10.2024 14:14, Ranier Vilela wrote:
>
> Em qua., 16 de out. de 2024 às 04:45, Peter Eisentraut <
> pe...@eisentraut.org> escreveu:
>
>>
>> This wouldn't fix anythi
s null in colors.
> >
> > Yes, this is indeed incorrect. We need to keep a separate pointer to
> > the start of the string to free later. This matches the example on the
> > strsep man page (https://man.freebsd.org/cgi/man.cgi?strsep(3)). Patch
> > attached.
>
> I have committed both fixes mentioned in this thread in the last couple
> of days.
>
Thanks.
Thanks Alexander, for the hard work.
best regards,
Ranier Vilela
Em ter., 29 de out. de 2024 às 09:25, David Rowley
escreveu:
> On Wed, 30 Oct 2024 at 01:07, Ranier Vilela wrote:
> > With the function *DefineVirtualRelation* has a possible
> > useless call to *makeNode* function, which invokes palloc.
> >
> > So, reduce the scop
Hi.
With the function *DefineVirtualRelation* has a possible
useless call to *makeNode* function, which invokes palloc.
So, reduce the scope for the variable to inner else
where it is really necessary.
trivial patch attached.
best regards,
Ranier Vilela
0001-avoid-possible-useless-palloc
check zeros using BERTRAND 1 0.18s
+ const unsigned char *aligned_end;
+ /* Multiple bytes comparison(s) at once */
+ aligned_end = (const unsigned char *) ((uintptr_t) end &
(~(sizeof(size_t) - 1)));
+ for (; p < aligned_end; p += sizeof(size_t))
best regards,
Ranier Vilela
[1] https://godbolt.org/z/fvdzjbnc7
Em ter., 5 de nov. de 2024 às 00:23, David Rowley
escreveu:
> On Tue, 5 Nov 2024 at 06:39, Ranier Vilela wrote:
> > I think we can add a small optimization to this last patch [1].
> > The variable *aligned_end* is only needed in the second loop (for).
> > So, only befo
ed_end at these two different
> locations has this much effect once the compiler optimizes the
> surroundings, but well.
>
I think that's a plus point for the benefit of not touching the memory if
it's not explicitly necessary.
best regards,
Ranier Vilela
Em seg., 28 de out. de 2024 às 12:08, Tom Lane escreveu:
> Ranier Vilela writes:
> > It seems to me that [reversing the loop direction] is more optimized.
>
> That's far from clear: you're ignoring the possibility that memory
> access logic is better optimized for f
Em seg., 28 de out. de 2024 às 09:13, Heikki Linnakangas
escreveu:
> On 09/10/2024 19:16, Ranier Vilela wrote:
> > Em ter., 8 de out. de 2024 às 18:28, Nathan Bossart
> > mailto:nathandboss...@gmail.com>> escreveu:
> >
> > On Tue, Oct 08, 2024 at 04:0
rsi, [rsp + 8]
xor eax, eax
call__isoc99_scanf@PLT
lea rdi, [rip + .L.str.1]
xor esi, esi
xor eax, eax
callprintf@PLT
xor eax, eax
add rsp, 24
ret
best regards,
Ranier Vilela
Em ter., 12 de nov. de 2024 às 21:33, Michael Paquier
escreveu:
> On Tue, Nov 12, 2024 at 01:32:36PM -0300, Ranier Vilela wrote:
> > See v1_allzeros_small.c attached.
>
> In your pg_memory_is_all_zeros_v11:
> while (((uintptr_t) p & (sizeof(size_t) - 1)) != 0)
>
]: it looks like gcc is smart enough to create an optimized version
> for that size using constant propagation
> - if a[63]: Same as above
> - if a[256]: Same as above
> - if a[8192]: Same as above
>
> I did a quick check with clang and it looks like it is not as smart as gcc
> for the non inline case.
>
> Anyway it's not like we have the choice: we need (at least) one len check
> for
> safety reason (to not crash or read invalid data).
>
> So, I'd vote for pg_memory_is_all_zeros_v12() then, thoughts?
>
I think that's good enough.
best regards,
Ranier Vilela
801 - 900 of 997 matches
Mail list logo
