Re: POC: GROUP BY optimization

On 4/12/24 06:44, Tom Lane wrote: If this patch were producing better results I'd be more excited about putting more work into it. But on the basis of what I'm seeing right now, I think maybe we ought to give up on it. First, thanks for the deep review - sometimes, only a commit gives us a

Re: Issue with the PRNG used by Postgres

Hi Andres, 12.04.2024 07:41, Andres Freund wrote: FWIW, I just reproduced the scenario with signals. I added tracking of the total time actually slept and lost to SpinDelayStatus, and added a function to trigger a wait on a spinlock. To wait less, I set max_standby_streaming_delay=0.1, but

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-11 20:47:37 -0700, Andres Freund wrote: > > So there's that. But that's not an argument that we need to be in a > > hurry to timeout; if the built-in reaction time is less than perhaps > > 10 minutes you're still miles ahead of the manual solution. > > The current timeout is of a

further improving roles_is_member_of()

(moved to a new thread) On Thu, Mar 21, 2024 at 04:31:45PM -0400, Tom Lane wrote: > I wrote: >> ... I still see the problematic GRANT taking ~250ms, compared >> to 5ms in v15. roles_is_member_of is clearly on the hook for that. > > Ah: looks like that is mainly the fault of the

Re: Issue with the PRNG used by Postgres

Andres Freund writes: > On 2024-04-11 23:15:38 -0400, Tom Lane wrote: >> On the third hand, it's still true that we have no comparable >> behavior for any other source of system lockups, and it's difficult >> to make a case that stuck spinlocks really need more concern than >> other kinds of

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-11 23:15:38 -0400, Tom Lane wrote: > I wrote: > > ... But Robert's question remains: how does > > PANIC'ing after awhile make anything better? I flat out don't > > believe the idea that having a backend stuck on a spinlock > > would otherwise go undetected. > > Oh, wait. After

Re: Synchronizing slots from primary to standby

On Thu, Apr 11, 2024 at 5:04 PM Zhijie Hou (Fujitsu) wrote: > > On Thursday, April 11, 2024 12:11 PM Amit Kapila > wrote: > > > > > 2. > > - if (remote_slot->restart_lsn < slot->data.restart_lsn) > > + if (remote_slot->confirmed_lsn < slot->data.confirmed_flush) > > elog(ERROR, > > "cannot

Re: Can't find not null constraint, but \d+ shows that

jian he 于2024年4月12日周五 10:12写道： > On Thu, Apr 11, 2024 at 10:48 PM Alvaro Herrera > wrote: > > > > > > I'm still not ready with this -- still not convinced about the new AT > > pass. Also, I want to add a test for the pg_dump behavior, and there's > > an XXX comment. > > > Now I am more

Re: BitmapHeapScan streaming read user and prelim refactoring

On Sun, Apr 7, 2024 at 10:42 PM Tomas Vondra wrote: > create table t (a int, b int) with (fillfactor=10); > insert into t select mod((i/22),2), (i/22) from generate_series(0,1000) > S(i); > create index on t(a); > vacuum analyze t; > > set enable_indexonlyscan = off; > set enable_seqscan = off;

Re: Issue with the PRNG used by Postgres

I wrote: > ... But Robert's question remains: how does > PANIC'ing after awhile make anything better? I flat out don't > believe the idea that having a backend stuck on a spinlock > would otherwise go undetected. Oh, wait. After thinking a bit longer I believe I recall the argument for this

Re: post-freeze damage control

On 4/12/24 12:15, Robert Haas wrote: On Thu, Apr 11, 2024 at 5:48 PM David Steele wrote: But they'll try because it is a new pg_basebackup feature and they'll assume it is there to be used. Maybe it would be a good idea to make it clear in the documentation that significant tooling will be

Re: pg_upgrde failed : logical replication : alter_subscription_add_log

On Fri, Apr 12, 2024 at 6:18 AM Perumal Raj wrote: > > I am trying to upgrade PostgreSQL (RHEL 7) from version 13.7 to 15.6 using > pglogical. > My Standby(destination) machine has following rpms, > > postgresql13-pglogical-3.7.16-1.el7.x86_64 > pglogical_15-2.4.3-1.rhel7.x86_64 > > And

Re: Issue with the PRNG used by Postgres

Robert Haas writes: > On Thu, Apr 11, 2024 at 5:30 PM Andres Freund wrote: >> By far the most of the stuck spinlocks I've seen were due to bugs in >> out-of-core extensions. Absurdly enough, the next common thing probably is >> due >> to people using gdb to make an uninterruptible process break

Re: Issue with the PRNG used by Postgres

On Thu, Apr 11, 2024 at 5:30 PM Andres Freund wrote: > I don't think that's a particularly apt comparison. If you have spinlocks that > cannot be acquired within tens of seconds, you're in a really bad situation, > regardless of whether you crash-restart or not. I agree with that. I just don't

Re: promotion related handling in pg_sync_replication_slots()

On Sat, Apr 6, 2024 at 12:25 PM Bharath Rupireddy wrote: > > On Fri, Apr 5, 2024 at 10:31 AM shveta malik wrote: > > > > Please find v2. Changes are: > > Thanks for the patch. Here are some comments. Thanks for reviewing. > > 1. Can we have a clear saying in the shmem variable who's syncing at

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Thu, Apr 11, 2024 at 9:54 PM Alexander Korotkov wrote: > I think we shouldn't unconditionally copy schema name and > relpersistence from the parent table. Instead we should throw the > error on a mismatch like CREATE TABLE ... PARTITION OF ... does. I'm > working on revising this fix. We

Re: promotion related handling in pg_sync_replication_slots()

On Sat, Apr 6, 2024 at 11:49 AM Amit Kapila wrote: > > On Fri, Apr 5, 2024 at 10:31 AM shveta malik wrote: > > > > Please find v2. Changes are: > > 1) Rebased the patch as there was conflict due to recent commit 6f132ed. > > 2) Added an Assert in update_synced_slots_inactive_since() to ensure >

Re: post-freeze damage control

On Thu, Apr 11, 2024 at 5:48 PM David Steele wrote: > But they'll try because it is a new pg_basebackup feature and they'll > assume it is there to be used. Maybe it would be a good idea to make it > clear in the documentation that significant tooling will be required to > make it work. I don't

Re: Should we add a compiler warning for large stack frames?

Hi, On 2024-04-11 15:07:11 -0700, Andres Freund wrote: > On 2024-04-11 16:35:58 -0400, Tom Lane wrote: > > Indeed. I recall reading, not long ago, some Linux kernel docs to the > > effect that automatic stack growth is triggered by a reference into > > the page just below what is currently

Re: Can't find not null constraint, but \d+ shows that

On Thu, Apr 11, 2024 at 10:48 PM Alvaro Herrera wrote: > > > I'm still not ready with this -- still not convinced about the new AT > pass. Also, I want to add a test for the pg_dump behavior, and there's > an XXX comment. > Now I am more confused... +-- make sure attnotnull is reset correctly

Re: Allow non-superuser to cancel superuser tasks.

At Fri, 12 Apr 2024 09:10:35 +0900, Michael Paquier wrote in > On Thu, Apr 11, 2024 at 04:55:59PM +0500, Kirill Reshke wrote: > > The test doesn't fail because pg_terminate_backend actually meets his > > point: autovac is killed. But while dying, autovac also receives > > segfault. Thats

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Thu, Apr 11, 2024 at 8:00 PM Alexander Lakhin wrote: > 11.04.2024 16:27, Dmitry Koval wrote: > > > > Added correction (and test), see > > v3-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch. > > > > Thank you for the correction, but may be an attempt to merge into implicit >

Re: Simplify documentation related to Windows builds

On Fri, Mar 22, 2024 at 01:34:43PM -0400, Robert Haas wrote: > I'm not very knowledgeable about building software about Windows in > general, but on the rare occasions that I've done it, it was MUCH > harder to figure out where to get things like Perl that it is on Linux > or macOS machines. On

Re: Should we add a compiler warning for large stack frames?

Andres Freund writes: > On 2024-04-11 16:35:58 -0400, Tom Lane wrote: >> Indeed. I recall reading, not long ago, some Linux kernel docs to the >> effect that automatic stack growth is triggered by a reference into >> the page just below what is currently mapped as your stack, and >> therefore

Re: SET ROLE documentation improvement

On Thu, Apr 11, 2024 at 02:21:49PM -0500, Nathan Bossart wrote: > No objections here. I'll give this a few days for others to comment. I'm > not particularly interested in back-patching this since it's arguably not > fixing anything that's incorrect, but if anyone really wants me to, I will.

Re: session username in default psql prompt?

On Tue, Mar 26, 2024 at 7:14 AM Andrew Dunstan wrote: > > > > On Mon, Mar 25, 2024 at 9:14 AM Jelte Fennema-Nio wrote: >> >> On Mon, 25 Mar 2024 at 14:06, Robert Haas wrote: >> > On Mon, Mar 25, 2024 at 4:30 AM Jelte Fennema-Nio >> > wrote: >> > > That problem seems easy to address by adding

pg_upgrde failed : logical replication : alter_subscription_add_log

Hi Community I am trying to upgrade PostgreSQL (RHEL 7) from version 13.7 to 15.6 using pglogical. My Standby(destination) machine has following rpms, *postgresql13-pglogical-3.7.16-1.el7.x86_64pglogical_15-2.4.3-1.rhel7.x86_64* And Primary(Source) has ,

Re: Support a wildcard in backtrace_functions

On Wed, Apr 10, 2024 at 11:07:00AM +0200, Jelte Fennema-Nio wrote: > I think patch 0002 should be considered an Open Item for PG17. Since > it's proposing changing the name of the newly introduced > backtrace_on_internal_error GUC. If we want to change it in this way, > we should do it before the

Re: Allow non-superuser to cancel superuser tasks.

On Thu, Apr 11, 2024 at 04:55:59PM +0500, Kirill Reshke wrote: > The test doesn't fail because pg_terminate_backend actually meets his > point: autovac is killed. But while dying, autovac also receives > segfault. Thats because of injections points: > > (gdb) bt > #0 0x56361c3379ea in tas

Re: POC: GROUP BY optimization

I'm late to the party, and I apologize for not having paid attention to this thread for months ... but I am wondering why 0452b461b got committed. It seems to add a substantial amount of complexity and planner cycles in return for not much. The reason why I'm dubious about it can be found in

Re: Table AM Interface Enhancements

On Thu, Apr 11, 2024 at 11:27 PM Robert Haas wrote: > On Thu, Apr 11, 2024 at 1:46 PM Alexander Korotkov > wrote: > > I understand that I'm the bad guy of this release, not sure if my > > opinion counts. > > > > But what is going on here? I hope this work is targeting pg18. > > Otherwise, do I

Re: Add notes to pg_combinebackup docs

On 4/11/24 20:51, Tomas Vondra wrote: On 4/11/24 02:01, David Steele wrote: I have a hard time seeing this feature as being very useful, especially for large databases, until pg_combinebackup works on tar (and compressed tar). Right now restoring an incremental requires at least twice the

Re: Should we add a compiler warning for large stack frames?

Hi, On 2024-04-11 16:35:58 -0400, Tom Lane wrote: > Andres Freund writes: > > d8f5acbdb9b made me wonder if we should add a compiler option to warn when > > stack frames are large. gcc compatible compilers have -Wstack-usage=limit, > > so > > that's not hard. > > > Huge stack frames are

Re: Table AM Interface Enhancements

On Fri, Apr 12, 2024 at 12:04 AM Andres Freund wrote: > On 2024-04-11 20:46:02 +0300, Alexander Korotkov wrote: > > I hope this work is targeting pg18. > > I think anything of the scope discussed by Melanie would be very clearly > targeting 18. For 17, I don't know yet whether we should revert

Re: post-freeze damage control

On 4/11/24 20:26, Tomas Vondra wrote: On 4/11/24 03:52, David Steele wrote: On 4/11/24 10:23, Tom Kincaid wrote: The extensive Beta process we have can be used to build confidence we need in a feature that has extensive review and currently has no known issues or outstanding objections. I

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-11 16:46:23 -0400, Robert Haas wrote: > On Thu, Apr 11, 2024 at 3:52 PM Andres Freund wrote: > > My suspicion is that most of the false positives are caused by lots of > > signals > > interrupting the pg_usleep()s. Because we measure the number of delays, not > > the actual time

Re: [Patch] add multiple client certificate selection feature

Hello I would like to share an updated patch that adds a feature to libpq to automatically select the best client certificate to send to the server (if it requests one). This feature is inspired by this email discussion years ago:

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-11 16:46:10 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2024-04-11 16:11:40 -0400, Tom Lane wrote: > >> We wouldn't need to fix it, if we simply removed the NUM_DELAYS > >> limit. Whatever kicked us off the sleep doesn't matter, we might > >> as well go check the

Re: Table AM Interface Enhancements

Hi, On 2024-04-11 20:46:02 +0300, Alexander Korotkov wrote: > I hope this work is targeting pg18. I think anything of the scope discussed by Melanie would be very clearly targeting 18. For 17, I don't know yet whether we should revert the the ANALYZE streaming read user (041b96802ef), just do a

Re: Issue with the PRNG used by Postgres

On Thu, Apr 11, 2024 at 3:52 PM Andres Freund wrote: > My suspicion is that most of the false positives are caused by lots of signals > interrupting the pg_usleep()s. Because we measure the number of delays, not > the actual time since we've been waiting for the spinlock, signals > interrupting

Re: Issue with the PRNG used by Postgres

Andres Freund writes: > On 2024-04-11 16:11:40 -0400, Tom Lane wrote: >> We wouldn't need to fix it, if we simply removed the NUM_DELAYS >> limit. Whatever kicked us off the sleep doesn't matter, we might >> as well go check the spinlock. > I suspect we should fix it regardless of whether we

Re: Should we add a compiler warning for large stack frames?

Andres Freund writes: > d8f5acbdb9b made me wonder if we should add a compiler option to warn when > stack frames are large. gcc compatible compilers have -Wstack-usage=limit, so > that's not hard. > Huge stack frames are somewhat dangerous, as they can defeat our stack-depth > checking logic.

Re: Table AM Interface Enhancements

On Thu, Apr 11, 2024 at 1:46 PM Alexander Korotkov wrote: > I understand that I'm the bad guy of this release, not sure if my > opinion counts. > > But what is going on here? I hope this work is targeting pg18. > Otherwise, do I get this right that this post feature-freeze works on > designing a

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-11 16:11:40 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2024-04-11 15:24:28 -0400, Robert Haas wrote: > >> Or, rip out the whole, whole mechanism and just don't PANIC. > > > I continue believe that that'd be a quite bad idea. > > I'm warming to it myself. > > > My

Re: Should we add a compiler warning for large stack frames?

Hi, On 2024-04-11 15:16:57 -0400, Andrew Dunstan wrote: > On 2024-04-11 Th 15:01, Andres Freund wrote: > > [1345/1940 42 69%] Compiling C object > > src/bin/pg_verifybackup/pg_verifybackup.p/pg_verifybackup.c.o > >

Re: Issue with the PRNG used by Postgres

Andres Freund writes: > On 2024-04-11 15:24:28 -0400, Robert Haas wrote: >> Or, rip out the whole, whole mechanism and just don't PANIC. > I continue believe that that'd be a quite bad idea. I'm warming to it myself. > My suspicion is that most of the false positives are caused by lots of

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-10 21:52:59 -0400, Tom Lane wrote: > Less drastically, I wonder if we should call finish_spin_delay > at all in these off-label uses of perform_spin_delay. What > we're trying to measure there is the behavior of TAS() spin loops, > and I'm not sure that what LWLockWaitListLock and

Re: Issue with the PRNG used by Postgres

Robert Haas writes: > On Wed, Apr 10, 2024 at 9:53 PM Tom Lane wrote: >> Maybe we should rip out the whole mechanism and hard-wire >> spins_per_delay at 1000 or so. > Or, rip out the whole, whole mechanism and just don't PANIC. By that you mean "remove the NUM_DELAYS limit", right? We still

Re: Issue with the PRNG used by Postgres

Hi, On 2024-04-11 15:24:28 -0400, Robert Haas wrote: > On Wed, Apr 10, 2024 at 9:53 PM Tom Lane wrote: > > Maybe we should rip out the whole mechanism and hard-wire > > spins_per_delay at 1000 or so. > > Or, rip out the whole, whole mechanism and just don't PANIC. I continue believe that

Re: Issue with the PRNG used by Postgres

On Wed, Apr 10, 2024 at 9:53 PM Tom Lane wrote: > Maybe we should rip out the whole mechanism and hard-wire > spins_per_delay at 1000 or so. Or, rip out the whole, whole mechanism and just don't PANIC. I'm not 100% sure that's better, but I think it's worth considering. The thing is, if you're

Re: allow changing autovacuum_max_workers without restarting

On Thu, Apr 11, 2024 at 03:37:23PM +, Imseih (AWS), Sami wrote: >> My concern with this approach is that other background workers could use up >> all the slots and prevent autovacuum workers from starting > > That's a good point, the current settings do not guarantee that you > get a worker

Re: SET ROLE documentation improvement

On Thu, Apr 11, 2024 at 01:38:37PM -0400, Robert Haas wrote: > On Thu, Apr 11, 2024 at 1:03 PM Nathan Bossart > wrote: >> While it's fresh on my mind, I very hastily hacked together a draft of what >> I believe is the remaining work. > > That looks fine to me. And if others agree, I think it's

Re: Should we add a compiler warning for large stack frames?

On 2024-04-11 Th 15:01, Andres Freund wrote: Hi, d8f5acbdb9b made me wonder if we should add a compiler option to warn when stack frames are large. gcc compatible compilers have -Wstack-usage=limit, so that's not hard. Huge stack frames are somewhat dangerous, as they can defeat our

Should we add a compiler warning for large stack frames?

Hi, d8f5acbdb9b made me wonder if we should add a compiler option to warn when stack frames are large. gcc compatible compilers have -Wstack-usage=limit, so that's not hard. Huge stack frames are somewhat dangerous, as they can defeat our stack-depth checking logic. There are also some cases

Re: RFC: Additional Directory for Extensions

On Apr 4, 2024, at 1:20 PM, David E. Wheeler wrote: > I’ve added some docs based on your GUC description; updated patch attached. Here’s a rebase. I realize this probably isn’t going to happen for 17, given the freeze, but I would very much welcome feedback and pointers to address concerns

Re: Table AM Interface Enhancements

On Thu, Apr 11, 2024 at 12:19 PM Melanie Plageman wrote: > > On Wed, Apr 10, 2024 at 5:21 PM Andres Freund wrote: > > > > Hi, > > > > On 2024-04-10 16:50:44 -0400, Melanie Plageman wrote: > > > This brings up a question about the prefetching. We never had to have > > > this discussion for

Re: Table AM Interface Enhancements

Hi! On Thu, Apr 11, 2024 at 7:19 PM Melanie Plageman wrote: > On Wed, Apr 10, 2024 at 5:21 PM Andres Freund wrote: > > On 2024-04-10 16:50:44 -0400, Melanie Plageman wrote: > > > This brings up a question about the prefetching. We never had to have > > > this discussion for sequential scan

Re: SET ROLE documentation improvement

On Thu, Apr 11, 2024 at 1:03 PM Nathan Bossart wrote: > On Thu, Apr 11, 2024 at 11:48:30AM -0500, Nathan Bossart wrote: > > On Thu, Apr 11, 2024 at 11:36:52AM -0400, Robert Haas wrote: > >> I suggest that we close the existing CF entry as committed and > >> somebody can start a new one for

Re: Table AM Interface Enhancements

On Thu, Apr 11, 2024 at 8:11 PM Jeff Davis wrote: > On Wed, 2024-04-10 at 15:19 +0300, Alexander Korotkov wrote: > > 1) 9bd99f4c26 comprises the reworked patch after working with notes > > from Jeff Davis. I agree it would be better to wait for him to > > express explicit agreement. Before

Re: Table AM Interface Enhancements

On Wed, 2024-04-10 at 15:19 +0300, Alexander Korotkov wrote: > 1) 9bd99f4c26 comprises the reworked patch after working with notes > from Jeff Davis.  I agree it would be better to wait for him to > express explicit agreement.  Before reverting this, I would prefer to > hear his opinion. On this

Re: SET ROLE documentation improvement

On Thu, Apr 11, 2024 at 11:48:30AM -0500, Nathan Bossart wrote: > On Thu, Apr 11, 2024 at 11:36:52AM -0400, Robert Haas wrote: >> I suggest that we close the existing CF entry as committed and >> somebody can start a new one for whatever remains. I think that will >> be less confusing. > > Done:

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

11.04.2024 16:27, Dmitry Koval wrote: Added correction (and test), see v3-0001-Fix-for-SPLIT-MERGE-partitions-of-temporary-table.patch. Thank you for the correction, but may be an attempt to merge into implicit pg_temp should fail just like CREATE TABLE ... PARTITION OF ... does? Please

Re: SET ROLE documentation improvement

On Thu, Apr 11, 2024 at 11:36:52AM -0400, Robert Haas wrote: > I suggest that we close the existing CF entry as committed and > somebody can start a new one for whatever remains. I think that will > be less confusing. Done: https://commitfest.postgresql.org/48/4923/. -- Nathan Bossart Amazon

Re: Another WaitEventSet resource leakage in back branches

Hi, On 2024-03-22 21:15:45 +0900, Etsuro Fujita wrote: > While working on [1], I noticed $SUBJECT: WaitLatchOrSocket in back > branches is ignoring the possibility of failing partway through, too. > I added a PG_FAINALLY block to that function, like commit 555276f85. > Patch attached. Could you

Re: Table AM Interface Enhancements

On Wed, Apr 10, 2024 at 5:21 PM Andres Freund wrote: > > Hi, > > On 2024-04-10 16:50:44 -0400, Melanie Plageman wrote: > > This brings up a question about the prefetching. We never had to have > > this discussion for sequential scan streaming read because it didn't > > (and still doesn't) do

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 11/04/2024 18:09, Alexander Korotkov wrote: On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas wrote: On 07/04/2024 00:52, Alexander Korotkov wrote: * At first, we check that pg_wal_replay_wait() is called in a non-atomic * context. That is, a procedure call isn't wrapped

Re: allow changing autovacuum_max_workers without restarting

> My concern with this approach is that other background workers could use up > all the slots and prevent autovacuum workers from starting That's a good point, the current settings do not guarantee that you get a worker for the purpose if none are available, i.e. max_parallel_workers_per_gather,

Re: SET ROLE documentation improvement

On Thu, Apr 11, 2024 at 10:03 AM Nathan Bossart wrote: > On Thu, Apr 11, 2024 at 10:33:15AM +0900, Michael Paquier wrote: > > On Tue, Apr 09, 2024 at 09:21:39AM +0300, Andrey M. Borodin wrote: > >> Can I ask you please to help me with determining status of CF item > >> [0]. Is it committed or

some LLVM function checks missing in meson

I have been checking the pg_config.h generated by configure and meson to see if there is anything materially different. I found that HAVE_DECL_LLVMCREATEGDBREGISTRATIONLISTENER and HAVE_DECL_LLVMCREATEPERFJITEVENTLISTENER are missing on the meson side. Something like the below would appear

Re: Allow non-superuser to cancel superuser tasks.

On Thu, 11 Apr 2024 at 19:07, Nathan Bossart wrote: > > On Thu, Apr 11, 2024 at 04:55:59PM +0500, Kirill Reshke wrote: > > Posting updated version of this patch with comments above addressed. > > I look for a commitfest entry for this one, but couldn't find it. Would > you mind either creating

Re: [HACKERS] make async slave to wait for lsn to be replayed

Hi, Heikki! Thank you for your interest in the subject. On Thu, Apr 11, 2024 at 1:46 AM Heikki Linnakangas wrote: > On 07/04/2024 00:52, Alexander Korotkov wrote: > > On Fri, Apr 5, 2024 at 9:15 PM Alvaro Herrera > > wrote: > >> I'm still concerned that WaitLSNCleanup is only called in

Re: allow changing autovacuum_max_workers without restarting

On Thu, Apr 11, 2024 at 09:42:40AM -0500, Nathan Bossart wrote: > On Thu, Apr 11, 2024 at 02:24:18PM +, Imseih (AWS), Sami wrote: >> max_worker_processes defines a pool of max # of background workers allowed. >> parallel workers and extensions that spin up background workers all utilize >>

Re: Can't find not null constraint, but \d+ shows that

On 2024-Apr-11, Alvaro Herrera wrote: > Well, I think you were right that we should try to handle the situation > of unmarking attnotnull as much as possible, to decrease the chances > that the problematic situation occurs. That means, we can use the > earlier code to handle DROP COLUMN when it

Re: allow changing autovacuum_max_workers without restarting

On Thu, Apr 11, 2024 at 02:24:18PM +, Imseih (AWS), Sami wrote: > max_worker_processes defines a pool of max # of background workers allowed. > parallel workers and extensions that spin up background workers all utilize > from > this pool. > > Should autovacuum_max_workers be able to

Re: Allow non-superuser to cancel superuser tasks.

On Thu, Apr 11, 2024 at 04:55:59PM +0500, Kirill Reshke wrote: >> It's feeling more natural here to check that we have a superuser-owned >> backend first, and then do a lookup of the process type. > >> I figured since there's no reason to rely on that behavior, we might as >> well do a bit of

Re: allow changing autovacuum_max_workers without restarting

> I frequently hear about scenarios where users with thousands upon thousands > of tables realize that autovacuum is struggling to keep up. When they > inevitably go to bump up autovacuum_max_workers, they discover that it > requires a server restart (i.e., downtime) to take effect, causing

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi, Dmitry! On Thu, Apr 11, 2024 at 4:27 PM Dmitry Koval wrote: > 1. > Alexander Lakhin sent a question about index name after MERGE (partition > name is the same as one of the merged partitions): > > start of quote > I'm also confused by an index name after MERGE: > CREATE TABLE t (i

Re: post-freeze damage control

Hi! I also worked with this patch and until your explanation I didn’t fully understand the reasons why it was wrong to have this implementation when removing duplicate OR expressions. Thank you, now I understand it! I agree with explanation of Andrei Lepikhov regarding the fact that there

Re: Allow non-superuser to cancel superuser tasks.

On Thu, Apr 11, 2024 at 04:55:59PM +0500, Kirill Reshke wrote: > Posting updated version of this patch with comments above addressed. I look for a commitfest entry for this one, but couldn't find it. Would you mind either creating one or, if I've somehow missed it, pointing me to the existing

Re: SET ROLE documentation improvement

On Thu, Apr 11, 2024 at 10:33:15AM +0900, Michael Paquier wrote: > On Tue, Apr 09, 2024 at 09:21:39AM +0300, Andrey M. Borodin wrote: >> Can I ask you please to help me with determining status of CF item >> [0]. Is it committed or there's something to move to next CF? > > Only half of the patch

Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)

Em qui., 11 de abr. de 2024 às 09:54, Heikki Linnakangas escreveu: > On 11/04/2024 15:03, Ranier Vilela wrote: > > Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas > > mailto:hlinn...@iki.fi>> escreveu: > > > > On 10/04/2024 21:07, Ranier Vilela wrote: > > > Hi, > > > > >

Re: Typos in the code and README

> On 11 Apr 2024, at 15:29, David Rowley wrote: > > On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, > wrote: >> Now that the tree has settled down a bit post-freeze I ran some tooling to >> check spelling. I was primarily interested in docs and README* which were >>

Re: Improve eviction algorithm in ReorderBuffer

On Thu, Apr 11, 2024 at 10:46 AM Hayato Kuroda (Fujitsu) wrote: > > Dear Heikki, > > I also prototyped the idea, which has almost the same shape. > I attached just in case, but we may not have to see. > > Few comments based on the experiment. Thank you for reviewing the patch. I didn't include

Re: Typos in the code and README

On Fri, 12 Apr 2024, 1:05 am Daniel Gustafsson, wrote: > Now that the tree has settled down a bit post-freeze I ran some tooling to > check spelling. I was primarily interested in docs and README* which were > mostly free from simply typos, while the code had some in various comments > and >

TerminateOtherDBBackends code comments inconsistency.

Hi hackers! While working on [0] i have noticed this comment in TerminateOtherDBBackends function: /* * Check whether we have the necessary rights to terminate other * sessions. We don't terminate any session until we ensure that we * have rights on all the sessions to be terminated. These

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi! 1. Alexander Lakhin sent a question about index name after MERGE (partition name is the same as one of the merged partitions): start of quote I'm also confused by an index name after MERGE: CREATE TABLE t (i int) PARTITION BY RANGE (i); CREATE TABLE tp_0_1 PARTITION OF t FOR

Re: Table AM Interface Enhancements

Hi Andres, On Wed, Apr 10, 2024 at 7:52 PM Andres Freund wrote: > On 2024-04-08 14:54:46 -0400, Robert Haas wrote: > > Exactly how much is getting reverted here? I see these, all since March > > 23rd: > > IMO: > > > > dd1f6b0c17 Provide a way block-level table AMs could re-use > >

Re: Typos in the code and README

On 2024-04-11 Th 09:05, Daniel Gustafsson wrote: Now that the tree has settled down a bit post-freeze I ran some tooling to check spelling. I was primarily interested in docs and README* which were mostly free from simply typos, while the code had some in various comments and one in code.

Typos in the code and README

Now that the tree has settled down a bit post-freeze I ran some tooling to check spelling. I was primarily interested in docs and README* which were mostly free from simply typos, while the code had some in various comments and one in code. The attached fixes all that I came across (not

Re: Improve eviction algorithm in ReorderBuffer

On 11/04/2024 11:20, Masahiko Sawada wrote: On Thu, Apr 11, 2024 at 11:52 AM Masahiko Sawada wrote: We can see 2% ~ 3% performance regressions compared to the current HEAD, but it's much smaller than I expected. Given that we can make the code simple, I think we can go with this direction.

Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)

On 11/04/2024 15:03, Ranier Vilela wrote: Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas mailto:hlinn...@iki.fi>> escreveu: On 10/04/2024 21:07, Ranier Vilela wrote: > Hi, > > Per Coverity. > > The function ReorderBufferTXNByXid, > can return NULL

Re: Fix possible dereference null pointer (src/backend/replication/logical/reorderbuffer.c)

Em qua., 10 de abr. de 2024 às 18:28, Heikki Linnakangas escreveu: > On 10/04/2024 21:07, Ranier Vilela wrote: > > Hi, > > > > Per Coverity. > > > > The function ReorderBufferTXNByXid, > > can return NULL when the parameter *create* is false. > > > > In the functions ReorderBufferSetBaseSnapshot

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi Dmitry, 11.04.2024 11:59, Dmitry Koval wrote: FWIW, I also proposed a patch earlier that fixes error messages and comments in the split partition code Sorry, I thought all the fixes you suggested were already included in v1-0002-Fixes-for-english-text.patch (but they are not). Added

Re: Allow non-superuser to cancel superuser tasks.

Posting updated version of this patch with comments above addressed. 1) pg_signal_autovacuum -> pg_signal_autovacuum_worker, as there seems to be no objections to that. 2) There are comments on how to write if statement: > In core, do_autovacuum() is only called in a process without > a role

RE: Synchronizing slots from primary to standby

On Thursday, April 11, 2024 12:11 PM Amit Kapila wrote: > > On Wed, Apr 10, 2024 at 5:28 PM Zhijie Hou (Fujitsu) > wrote: > > > > On Thursday, April 4, 2024 5:37 PM Amit Kapila > wrote: > > > > > > BTW, while thinking on this one, I > > > noticed that in the function

Re: type in basebackup_incremental.c ?

> On 11 Apr 2024, at 13:16, Andrew Dunstan wrote: > Thanks, I will include that in the cleanups I'm intending to push today. +1, thanks! -- Daniel Gustafsson

Re: type in basebackup_incremental.c ?

On 2024-04-11 Th 06:15, Daniel Gustafsson wrote: On 11 Apr 2024, at 11:49, Daniel Westermann (DWE) wrote: Hi, /* * we expect the find the last lines of the manifest, including the checksum, * in the last MIN_CHUNK bytes of the manifest. We trigger an incremental * parse step if we

Re: type in basebackup_incremental.c ?

>Sent: Thursday, April 11, 2024 12:15 >To: Daniel Westermann (DWE) >Cc: PostgreSQL Hackers >Subject: Re: type in basebackup_incremental.c ? > >> On 11 Apr 2024, at 11:49, Daniel Westermann (DWE) >> wrote: >> >> Hi, >> >> /* >> * we expect the find the last lines of the manifest, including the

Re: Add notes to pg_combinebackup docs

On 4/11/24 02:01, David Steele wrote: > On 4/9/24 19:44, Tomas Vondra wrote: >> >> On 4/9/24 09:59, Martín Marqués wrote: >>> Hello, >>> >>> While doing some work/research on the new incremental backup feature >>> some limitations were not listed in the docs. Mainly the fact that >>>

Re: Comment about handling of asynchronous requests in postgres_fdw.c

On Wed, Apr 10, 2024 at 8:51 PM Etsuro Fujita wrote: > We updated $SUBJECT in back branches to make it clear (see commit > f6f61a4bd), so I would like to propose to do so in HEAD as well for > consistency. Attached is a patch for that. Pushed. Best regards, Etsuro Fujita

  1   2   >