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: 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

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: 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: 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: [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: 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

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: 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: 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: 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

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: 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: 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: 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: 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: 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 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: 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

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: 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: 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: 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: 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

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: 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 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.

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

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: 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: 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 >

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: 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: 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

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

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: 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: 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?

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

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: 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.

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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

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.

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: 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: 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: 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: [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: 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: 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: 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: 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: 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: 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: 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

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: 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: 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: 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: 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

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: 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: 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: 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: 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: 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: 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

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: 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: 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

apply_scanjoin_target_to_paths and partitionwise join

Hi All, Per below code and comment in apply_scanjoin_target_to_paths(), the function zaps all the paths of a partitioned relation. /* * If the rel is partitioned, we want to drop its existing paths and * generate new ones. This function would still be correct if we kept the * existing paths: we'd

Re: Incorrect handling of IS [NOT] NULL quals on inheritance parents

On Thu, Apr 11, 2024 at 10:23 AM David Rowley wrote: > On Wed, 10 Apr 2024 at 19:12, Richard Guo wrote: > > And I think recording NOT NULL columns for traditional inheritance > > parents can be error-prone for some future optimization where we look > > at an inheritance parent's notnullattnums

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

On Wed, Apr 10, 2024 at 2:10 PM jian he wrote: > > DROP TABLE if exists notnull_tbl2; > CREATE TABLE notnull_tbl2 (c0 int generated by default as IDENTITY, c1 int); > ALTER TABLE notnull_tbl2 ADD CONSTRAINT Q PRIMARY KEY(c0, c1); > ALTER TABLE notnull_tbl2 DROP CONSTRAINT

Re: apply_scanjoin_target_to_paths and partitionwise join

On Thu, Apr 11, 2024 at 12:07 PM Ashutosh Bapat < ashutosh.bapat@gmail.com> wrote: > Hi All, > Per below code and comment in apply_scanjoin_target_to_paths(), the > function zaps all the paths of a partitioned relation. > /* > * If the rel is partitioned, we want to drop its existing paths

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

On Thu, Apr 11, 2024 at 1:22 AM Dmitry Koval wrote: > 2) v1-0002-Fixes-for-english-text.patch - fixes for English text > (comments, error messages etc.). FWIW, I also proposed a patch earlier that fixes error messages and comments in the split partition code at

Re: Add SPLIT PARTITION/MERGE PARTITIONS commands

Hi! 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 missing lines to

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

On 2024-Apr-11, jian he wrote: > now I figured out that > dropping a column of primary key columns will not change other key > columns' "not null" property. > dropping the primary key associated constraint will make all key > columns "not null" property disappear. Well, I think you were right

Re: Improve eviction algorithm in ReorderBuffer

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. Pushed the patch and reverted binaryheap

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

jian he 于2024年4月11日周四 14:40写道： > On Wed, Apr 10, 2024 at 2:10 PM jian he > wrote: > > > > DROP TABLE if exists notnull_tbl2; > > CREATE TABLE notnull_tbl2 (c0 int generated by default as IDENTITY, c1 > int); > > ALTER TABLE notnull_tbl2 ADD CONSTRAINT Q PRIMARY KEY(c0, c1); > > ALTER TABLE

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

On Thu, Apr 11, 2024 at 3:19 PM Tender Wang wrote: > >> +DROP TABLE notnull_tbl1; >> +-- make sure attnotnull is reset correctly when a PK is dropped indirectly >> +CREATE TABLE notnull_tbl1 (c0 int, c1 int, PRIMARY KEY (c0, c1)); >> +ALTER TABLE notnull_tbl1 DROP c1; >> +\d+ notnull_tbl1 >> +

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

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 >>>

  1   2   >