PG_TEST_EXTRA and meson

Hi All, Using PG_TEST_EXTRA with make is simple, one just sets that environment variable $ make check ... snip ... PG_REGRESS='/home/ashutosh/work/units/pghead_make/coderoot/pg/src/test/modules/xid_wraparound/../../../../src/test/regress/pg_regress' /usr/bin/prove -I ../../../../src/test/perl/ -I

Re: Pgoutput not capturing the generated columns

On Wed, Jul 10, 2024 at 4:22 AM Peter Smith wrote: > > Hi Shubham/Shlok, I was thinking some more about the suggested new > BitMapSet (BMS) idea of patch 0001 that changes the 'columns' meaning > to include generated cols also where necessary. > > I feel it is a bit risky to change lots of code wi

Re: relfilenode statistics

Hi, On Thu, Jul 11, 2024 at 01:58:19PM +0900, Michael Paquier wrote: > On Wed, Jul 10, 2024 at 01:38:06PM +, Bertrand Drouvot wrote: > > So, I think it makes sense to link the hashkey to all the RelFileLocator > > fields, means: > > > > dboid (linked to RelFileLocator's dbOid) > > objoid (lin

Redundant syscache access in get_rel_sync_entry()

Hi, in func get_rel_sync_entry() we access the same tuple in pg_class three times:     Oid         schemaId = get_rel_namespace(relid);     bool am_partition = get_rel_relispartition(relid);     char relkind = get_rel_relkind(relid); Why not just merge into one?

Re: Conflict detection and logging in logical replication

On Thu, Jul 11, 2024 at 7:47 AM Zhijie Hou (Fujitsu) wrote: > > On Wednesday, July 10, 2024 5:39 PM shveta malik > wrote: > > > > On Wed, Jul 3, 2024 at 8:31 AM Zhijie Hou (Fujitsu) > > wrote: > > > > > > On Wednesday, June 26, 2024 10:58 AM Zhijie Hou (Fujitsu) > > wrote: > > > > > > > > > >

Re: relfilenode statistics

On Wed, Jul 10, 2024 at 01:38:06PM +, Bertrand Drouvot wrote: > On Wed, Jul 10, 2024 at 03:02:34PM +0900, Michael Paquier wrote: >> and I am troubled by the approach taken (mentioned down by you), but >> that's invasive compared to how pgstats wants to be transparent with >> its stats kinds. >>

Re: Speed up Hash Join by teaching ExprState about hashing

On Mon, 13 May 2024 at 21:23, David Rowley wrote: > In master, if you look at ExecHashGetHashValue() in nodeHash.c, you > can see that it calls ExecEvalExpr() and then manually calls the hash > function on the returned value. This process is repeated once for each > hash key. This is inefficient f

Re: Improving the latch handling between logical replication launcher and worker processes.

On Mon, 8 Jul 2024 at 17:46, vignesh C wrote: > > On Fri, 5 Jul 2024 at 18:38, Heikki Linnakangas wrote: > > > > On 05/07/2024 14:07, vignesh C wrote: > > > On Thu, 4 Jul 2024 at 16:52, Heikki Linnakangas wrote: > > >> > > >> I'm don't quite understand the problem we're trying to fix: > > >> > >

Re: improve performance of pg_dump with many sequences

On Wed, Jul 10, 2024, at 7:05 PM, Nathan Bossart wrote: > I'm not following why that would be a better approach. strncpy() will add > a NUL to the end of the string unless it doesn't fit in the buffer, in > which case we'll add our own via "seqtype[sizeof(seqtype) - 1] = '\0'". > Furthermore, the

RE: Conflict detection and logging in logical replication

On Wednesday, July 10, 2024 5:39 PM shveta malik wrote: > > On Wed, Jul 3, 2024 at 8:31 AM Zhijie Hou (Fujitsu) > wrote: > > > > On Wednesday, June 26, 2024 10:58 AM Zhijie Hou (Fujitsu) > wrote: > > > > > > > Hi, > > > > As suggested by Sawada-san in another thread[1]. > > > > I am attaching t

Re: Parent/child context relation in pg_get_backend_memory_contexts()

On Thu, 11 Jul 2024 at 09:19, Robert Haas wrote: > FWIW, I would have done what Melih did. A path normally is listed in > root-to-leaf order, not leaf-to-root. Melih and I talked about this in a meeting yesterday evening. I think I'm about on the fence about having the IDs in leaf-to-root or root

Re: Allow non-superuser to cancel superuser tasks.

On Wed, Jul 10, 2024 at 10:57:45PM +0500, Kirill Reshke wrote: > Hi, that's for digging into this. Turns out I completely missed one of > your emails today morning. Don't worry. Using this domain tends to put my emails in one's spam folder. -- Michael signature.asc Description: PGP signature

Re: POC, WIP: OR-clause support for indexes

On 27.06.2024 23:06, Alena Rybakina wrote: Tobe honest,I've alreadystartedwritingcodetodothis,butI'm facedwitha misunderstandingof howto correctlycreatea conditionfor"OR"expressionsthatare notsubjectto transformation. For example,the expressions b=1in the query below: alena@postgres=# explain

Re: improve performance of pg_dump with many sequences

On Wed, Jul 10, 2024 at 05:08:56PM -0300, Euler Taveira wrote: > Nice improvement. The numbers for a realistic scenario (10k sequences) are Thanks for taking a look! > You are changing internal representation from char to int64. Is the main goal > to > validate catalog data? What if there is a n

Re: improve predefined roles documentation

Committed. Thank you for reviewing! -- nathan

Re: Parent/child context relation in pg_get_backend_memory_contexts()

On Fri, Jul 5, 2024 at 4:06 AM David Rowley wrote: > I've been wondering about the order of the "path" column. When we > talked, I had in mind that the TopMemoryContext should always be at > the end of the array rather than the start, but I see you've got it > the other way around. FWIW, I would

Re: Parent/child context relation in pg_get_backend_memory_contexts()

On Wed, Apr 3, 2024 at 7:34 PM Michael Paquier wrote: > I've been re-reading the patch again to remember what this is about, > and I'm OK with having this "path" column in the catalog. However, > I'm somewhat confused by the choice of having a temporary number that > shows up in the catalog repre

Re: Assertion failure with summarize_wal enabled during pg_createsubscriber

On Wed, Jul 3, 2024 at 1:07 PM Robert Haas wrote: > I think the problem here is that the WAL summarizer believes that when > a new timeline appears, it should pick up from where the old timeline > ended. And here, that doesn't happen: the new timeline branches off > before the end of the old timel

Re: improve performance of pg_dump with many sequences

On Tue, Jul 9, 2024, at 4:11 PM, Nathan Bossart wrote: > rebased Nice improvement. The numbers for a realistic scenario (10k sequences) are for i in `seq 1 1`; do echo "CREATE SEQUENCE s$i;"; done > /tmp/s.sql master: real 0m1,141s user 0m0,056s sys 0m0,147s patched: real 0m0,410s user 0m0,

Re: pg_maintain and USAGE privilege on schema

On Wed, Jul 10, 2024 at 12:29:00PM -0700, Jeff Davis wrote: >> > It might be reasonable to give implicit USAGE privileges on all >> > schemas >> > during maintenance commands to pg_maintain roles. > > That's an even more specific exception: having USAGE only in the > context of a maintenance comma

Re: Simplifying width_bucket_numeric()

On Sun, 7 Jul 2024 at 13:43, Joel Jacobson wrote: > > > SELECT hash_array(array_agg(width_bucket(op, b1, b2, c))) FROM t; > > -- Result not changed by patch > > Same hash_array on all my three machines: > > > SELECT sum(width_bucket(op, b1, b2, c)) FROM t; > > Time: 3658.962 ms (00:03.659) -- HEA

Re: pg_maintain and USAGE privilege on schema

On Wed, 2024-07-10 at 17:13 +0900, Fujii Masao wrote: > ISTM that both > pg_read_all_data and pg_write_all_data roles are defined similarly, > with USAGE rights on all schemas. I'm not so sure that was a great idea to begin with. If you create a private schema with a SECURITY DEFINER function in i

Re: Missed opportunity for bsearch() in TransactionIdIsCurrentTransactionId()?

On Wed, Jul 10, 2024 at 05:00:13PM +0200, Antonin Houska wrote: > I don't quite understand why TransactionIdIsCurrentTransactionId() implements > binary search in ParallelCurrentXids "from scratch" instead of using > bsearch(). I believe there are a number of open-coded binary searches in the tree

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote: > We went through a ton of permutations of that kind of > idea years ago, when it first became totally clear that cross-checks > between GUCs do not work nicely if implemented in check_hooks. > (You can find all the things we tried in the co

Re: Allow non-superuser to cancel superuser tasks.

Hi, that's for digging into this. Turns out I completely missed one of your emails today morning. On Wed, 10 Jul 2024 at 10:15, Michael Paquier wrote: > And then the timestamp of the tests: > [12:48:23.277](0.058s) not ok 2 - autovacuum worker signaled with > pg_signal_autovacuum_worker granted >

Re: long-standing data loss bug in initial sync of logical replication

On Wed, Jul 10, 2024 at 10:39 PM vignesh C wrote: > > On Wed, 10 Jul 2024 at 12:28, Amit Kapila wrote: > > The patch missed to use the ShareRowExclusiveLock for partitions, see > > attached. I haven't tested it but they should also face the same > > problem. Apart from that, I have changed the co

Re: Windows: openssl & gssapi dislike each other

On Tue, Jul 9, 2024 at 2:32 AM Andres Freund wrote: > > Hi, > > > On 2024-06-13 00:12:51 +0900, Imran Zaheer wrote: > > I removed the macro from the sslinfo.c as suggested by Andrew. Then I > > was thinking maybe we can undo some other similar code. > > What precisely do you mean by that? Just get

Re: long-standing data loss bug in initial sync of logical replication

On Wed, 10 Jul 2024 at 12:28, Amit Kapila wrote: > > On Tue, Jul 9, 2024 at 8:14 PM vignesh C wrote: > > > > On Tue, 9 Jul 2024 at 17:05, Amit Kapila wrote: > > > > > > On Mon, Jul 1, 2024 at 10:51 AM vignesh C wrote: > > > > > > > > > > > > This issue is present in all supported versions. I wa

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, Jul 10, 2024 at 10:10 AM Robert Haas wrote: > On Wed, Jul 10, 2024 at 1:56 AM Fujii Masao > wrote: > > I believe this issue occurs when the server is shut down cleanly. > > The shutdown-checkpoint record retains the wal_level value used > > before the shutdown. If wal_level is changed af

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Thu, Jul 11, 2024 at 01:02:25AM +0900, Fujii Masao wrote: > On 2024/07/10 23:18, Nathan Bossart wrote: >> Yeah. I initially thought this patch might be okay, at least as a stopgap, >> but Jelte pointed out a case where it doesn't work, namely when you have >> something like the following in the

Re: Streaming I/O, vectored I/O (WIP)

Hi, It seems that Heikki's 'v9.heikki-0007-Trivial-comment-fixes.patch' [1] is partially applied, the top comment is not updated. The attached patch just updates it. [1] https://www.postgresql.org/message-id/289a1c0e-8444-4009-a8c2-c2d77ced6f07%40iki.fi -- Regards, Nazir Bilal Yavuz Microsoft

Re: Allow logical failover slots to wait on synchronous replication

Hi, On Mon, Jul 08, 2024 at 12:08:58PM -0700, John H wrote: > I took a deeper look at this with GDB and I think it's necessary to > cache the value of "mode". > We first check: > > if (mode == SYNC_REP_NO_WAIT) > return true; > > However after this check it's possible to receive a SIGHUP changin

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, Jul 10, 2024 at 11:54:38AM -0400, Tom Lane wrote: > Nathan Bossart writes: >> I haven't tested it, but from skimming around the code, it looks like >> ProcessConfigFileInternal() would deduplicate any previous entries in the >> file prior to applying the values and running the check hooks.

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On 2024/07/11 0:44, Nathan Bossart wrote: On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote: Please, no. We went through a ton of permutations of that kind of idea years ago, when it first became totally clear that cross-checks between GUCs do not work nicely if implemented in check_h

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On 2024/07/10 23:18, Nathan Bossart wrote: On Wed, Jul 10, 2024 at 10:10:30AM -0400, Robert Haas wrote: On Wed, Jul 10, 2024 at 1:56 AM Fujii Masao wrote: I'm sure this patch is necessary as a safeguard for WAL summarization. OTOH, I also think we should apply the patch I proposed earlier i

Send duration output to separate log files

Please find attached a patch to allow for durations to optionally be sent to separate log files. In other words, rather than cluttering up our postgres202007.log file with tons of output from log_min_duration_statement, duration lines are sent instead to the file postgres202007.duration. Over the

Re: Is it possible to create a cursor with hold using extended query protocol

On Wed, Jul 10, 2024 at 8:29 AM Dave Cramer wrote: > > On Wed, 10 Jul 2024 at 11:04, David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> On Wednesday, July 10, 2024, Dave Cramer wrote: >> >>> Greetings, >>> >>> There are suggestions that you can use extended query to fetch from a >>> c

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

Nathan Bossart writes: > I haven't tested it, but from skimming around the code, it looks like > ProcessConfigFileInternal() would deduplicate any previous entries in the > file prior to applying the values and running the check hooks. Else, > reloading a configuration file with multiple startup-

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, Jul 10, 2024 at 11:11:13AM -0400, Tom Lane wrote: > Please, no. We went through a ton of permutations of that kind of > idea years ago, when it first became totally clear that cross-checks > between GUCs do not work nicely if implemented in check_hooks. > (You can find all the things we tr

Re: Is it possible to create a cursor with hold using extended query protocol

On Wed, 10 Jul 2024 at 11:04, David G. Johnston wrote: > On Wednesday, July 10, 2024, Dave Cramer wrote: > >> Greetings, >> >> There are suggestions that you can use extended query to fetch from a >> cursor, however I don't see how you can bind values to the cursor ? >> >> PostgreSQL: Documentat

Re: jsonpath: Inconsistency of timestamp_tz() Output

On Jul 10, 2024, at 10:54, David E. Wheeler wrote: > So it should be -7, not -8. Not sure where to tell it to pay proper attention > to daylight savings time. Oh, and the time and date were wrong, too, because I blindly used the same conversion for dates as for timestamps. Fixed in v2. PR: ht

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

Jelte Fennema-Nio writes: > On Wed, 10 Jul 2024 at 16:18, Nathan Bossart wrote: >> Yeah. I initially thought this patch might be okay, at least as a stopgap, >> but Jelte pointed out a case where it doesn't work, namely when you have >> something like the following in the config file: >> >> wal

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, 10 Jul 2024 at 16:46, Nathan Bossart wrote: > Do we actually need to look at pmState? Or could we just skip > it if the context is <= PGC_S_ARGV? I'm not 100% sure, but I think PGC_S_FILE would still be used when postgresql.conf changes and on SIGHUP is sent. And we would want the check_

Re: Is it possible to create a cursor with hold using extended query protocol

On Wednesday, July 10, 2024, Dave Cramer wrote: > Greetings, > > There are suggestions that you can use extended query to fetch from a > cursor, however I don't see how you can bind values to the cursor ? > > PostgreSQL: Documentation: 16: FETCH >

Missed opportunity for bsearch() in TransactionIdIsCurrentTransactionId()?

I don't quite understand why TransactionIdIsCurrentTransactionId() implements binary search in ParallelCurrentXids "from scratch" instead of using bsearch(). If I read the code correctly, the contents of the ParallelCurrentXids is composed in SerializeTransactionState(), which uses xidComparator:

Re: jsonpath: Inconsistency of timestamp_tz() Output

On Jul 10, 2024, at 10:33, David E. Wheeler wrote: > Yeah I don’t know either, but now at least it’s consistent. I’ve attached a > patch to fix it. Actually I think there’s a subtlety still missing here: @@ -2914,7 +2914,7 @@ HINT: Use *_tz() function for time zone support. select jsonb_path

Re: Possible incorrect row estimation for Gather paths

Hello Anthonin, I spent some time on this problem and your proposed solution. As I understand it, this is the correction for the row count when the number of parallel workers < 4. Once the number of workers is 4 or more, the output from parallel_divisor is the same as the number of parallel worker

Is it possible to create a cursor with hold using extended query protocol

Greetings, There are suggestions that you can use extended query to fetch from a cursor, however I don't see how you can bind values to the cursor ? PostgreSQL: Documentation: 16: FETCH Is this possible? Dave Cramer

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, Jul 10, 2024 at 04:29:14PM +0200, Jelte Fennema-Nio wrote: > On Wed, 10 Jul 2024 at 16:18, Nathan Bossart wrote: >> Yeah. I initially thought this patch might be okay, at least as a stopgap, >> but Jelte pointed out a case where it doesn't work, namely when you have >> something like the

Re: jsonpath: Inconsistency of timestamp_tz() Output

On Jul 10, 2024, at 10:33, David E. Wheeler wrote: > Yeah I don’t know either, but now at least it’s consistent. I’ve attached a > patch to fix it. > > Ideally, I think, we wouldn’t convert the value and determine the offset > twice, but teach date_timestamptz and timestamp_timestamptz (or >

Re: jsonpath: Inconsistency of timestamp_tz() Output

On Jul 10, 2024, at 01:48, Junwang Zhao wrote: > I apply your patch with some minor change(to make the server not crash): Oh, thank you! Kicking myself for not catching the obvious. > It now gives the local tz: > > [local] postgres@postgres:5432-54960=# set time zone 'America/New_York'; > SET

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, 10 Jul 2024 at 16:18, Nathan Bossart wrote: > Yeah. I initially thought this patch might be okay, at least as a stopgap, > but Jelte pointed out a case where it doesn't work, namely when you have > something like the following in the config file: > > wal_level = 'minimal' >

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, Jul 10, 2024 at 10:10:30AM -0400, Robert Haas wrote: > On Wed, Jul 10, 2024 at 1:56 AM Fujii Masao > wrote: >> I'm sure this patch is necessary as a safeguard for WAL summarization. >> OTOH, I also think we should apply the patch I proposed earlier >> in this thread, which prevents summar

Re: Add a GUC check hook to ensure summarize_wal cannot be enabled when wal_level is minimal

On Wed, Jul 10, 2024 at 1:56 AM Fujii Masao wrote: > I believe this issue occurs when the server is shut down cleanly. > The shutdown-checkpoint record retains the wal_level value used > before the shutdown. If wal_level is changed after this, > the wal_level that indicated by the shutdown-checkpo

Re: pg_maintain and USAGE privilege on schema

On Wed, Jul 10, 2024 at 05:13:58PM +0900, Fujii Masao wrote: > However, unlike the database owner, pg_maintain by definition should > have *all* the rights needed for maintenance tasks, including MAINTAIN > rights on tables and USAGE rights on schemas? ISTM that both > pg_read_all_data and pg_write

Re: tests fail on windows with default git settings

On 2024-07-10 We 9:25 AM, Tom Lane wrote: Dave Page writes: On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote: As I was looking at this I wondered if there might be anywhere else that needed adjustment. One thing that occurred to me was that that maybe we should replace the use of "-w" in

Re: relfilenode statistics

Hi, On Wed, Jul 10, 2024 at 03:02:34PM +0900, Michael Paquier wrote: > On Sat, May 25, 2024 at 07:52:02AM +, Bertrand Drouvot wrote: > > But I think that it is in a state that can be used to discuss the approach > > it > > is implementing (so that we can agree or not on it) before moving > >

Re: MERGE/SPLIT partition commands should create new partitions in the parent's tablespace?

On Wed, Jul 10, 2024 at 5:14 PM Masahiko Sawada wrote: > > On Wed, Jul 10, 2024 at 4:14 PM Fujii Masao > wrote: > > > > > > > > On 2024/07/10 12:13, Masahiko Sawada wrote: > > > On Sat, Jul 6, 2024 at 4:06 PM Fujii Masao > > > wrote: > > >> > > >> Hi, > > >> > > >> I noticed that ALTER TABLE M

Re: tests fail on windows with default git settings

Dave Page writes: > On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote: >> As I was looking at this I wondered if there might be anywhere else that >> needed adjustment. One thing that occurred to me was that that maybe we >> should replace the use of "-w" in pg_regress.c with this rather less >>

Re: Allow non-superuser to cancel superuser tasks.

> On 10 Jul 2024, at 11:27, Kirill Reshke wrote: > > That's very strange, because the test works fine on my virtual > machine. Also, it seems that it works in Cirrus [0], as there is this > line: So far I could not reproduce that failure. I’ve checkouted 6edec53 from CFbot repository, but it

Re: [EXTERNAL] Re: Add non-blocking version of PQcancel

On Mon, 1 Jul 2024 at 00:38, Jelte Fennema-Nio wrote: > Ugh yes, I think this was a copy paste error. See attached patch 0003 > to fix this (rest of the patches are untouched from previous > revision). Alvaro committed 0003, which caused cfbot to think a rebase is necessary. Attached should solve

Re: Should we work around msvc failing to compile tab-complete.c?

On 2024-07-10 We 5:55 AM, Dave Page wrote: What is more relevant is that as far as I can see, we've never actually supported either libedit or readline in MSVC++ builds - which kinda makes sense because Windows terminals are very different from traditional *nix ones. Windows isn't supporte

Re: speed up a logical replica setup

On Tue, Jul 9, 2024, at 8:00 AM, Alexander Lakhin wrote: > Hello Amit and Kuroda-san, > > 03.07.2024 14:02, Amit Kapila wrote: > > Pushed 0002 and 0003. Let's wait for a discussion on 0001. > > Please look at another failure of the test [1]: > [13:28:05.647](2.460s) not ok 26 - failover slot is s

Re: tests fail on windows with default git settings

On Wed, 10 Jul 2024 at 12:12, Andrew Dunstan wrote: > > On 2024-07-09 Tu 11:34 AM, Andrew Dunstan wrote: > > > On 2024-07-09 Tu 9:52 AM, Dave Page wrote: > > > >> > What I suggest (see attached) is we run the diff command with >> > --strip-trailing-cr on Windows. Then we just won't care if the ex

Re: tests fail on windows with default git settings

On 2024-07-09 Tu 11:34 AM, Andrew Dunstan wrote: On 2024-07-09 Tu 9:52 AM, Dave Page wrote: > What I suggest (see attached) is we run the diff command with > --strip-trailing-cr on Windows. Then we just won't care if the expected file > and/or the output file has CRs. I

Re: Lock-free compaction. Why not?

On 7/10/24 11:49, David Rowley wrote: > On Tue, 9 Jul 2024 at 16:58, Ahmed Yarub Hani Al Nuaimi > wrote: >> The thing is, after reading the code a million times, I still don't >> understand why lock-free (or minimum locking) is such a big problem! Is it >> that hard to lazily move tuples from on

Re: MERGE/SPLIT partition commands should create new partitions in the parent's tablespace?

On Sat, 6 Jul 2024 at 19:06, Fujii Masao wrote: > I noticed that ALTER TABLE MERGE PARTITIONS and SPLIT PARTITION commands > always create new partitions in the default tablespace, regardless of > the parent's tablespace. However, the indexes of these new partitions inherit > the tablespaces of th

Re: Should we work around msvc failing to compile tab-complete.c?

On Tue, 9 Jul 2024 at 17:23, Andres Freund wrote: > Hi, > > On 2024-07-09 09:14:33 +0100, Dave Page wrote: > > On Mon, 8 Jul 2024 at 21:08, Andres Freund wrote: > > > I think we'd need to backpatch more for older branches. At least > > > > > > commit 3f28bd7337d > > > Author: Thomas Munro > > >

Re: Lock-free compaction. Why not?

On Tue, 9 Jul 2024 at 16:58, Ahmed Yarub Hani Al Nuaimi wrote: > The thing is, after reading the code a million times, I still don't > understand why lock-free (or minimum locking) is such a big problem! Is it > that hard to lazily move tuples from one page to the other after > defragmenting it

Re: Conflict detection and logging in logical replication

On Wed, Jul 3, 2024 at 8:31 AM Zhijie Hou (Fujitsu) wrote: > > On Wednesday, June 26, 2024 10:58 AM Zhijie Hou (Fujitsu) > wrote: > > > > Hi, > > As suggested by Sawada-san in another thread[1]. > > I am attaching the V4 patch set which tracks the delete_differ > conflict in logical replication.

Re: Add memory/disk usage for WindowAgg nodes in EXPLAIN

>>> Yes, I think so. I'd keep each as a separate patch so they can be >>> considered independently. Doing all of them should hopefully ensure we >>> strike the right balance of what code to put in explain.c and what >>> code to put in tuplestore.c. >> +1 >> >> + if (es->format != EXPLAIN_FORMAT_TE

Re: tests fail on windows with default git settings

Sorry - somehow managed to send whilst pasting in logs... On Wed, 10 Jul 2024 at 10:30, Dave Page wrote: > > > On Tue, 9 Jul 2024 at 17:32, Andres Freund wrote: > >> Hi, >> >> On 2024-07-09 14:52:39 +0100, Dave Page wrote: >> > I have 4 different diff.exe's on my ~6 week old build VM (not count

Re: tests fail on windows with default git settings

On Tue, 9 Jul 2024 at 17:32, Andres Freund wrote: > Hi, > > On 2024-07-09 14:52:39 +0100, Dave Page wrote: > > I have 4 different diff.exe's on my ~6 week old build VM (not counting > > shims), all of which seem to support --strip-trailing-cr. Those builds > came > > with: > > > > - git > > - VC+

Re: Pluggable cumulative statistics

Hi, On Wed, Jul 10, 2024 at 08:28:56AM +, Bertrand Drouvot wrote: > Hi, > > On Tue, Jul 09, 2024 at 03:54:37PM +0900, Michael Paquier wrote: > > On Mon, Jul 08, 2024 at 02:07:58PM +, Bertrand Drouvot wrote: > > > It looks pretty straightforward, just one comment: > > > > > > +

Re: Pluggable cumulative statistics

Hi, On Tue, Jul 09, 2024 at 03:54:37PM +0900, Michael Paquier wrote: > On Mon, Jul 08, 2024 at 02:07:58PM +, Bertrand Drouvot wrote: > > It looks pretty straightforward, just one comment: > > > > + ptr = ((char *) ctl) + kind_info->shared_ctl_off; > > +

Re: Eager aggregation, take 3

On Sun, Jul 7, 2024 at 10:45 AM Paul George wrote: > Thanks for reviving this patch and for all of your work on it! Eager > aggregation pushdown will be beneficial for my work and I'm hoping to see it > land. Thanks for looking at this patch! > The output of both the original query and this on

Re: Logical Replication of sequences

Here are a few comments for patch v20240705-0003. (This is a WIP. I have only looked at the docs so far.) == doc/src/sgml/config.sgml nitpick - max_logical_replication_workers: /and sequence synchornization worker/and a sequence synchornization worker/ == doc/src/sgml/logical-replicatio

Re: MERGE/SPLIT partition commands should create new partitions in the parent's tablespace?

On Wed, Jul 10, 2024 at 4:14 PM Fujii Masao wrote: > > > > On 2024/07/10 12:13, Masahiko Sawada wrote: > > On Sat, Jul 6, 2024 at 4:06 PM Fujii Masao > > wrote: > >> > >> Hi, > >> > >> I noticed that ALTER TABLE MERGE PARTITIONS and SPLIT PARTITION commands > >> always create new partitions in t

Re: pg_maintain and USAGE privilege on schema

On 2024/07/08 11:13, Nathan Bossart wrote: On Mon, Jul 08, 2024 at 01:03:42AM +0900, Fujii Masao wrote: I've noticed an issue with non-superusers who have the pg_maintain role. When they run VACUUM on a specific table within a specific schema, like "VACUUM mynsp.mytbl", it fails if they don't

Re: Avoid orphaned objects dependencies, take 3

Hi, On Tue, Jul 02, 2024 at 05:56:23AM +, Bertrand Drouvot wrote: > Hi, > > On Mon, Jul 01, 2024 at 09:39:17AM +, Bertrand Drouvot wrote: > > Hi, > > > > On Wed, Jun 26, 2024 at 10:24:41AM +, Bertrand Drouvot wrote: > > > Hi, > > > > > > On Fri, Jun 21, 2024 at 01:22:43PM +, Ber

Re: MERGE/SPLIT partition commands should create new partitions in the parent's tablespace?

On 2024/07/10 12:13, Masahiko Sawada wrote: On Sat, Jul 6, 2024 at 4:06 PM Fujii Masao wrote: Hi, I noticed that ALTER TABLE MERGE PARTITIONS and SPLIT PARTITION commands always create new partitions in the default tablespace, regardless of the parent's tablespace. However, the indexes of

Re: Doc: fix track_io_timing description to mention pg_stat_io

On 2024/07/08 12:01, hajime.matsun...@nttdata.com wrote: From: Fujii Masao Sent: Wednesday, July 3, 2024 7:44 PM On 2024/07/03 17:51, hajime.matsun...@nttdata.com wrote: Thanks for the suggestions the other day. I have created a patch that incorporates your suggestions. -pg_sta