PostgresSQL 13.0 Beta 1 on Phoronix

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

Re: Parallel Seq Scan vs kernel read ahead

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

Re: Parallel Seq Scan vs kernel read ahead

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; >

Re: Parallel Seq Scan vs kernel read ahead

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 >

Re: Parallel Seq Scan vs kernel read ahead

count --- 2 (1 row) Time: 32645,448 ms (00:32,645) How display " -> execution time 5.2s, average read size ="? regards, Ranier VIlela

Re: Why is pq_begintypsend so slow?

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

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

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

Re: Multiple FPI_FOR_HINT for the same block during killing btree index items

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

Re: calling procedures is slow and consumes extra much memory against calling function

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: >> >>> >>

Re: calling procedures is slow and consumes extra much memory against calling function

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

Re: calling procedures is slow and consumes extra much memory against calling function

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: >> >>> >>> >&

Re: calling procedures is slow and consumes extra much memory against calling function

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 >>>

Re: calling procedures is slow and consumes extra much memory against calling function

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

Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)

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

Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)

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

Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)

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

Re: [PATCH] Fix ouside scope t_ctid (ItemPointerData)

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

[PATCH] Fix ouside scope t_ctid (ItemPointerData)

t would be good to seize the opportunity. regards, Ranier Vilela 001_fix_outside_scope_t_ctid.patch Description: Binary data

Re: PG compilation error with Visual Studio 2015/2017/2019

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

Re: SLRU statistics

> > 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

Re: [PATCH] Fix division by zero (explain.c)

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: > > &

Re: [PATCH] Fix division by zero (explain.c)

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

Re: [PATCH] Fix division by zero (explain.c)

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

Re: [PATCH] Fix division by zero (explain.c)

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

Re: pg_restore error message

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

Re: Postgres Windows build system doesn't work with python installed in Program Files

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 > > &

Re: Postgres Windows build system doesn't work with python installed in Program Files

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

Re: Postgres Windows build system doesn't work with python installed in Program Files

is. No problem for me, I already got around the difficulty. regards, Ranier Vilela

Re: Postgres Windows build system doesn't work with python installed in Program Files

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

Re: Postgres Windows build system doesn't work with python installed in Program Files

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

Re: Postgres Windows build system doesn't work with python installed in Program Files

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

Re: Postgres Windows build system doesn't work with python installed in Program Files

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

Re: Postgres Windows build system doesn't work with python installed in Program Files

m still investigating. regards, Ranier Vilela

Re: Unify drop-by-OID functions

, 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

Re: Unify drop-by-OID functions

Em ter., 5 de mai. de 2020 às 18:11, Alvaro Herrera < alvhe...@2ndquadrant.com> escreveu: > On 2020-May-05, Ranier Vilela wrote: > > > And in that specific case, leaving resources blocked, which perhaps, in > my > > humble opinion, could be released quickly. > &g

Re: Unify drop-by-OID functions

Em ter., 5 de mai. de 2020 às 14:57, Robert Haas escreveu: > On Tue, May 5, 2020 at 1:43 PM Ranier Vilela wrote: > > I see, the famous "cliché". > > By using the word cliché, and by putting it in quotes, you seem to > suggest that you consider my argument dubious. Ho

Re: Unify drop-by-OID functions

Em ter., 5 de mai. de 2020 às 14:29, Robert Haas escreveu: > On Tue, May 5, 2020 at 1:22 PM Ranier Vilela wrote: > > Ok, so the question. If (3) is not safe, obvious we shouldn't use, and > must call table_close, after systable_endscan. > > Now (1) and (2), I would have

Re: Unify drop-by-OID functions

Em ter., 5 de mai. de 2020 às 13:06, Robert Haas escreveu: > On Fri, May 1, 2020 at 5:32 PM Ranier Vilela wrote: > > I can suggest improvements? > > > > 1. In case Object is cached, delay open_table until the last moment, for > the row to be blocked as little as possibl

Re: [REPORT] Static analys warnings

, // INT bool split_only_page); static Buffer _bt_split(Relation rel, BTScanInsert itup_key, Buffer buf, Buffer cbuf, OffsetNumber newitemoff, Size newitemsz, IndexTuple newitem, IndexTuple orignewitem, IndexTuple nposting, uint16 postingoff); // UINT16 regards, Ranier Vilela

Re: Postgres Windows build system doesn't work with python installed in Program Files

Em seg., 4 de mai. de 2020 às 02:58, Michael Paquier escreveu: > On Sun, May 03, 2020 at 04:23:24PM -0300, Ranier Vilela wrote: > > I don't know if it applies to the same case, but from the moment I > > installed python on the development machine, the Postgres build stopped &

[REPORT] Static analys warnings

((overwrite) ? PAI_OVERWRITE : 0) | \ ((is_heap) ? PAI_IS_HEAP : 0)) Typo | should be ||: ((overwrite) ? PAI_OVERWRITE : 0) || \ ((is_heap) ? PAI_IS_HEAP : 0)) regards, Ranier Vilela

Re: Postgres Windows build system doesn't work with python installed in Program Files

ram.y 'perl' nao é reconhecido como um comando interno ou externo, um programa operável ou um arquivo em lotes. etc Warning from build.pl Use of uninitialized value $ARGV[0] in uc at build.pl line 44. Use of uninitialized value $ARGV[0] in uc at build.pl line 48. regards, Ranier Vilela

Re: Unify drop-by-OID functions

Em sáb., 2 de mai. de 2020 às 05:01, Peter Eisentraut < peter.eisentr...@2ndquadrant.com> escreveu: > On 2020-05-01 23:31, Ranier Vilela wrote: > > I can suggest improvements? > > > > 1. In case Object is cached, delay open_table until the last moment, for > > t

Re: Unify drop-by-OID functions

, + object->classId, object->objectId); + + CatalogTupleDelete(rel, &tup->t_self); + systable_endscan(scan); +table_close(rel, RowExclusiveLock); + } +} + regards, Ranier Vilela

Re: [PATCH] Fix possible overflow on tuplesort.c

Em qui., 23 de abr. de 2020 às 16:43, Alvaro Herrera < alvhe...@2ndquadrant.com> escreveu: > On 2020-Apr-16, Ranier Vilela wrote: > > > When multiplying variables, the overflow will take place anyway, and only > > then will the meaningless product be explicitly promoted

Re: [PATCH] FIx resource leaks (pg_resetwal.c)

Em qui., 23 de abr. de 2020 às 16:43, Robert Haas escreveu: > On Thu, Apr 23, 2020 at 2:41 PM Ranier Vilela wrote: > > I do not agree in any way. At the very least what I am reporting is > suspect. And if I already propose a solution even if it is not the best, it > is much be

Re: [PATCH] FIx resource leaks (pg_resetwal.c)

Em qui., 23 de abr. de 2020 às 16:27, Peter Geoghegan escreveu: > On Thu, Apr 23, 2020 at 11:41 AM Ranier Vilela > wrote: > > And if I already propose a solution even if it is not the best, it is > much better than being silent and missing the opportunity to fix a bug. > >

[PATCH] Fix possible Uninitialized variables (parse_manifest.c)

Hi, Per Coverity. verify_manifest_checksum, declare and can utilize array of uint8, without initializing it. While here, I applied the quick exit technique, to avoid unnecessary computations, if it is possible to avoid them. regards, Ranier Vilela fix_uninitialized_array_parse_manifest.patch

Re: [PATCH] FIx resource leaks (pg_resetwal.c)

Em qui., 23 de abr. de 2020 às 15:27, Andres Freund escreveu: > Hi, > > On 2020-04-23 15:20:59 -0300, Ranier Vilela wrote: > > Per Coverity. > > > > read_controlfile alloc memory with pg_malloc and fail in releasing the > > memory. > > Seriously, this is ge

[PATCH] FIx resource leaks (pg_resetwal.c)

Hi, Per Coverity. read_controlfile alloc memory with pg_malloc and fail in releasing the memory. regards, Ranier Vilela fix_resource_leaks_pg_resetwal.patch Description: Binary data

[PATCH] Fix Null pointer dereferences (pgoutput.c)

Hi, Per Coverity. If test oldtuple can be NULL, I mean it can really be NULL. On DELETE process, if oldtuple is NULL, log error and continue. So UPDATE must have the same treatment. regards, Ranier Vilela fix_null_pointer_dereference_pgoutput.patch Description: Binary data

[PATCH] Fix division by zero (explain.c)

ioned modes (copying the tuples into a * prefix group), we don't need to do anything if there were 0 full * groups. */ regards, Ranier Vilela fix_division_by_zero_explain.patch Description: Binary data

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

Em qua., 22 de abr. de 2020 às 23:27, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > Hello. > > At Wed, 22 Apr 2020 19:48:07 -0300, Ranier Vilela > wrote in > > Hi, > > strncpy, it is not a safe function and has the risk of corrupting memory. > > O

Re: [PATCH] FIx explicit null dereference pointer (nbtree.c)

Em qua., 22 de abr. de 2020 às 21:24, Peter Geoghegan escreveu: > On Wed, Apr 22, 2020 at 3:55 PM Ranier Vilela wrote: > > per Coverity. > > Some Postgres hackers have access to a dedicated coverity > installation, and this issue has probably already been dismissed. &g

[PATCH] FIx explicit null dereference pointer (nbtree.c)

h. CID 1314742 (#2 of 2): Explicit null dereferenced (FORWARD_NULL) 6. var_deref_op: Dereferencing null pointer opaque. regards, Ranier Vilela fix_explicit_null_dereference_nbtree.patch Description: Binary data

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

Hi, strncpy, it is not a safe function and has the risk of corrupting memory. On ecpg lib, two sources, make use of strncpy risk, this patch tries to fix. 1. Make room for the last null-characte; 2. Copies Maximum number of characters - 1. per Coverity. regards, Ranier Vilela

Re: PG compilation error with Visual Studio 2015/2017/2019

tached patch. > I made some style changes too. 1. Change: strcpy(iso_lc_messages, "C"); to iso_lc_messages[0] = 'C'; iso_lc_messages[1] = '\0'; 2. Remove vars hyphen and underscore; 3. Avoid call second wcsrchr, if hyphen is not found. If it's not too much per

Re: PG compilation error with Visual Studio 2015/2017/2019

ion for EnumSystemLocalesEx. * Stop enumerating if a match is found for a locale with the format * _. * The order for search locale is essential: * Find LCType first as LOCALE_SNAME, if not found try LOCALE_SENGLISHLANGUAGENAME and * finally LOCALE_SENGLISHCOUNTRYNAME, before return. */ Typo "enumarating". 2. Maybe the fail has here: if (hyphen == NULL || underscore == NULL) Change || to &&, the logical is wrong? 3. Why iso_lc_messages[0] = '\0'? If we go call strchr, soon after, it's a waste. regards, Ranier Vilela

Re: [PATCH] Small optimization across postgres (remove strlen duplicate usage)

Em dom., 19 de abr. de 2020 às 22:00, David Rowley escreveu: > On Mon, 20 Apr 2020 at 11:24, Ranier Vilela wrote: > > I tried: https://godbolt.org with: > > > > -O2: > > > > f1: > > int main (int argv, char **argc) > > { > > return strlen

Re: [PATCH] Small optimization across postgres (remove strlen duplicate usage)

Em dom., 19 de abr. de 2020 às 18:38, Tom Lane escreveu: > Tomas Vondra writes: > > On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote: > >> strlen it is one of the low fruits that can be harvested. > > > Maybe there are places where this would help, but

Re: [PATCH] Small optimization across postgres (remove strlen duplicate usage)

7;; } f2: Assembly main: # @main xor eax, eax cmp qword ptr [rsi], 0 sete al ret For me clearly str [0] == '\ 0', wins. regards, Ranier Vilela

Re: [PATCH] Small optimization across postgres (remove strlen duplicate usage)

Em dom., 19 de abr. de 2020 às 16:33, Tomas Vondra < tomas.von...@2ndquadrant.com> escreveu: > On Sun, Apr 19, 2020 at 11:24:38AM -0300, Ranier Vilela wrote: > >Hi, > >strlen it is one of the low fruits that can be harvested. > >What is your opinion? > > >

Re: PG compilation error with Visual Studio 2015/2017/2019

Em dom., 19 de abr. de 2020 às 12:34, Juan José Santamaría Flecha < juanjo.santama...@gmail.com> escreveu: > > On Sun, Apr 19, 2020 at 1:58 PM Ranier Vilela wrote: > >> Em dom., 19 de abr. de 2020 às 07:16, Juan José Santamaría Flecha < >> juanjo.santama...@gmai

[PATCH] Small optimization across postgres (remove strlen duplicate usage)

Hi, strlen it is one of the low fruits that can be harvested. What is your opinion? regards, Ranier Vilela remove_strlen.patch Description: Binary data

Re: PG compilation error with Visual Studio 2015/2017/2019

kup-table. > > The attached results (WindowsNLSLocales.ods) come from Windows 10 (1903) > and Visual C++ build 1924, 64-bit. > > On Sat, Apr 18, 2020 at 1:43 PM Ranier Vilela wrote: > >> I have some observations about this patch, related to style, if you will >> al

Re: PG compilation error with Visual Studio 2015/2017/2019

en = wcslen(test_locale); + if (GetLocaleInfoEx(pStr, LOCALE_SENGLISHCOUNTRYNAME, + test_locale + len, LOCALE_NAME_MAX_LENGTH - len) > 0) + { + WCHAR **argv = (WCHAR **) lparam; + + if (wcsncmp(argv[0], test_locale, len) == 0) + { + wcscpy(argv[1], pStr); + return FALSE; + } + } + } + return TRUE; +} regards, Ranier Vilela

[PATCH] Fix possible overflow on tuplesort.c

Hi, When multiplying variables, the overflow will take place anyway, and only then will the meaningless product be explicitly promoted to type int64. It is one of the operands that should have been cast instead to avoid the overflow. regards, Ranier Vilela

[PATCH] Tiny optimization on nbtinsert.c

Hi, Avoiding some calls and set vars, when it is not necessary. best regards, Ranier Vilela nbtinsert_tiny_optimization.patch Description: Binary data

Re: [PATCH'] Variables assigned with values that is never used.

Em sáb., 28 de mar. de 2020 às 10:33, Ranier Vilela escreveu: > Hi, > > Theses variables, are assigned with values that never is used and, can > safely have their values removed. > 1. https://github.com/postgres/postgres/commit/f0ca378d4c139eda99ef14998115c1674dac3fc5 diff --gi

Re: PG compilation error with Visual Studio 2015/2017/2019

Em qua., 15 de abr. de 2020 às 15:28, Juan José Santamaría Flecha < juanjo.santama...@gmail.com> escreveu: > > > On Wed, Apr 15, 2020 at 4:46 PM Ranier Vilela wrote: > >> Em qua., 15 de abr. de 2020 às 03:08, davinder singh < >> davindersingh2...@gmail.com&

Re: PG compilation error with Visual Studio 2015/2017/2019

Em qua., 15 de abr. de 2020 às 03:08, davinder singh < davindersingh2...@gmail.com> escreveu: > > Thanks for the review comments. > > On Tue, Apr 14, 2020 at 9:12 PM Ranier Vilela wrote: > >> >>I m still working on testing this patch. If anyone has Idea please &g

PG compilation error with Visual Studio 2015/2017/2019

_WINNT >= 0x0600 is true and loct is not used? regards, Ranier Vilela

Re: PG compilation error with Visual Studio 2015/2017/2019

Em qui., 9 de abr. de 2020 às 09:14, Juan José Santamaría Flecha < juanjo.santama...@gmail.com> escreveu: > > On Thu, Apr 9, 2020 at 1:56 PM Ranier Vilela wrote: > >> Attached, your patch with those considerations. >> > I see no attachment. > Sorry, my mystake.

Re: PG compilation error with Visual Studio 2015/2017/2019

title. Hi, I have a few comments about the patch, if I may. 1. Variable rc runs the risk of being used uninitialized. 2. Variable loct has a redundant declaration ( = NULL). 3. Return "C", does not solve the first case? Attached, your patch with those considerations. regards, Ranier VIlela

Re: [PATCH] Redudant initilization

Hi, New patch with yours suggestions. best regards, Ranier Vilela v2_redundant_initialization.patch Description: Binary data

[PATCH] Fix type var declaration (src/backend/access/brin/brin.c)

Hi, bringetbitmap function returns int64 value, but internally uses int. For prevent future bugs, fix to right type. best regards, Ranier Vilela fix_int64_brin.patch Description: Binary data

Re: [PATCH] remove condition always true (/src/backend/access/heap/vacuumlazy.c)

Hi, Thanks for the commit. Ranier Vilela

Re: [PATCH] remove condition always true (/src/backend/access/heap/vacuumlazy.c)

Em seg., 30 de mar. de 2020 às 18:14, Andres Freund escreveu: > Hi, > > On 2020-03-30 14:10:29 -0700, Andres Freund wrote: > > On 2020-03-30 17:08:01 -0300, Ranier Vilela wrote: > > > Em seg., 30 de mar. de 2020 às 16:05, Andres Freund < > and...@anarazel.de>

[PATCH] remove condition always true (/src/backend/access/heap/vacuumlazy.c)

does, apparently it checks before unlocking. best regards, Ranier Vilela remove_condition_always_true.patch Description: Binary data

[PATCH] Remove some reassigned values.

Hi, This patch remove reassigned values, with safety. Plancat.c, needs a more careful review. Best regards Ranier Vilela remove_reassigned_values.patch Description: Binary data

Re: Possible copy and past error? (\usr\backend\commands\analyze.c)

Em seg., 30 de mar. de 2020 às 06:06, Magnus Hagander escreveu: > On Sat, Mar 28, 2020 at 11:49 AM Ranier Vilela > wrote: > > > > Em sex., 27 de mar. de 2020 às 20:49, Tom Lane > escreveu: > >> > >> Ranier Vilela writes: > >> > Can someon

Re: Possible copy and past error? (\usr\backend\commands\analyze.c)

Em seg., 30 de mar. de 2020 às 05:16, Michael Paquier escreveu: > On Sat, Mar 28, 2020 at 07:48:22AM -0300, Ranier Vilela wrote: > > I completely disagree. My tools have proven their worth, including > finding > > serious errors in the code, which fortunately have b

Re: [PATCH] Redudant initilization

Em dom., 29 de mar. de 2020 às 21:57, Kyotaro Horiguchi < horikyota@gmail.com> escreveu: > Hello. > > At Sat, 28 Mar 2020 19:04:00 -0300, Ranier Vilela > wrote in > > Hi, > > This patch fixes some redundant initilization, that are safe to remove. > > &g

[PATCH] Redudant initilization

Hi, This patch fixes some redundant initilization, that are safe to remove. best regards, Ranier Vilela redudant_initialization.patch Description: Binary data

[PATCH'] Variables assigned with values that is never used.

Hi, Theses variables, are assigned with values that never is used and, can safely have their values removed. best regards, Ranier Vilela variables_assigned_unused_value.patch Description: Binary data

Re: Possible copy and past error? (\usr\backend\commands\analyze.c)

Em sex., 27 de mar. de 2020 às 20:49, Tom Lane escreveu: > Ranier Vilela writes: > > Can someone check if there is a copy and paste error, at file: > > \usr\backend\commands\analyze.c, at lines 2225 and 2226? > > int num_mcv = stats->attr->attstattarget; >

Possible copy and past error? (\usr\backend\commands\analyze.c)

stats->attr->attstattarget; int num_bins = num_mcv; To silence this alert. best regards, Ranier Vilela

Re: Broken resetting of subplan hash tables

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

[REPORT] Possible Memory Leak Postgres Windows

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

Re: [PATCH] libpq improvements and fixes

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. > &

Re: [PATCH] libpq improvements and fixes

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

[PATCH] libpq improvements and fixes

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

Re: Postgres 32 bits client compilation fail. Win32 bits client is supported?

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

Re: Postgres 32 bits client compilation fail. Win32 bits client is supported?

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

Re: Postgres 32 bits client compilation fail. Win32 bits client is supported?

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

Postgres 32 bits client compilation fail. Win32 bits client is supported?

gres \ src \ tools \ msvc / Mkvcbuild.pm line 842. Question: Will Postgres continue to support 32-bit client? regards, Ranier Vilela

Re: [PATCH] Windows port, fix some resources leaks

f. > Maybe it didn't bother anyone, because the Windows port is much less used. Anyway, I believe that freeing the memory before returning false, will not bring down the service, changing the patch to LOG, instead of FATAL. The primary error of the patch was to use FATAL. regards, Ranier Vilela

Re: [PATCH] Windows port, fix some resources leaks

/backend/port/win32_shmem.c. On line 575 in src / backend / port / win32_shmem.c, there is a comment that tells to not use FATAL. "Don't use FATAL since we're running in the postmaster." regards, Ranier Vilela

Re: [PATCH] /src/backend/access/transam/xlog.c, tiny improvements

Em dom., 26 de jan. de 2020 às 23:48, Mark Dilger < mark.dil...@enterprisedb.com> escreveu: > > On Jan 24, 2020, at 12:48 PM, Ranier Vilela wrote: > > > > 3. At function KeepLogSeg (line 9357) the test if (slotSegNo <= 0), the > var slotSegNo is uint64 and not can

Re: [PATCH] Windows port, fix some resources leaks

Em dom., 26 de jan. de 2020 às 23:04, Michael Paquier escreveu: > On Fri, Jan 24, 2020 at 09:37:25AM -0300, Ranier Vilela wrote: > > Em sex., 24 de jan. de 2020 às 04:13, Michael Paquier < > mich...@paquier.xyz> > > escreveu: > >> There is some progress. You sho

<    3   4   5   6   7   8   9   >