public inbox for [email protected]help / color / mirror / Atom feed
[PATCH 06/18] One fewer (not one less) 8+ messages / 5 participants [nested] [flat]
* [PATCH 06/18] One fewer (not one less) @ 2021-01-18 20:37 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 8+ messages in thread From: Justin Pryzby @ 2021-01-18 20:37 UTC (permalink / raw) --- contrib/pageinspect/heapfuncs.c | 2 +- doc/src/sgml/charset.sgml | 2 +- doc/src/sgml/ref/create_type.sgml | 2 +- doc/src/sgml/rules.sgml | 2 +- src/backend/access/common/heaptuple.c | 4 ++-- src/backend/commands/analyze.c | 2 +- src/backend/utils/adt/jsonpath_exec.c | 2 +- src/backend/utils/adt/selfuncs.c | 2 +- src/backend/utils/cache/catcache.c | 2 +- src/backend/utils/misc/sampling.c | 2 +- src/backend/utils/mmgr/freepage.c | 2 +- src/bin/pgbench/pgbench.c | 2 +- src/include/pg_config_manual.h | 4 ++-- src/interfaces/ecpg/include/sqlda-native.h | 2 +- src/test/regress/expected/geometry.out | 2 +- src/test/regress/sql/geometry.sql | 2 +- 16 files changed, 18 insertions(+), 18 deletions(-) diff --git a/contrib/pageinspect/heapfuncs.c b/contrib/pageinspect/heapfuncs.c index 9abcee32af..f6760eb31e 100644 --- a/contrib/pageinspect/heapfuncs.c +++ b/contrib/pageinspect/heapfuncs.c @@ -338,7 +338,7 @@ tuple_data_split_internal(Oid relid, char *tupdata, attr = TupleDescAttr(tupdesc, i); /* - * Tuple header can specify less attributes than tuple descriptor as + * Tuple header can specify fewer attributes than tuple descriptor as * ALTER TABLE ADD COLUMN without DEFAULT keyword does not actually * change tuples in pages, so attributes with numbers greater than * (t_infomask2 & HEAP_NATTS_MASK) should be treated as NULL. diff --git a/doc/src/sgml/charset.sgml b/doc/src/sgml/charset.sgml index cebc09ef91..1b00e543a6 100644 --- a/doc/src/sgml/charset.sgml +++ b/doc/src/sgml/charset.sgml @@ -619,7 +619,7 @@ SELECT * FROM test1 ORDER BY a || b COLLATE "fr_FR"; name such as <literal>de_DE</literal> can be considered unique within a given database even though it would not be unique globally. Use of the stripped collation names is recommended, since it will - make one less thing you need to change if you decide to change to + make one fewer thing you need to change if you decide to change to another database encoding. Note however that the <literal>default</literal>, <literal>C</literal>, and <literal>POSIX</literal> collations can be used regardless of the database encoding. diff --git a/doc/src/sgml/ref/create_type.sgml b/doc/src/sgml/ref/create_type.sgml index 0b24a55505..693423e524 100644 --- a/doc/src/sgml/ref/create_type.sgml +++ b/doc/src/sgml/ref/create_type.sgml @@ -867,7 +867,7 @@ CREATE TYPE <replaceable class="parameter">name</replaceable> Before <productname>PostgreSQL</productname> version 8.3, the name of a generated array type was always exactly the element type's name with one underscore character (<literal>_</literal>) prepended. (Type names were - therefore restricted in length to one less character than other names.) + therefore restricted in length to one fewer character than other names.) While this is still usually the case, the array type name may vary from this in case of maximum-length names or collisions with user type names that begin with underscore. Writing code that depends on this convention diff --git a/doc/src/sgml/rules.sgml b/doc/src/sgml/rules.sgml index e81addcfa9..aa172d102b 100644 --- a/doc/src/sgml/rules.sgml +++ b/doc/src/sgml/rules.sgml @@ -1266,7 +1266,7 @@ CREATE [ OR REPLACE ] RULE <replaceable class="parameter">name</replaceable> AS <para> The query trees generated from rule actions are thrown into the rewrite system again, and maybe more rules get applied resulting - in more or less query trees. + in additional or fewer query trees. So a rule's actions must have either a different command type or a different result relation than the rule itself is on, otherwise this recursive process will end up in an infinite loop. diff --git a/src/backend/access/common/heaptuple.c b/src/backend/access/common/heaptuple.c index 24a27e387d..0b56b0fa5a 100644 --- a/src/backend/access/common/heaptuple.c +++ b/src/backend/access/common/heaptuple.c @@ -719,11 +719,11 @@ heap_copytuple_with_tuple(HeapTuple src, HeapTuple dest) } /* - * Expand a tuple which has less attributes than required. For each attribute + * Expand a tuple which has fewer attributes than required. For each attribute * not present in the sourceTuple, if there is a missing value that will be * used. Otherwise the attribute will be set to NULL. * - * The source tuple must have less attributes than the required number. + * The source tuple must have fewer attributes than the required number. * * Only one of targetHeapTuple and targetMinimalTuple may be supplied. The * other argument must be NULL. diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c index 7295cf0215..64908ac39c 100644 --- a/src/backend/commands/analyze.c +++ b/src/backend/commands/analyze.c @@ -1003,7 +1003,7 @@ examine_attribute(Relation onerel, int attnum, Node *index_expr) * As of May 2004 we use a new two-stage method: Stage one selects up * to targrows random blocks (or all blocks, if there aren't so many). * Stage two scans these blocks and uses the Vitter algorithm to create - * a random sample of targrows rows (or less, if there are less in the + * a random sample of targrows rows (or fewer, if there are fewer in the * sample of blocks). The two stages are executed simultaneously: each * block is processed as soon as stage one returns its number and while * the rows are read stage two controls which ones are to be inserted diff --git a/src/backend/utils/adt/jsonpath_exec.c b/src/backend/utils/adt/jsonpath_exec.c index 4d185c27b4..078aaef539 100644 --- a/src/backend/utils/adt/jsonpath_exec.c +++ b/src/backend/utils/adt/jsonpath_exec.c @@ -263,7 +263,7 @@ static int compareDatetime(Datum val1, Oid typid1, Datum val2, Oid typid2, * implement @? and @@ operators, which in turn are intended to have an * index support. Thus, it's desirable to make it easier to achieve * consistency between index scan results and sequential scan results. - * So, we throw as less errors as possible. Regarding this function, + * So, we throw as few errors as possible. Regarding this function, * such behavior also matches behavior of JSON_EXISTS() clause of * SQL/JSON. Regarding jsonb_path_match(), this function doesn't have * an analogy in SQL/JSON, so we define its behavior on our own. diff --git a/src/backend/utils/adt/selfuncs.c b/src/backend/utils/adt/selfuncs.c index 47ca4ddbb5..52314d3aa1 100644 --- a/src/backend/utils/adt/selfuncs.c +++ b/src/backend/utils/adt/selfuncs.c @@ -645,7 +645,7 @@ scalarineqsel(PlannerInfo *root, Oid operator, bool isgt, bool iseq, /* * The calculation so far gave us a selectivity for the "<=" case. - * We'll have one less tuple for "<" and one additional tuple for + * We'll have one fewer tuple for "<" and one additional tuple for * ">=", the latter of which we'll reverse the selectivity for * below, so we can simply subtract one tuple for both cases. The * cases that need this adjustment can be identified by iseq being diff --git a/src/backend/utils/cache/catcache.c b/src/backend/utils/cache/catcache.c index fa2b49c676..55c9445898 100644 --- a/src/backend/utils/cache/catcache.c +++ b/src/backend/utils/cache/catcache.c @@ -1497,7 +1497,7 @@ GetCatCacheHashValue(CatCache *cache, * It doesn't make any sense to specify all of the cache's key columns * here: since the key is unique, there could be at most one match, so * you ought to use SearchCatCache() instead. Hence this function takes - * one less Datum argument than SearchCatCache() does. + * one fewer Datum argument than SearchCatCache() does. * * The caller must not modify the list object or the pointed-to tuples, * and must call ReleaseCatCacheList() when done with the list. diff --git a/src/backend/utils/misc/sampling.c b/src/backend/utils/misc/sampling.c index 0c327e823f..7348b86682 100644 --- a/src/backend/utils/misc/sampling.c +++ b/src/backend/utils/misc/sampling.c @@ -42,7 +42,7 @@ BlockSampler_Init(BlockSampler bs, BlockNumber nblocks, int samplesize, bs->N = nblocks; /* measured table size */ /* - * If we decide to reduce samplesize for tables that have less or not much + * If we decide to reduce samplesize for tables that have fewer or not much * more than samplesize blocks, here is the place to do it. */ bs->n = samplesize; diff --git a/src/backend/utils/mmgr/freepage.c b/src/backend/utils/mmgr/freepage.c index e4ee1aab97..10a1effb74 100644 --- a/src/backend/utils/mmgr/freepage.c +++ b/src/backend/utils/mmgr/freepage.c @@ -495,7 +495,7 @@ FreePageManagerDump(FreePageManager *fpm) * if we search the parent page for the first key greater than or equal to * the first key on the current page, the downlink to this page will be either * the exact index returned by the search (if the first key decreased) - * or one less (if the first key increased). + * or one fewer (if the first key increased). */ static void FreePageBtreeAdjustAncestorKeys(FreePageManager *fpm, FreePageBtree *btp) diff --git a/src/bin/pgbench/pgbench.c b/src/bin/pgbench/pgbench.c index a4a3f40048..627a244fb7 100644 --- a/src/bin/pgbench/pgbench.c +++ b/src/bin/pgbench/pgbench.c @@ -6458,7 +6458,7 @@ threadRun(void *arg) /* * If advanceConnectionState changed client to finished state, - * that's one less client that remains. + * that's one fewer client that remains. */ if (st->state == CSTATE_FINISHED || st->state == CSTATE_ABORTED) remains--; diff --git a/src/include/pg_config_manual.h b/src/include/pg_config_manual.h index d27c8601fa..e3d2e751ea 100644 --- a/src/include/pg_config_manual.h +++ b/src/include/pg_config_manual.h @@ -21,7 +21,7 @@ /* * Maximum length for identifiers (e.g. table names, column names, - * function names). Names actually are limited to one less byte than this, + * function names). Names actually are limited to one fewer byte than this, * because the length must include a trailing zero byte. * * Changing this requires an initdb. @@ -87,7 +87,7 @@ /* * MAXPGPATH: standard size of a pathname buffer in PostgreSQL (hence, - * maximum usable pathname length is one less). + * maximum usable pathname length is one fewer). * * We'd use a standard system header symbol for this, if there weren't * so many to choose from: MAXPATHLEN, MAX_PATH, PATH_MAX are all diff --git a/src/interfaces/ecpg/include/sqlda-native.h b/src/interfaces/ecpg/include/sqlda-native.h index 67d3c7b4e4..9e73f1f1b1 100644 --- a/src/interfaces/ecpg/include/sqlda-native.h +++ b/src/interfaces/ecpg/include/sqlda-native.h @@ -7,7 +7,7 @@ /* * Maximum length for identifiers (e.g. table names, column names, - * function names). Names actually are limited to one less byte than this, + * function names). Names actually are limited to one fewer byte than this, * because the length must include a trailing zero byte. * * This should be at least as much as NAMEDATALEN of the database the diff --git a/src/test/regress/expected/geometry.out b/src/test/regress/expected/geometry.out index 84f7eabb66..9799cfbdbd 100644 --- a/src/test/regress/expected/geometry.out +++ b/src/test/regress/expected/geometry.out @@ -4325,7 +4325,7 @@ SELECT f1, polygon(8, f1) FROM CIRCLE_TBL WHERE f1 >= '<(0,0),1>'; <(100,1),115> | ((-15,1),(18.6827201635,82.3172798365),(100,116),(181.317279836,82.3172798365),(215,1),(181.317279836,-80.3172798365),(100,-114),(18.6827201635,-80.3172798365)) (6 rows) --- Too less points error +-- Too few points error SELECT f1, polygon(1, f1) FROM CIRCLE_TBL WHERE f1 >= '<(0,0),1>'; ERROR: must request at least 2 points -- Zero radius error diff --git a/src/test/regress/sql/geometry.sql b/src/test/regress/sql/geometry.sql index 96df0ab05a..b0ab6d03ec 100644 --- a/src/test/regress/sql/geometry.sql +++ b/src/test/regress/sql/geometry.sql @@ -424,7 +424,7 @@ SELECT f1, f1::polygon FROM CIRCLE_TBL WHERE f1 >= '<(0,0),1>'; -- To polygon with less points SELECT f1, polygon(8, f1) FROM CIRCLE_TBL WHERE f1 >= '<(0,0),1>'; --- Too less points error +-- Too few points error SELECT f1, polygon(1, f1) FROM CIRCLE_TBL WHERE f1 >= '<(0,0),1>'; -- Zero radius error -- 2.17.0 --lc9FT7cWel8HagAv Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0007-function-comment-get_am_name.patch" ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Modern SHA2- based password hashes for pgcrypto @ 2025-04-05 17:22 Alvaro Herrera <[email protected]> 0 siblings, 3 replies; 8+ messages in thread From: Alvaro Herrera @ 2025-04-05 17:22 UTC (permalink / raw) To: Bernd Helmle <[email protected]>; +Cc: Japin Li <[email protected]>; pgsql-hackers Hello, I have pushed this now, hoping it won't explode. Thanks! -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "No es bueno caminar con un hombre muerto" ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Modern SHA2- based password hashes for pgcrypto @ 2025-04-06 17:39 Bernd Helmle <[email protected]> parent: Alvaro Herrera <[email protected]> 2 siblings, 0 replies; 8+ messages in thread From: Bernd Helmle @ 2025-04-06 17:39 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: Japin Li <[email protected]>; pgsql-hackers Am Samstag, dem 05.04.2025 um 19:22 +0200 schrieb Alvaro Herrera: > Hello, > > I have pushed this now, hoping it won't explode. > > Thanks! Very cool, i keep my fingers crossed. Thanks, Bernd ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Modern SHA2- based password hashes for pgcrypto @ 2025-04-06 19:43 Tom Lane <[email protected]> parent: Alvaro Herrera <[email protected]> 2 siblings, 1 reply; 8+ messages in thread From: Tom Lane @ 2025-04-06 19:43 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: Bernd Helmle <[email protected]>; Japin Li <[email protected]>; pgsql-hackers Alvaro Herrera <[email protected]> writes: > I have pushed this now, hoping it won't explode. mamba is not happy: ccache cc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -O2 -Werror -fPIC -DPIC -fvisibility=hidden -I. -I. -I../../src/include -I/usr/pkg/include/libxml2 -I/usr/pkg/include -I/usr/pkg/include -I/usr/pkg/include -c -o pgcrypto.o pgcrypto.c In file included from /usr/include/ctype.h:100, from ../../src/include/port.h:16, from ../../src/include/c.h:1345, from ../../src/include/postgres.h:48, from crypt-sha.c:46: crypt-sha.c: In function 'px_crypt_shacrypt': crypt-sha.c:324:16: error: array subscript has type 'char' [-Werror=char-subscripts] 324 | if (isalpha(*ep) || isdigit(*ep) || (*ep == '.') || (*ep == '/')) | ^ crypt-sha.c:324:32: error: array subscript has type 'char' [-Werror=char-subscripts] 324 | if (isalpha(*ep) || isdigit(*ep) || (*ep == '.') || (*ep == '/')) | ^ cc1: all warnings being treated as errors gmake[1]: *** [<builtin>: crypt-sha.o] Error 1 What this is on about is that portable use of isalpha() or isdigit() requires casting a "char" value to "unsigned char". I was about to make that simple change when I started to question if we actually want to be using <ctype.h> here at all. Do you REALLY intend that any random non-ASCII letter is okay to include in the decoded_salt? Are you okay with that filter being locale-dependent? I'd be more comfortable with a check like if (strchr("...valid chars...", *ep) != NULL) It looks like "_crypt_itoa64" might be directly usable as the valid-chars string, too. (BTW, why is _crypt_itoa64 not marked const?) regards, tom lane ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Modern SHA2- based password hashes for pgcrypto @ 2025-04-07 03:02 Andres Freund <[email protected]> parent: Alvaro Herrera <[email protected]> 2 siblings, 1 reply; 8+ messages in thread From: Andres Freund @ 2025-04-07 03:02 UTC (permalink / raw) To: Alvaro Herrera <[email protected]>; +Cc: Bernd Helmle <[email protected]>; Japin Li <[email protected]>; pgsql-hackers Hi, On 2025-04-05 19:22:58 +0200, Alvaro Herrera wrote: > I have pushed this now, hoping it won't explode. I have a WIP patch that adds gcc specific allocator attributes for palloc et al. Just rebased that. It warns on the new code as follows: [1489/1804 42 82%] Compiling C object contrib/pgcrypto/pgcrypto.so.p/crypt-sha.c.o ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-sha.c: In function 'px_crypt_shacrypt': ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-sha.c:605:13: warning: pointer 'cp' may be used after 'pfree' [-Wuse-after-free] 605 | *cp = '\0'; | ~~~~^~~~~~ ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt-sha.c:533:9: note: call to 'pfree' here 533 | pfree(s_bytes); | ^~~~~~~~~~~~~~ And it sure seems to have a point. I'm surprised this isn't causing wider issues... Greetings, Andres Freund ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Modern SHA2- based password hashes for pgcrypto @ 2025-04-07 07:03 Bernd Helmle <[email protected]> parent: Tom Lane <[email protected]> 0 siblings, 0 replies; 8+ messages in thread From: Bernd Helmle @ 2025-04-07 07:03 UTC (permalink / raw) To: Tom Lane <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: Japin Li <[email protected]>; pgsql-hackers Am Sonntag, dem 06.04.2025 um 15:43 -0400 schrieb Tom Lane: > What this is on about is that portable use of isalpha() or isdigit() > requires casting a "char" value to "unsigned char". I was about to > make that simple change when I started to question if we actually > want to be using <ctype.h> here at all. Do you REALLY intend that > any random non-ASCII letter is okay to include in the decoded_salt? > Are you okay with that filter being locale-dependent? > > I'd be more comfortable with a check like > > if (strchr("...valid chars...", *ep) != NULL) > Hmm, the idea was to allow a wider range of letters for the salt. This came from my experiments that openssl allows more than just the ones from _crypt_itoa64. But after reading this, i realized even isalpha() isn't enough, since e.g. mulitbyte character wouldn't work anyways, like openssl allows: echo -n password | openssl passwd -5 -salt ÄÖÜ -stdin $5$ÄÖÜ$NduBUgCdzvnW1lW8EMxW9DuxN6HmT0niS7H4ftRxuX0 So we would have to test for these cases, too. I looked again into pyhon's passlib, and they don't accept any non-ASCII fancy characters, neither. So i think Tom has a point, we can restrict this to the characters from _crypt_itoa64 and go that route. I am not sure about externally generated hashes which are going to be stored in postgres and validated later there. This can restrict the use case perhaps. > It looks like "_crypt_itoa64" might be directly usable as the > valid-chars string, too. (BTW, why is _crypt_itoa64 not > marked const?) That's an oversight by me. I can create a patch with the fixes (and the one Andres' reported) for today. Thanks Bernd ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Modern SHA2- based password hashes for pgcrypto @ 2025-04-07 07:09 Bernd Helmle <[email protected]> parent: Andres Freund <[email protected]> 0 siblings, 1 reply; 8+ messages in thread From: Bernd Helmle @ 2025-04-07 07:09 UTC (permalink / raw) To: Andres Freund <[email protected]>; Alvaro Herrera <[email protected]>; +Cc: Japin Li <[email protected]>; pgsql-hackers Am Sonntag, dem 06.04.2025 um 23:02 -0400 schrieb Andres Freund: > Hi, > > On 2025-04-05 19:22:58 +0200, Alvaro Herrera wrote: > > I have pushed this now, hoping it won't explode. > > I have a WIP patch that adds gcc specific allocator attributes for > palloc et > al. Just rebased that. It warns on the new code as follows: > > [1489/1804 42 82%] Compiling C object > contrib/pgcrypto/pgcrypto.so.p/crypt-sha.c.o > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt- > sha.c: In function 'px_crypt_shacrypt': > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt- > sha.c:605:13: warning: pointer 'cp' may be used after 'pfree' [-Wuse- > after-free] > 605 | *cp = '\0'; > | ~~~~^~~~~~ > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt- > sha.c:533:9: note: call to 'pfree' here > 533 | pfree(s_bytes); > | ^~~~~~~~~~~~~~ > > And it sure seems to have a point. I'm surprised this isn't causing > wider > issues... Indeed. I think this assignment is useless anyways, since s_bytes is already allocated with palloc0. I must have overseen this one when rearranging code...but yes, strange that it didn't cause drama. Thanks Bernd ^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: Modern SHA2- based password hashes for pgcrypto @ 2025-04-07 18:00 Andres Freund <[email protected]> parent: Bernd Helmle <[email protected]> 0 siblings, 0 replies; 8+ messages in thread From: Andres Freund @ 2025-04-07 18:00 UTC (permalink / raw) To: Bernd Helmle <[email protected]>; +Cc: Alvaro Herrera <[email protected]>; Japin Li <[email protected]>; pgsql-hackers Hi, On 2025-04-07 09:09:39 +0200, Bernd Helmle wrote: > Am Sonntag, dem 06.04.2025 um 23:02 -0400 schrieb Andres Freund: > > On 2025-04-05 19:22:58 +0200, Alvaro Herrera wrote: > > > I have pushed this now, hoping it won't explode. > > > > I have a WIP patch that adds gcc specific allocator attributes for > > palloc et > > al. Just rebased that. It warns on the new code as follows: > > > > [1489/1804 42 82%] Compiling C object > > contrib/pgcrypto/pgcrypto.so.p/crypt-sha.c.o > > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt- > > sha.c: In function 'px_crypt_shacrypt': > > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt- > > sha.c:605:13: warning: pointer 'cp' may be used after 'pfree' [-Wuse- > > after-free] > > 605 | *cp = '\0'; > > | ~~~~^~~~~~ > > ../../../../../home/andres/src/postgresql/contrib/pgcrypto/crypt- > > sha.c:533:9: note: call to 'pfree' here > > 533 | pfree(s_bytes); > > | ^~~~~~~~~~~~~~ > > > > And it sure seems to have a point. I'm surprised this isn't causing > > wider > > issues... > > Indeed. I think this assignment is useless anyways, since s_bytes is > already allocated with palloc0. I must have overseen this one when > rearranging code...but yes, strange that it didn't cause drama. Valgrind did find it actually, I just missed it due to other failures: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=skink&dt=2025-04-05%2020%3A52%3A38... ==2917549== VALGRINDERROR-BEGIN ==2917549== Invalid write of size 1 ==2917549== at 0x11D4AD9C: px_crypt_shacrypt (crypt-sha.c:605) ==2917549== by 0x11D54B50: run_crypt_sha (px-crypt.c:76) ==2917549== by 0x11D54BCB: px_crypt (px-crypt.c:119) ==2917549== by 0x11D4BCBB: pg_crypt (pgcrypto.c:228) ==2917549== by 0x3BBCEA: ExecInterpExpr (execExprInterp.c:1001) ==2917549== by 0x3B790E: ExecInterpExprStillValid (execExprInterp.c:2299) ==2917549== by 0x48FD40: ExecEvalExprSwitchContext (executor.h:466) ==2917549== by 0x48FD40: evaluate_expr (clauses.c:5012) ==2917549== by 0x48FF08: evaluate_function (clauses.c:4519) ==2917549== by 0x492054: simplify_function (clauses.c:4108) ==2917549== by 0x4901FA: eval_const_expressions_mutator (clauses.c:2593) ==2917549== by 0x432CDE: expression_tree_mutator_impl (nodeFuncs.c:3486) ==2917549== by 0x48FFB9: eval_const_expressions_mutator (clauses.c:3727) ==2917549== Address 0x82fa740 is 912 bytes inside a recently re-allocated block of size 8,192 alloc'd ==2917549== at 0x4844818: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so) ==2917549== by 0x71EF75: AllocSetContextCreateInternal (aset.c:444) ==2917549== by 0x3D17AE: CreateExprContextInternal (execUtils.c:260) ==2917549== by 0x3D1CA8: CreateExprContext (execUtils.c:310) ==2917549== by 0x3D1ED8: MakePerTupleExprContext (execUtils.c:462) ==2917549== by 0x48FDBF: evaluate_expr (clauses.c:5013) ==2917549== by 0x48FF08: evaluate_function (clauses.c:4519) ==2917549== by 0x492054: simplify_function (clauses.c:4108) ==2917549== by 0x4901FA: eval_const_expressions_mutator (clauses.c:2593) ==2917549== by 0x432CDE: expression_tree_mutator_impl (nodeFuncs.c:3486) ==2917549== by 0x48FFB9: eval_const_expressions_mutator (clauses.c:3727) ==2917549== by 0x432EFD: expression_tree_mutator_impl (nodeFuncs.c:3572) ==2917549== ==2917549== VALGRINDERROR-END { <insert_a_suppression_name_here> Memcheck:Addr1 fun:px_crypt_shacrypt fun:run_crypt_sha fun:px_crypt fun:pg_crypt fun:ExecInterpExpr fun:ExecInterpExprStillValid fun:ExecEvalExprSwitchContext fun:evaluate_expr fun:evaluate_function fun:simplify_function fun:eval_const_expressions_mutator fun:expression_tree_mutator_impl fun:eval_const_expressions_mutator } **2917549** Valgrind detected 1 error(s) during execution of "SELECT crypt('', '$5$Szzz0yzz');" Greetings, Andres ^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2025-04-07 18:00 UTC | newest] Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-01-18 20:37 [PATCH 06/18] One fewer (not one less) Justin Pryzby <[email protected]> 2025-04-05 17:22 Re: Modern SHA2- based password hashes for pgcrypto Alvaro Herrera <[email protected]> 2025-04-06 17:39 ` Re: Modern SHA2- based password hashes for pgcrypto Bernd Helmle <[email protected]> 2025-04-06 19:43 ` Re: Modern SHA2- based password hashes for pgcrypto Tom Lane <[email protected]> 2025-04-07 07:03 ` Re: Modern SHA2- based password hashes for pgcrypto Bernd Helmle <[email protected]> 2025-04-07 03:02 ` Re: Modern SHA2- based password hashes for pgcrypto Andres Freund <[email protected]> 2025-04-07 07:09 ` Re: Modern SHA2- based password hashes for pgcrypto Bernd Helmle <[email protected]> 2025-04-07 18:00 ` Re: Modern SHA2- based password hashes for pgcrypto Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox