Re: Synchronizing slots from primary to standby

Hi, On Thu, Jan 25, 2024 at 02:57:30AM +, Zhijie Hou (Fujitsu) wrote: > On Wednesday, January 24, 2024 6:31 PM Amit Kapila > wrote: > > > > On Tue, Jan 23, 2024 at 5:13 PM shveta malik wrote: > > > > > > Thanks Ajin for testing the patch. PFA v66 which fixes this issue. > > > > > > > I

Re: Add system identifier to backup manifest

On Wed, Jan 24, 2024 at 10:53 PM Robert Haas wrote: > On Mon, Jan 22, 2024 at 2:22 AM Amul Sul wrote: > > Thinking a bit more on this, I realized parse_manifest_file() has many > out > > parameters. Instead parse_manifest_file() should simply return manifest > data > > like

Re: A compiling warning in jsonb_populate_record_valid

On Thu, Jan 25, 2024 at 2:28 PM Amit Langote wrote: > On Thu, Jan 25, 2024 at 2:59 PM Richard Guo > wrote: > > I came across a warning when building master (a044e61f1b) on old GCC > > (4.8.5). > > > > jsonfuncs.c: In function ‘jsonb_populate_record_valid’: > >

Re: the s_lock_stuck on perform_spin_delay

Andres Freund writes: > On 2024-01-18 14:00:58 -0500, Robert Haas wrote: >> > The LockBufHdr also used init_local_spin_delay / perform_spin_delay >> > infrastruce and then it has the same issue like ${subject}, it is pretty >> > like the code in s_lock; Based on my current knowledge, I think

Re: the s_lock_stuck on perform_spin_delay

Hi, > Hi, > > On 2024-01-22 15:18:35 +0800, Andy Fan wrote: >> I used sigismember(, SIGQUIT) to detect if a process is doing a >> quickdie, however this is bad not only because it doesn't work on >> Windows, but also it has too poor performance even it impacts on >> USE_ASSERT_CHECKING build

Re: Trivial revise for the check of parameterized partial paths

On Sun, Jan 21, 2024 at 8:36 PM vignesh C wrote: > I'm seeing that there has been no activity in this thread for nearly 7 > months, I'm planning to close this in the current commitfest unless > someone is planning to take it forward. This patch fixes the wrong comments in

Re: UUID v7

> On 25 Jan 2024, at 09:40, Nikolay Samokhvalov wrote: > > From a practical point of view, these two things are extremely important to > have to support partitioning. It is better to implement limitations than > throw them away. Postgres always was a bit hackerish, allowing slightly more

Re: make dist using git archive

On 24.01.24 18:57, Tristan Partin wrote: > 4. Meson uses git archive internally, but then unpacks and repacks the > archive, which loses the ability to use git get-tar-commit-id. Because Meson allows projects to distribute arbitrary files via meson.add_dist_script(), and can include

Re: SQL:2011 application time

On 24.01.24 23:06, Paul Jungwirth wrote: On 1/24/24 08:32, Peter Eisentraut wrote: > On 18.01.24 04:59, Paul Jungwirth wrote: >> Here are new patches consolidating feedback from several emails. > > I have committed 0001 and 0002 (the primary key support). Thanks Peter! I noticed the comment

Re: A compiling warning in jsonb_populate_record_valid

Hi, On Thu, Jan 25, 2024 at 2:59 PM Richard Guo wrote: > > I came across a warning when building master (a044e61f1b) on old GCC > (4.8.5). > > jsonfuncs.c: In function ‘jsonb_populate_record_valid’: > ../../../../src/include/nodes/miscnodes.h:53:15: warning: the comparison will > always

Re: Synchronizing slots from primary to standby

On Thu, Jan 25, 2024 at 9:13 AM Amit Kapila wrote: > > > 3) Removed syncing 'failover' on standby from remote_slot. The > > 'failover' field will be false for synced slots. Since we do not > > support sync to cascading standbys yet, thus failover=true was > > misleading and unused there. > > > >

A compiling warning in jsonb_populate_record_valid

I came across a warning when building master (a044e61f1b) on old GCC (4.8.5). jsonfuncs.c: In function ‘jsonb_populate_record_valid’: ../../../../src/include/nodes/miscnodes.h:53:15: warning: the comparison will always evaluate as ‘true’ for the address of ‘escontext’ will never be NULL

Re: Add tuples_skipped to pg_stat_progress_copy

On Thu, Jan 25, 2024 at 11:25 AM torikoshia wrote: > > On 2024-01-24 17:05, Masahiko Sawada wrote: > > On Tue, Jan 23, 2024 at 1:02 AM torikoshia > > wrote: > >> > >> On 2024-01-17 14:47, Masahiko Sawada wrote: > >> > On Wed, Jan 17, 2024 at 2:22 PM torikoshia > >> > wrote: > >> >> > >> >> Hi,

Re: Synchronizing slots from primary to standby

Hi, On Wed, Jan 24, 2024 at 04:09:15PM +0530, shveta malik wrote: > On Wed, Jan 24, 2024 at 2:38 PM Bertrand Drouvot > wrote: > > > > I also see Sawada-San's point and I'd vote for "sync_replication_slots". > > Then for > > the current feature I think "failover" and "on" should be the values to

RE: speed up a logical replica setup

Dear hackers, Based on the requirement, I have profiled the performance test. It showed bottlenecks are in small-data case are mainly two - starting a server and waiting until the recovery is done. # Tested source code V7 patch set was applied atop HEAD(0eb23285). No configure options were

Re: Remove pthread_is_threaded_np() checks in postmaster

On Wed, Jan 24, 2024 at 1:39 PM Andres Freund wrote: > On 2024-01-23 17:26:19 -0600, Tristan Partin wrote: > > On Tue Jan 23, 2024 at 4:23 PM CST, Andres Freund wrote: > > > A fork() while threads are running is undefined behavior IIRC, and > > > undefined > > > behavior isn't limited to a

Re: Make COPY format extendable: Extract COPY TO format implementations

On Thu, Jan 25, 2024 at 1:53 PM Michael Paquier wrote: > > On Thu, Jan 25, 2024 at 01:36:03PM +0900, Masahiko Sawada wrote: > > Hmm I can see a similar trend that Suto-san had; the binary format got > > slightly faster whereas both text and csv format has small regression > > (4%~5%). I think

Re: Synchronizing slots from primary to standby

Here are some review comments for v67-0002. == src/backend/replication/logical/slotsync.c 1. +/* The sleep time (ms) between slot-sync cycles varies dynamically + * (within a MIN/MAX range) according to slot activity. See + * wait_for_slot_activity() for details. + */ +#define

Re: Make COPY format extendable: Extract COPY TO format implementations

On Thu, Jan 25, 2024 at 01:36:03PM +0900, Masahiko Sawada wrote: > Hmm I can see a similar trend that Suto-san had; the binary format got > slightly faster whereas both text and csv format has small regression > (4%~5%). I think that the improvement for binary came from the fact > that we removed

Re: UUID v7

On Wed, Jan 24, 2024 at 8:40 PM Nikolay Samokhvalov wrote: > On Wed, Jan 24, 2024 at 1:52 PM Sergey Prokhorenko < > sergeyprokhore...@yahoo.com.au> wrote: > >> That's right! There is no point in waiting for the official approval of >> the new RFC, which obviously will not change anything. I have

Re: UUID v7

On Wed, Jan 24, 2024 at 1:52 PM Sergey Prokhorenko < sergeyprokhore...@yahoo.com.au> wrote: > That's right! There is no point in waiting for the official approval of > the new RFC, which obviously will not change anything. I have been a > contributor to this RFC >

Re: Make COPY format extendable: Extract COPY TO format implementations

On Wed, Jan 24, 2024 at 11:17 PM Sutou Kouhei wrote: > > Hi, > > In <10025bac-158c-ffe7-fbec-32b426291...@dunslane.net> > "Re: Make COPY format extendable: Extract COPY TO format implementations" > on Wed, 24 Jan 2024 07:15:55 -0500, > Andrew Dunstan wrote: > > > > > On 2024-01-24 We 03:11,

RE: Synchronizing slots from primary to standby

On Wednesday, January 24, 2024 1:11 PM Masahiko Sawada wrote: > Here are random comments on slotsyncworker.c (v66): Thanks for the comments: > > --- > + elog(ERROR, > +"cannot synchronize local slot \"%s\" LSN(%X/%X)" > +" to remote slot's

Re: Remove redundant HandleWalWriterInterrupts()

On Thu, Jan 25, 2024 at 4:40 AM Nathan Bossart wrote: > > On Wed, Jan 24, 2024 at 07:30:17PM +0530, Bharath Rupireddy wrote: > > On Wed, Jan 24, 2024 at 5:50 PM Fujii Masao wrote: > >> Because of commit 1bdd54e662, the code of HandleWalWriterInterrupts() > >> became the same as

Re: Guiding principle for dropping LLVM versions?

Thanks all for the discussion. Pushed. A few build farm animals will now fail in the configure step as discussed, and need some adjustment (ie disable LLVM or upgrade to LLVM 10+ for the master branch). Next year I think we should be able to do a much bigger cleanup, by moving to LLVM 14+.

Re: Synchronizing slots from primary to standby

On Wed, Jan 24, 2024 at 5:17 PM shveta malik wrote: > > PFA v67. Note that the GUC (enable_syncslot) name is unchanged. Once > we have final agreement on the name, we can make the change in the > next version. > > Changes in v67 are: > > 1) Addressed comments by Peter given in [1]. > 2) Addressed

Re: dblink query interruptibility

On Thu, Jan 25, 2024 at 5:45 AM Noah Misch wrote: > > On Thu, Jan 25, 2024 at 04:23:39AM +0900, Fujii Masao wrote: > > I found that this patch was committed at d3c5f37dd5 and changed the > > error message in postgres_fdw slightly. Here's an example: > > > > #1. Begin a new transaction. > > #2.

Re: Make COPY format extendable: Extract COPY TO format implementations

On Thu, Jan 25, 2024 at 10:53:58AM +0800, jian he wrote: > apply your patch: > COPY data TO '/dev/null' WITH (FORMAT csv) \watch count=5 > Time: 668.996 ms > Time: 596.254 ms > Time: 592.723 ms > Time: 591.663 ms > Time: 590.803 ms > > not apply your patch, at git

Re: Make COPY format extendable: Extract COPY TO format implementations

On Wed, Jan 24, 2024 at 11:17:26PM +0900, Sutou Kouhei wrote: > In <10025bac-158c-ffe7-fbec-32b426291...@dunslane.net> > "Re: Make COPY format extendable: Extract COPY TO format implementations" > on Wed, 24 Jan 2024 07:15:55 -0500, > Andrew Dunstan wrote: >> We've spent quite a lot of blood

Re: Make COPY format extendable: Extract COPY TO format implementations

On Wed, Jan 24, 2024 at 10:17 PM Sutou Kouhei wrote: > > I uploaded my benchmark script so that you can run the same > benchmark on your machine: > > https://gist.github.com/kou/be02e02e5072c91969469dbf137b5de5 > > Could anyone try the benchmark with master and master+0001? > sorry. I made a

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Wed, Jan 24, 2024 at 9:13 PM Melanie Plageman wrote: > I didn't incorporate it because I wasn't sure I understood the > situation. I can imagine us skipping updating the FSM after > lazy_scan_prune() because there are indexes on the relation and dead > items on the page and we think we'll do a

Re: Add tuples_skipped to pg_stat_progress_copy

On 2024-01-24 17:05, Masahiko Sawada wrote: On Tue, Jan 23, 2024 at 1:02 AM torikoshia wrote: On 2024-01-17 14:47, Masahiko Sawada wrote: > On Wed, Jan 17, 2024 at 2:22 PM torikoshia > wrote: >> >> Hi, >> >> 132de9968840c introduced SAVE_ERROR_TO option to COPY and enabled to >> skip

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Wed, Jan 24, 2024 at 4:34 PM Melanie Plageman wrote: > > On Wed, Jan 24, 2024 at 2:59 PM Robert Haas wrote: ... > > If you'd like, I can try rewriting these comments to my satisfaction > > and you can reverse-review the result. Or you can rewrite them and > > I'll re-review the result. But I

Re: Synchronizing slots from primary to standby

Here are some review comments for the patch v67-0001. == 1. There are a couple of places checking for failover usage on a standby. + if (RecoveryInProgress() && failover) + ereport(ERROR, + errcode(ERRCODE_FEATURE_NOT_SUPPORTED), + errmsg("cannot enable failover for a replication slot" +

Re: LLVM 18

On Wed, Jan 3, 2024 at 6:04 PM Thomas Munro wrote: > LLVM 16 provided a new function name[1], and LLVM 18 (not shipped yet) > has started complaining[2] about the old spelling. > > Here's a patch. And pushed. Just in case anyone else is confused by this, be aware that they've changed their

Re: Sequence Access Methods, round two

On Tue, Jan 23, 2024 at 10:58:50AM +0100, Peter Eisentraut wrote: > On 18.01.24 16:54, Matthias van de Meent wrote: > The proposed sequence AM patch would support a different nextval function, > but does it support additional parameters? I haven't found that. Yes and no. Yes as in "the patch

Re: Documentation to upgrade logical replication cluster

Here are some review comments for patch v3. == doc/src/sgml/ref/pgupgrade.sgml 1. + + + This page does not cover steps to upgrade logical replication clusters, refer +for details on upgrading + logical replication clusters. + + I felt that maybe this note was misplaced. Won't it

Re: A performance issue with Memoize

On Fri, 20 Oct 2023 at 23:40, Richard Guo wrote: > The Memoize runtime stats 'Hits: 0 Misses: 1 Evictions: ' > seems suspicious to me, so I've looked into it a little bit, and found > that the MemoizeState's keyparamids and its outerPlan's chgParam are > always different, and that makes

Re: [PATCH] Add native windows on arm64 support

On Wed, Jan 24, 2024 at 06:45:21AM -0500, Dave Cramer wrote: > I managed to get it to build the vcvarsall arch needs to be x64. I need to > add some options, but the patch above needs to be applied to build it. Nice. If I may ask, what kind of host and/or configuration have you used to reach a

Re: Refactoring backend fork+exec code

On 23/01/2024 21:50, Andres Freund wrote: On 2024-01-23 21:07:08 +0200, Heikki Linnakangas wrote: On 22/01/2024 23:07, Andres Freund wrote: diff --git a/src/backend/utils/activity/backend_status.c b/src/backend/utils/activity/backend_status.c index 1a1050c8da1..92f24db4e18 100644 ---

Re: Patch: Improve Boolean Predicate JSON Path Docs

On Jan 24, 2024, at 16:32, Tom Lane wrote: > "David E. Wheeler" writes: > >> In any event, something to do with @@, perhaps to have some compatibility >> with `jsonb @> jsonb`? I don’t know why @@ was important to have. > > Yeah, that's certainly under-explained. But it seems like I'm not >

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [ NOT Fixed ]

On Wed, Jan 24, 2024 at 4:16 PM Thomas Munro wrote: > On Thu, Jan 25, 2024 at 8:51 AM Kirk Wolak wrote: > > getrusage(RUSAGE_SELF, ); > > memory_usage_bytes = usage.ru_maxrss * 1024; > > FWIW log_statement_stats = on shows that in the logs. See ShowUsage() > in postgres.c. > Thank you

Re: Make documentation builds reproducible

On Tue, Jan 23, 2024 at 12:32 PM Peter Smith wrote: > > On Tue, Jan 23, 2024 at 12:13 PM Tom Lane wrote: > > > > Peter Smith writes: > > > I usually the HTML documentation locally using command: > > > make STYLE=website html > > > This has been working forever, but seems to have broken due to

Current Connection Information

Hi, It would be viable and appropriate to implement a unified function that provides important information about the current connection? Just an example: "Current Connection Informations". I implemented it in PL/pgSQL to demonstrate the idea, see on GitHub:

Re: UUID v7

That's right! There is no point in waiting for the official approval of the new RFC, which obviously will not change anything. I have been a contributor to this RFC for several years, and I can testify that every aspect imaginable has been thoroughly researched and agreed upon. Nothing new will

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Wed, Jan 24, 2024 at 2:59 PM Robert Haas wrote: > > On Thu, Jan 18, 2024 at 9:23 PM Melanie Plageman > wrote: > > I have attached a rebased version of the former 0004 as v11-0001. > > This looks correct to me, although I wouldn't mind some more eyes on > it. However, I think that the comments

Re: Patch: Improve Boolean Predicate JSON Path Docs

"David E. Wheeler" writes: > In any event, something to do with @@, perhaps to have some compatibility > with `jsonb @> jsonb`? I don’t know why @@ was important to have. Yeah, that's certainly under-explained. But it seems like I'm not getting traction for the idea of changing the behavior,

Re: UUID v7

"Other people" think that extracting the timestamp from UUIDv7 in violation of the new RFC, and generating UUIDv7 from the timestamp were both terrible and poorly thought out ideas. The authors of the new RFC had very good reasons to prohibit this. And the problems you face are the best

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [ NOT Fixed ]

On Thu, Jan 25, 2024 at 8:51 AM Kirk Wolak wrote: > getrusage(RUSAGE_SELF, ); > memory_usage_bytes = usage.ru_maxrss * 1024; FWIW log_statement_stats = on shows that in the logs. See ShowUsage() in postgres.c.

Re: UUID v7

On Wed, 24 Jan 2024 at 21:47, Marcos Pegoraro wrote: > > I understand your point, but > '2000-01-01' :: timestamp and '1900-01-01' :: timestamp are both valid > timestamps. > > So looks strange if user can do > select uuidv7(TIMESTAMP '2000-01-01') > but cannot do > select uuidv7(TIMESTAMP

Re: UUID v7

I understand your point, but '2000-01-01' :: timestamp and '1900-01-01' :: timestamp are both valid timestamps. So looks strange if user can do select uuidv7(TIMESTAMP '2000-01-01') but cannot do select uuidv7(TIMESTAMP '1900-01-01') Regards Marcos Em qua., 24 de jan. de 2024 às 14:51, Andrey

Re: dblink query interruptibility

On Thu, Jan 25, 2024 at 04:23:39AM +0900, Fujii Masao wrote: > I found that this patch was committed at d3c5f37dd5 and changed the > error message in postgres_fdw slightly. Here's an example: > > #1. Begin a new transaction. > #2. Execute a query accessing to a foreign table, like SELECT * FROM >

Re: s_lock_test no longer works

Hi, On 2024-01-24 15:05:12 -0500, Tom Lane wrote: > Andres Freund writes: > > On 2024-01-24 12:14:17 +0100, Alvaro Herrera wrote: > >> I do wonder if we want to keep this around, given that it's been more > >> than one year broken and nobody seems to have noticed, and the Meson > >> build does

Re: index prefetching

On Wed, Jan 24, 2024 at 4:19 AM Tomas Vondra wrote: > > On 1/24/24 01:51, Melanie Plageman wrote: > > >>> There are also table AM layering violations in my sketch which would > >>> have to be worked out (not to mention some resource leakage I didn't > >>> bother investigating [which causes it to

Re: s_lock_test no longer works

Andres Freund writes: > On 2024-01-24 12:14:17 +0100, Alvaro Herrera wrote: >> I do wonder if we want to keep this around, given that it's been more >> than one year broken and nobody seems to have noticed, and the Meson >> build does not support the test as a target. > Perhaps we should just

Re: Emit fewer vacuum records by reaping removable tuples during pruning

On Thu, Jan 18, 2024 at 9:23 PM Melanie Plageman wrote: > I have attached a rebased version of the former 0004 as v11-0001. This looks correct to me, although I wouldn't mind some more eyes on it. However, I think that the comments still need more work. Specifically: /* *

Re: Oom on temp (un-analyzed table caused by JIT) V16.1 [ NOT Fixed ]

On Mon, Jan 22, 2024 at 1:30 AM Kirk Wolak wrote: > On Fri, Jan 19, 2024 at 7:03 PM Daniel Gustafsson wrote: > >> > On 19 Jan 2024, at 23:09, Kirk Wolak wrote: >> >> ... >> ./configure --with-llvm >> LLVM_CONFIG=/path/to/llvm-config >> >> -- >> Daniel Gustafsson >> > > Thank you, that

Re: s_lock_test no longer works

Hi, On 2024-01-24 12:14:17 +0100, Alvaro Herrera wrote: > I do wonder if we want to keep this around, given that it's been more > than one year broken and nobody seems to have noticed, and the Meson > build does not support the test as a target. Perhaps we should just make the test built and run

Re: POC: GROUP BY optimization

On Wed, Jan 24, 2024 at 7:38 PM Nathan Bossart wrote: > A recent buildfarm failure [0] seems to indicate a name collision with the > "abc" index in the aggregates.sql test and the "abc" table in > namespace.sql. > > [0] >

Re: Remove redundant HandleWalWriterInterrupts()

On Wed, Jan 24, 2024 at 07:30:17PM +0530, Bharath Rupireddy wrote: > On Wed, Jan 24, 2024 at 5:50 PM Fujii Masao wrote: >> Because of commit 1bdd54e662, the code of HandleWalWriterInterrupts() >> became the same as HandleMainLoopInterrupts(). So I'd like to propose to >> remove

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 02:08:08PM -0500, Robert Haas wrote: > On Wed, Jan 24, 2024 at 1:05 PM Nathan Bossart > wrote: >> Otherwise, I think we'll probably need to add some additional logging to >> figure out what is happening... > > Where, though? I suppose we could: > > 1. Change the server

Re: dblink query interruptibility

On Wed, Nov 22, 2023 at 10:29 AM Noah Misch wrote: > > === Background > > Something as simple as the following doesn't respond to cancellation. In > v15+, any DROP DATABASE will hang as long as it's running: > > SELECT dblink_exec( > $$dbname='$$||current_database()||$$'

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 1:05 PM Nathan Bossart wrote: > There might be an overflow risk in the cutoff time calculation, but I doubt > that's the root cause of these failures: > > /* > * Files should only be removed if the last modification time > precedes the > * cutoff

Re: index prefetching

On 1/22/24 07:35, Konstantin Knizhnik wrote: > > On 22/01/2024 1:47 am, Tomas Vondra wrote: >> h, right. Well, you're right in this case we perhaps could set just one >> of those flags, but the "purpose" of the two places is quite different. >> >> The "prefetch" flag is fully controlled by the

Re: WIP Incremental JSON Parser

On Wed, Jan 24, 2024 at 10:04 AM Andrew Dunstan wrote: > The cfbot reports an error on a 32 bit build > : > > # Running: pg_basebackup -D >

Re: index prefetching

On 1/22/24 08:21, Konstantin Knizhnik wrote: > > On 22/01/2024 1:39 am, Tomas Vondra wrote: >>> Why we can prefer covering index  to compound index? I see only two good >>> reasons: >>> 1. Extra columns type do not  have comparison function need for AM. >>> 2. The extra columns are never used in

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 12:46:16PM -0500, Robert Haas wrote: > The "examining summary" line is generated based on the output of > pg_available_wal_summaries(). The way that works is that the server > calls readdir(), disassembles the filename into a TLI and two LSNs, > and returns the result.

Re: make dist using git archive

On Wed Jan 24, 2024 at 10:18 AM CST, Tristan Partin wrote: On Tue Jan 23, 2024 at 3:30 AM CST, Peter Eisentraut wrote: > On 22.01.24 21:04, Tristan Partin wrote: > > I am not really following why we can't use the builtin Meson dist > > command. The only difference from my testing is it doesn't

Re: UUID v7

> On 24 Jan 2024, at 22:00, Marcos Pegoraro wrote: > > Is enough from 1970 ? Per standard unix_ts_ms field is a number of milliseconds from UNIX start date 1970-01-01. > How about if user wants to have an UUID of his birth date ? I've claimed my 0078c135-bd00-70b1-865a-63c3741922a5 But

Re: logical decoding and replication of sequences, take 2

On 1/23/24 21:47, Robert Haas wrote: > On Thu, Jan 11, 2024 at 11:27 AM Tomas Vondra > wrote: >> 1) desirability: We want a built-in way to handle sequences in logical >> replication. I think everyone agrees this is not a way to do distributed >> sequences in an active-active setups, but that

Re: cleanup patches for incremental backup

On Wed, Jan 24, 2024 at 12:08 PM Nathan Bossart wrote: > I'm seeing some recent buildfarm failures for pg_walsummary: > > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer=2024-01-14%2006%3A21%3A58 > >

Re: POC: GROUP BY optimization

A recent buildfarm failure [0] seems to indicate a name collision with the "abc" index in the aggregates.sql test and the "abc" table in namespace.sql. [0] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet=2024-01-24%2014%3A05%3A14 -- Nathan Bossart Amazon Web Services:

Re: Add system identifier to backup manifest

On Mon, Jan 22, 2024 at 2:22 AM Amul Sul wrote: > Thinking a bit more on this, I realized parse_manifest_file() has many out > parameters. Instead parse_manifest_file() should simply return manifest data > like load_backup_manifest(). Attached 0001 patch doing the same, and removed >

Re: Set log_lock_waits=on by default

Hi, On Thu, Jan 11, 2024 at 03:24:55PM +0100, Michael Banck wrote: > On Thu, Dec 21, 2023 at 02:29:05PM +0100, Laurenz Albe wrote: > > Here is a patch to implement this. > > Being stuck behind a lock for more than a second is almost > > always a problem, so it is reasonable to turn this on by

Re: cleanup patches for incremental backup

I'm seeing some recent buildfarm failures for pg_walsummary: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer=2024-01-14%2006%3A21%3A58 https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=idiacanthus=2024-01-17%2021%3A10%3A36

Re: UUID v7

Is enough from 1970 ? How about if user wants to have an UUID of his birth date ? regards Marcos Em qua., 24 de jan. de 2024 às 13:54, Andrey M. Borodin < x4...@yandex-team.ru> escreveu: > > > > On 24 Jan 2024, at 20:46, Aleksander Alekseev > wrote: > > > > Only the > > fact that timestamp

Re: UUID v7

> On 24 Jan 2024, at 20:46, Aleksander Alekseev > wrote: > > Only the > fact that timestamp from the far past generates UUID from the future > bothers me. PFA implementation of guard checks, but I'm afraid that this can cause failures in ID generation unexpected to the user... See tests

Re: s_lock_test no longer works

Alvaro Herrera writes: > I do wonder if we want to keep this around, given that it's been more > than one year broken and nobody seems to have noticed, and the Meson > build does not support the test as a target. The last time it was broken, it took us multiple years to notice, too. I'm not sure

Re: SQL:2011 application time

On 18.01.24 04:59, Paul Jungwirth wrote: Here are new patches consolidating feedback from several emails. I have committed 0001 and 0002 (the primary key support). The only significant tweak I did was the error messages in GetOperatorFromWellKnownStrategy(), to make the messages translatable

Re: SSL tests fail on OpenSSL v3.2.0

On Wed Jan 24, 2024 at 9:58 AM CST, Jelte Fennema-Nio wrote: I ran into an SSL issue when using the MSYS2/MINGW build of Postgres for the PgBouncer test suite. Postgres crashed whenever you tried to open an ssl connection to it. https://github.com/msys2/MINGW-packages/issues/19851 I'm wondering

Re: make dist using git archive

On Tue Jan 23, 2024 at 3:30 AM CST, Peter Eisentraut wrote: On 22.01.24 21:04, Tristan Partin wrote: > I am not really following why we can't use the builtin Meson dist > command. The only difference from my testing is it doesn't use a > --prefix argument. Here are some problems I have

Re: Support TZ format code in to_timestamp()

Aleksander Alekseev writes: > +SELECT to_timestamp('2011-12-18 11:38 JUNK', '-MM-DD HH12:MI TZ'); -- > error > +ERROR: invalid value "JUNK" for "TZ" > +DETAIL: Time zone abbreviation is not recognized. > +SELECT to_timestamp('2011-12-18 11:38 ...', '-MM-DD HH12:MI TZ'); -- > error >

Re: Fixing backslash dot for COPY FROM...CSV

Robert Haas wrote: > Those links unfortunately seem not to be entirely specific to this > issue. Other, related things seem to be discussed there, and it's not > obvious that everyone agrees on what to do, or really that anyone > agrees on what to do. The best link that I found for this

Re: SSL tests fail on OpenSSL v3.2.0

I ran into an SSL issue when using the MSYS2/MINGW build of Postgres for the PgBouncer test suite. Postgres crashed whenever you tried to open an ssl connection to it. https://github.com/msys2/MINGW-packages/issues/19851 I'm wondering if the issue described in this thread could be related to the

Re: UUID v7

Hi, > Also, please not that uuidv7(time+1us) and uuidv7(time) will have the same > internal timestamp, so despite time+1us > time, still second uuid will be > greater. > > Both invariants you proposed cannot be reasonably guaranteed. Upholding any > of them greatly reduces usability of UUID

Re: UUID v7

> On 24 Jan 2024, at 18:29, Aleksander Alekseev > wrote: > > Hi, > >> Function to extract timestamp does not provide any guarantees at all. >> Standard states this, see Kyzer answers upthread. >> Moreover, standard urges against relying on that if uuidX was generated >> before uuidY, then

Re: WIP Incremental JSON Parser

On 2024-01-22 Mo 21:02, Andrew Dunstan wrote: On 2024-01-22 Mo 18:01, Andrew Dunstan wrote: On 2024-01-22 Mo 14:16, Andrew Dunstan wrote: On 2024-01-22 Mo 01:29, Peter Smith wrote: 2024-01 Commitfest. Hi, This patch has a CF status of "Needs Review" [1], but it seems there were CFbot

Re: Make COPY format extendable: Extract COPY TO format implementations

Hi, In <20240124.144936.67229716500876806@clear-code.com> "Re: Make COPY format extendable: Extract COPY TO format implementations" on Wed, 24 Jan 2024 14:49:36 +0900 (JST), Sutou Kouhei wrote: > I've implemented custom COPY format feature based on the > current design discussion. See

Re: Make COPY format extendable: Extract COPY TO format implementations

Hi, In <10025bac-158c-ffe7-fbec-32b426291...@dunslane.net> "Re: Make COPY format extendable: Extract COPY TO format implementations" on Wed, 24 Jan 2024 07:15:55 -0500, Andrew Dunstan wrote: > > On 2024-01-24 We 03:11, Michael Paquier wrote: >> On Wed, Jan 24, 2024 at 02:49:36PM +0900,

Re: make BuiltinTrancheNames less ugly

On 2024-Jan-23, Alvaro Herrera wrote: > I'm a total newbie to Meson, so it's likely that there are better ways > to implement this. I'll leave this here for a little bit in case > anybody wants to comment. OK, I pushed the array definition, and here's the other bits as a followup patch. I'll

Re: Remove redundant HandleWalWriterInterrupts()

On Wed, Jan 24, 2024 at 5:50 PM Fujii Masao wrote: > > Hi, > > Because of commit 1bdd54e662, the code of HandleWalWriterInterrupts() > became the same as HandleMainLoopInterrupts(). So I'd like to propose to > remove HandleWalWriterInterrupts() and make walwriter use > HandleMainLoopInterrupts()

Re: UUID v7

Hi, > Function to extract timestamp does not provide any guarantees at all. > Standard states this, see Kyzer answers upthread. > Moreover, standard urges against relying on that if uuidX was generated > before uuidY, then uuidX happen, but does not guaranty that. > All what is guaranteed is

Re: pgbnech: allow to cancel queries during benchmark

On Fri, 19 Jan 2024 17:46:03 +0900 (JST) Tatsuo Ishii wrote: > >> +/* send cancel requests to all connections */ > >> +static void > >> +cancel_all() > >> +{ > >> + for (int i = 0; i < nclients; i++) > >> + { > >> + char errbuf[1]; > >> + if (client_states[i].cancel != NULL)

Re: UUID v7

Hi, > Values that violate named invariants should be rejected with an error. To clarify, I don't think we should bother about the precision part. "Equals" in the example above means "equal within UUIDv7 precision", same for "more" and "less". However, years 2977 BC and 5943 AC are clearly not

Re: UUID v7

> On 24 Jan 2024, at 18:02, Aleksander Alekseev > wrote: > > Hi, > >> UUIDv7 range does not correspond to timestamp range. But it’s purpose is not >> in storing timestamp, but in being unique identifier. So I don’t think it >> worth throwing an error when overflowing value is given. BTW

Re: Network failure may prevent promotion

On Wed, Jan 24, 2024 at 8:29 PM Fujii Masao wrote: > > On Tue, Jan 23, 2024 at 6:43 PM Heikki Linnakangas wrote: > > There's an existing AmWalReceiverProcess() macro too. Let's use that. > > +1 > > > Hmm, but doesn't bgworker_die() have that problem with exit(1)ing in the > > signal handler? > >

Re: UUID v7

Hi, > UUIDv7 range does not correspond to timestamp range. But it’s purpose is not > in storing timestamp, but in being unique identifier. So I don’t think it > worth throwing an error when overflowing value is given. BTW if you will > subtract some nanoseconds - you will not get back

Re: Support TZ format code in to_timestamp()

Hi, > > Anyway, v2-0001 below is the previous patch rebased up to current > > (only line numbers change), and then v2-0002 responds to your > > and Daniel's review comments. > > LGTM. ``` +SELECT to_timestamp('2011-12-18 11:38 JUNK', '-MM-DD HH12:MI TZ'); -- error +ERROR: invalid value

Re: UUID v7

> On 24 Jan 2024, at 17:31, Aleksander Alekseev > wrote: > > Hi, > >> Cfbot also seems to be happy with the patch so I'm changing the CF >> entry status to RfC. > > I've found a bug: > > ``` > =# select now() - interval '5000 years'; >?column? >

Re: UUID v7

Hi, > Cfbot also seems to be happy with the patch so I'm changing the CF > entry status to RfC. I've found a bug: ``` =# select now() - interval '5000 years'; ?column? 2977-01-24 15:29:01.779462+02:30:17 BC Time: 0.957 ms =# select

  1   2   >