On Thu, 21 Aug 2025 at 15:52, Fujii Masao wrote:
> On Wed, Aug 20, 2025 at 10:37 AM Japin Li wrote:
>> Yeah. It's for both consistency and for proper file sorting.
>>
>> Zero-padding ensures that when a file system or tool sorts the snapshot files
>> a
On Wed, Aug 20, 2025 at 12:37:27AM +0900, Fujii Masao wrote:
> On Wed, Aug 13, 2025 at 9:56 AM Japin Li wrote:
> >
> > In commit 2633dae2e, I standardized the LSN formatting for log messages
> > using
> > zero-padding. However, I mistakenly changed the snapshot file n
On Thu, Aug 14, 2025 at 11:13:28AM +0900, Fujii Masao wrote:
> On Tue, Aug 12, 2025 at 7:36 PM Fujii Masao wrote:
> >
> > On Tue, Aug 12, 2025 at 4:45 PM Japin Li wrote:
> > >
> > > Hi, all
> > >
> > > Commit 2633dae2e487 standardized LSN fo
On Thu, Aug 14, 2025 at 12:04:12PM +1000, Peter Smith wrote:
> On Fri, Aug 1, 2025 at 5:43 PM Japin Li wrote:
> >
> > On Fri, Aug 01, 2025 at 05:18:11PM +1000, Peter Smith wrote:
> > > On Wed, Jul 30, 2025 at 9:07 PM Japin Li wrote:
> > > >
> > > ..
On Wed, Aug 13, 2025 at 07:28:34PM +0300, Timur Magomedov wrote:
> On Mon, 2025-08-11 at 17:39 +0800, Japin Li wrote:
> >
> > 1.
> > +static struct
> > +{
> > + int transfn_oid; /* Transition function's funcoid.
> > Arrays are
>
On Tue, Aug 12, 2025 at 10:02:32PM +0900, Fujii Masao wrote:
> On Tue, Aug 12, 2025 at 8:06 PM Japin Li wrote:
> > OTOH, I also update reorder buffer spill file path.
> >
> > $ git grep -E 'xid-.*-lsn.*spill'
> > src/backend/replication/logical/reorderbuffer.
cr1sDqKFUm-ef33Kdky9R8qdDC5JgeM7VdWNA%40mail.gmail.com
--
Best regards,
Japin Li
ChengDu WenWu Information Technology Co., LTD.
On Tue, Aug 12, 2025 at 07:58:25PM +0900, Fujii Masao wrote:
> On Tue, Aug 12, 2025 at 7:14 PM Fujii Masao wrote:
> >
> > On Tue, Aug 12, 2025 at 6:25 PM Japin Li wrote:
> > > I believe that the format %X-%X also works with sscanf(). However, to
> > > maintain
On Tue, Aug 12, 2025 at 07:14:38PM +0900, Fujii Masao wrote:
> On Tue, Aug 12, 2025 at 6:25 PM Japin Li wrote:
> > I believe that the format %X-%X also works with sscanf(). However, to
> > maintain
> > consistency, the format for sscanf() has been updated as well.
>
On Tue, Aug 12, 2025 at 05:57:45PM +0900, Fujii Masao wrote:
> On Tue, Aug 12, 2025 at 4:38 PM Japin Li wrote:
> >
> > On Tue, Aug 12, 2025 at 12:24:10PM +0530, shveta malik wrote:
> > > It looks like commit 2633dae (mistakenly) introduced a change ([1]) in
>
));
*
* To avoid breaking translatable messages, we're directly applying the
* LSN format instead of using a macro.
--
Best regards,
Japin Li
ChengDu WenWu Information Technology Co., LTD.
>From 24bc8e321b6c60f7659962eabe0288bf89fae3e0 Mon Sep 17 00:00:00 2001
From: Japin Li
Date: Tue
napBuildSerialize().
I'd prefer to update the format in SnapBuildSerialize() instead of reverting
this change.
diff --git a/src/backend/replication/logical/snapbuild.c
b/src/backend/replication/logical/snapbuild.c
index 8532bfd27e5..db7051170fc 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -1529,7 +1529,7 @@ SnapBuildSerialize(SnapBuild *builder, XLogRecPtr lsn)
* unless the user used pg_resetwal or similar. If a user did so, there's
* no hope continuing to decode anyway.
*/
-sprintf(path, "%s/%X-%X.snap",
+sprintf(path, "%s/%08X-%08X.snap",
PG_LOGICAL_SNAPSHOTS_DIR,
LSN_FORMAT_ARGS(lsn));
@@ -1573,7 +1573,7 @@ SnapBuildSerialize(SnapBuild *builder, XLogRecPtr lsn)
elog(DEBUG1, "serializing snapshot to %s", path);
/* to make sure only we will write to this tempfile, include pid */
-sprintf(tmppath, "%s/%X-%X.snap.%d.tmp",
+sprintf(tmppath, "%s/%08X-%08X.snap.%d.tmp",
PG_LOGICAL_SNAPSHOTS_DIR,
LSN_FORMAT_ARGS(lsn), MyProcPid);
--
Best regards,
Japin Li
ChengDu WenWu Information Technology Co., LTD.
On Mon, Aug 11, 2025 at 05:39:01PM +0800, Japin Li wrote:
> On Fri, Aug 08, 2025 at 06:08:27PM +1000, Peter Smith wrote:
> > Here are the latest v17 patches.
> >
> > Changes include:
> >
> > PATCH 0002.
> > - Rebase to fix compile error, result of r
opied.
*/
static void
vci_putInitPage(Oid oid, Page page, BlockNumber blkno)
[1]
https://www.postgresql.org/message-id/OS7PR01MB119642862AA1CE536549D08CFEA40A%40OS7PR01MB11964.jpnprd01.prod.outlook.com
--
Best regards,
Japin Li
ChengDu WenWu Information Technology Co., LTD.
diff --git a/contrib/vci/executor/vci_aggmer
On Fri, Aug 01, 2025 at 05:18:11PM +1000, Peter Smith wrote:
> On Wed, Jul 30, 2025 at 9:07 PM Japin Li wrote:
> >
> ...
> > 3.
> > I've also found that the VCI index is not working. Is this the expected
> > behavior?
>
trcasecmp(log_min_messages_backend_types[i], btype) == 0)
+ if
(pg_strncasecmp(log_min_messages_backend_types[i], btype, sep - tok) == 0)
{
/* Reject duplicates for a backend
type. */
if (assigned[i])
--
Best regards,
Japin Li
ChengDu WenWu Information Technology Co., LTD.
On Thu, 31 Jul 2025 at 18:51, Alvaro Herrera wrote:
> On 2025-Aug-01, Japin Li wrote:
>
>> If we set the log level for all backend types, I don't think a generic log
>> level is necessary.
>
> I don't understand what you mean by this. Can you elaborate
the list of
> backend types. I think Alvaro's proposal overcomes the objection [2], right?
>
If we set the log level for all backend types, I don't think a generic log
level is necessary.
--
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.
On Wed, 30 Jul 2025 at 19:07, Japin Li wrote:
> On Tue, 29 Jul 2025 at 06:57, Peter Smith wrote:
>> Here are the latest v15 patches.
>>
>> Changes include:
>>
>> PATCH 0002.
>> - README now says user should not tamper with VCI internal relations
>> -
On Tue, 29 Jul 2025 at 06:57, Peter Smith wrote:
> Here are the latest v15 patches.
>
> Changes include:
>
> PATCH 0002.
> - README now says user should not tamper with VCI internal relations
> - fixes/test the VACUUM bug -- fix provided by Japin [1]
> - fixes/tes
On Wed, 30 Jul 2025 at 14:49, Peter Smith wrote:
> On Fri, Jul 25, 2025 at 1:58 PM Japin Li wrote:
>>
>> On Wed, 23 Jul 2025 at 14:07, Peter Smith wrote:
>> > On Tue, Jul 22, 2025 at 8:12 PM Japin Li wrote:
>> > ...
> ...
>> >>
>> &
On Wed, 23 Jul 2025 at 14:07, Peter Smith wrote:
> On Tue, Jul 22, 2025 at 8:12 PM Japin Li wrote:
> ...
>> 1.
>> I encountered another crash while checking VCI's internal relations.
>>
>> rm -rf demo
>> initdb -D demo
>> cat <demo/postg
On Tue, 22 Jul 2025 at 14:36, Michael Paquier wrote:
> On Thu, Jul 17, 2025 at 01:34:42PM +0800, Japin Li wrote:
>> On Wed, 16 Jul 2025 at 10:08, Peter Smith wrote:
>>> What's going on there? Is it just an accidentally missing "/* can be
>>> NULL
Hi, Peter
On Tue, 22 Jul 2025 at 17:46, Peter Smith wrote:
> Hi.
>
> Here are the latest v14 patches.
>
> Changes include:
>
> PATCH 0002.
> - Fixes the enable_seqscan PANIC bug reported by Japin [1]
> - Adds a new regression test case for this
>
> ==
&g
On Wed, 23 Jul 2025 at 09:24, Fujii Masao wrote:
> On Mon, Jul 21, 2025 at 2:38 PM Japin Li wrote:
>>
>>
>> Hi, hackers,
>>
>> I was recently reviewing the KeepFileRestoredFromArchive() function and came
>> across a section that raised a question for me:
&
On Tue, 22 Jul 2025 at 17:46, Peter Smith wrote:
> Hi.
>
> Here are the latest v14 patches.
>
> Changes include:
>
> PATCH 0002.
> - Fixes the enable_seqscan PANIC bug reported by Japin [1]
> - Adds a new regression test case for this
>
> ==
> [1]
>
understand correctly, signals the archiver to re-archive this
already-archived WAL segment.
Is there a specific scenario or benefit I'm overlooking?
--
Regards,
Japin Li
lso in the documentation... [2]
>
> ==
> [1]
> https://github.com/postgres/postgres/blob/master/src/include/access/amapi.h
> [2] https://www.postgresql.org/docs/devel/index-api.html
>
How about asserting the existence of all required callbacks, similar to
GetTableAmRoutine()?
--
Regards,
Japin Li
On Tue, 15 Jul 2025 at 11:24, Alexander Kukushkin wrote:
> Hi,
>
> On Mon, 14 Jul 2025 at 11:24, Japin Li wrote:
>
> The configuration is as expected. My test script simulates two distinct hosts
> by utilizing local archive storage.
>
> For physical replication acros
On Mon, 14 Jul 2025 at 20:33, Fujii Masao wrote:
> On 2025/07/14 17:08, Japin Li wrote:
>> Hi all,
>> I recently hit an error with our streaming replication setup:
>>2025-07-14 11:52:59.361
>> CST,"replicator","",728458,"10.9.9.74:35724&qu
On Mon, 14 Jul 2025 at 18:47, Peter Smith wrote:
> Hi Japin,
>
> Thanks for your README questions.
>
> On Fri, Jul 11, 2025 at 7:18 PM Japin Li wrote:
> ...
>>
>> 3.
>> In the README, 'TID' seems to have conflicting definitions:
>> Trans
On Mon, 14 Jul 2025 at 10:21, Alexander Kukushkin wrote:
> On Mon, 14 Jul 2025 at 10:08, Japin Li wrote:
>
> Hi all,
>
> I recently hit an error with our streaming replication setup:
>
>2025-07-14 11:52:59.361
>
> CST,"replicator","&
the archive if
restore_command is set?
I found that Fujii Masao also requested this feature [1], but it seems there
wasn't a consensus.
I've attached a script to reproduce this issue.
[1]
https://www.postgresql.org/message-id/AANLkTinN%3DxsPOoaXzVFSp1OkfMDAB1f_d-F91xjEZDV8%40mail.gmail.co
ason
> to avoid enabling this optimization more broadly across plan nodes.
>
> I'll post the PoC patches and performance measurements. Posting this
> in advance to get feedback on the proposed direction and where best to
> place attr_used.
>
That's interesting. If I understand correctly, this approach wouldn't work if
the first attribute is variable-length, right?
--
Regards,
Japin Li
On Fri, 11 Jul 2025 at 16:31, Peter Smith wrote:
> Hi. Here is the latest patch set v12*
>
> Main differences are:
>
> Patch 0001 (core)
> - removed SizeOfIptrData macro, as reported by Tomas [1] and Japin [2]
>
> Patch 0002 (vci module)
> - Made fixes so the "ROS
On Thu, 10 Jul 2025 at 17:51, Peter Smith wrote:
> On Thu, Jul 10, 2025 at 4:07 PM Japin Li wrote:
> ...
>> I'm still trying to understand the patches.
>>
>> diff --git a/src/include/storage/itemptr.h b/src/include/storage/itemptr.h
>> index 74b87a9..d97d1c5
On Tue, 08 Jul 2025 at 10:11, Peter Smith wrote:
> Hi. Here is the latest patch set.
>
> Main differences are:
>
> Patch 0001 (core)
> - removed embedded vci code from autovacuum.c / postinit.c (now these
> are same as master)
>
> Patch 0002 (vci module)
> - a few changes to facilitate the fix to
On Mon, 07 Jul 2025 at 14:18, Álvaro Herrera wrote:
> On 2025-Jul-05, Masahiko Sawada wrote:
>
>> On Fri, Jul 4, 2025 at 8:01 PM Álvaro Herrera wrote:
>> >
>> > On 2025-Jul-04, Japin Li wrote:
>> >
>> > > I've opted to directly use %
On Mon, 07 Jul 2025 at 19:34, Ashutosh Bapat
wrote:
> On Fri, Jul 4, 2025 at 5:18 PM Álvaro Herrera wrote:
>>
>> On 2025-Jul-04, Japin Li wrote:
>>
>> > I've opted to directly use %X/%08X for LSN formatting in this patch, with
>> > an
>> > a
imur suggests that this also unused code anyway. Investigating...)
>>
>
> Fixed (removed) in v10.
>
Hi, Perter
When trying vic, I received the following error:
TRAP: failed Assert("TransactionIdIsNormal(xmax)"), File:
"/data/Codes/pg/master/build/../src/backend/acc
On Thu, 03 Jul 2025 at 12:59, John H wrote:
> Hi,
>
> On Wed, Jul 2, 2025 at 6:40 PM Japin Li wrote:
>>
>> >
>>
>> Splitting the logs from $PGDATA is definitely better. The question is whether
>> it's worth implementing this directly in core or if
and add the description to the
LSN_FORMAT_ARGS macro.
> The GNU gettext manual suggests you can print the value to a string
> variable and then use %s to include that in the translatable string, but
> I doubt that's an improvement over just using %X/%08X directly.
> Bottom of this page here:
> https://www.gnu.org/software/gettext/manual/html_node/No-string-concatenation.html
>
Yes, I don't consider that an improvement.
--
Regards,
Japin Li
On Wed, 02 Jul 2025 at 09:57, Peter Eisentraut wrote:
> On 01.05.25 15:47, Japin Li wrote:
>> On Thu, 01 May 2025 at 12:13, Peter Eisentraut wrote:
>>> On 30.04.25 17:48, Japin Li wrote:
>>>> While working on [1], I found outdated comments in IndexInfo.
>>
gt; off as well. I'd also think you would want to avoid putting the logs
> in $PGDATA to have smaller backups if you are using tools like
> pg_basebackup.
>
Splitting the logs from $PGDATA is definitely better. The question is whether
it's worth implementing this directly in cor
tion for handling file content types?
2.
Perhaps decide_wal_file_action() could be defined in filemap.c.
While this is unrelated to WAL logging, it could also contribute to faster
pg_rewind operations. Should we consider ignoring log files under PGDATA
(e.g., those in the default log/ directory)?
--
Regards,
Japin Li
On Tue, 01 Jul 2025 at 13:39, Álvaro Herrera wrote:
> On 2025-Jul-01, Japin Li wrote:
>
>> This inconsistency, while minor, could be confusing when cross-referencing
>> LSNs within pg_waldump's own output or when parsing it programmatically.
>
> I agree that we should
t;rmgr: %-11s len (rec/tot):
%6u/%6u, tx: %10u, lsn: %X/%08X, prev %X/%08X, ",
This inconsistency, while minor, could be confusing when cross-referencing
LSNs within pg_waldump's own output or when parsing it programmatically.
--
Regards,
Japin Li
>From b38d020375481ae54aaf745bee58
Hi, hackers
I've run into a build issue when trying to use pg_probackup with PostgreSQL
18beta1. After some adjustments to pg_probackup, I encountered the following
linker errors:
/usr/bin/ld: src/pg_crc.o: in function `crc32_bytea':
/home/japin/Codes/extensions/pg_probackup/src/pg
On Tue, 03 Jun 2025 at 13:27, Michael Paquier wrote:
> On Tue, Jun 03, 2025 at 12:16:21PM +0800, Japin Li wrote:
>> I've replaced the hardcoded arithmetic expression for calculating TotalProcs
>> within the pgaio_uring_shmem_init() with a call to the dedicated
>> pg
be updated in one place.
--
Regards,
Japin Li
>From c3477213ff64788d32430361a8298c8f8a958238 Mon Sep 17 00:00:00 2001
From: Japin Li
Date: Tue, 3 Jun 2025 12:07:04 +0800
Subject: [PATCH v1] Encapsulate io_uring process count calculation
Replace the direct arithmetic expression for TotalProc
Hi, Peter and Richard
On Thu, 01 May 2025 at 12:13, Peter Eisentraut wrote:
> On 30.04.25 17:48, Japin Li wrote:
>> While working on [1], I found outdated comments in IndexInfo.
>> The attached patch corrects them.
>> [1]
>> https://www.postgresql.org/message
Hi, all
While working on [1], I found outdated comments in IndexInfo.
The attached patch corrects them.
[1]
https://www.postgresql.org/message-id/2A40921D-83AB-411E-ADA6-7E509A46F1E4%40logansw.com
--
Regrads,
Japin Li
>From 7c01644860a32ca9ab93367c2f8e34047c9d703f Mon Sep 17 00:00:00 2
> meta-command will be
> very useful when there are indexes that are the same except for the
> name (and do
> not enforce constraints?). This will at least help DBAs quickly spot
> such indexes in
> their tables.
>
I agree that psql annotations are helpful, but to accommodate users who don't
use it, should we also consider adding a view?
--
Regrads,
Japin Li
and fallback_application_name?
Additionally, if a SET application_name TO xxx command is issued during
a subsequent connection, will the appname field within the PGconn structure
be updated promptly?
--
Regrads,
Japin Li
Hi, Greg and David
Thank you for your feedback.
On Thu, 24 Apr 2025 at 08:26, Greg Sabino Mullane wrote:
> On Thu, Apr 24, 2025 at 7:31 AM David Rowley wrote:
>
> On Thu, 24 Apr 2025 at 21:27, Japin Li wrote:
> > I propose that PostgreSQL prevent redundant index creation
nance
- Enhance efficiency and user flexibility
I’d love to hear your feedback or suggestions for improvement.
[1] https://docs.oracle.com/en/error-help/db/ora-01408/?r=19c
--
Regrads,
Japin Li
sizeof(qbuf), "set client_encoding to
> '%s'", encoding);
> + if (len >= sizeof(qbuf))
> return -1;
>
> /* ok, now send a query */
> - sprintf(qbuf, query, encoding);
> res = PQexec(conn, qbuf);
>
> if (res == NULL)
>
Thank you for all the explanations! The above code looks good to me, except
for a minor issue; since snprintf may return a negative value, should we
check for this?
--
Regrads,
Japin Li
;%s'";
PGresult *res;
int status;
--
Regrads,
Japin Li
omm.c
+++ b/src/backend/libpq/pqcomm.c
@@ -53,9 +53,6 @@
*/
#include "postgres.h"
-#ifdef HAVE_POLL_H
-#include
-#endif
#include
#include
#include
--
Regrads,
Japin Li
ils even for
successes\n"
" -q, --quiet only show failures\n"
- " --force-unsupported test invalid input even if
unsupported\n"
+ " -f, --force-unsupported test invalid input even if
unsupported\n"
);
if (hint)
--
Regrads,
Japin Li
NOT NULL "c"
> Access method: heap
>
> postgres=#
>
> I think this test case does not fully reflect the original meaning. So I made
> a small change to this and look forward to
> your feedback. Thanks!
>
Yeah, the primary key of t3 is deferred, so only the t3_c_uidx can be used.
The test case is inconsistent with comments.
It seems that the t2 does not have a unique index on z, do you forget to
create it in the patch?
--
Regrads,
Japin Li
ng_options,
&option_index)) != -1)
+ while ((c = getopt_long(argc, argv, "c:vqh", long_options,
&option_index)) != -1)
{
switch (c)
{
--
Regrads,
Japin Li
On Mon, 17 Feb 2025 at 15:45, Daniel Gustafsson wrote:
>> On 17 Feb 2025, at 15:39, Japin Li wrote:
>
>> When I read the ListenServerPort(), I noticed two incorrect translator
>> implementations: 1) the translator for setsockopt(SO_REUSEADDR), which
>> should not be &q
ot;,
familyDesc,
addrDesc)));
--
Regrads,
Japin Li
On Mon, 10 Feb 2025 at 22:12, "Zhou, Zhiguo" wrote:
> On 2/5/2025 4:32 PM, Japin Li wrote:
>> On Mon, 27 Jan 2025 at 17:30, "Zhou, Zhiguo" wrote:
>>> On 1/26/2025 10:59 PM, Yura Sokolov wrote:
>>>> 24.01.2025 12:07, Japin Li пишет:
>>>
y peeked, so the error should
never
+* Eat the ":=" and "=>". We already peeked, so the
error should never
* happen.
*/
tok2 = yylex(yylvalp, yyllocp, yyscanner);
--
Regrads,
Japin Li
On Fri, 07 Feb 2025 at 10:31, Alvaro Herrera wrote:
> On 2025-Feb-07, Japin Li wrote:
>
>> Since there is no standard, how do we handle this? I prefer to use
>> the strict mode like passlib.
>
> I definitely like that passlib have documented their thought process
> th
s
> should be viewed as an absolute minimum).
>
> This "Password Hashing Competition" organization hardly seems an
> authority though. It'd be great to have an IETF standard about this ...
Yeah.
Since there is no standard, how do we handle this? I prefer to use the strict
mode like passlib.
--
Regrads,
Japin Li
file or on the server command line;
but the setting can be overridden for individual tables by
--
Regrads,
Japin Li
t" modifiers at use sites, too.)
>
> Good point, from the link referenced it's clear that FreeBSD has made that
> change as well. I'll fix that at the same time.
>
Oh, I didn't notice this. +1.
--
Regrads,
Japin Li
[2] https://reviews.freebsd.org/D7306
--
Regrads,
Japin Li
On Mon, 27 Jan 2025 at 17:30, "Zhou, Zhiguo" wrote:
> On 1/26/2025 10:59 PM, Yura Sokolov wrote:
>> 24.01.2025 12:07, Japin Li пишет:
>>> On Thu, 23 Jan 2025 at 21:44, Japin Li wrote:
>>>> On Thu, 23 Jan 2025 at 15:03, Yura Sokolov
>>>> wrot
ad security and should be rejected. If we did so in the past
> without noticing, that's bad already, but we should not replicate that
> behavior any further.
>
I agree with this point, so maybe we should fix this for px_crypt_md().
--
Regrads,
Japin Li
On Thu, 23 Jan 2025 at 21:44, Japin Li wrote:
> On Thu, 23 Jan 2025 at 15:03, Yura Sokolov wrote:
>> 23.01.2025 11:46, Japin Li пишет:
>>> On Wed, 22 Jan 2025 at 22:44, Japin Li wrote:
>>>> On Wed, 22 Jan 2025 at 17:02, Yura Sokolov
>>>> wrote:
>&g
l branch and stop patching, run "git am --abort".
I see the patch compresses the WAL record according to the wal_compression,
IIRC the wal_compression is only used for FPI, right? Maybe we should update
the description of this parameter.
I see that the wal_compression_threshold defaults to 512. I wonder if you
chose this value based on testing or randomly.
--
Regrads,
Japin Li
On Thu, 23 Jan 2025 at 15:50, Yura Sokolov wrote:
> 23.01.2025 08:41, wenhui qiu wrote:
>> HI Japin
>> Thank you for you test ,It seems NUM_XLOGINSERT_LOCKS 64
>> is great , I think it doesn't need to grow much,What do you think?
>
> I agree: while 128 shows
On Thu, 23 Jan 2025 at 15:03, Yura Sokolov wrote:
> 23.01.2025 11:46, Japin Li пишет:
>> On Wed, 22 Jan 2025 at 22:44, Japin Li wrote:
>>> On Wed, 22 Jan 2025 at 17:02, Yura Sokolov wrote:
>>>> I believe, I know why it happens: I was in hurry making v2 by
>>&
g the `l` suffix, since both PX_SHACRYPT_ROUNDS_MIN and
PX_SHACRYPT_ROUNDS_MAX have this suffix.
5.
Does the following work as expected?
postgres=# select crypt('hello', '$5$$6$rounds=1$/Zg436s2vmTwsoSz');
crypt
-
$5$$TCRu/ts4Npu8OJyeWy2WnUHCe/6bKVMSi0sROUrPh48
(1 row)
postgres=# select crypt('hello', '$5$rounds=1$/Zg436s2vmTwsoSz');
crypt
--
$5$rounds=1$/Zg436s2vmTwsoSz$N4Ad0oGzE6ak30z4EGSEXOc2OXQOpmauicPT3560lY2
(1 row)
According to the documentation, I think the first should output as following:
$5$rounds=5000$TCRu/ts4Npu8OJyeWy2WnUHCe/6bKVMSi0sROUrPh48
--
Regrads,
Japin Li
On Wed, 22 Jan 2025 at 22:44, Japin Li wrote:
> On Wed, 22 Jan 2025 at 17:02, Yura Sokolov wrote:
>> I believe, I know why it happens: I was in hurry making v2 by
>> cherry-picking internal version. I reverted some changes in
>> CalcCuckooPositions manually and
tested the patch on Hygon C86 7490 64-core using benchmarksql 5.0 with
500 warehouses and 256 terminals run time 10 mins:
| case | min | avg | max |
|+--+--+--|
| master (4108440) | 891,225.77 | 904,868.75 | 913,708.17 |
| lock 64| 1,007,716.95 | 1,012,013.22 | 1,018,674.00 |
| lock 64 attempt 1 | 1,016,716.07 | 1,017,735.55 | 1,019,328.36 |
| lock 64 attempt 2 | 1,015,328.31 | 1,018,147.74 | 1,021,513.14 |
| lock 128 | 1,010,147.38 | 1,014,128.11 | 1,018,672.01 |
| lock 128 attempt 1 | 1,018,154.79 | 1,023,348.35 | 1,031,365.42 |
| lock 128 attempt 2 | 1,013,245.56 | 1,018,984.78 | 1,023,696.00 |
I didn't NUM_XLOGINSERT_LOCKS with 16 and 32, however, I tested it with 256,
and got the following error:
2025-01-23 02:23:23.828 CST [333524] PANIC: too many LWLocks taken
I hope this test will be helpful.
--
Regrads,
Japin Li
tegies + "8 positions in two cache-lines" strategy.
>
> You may play with switching PREV_LINKS_HASH_STRATEGY to 2 or 3 and see
> if it affects measurably.
Thanks for your quick fixing. I will retest it tomorrow.
--
Regrads,
Japin Li
On Wed, 22 Jan 2025 at 16:49, Japin Li wrote:
> On Wed, 22 Jan 2025 at 11:22, Yura Sokolov wrote:
>> 22.01.2025 10:54, Japin Li пишет:
>>> On Wed, 22 Jan 2025 at 10:25, Yura Sokolov wrote:
>>>> 22.01.2025 09:09, Japin Li пишет:
>>>>> Hi, Yura Sokolov
On Wed, 22 Jan 2025 at 11:22, Yura Sokolov wrote:
> 22.01.2025 10:54, Japin Li пишет:
>> On Wed, 22 Jan 2025 at 10:25, Yura Sokolov wrote:
>>> 22.01.2025 09:09, Japin Li пишет:
>>>> Hi, Yura Sokolov
>>>> Thanks for updating the patch.
>>>>
On Wed, 22 Jan 2025 at 10:25, Yura Sokolov wrote:
> 22.01.2025 09:09, Japin Li пишет:
>> Hi, Yura Sokolov
>> Thanks for updating the patch.
>> I test the v2 patch using BenchmarkSQL 1000 warehouse, and here is the tpmC
>> result:
>> case
/patch:37: space before tab in indent.
{
.git/rebase-apply/patch:38: space before tab in indent.
int i;
.git/rebase-apply/patch:39: trailing whitespace.
.git/rebase-apply/patch:46: space before tab in indent.
LWLockReleaseClearVar(&WALInsertLocks[i].l.lock,
warning: squelched 4 whitespace errors
warning: 9 lines add whitespace errors.
2.
And there is a typo:
+ * PrevLinksHash is a lock-free hash table based on Cuckoo algorith. It is
+ * mostly 4 way: for every element computed two positions h1, h2, and
s/algorith/algorithm/g
--
Regrads,
Japin Li
--with-lz4 \
--with-pam \
CFLAGS='-Wmissing-prototypes -Wincompatible-pointer-types'
make -j $(nproc) -s && make install -s
(cd contrib/ && make -j $(nproc) -s && make install -s)
make check-
On Fri, 03 Jan 2025 at 17:55, Bernd Helmle wrote:
> Am Freitag, dem 03.01.2025 um 23:57 +0800 schrieb Japin Li:
>>
>> Greate! I have some questions after using it.
>>
>> When I use the following query, it crashed!
>>
>> [local]:4012204 postgres=# selec
6s2vmTwsoSz');
Maybe we should add CHECK_FOR_INTERRUPTS() in step 21.
@@ -411,6 +411,7 @@ px_crypt_shacrypt(const char *pw, const char *salt, char
*passwd, unsigned dstle
*uses the notation "digest A/B" to describe this behavior.
*/
for (block = 0; block < rounds; block++) {
+CHECK_FOR_INTERRUPTS();
/* a) start digest B */
px_md_reset(digestB);
--
Regrads,
Japin Li
Hi, hackers
When I read the PL/pgSQL source code, I found that plpgsql_yyparse() is defined
in pl_gram.y, however, the comment says it is defined in gram.y.
PFA.
--
Regrads,
Japin Li
>From 9629535310eef217f195fc3526d8227b9f6ab29c Mon Sep 17 00:00:00 2001
From: Japin Li
Date: Mon, 30
Hi, hackers
When I reading the implementation of CreateFunction(), I found there is a typo
in comment of compute_return_type().
--
Regrads,
Japin Li
>From 3a1008c692a919d55a456a7fa34e07d9c93879dd Mon Sep 17 00:00:00 2001
From: Li Jianping
Date: Wed, 25 Dec 2024 14:39:15 +0800
Subject: [PA
e the original branch and stop patching, run "git am --abort".
The comment of prev_check_password_hook has been changed which case the apply
failed.
--
Regrads,
Japin Li
On Wed, 27 Nov 2024 at 15:51, wenhui qiu wrote:
> HI Japin Li
> Thank you for you reply, Do you think that removing the log2 algorithm
> because it will be more frequent,I think sql
> server chose sqrt algorithm after their long-term verification, I think we
> need to retain
rgey Prokhorenko just draw my attention to the new release of MariaDB
>> >> [0]. They are doing very similar UUID v7 generation as we do [1].
>> >>
>> >
>> > Thank you for the references. It made me think that we can use the
>> > function name uuid_v7() rather than uuidv7().
>>
>> I think it's a good idea if we will be kind of SQL-compatible.
>>
>
> Okay, let"s rename it.
>
> I've merged patches and renamed functions (also updated the commit
> message). Please find the attachment.
>
It seems a typo about uuid_v{4,7}.
+uuidv_4 () uuid
+
+ These functions return a version 4 (random) UUID.
+
+uuidv_7 () uuid
--
Regrads,
Japin Li
we need so many autovacuum algorithms here since it makes
the choice harder (maybe).
--
Regrads,
Japin Li
le overflow?
+ const char *end = &p[len];
How about use MAXALIGN64 macro here?
When handling the aligned, is it possible to handle multiple values
(such as 4 or 8) in one iteration?
It might be faster. However, I'm not tested.
--
Regrads,
Japin Li
ray() functions.
.git/rebase-apply/patch:475: trailing whitespace.
rand_array
warning: 1 line adds whitespace errors.
The other looks good to me.
--
Regrads,
Japin Li
147_483_648"
postgres=# alter system set autovacuum_vacuum_threshold to 2_147_483_647;
ALTER SYSTEM
```
IIRC, the lexer only supports integers but not int64.
--
Best regards,
Japin Li
es the delay.
context | user
vartype | int64
source | default
min_val | 0
max_val | 9223372036854775807
enumvals|
boot_val| 0
reset_val | 0
sourcefile |
sourceline |
pending_restart | f
```
[1] https://www.postgresql.org/docs/current/datatype-numeric.html
--
Regrads,
Japin Li
On Wed, 28 Aug 2024 at 12:27, Andy Fan wrote:
> Japin Li writes:
>
>
>> Thanks for updating the patch. Here are some comments.
>>
>> +if (minlen >= maxlen)
>> +ereport(ERROR,
>> +
; 0)
+ ereport(ERROR,
+ (errcode(ERRCODE_INVALID_PARAMETER_VALUE),
+ errmsg("minlen and maxlen must be greater than
zero.")));
Here the minlen might be zero, so the error message is incorrect.
How about use "minlen must be greater than or equal to zero"?
--
Regrads,
Japin Li
1 - 100 of 535 matches
Mail list logo
