On Thu, Jun 12, 2025 at 4:22 PM shveta malik wrote:
>
> On Thu, Jun 12, 2025 at 11:34 AM Zhijie Hou (Fujitsu)
> wrote:
> >
> >
> > Here is the V35 patch set which includes the following changes:
> >
>
> Thank You for the patches. Few comments:
>
> 1)
> Since now we create slot for rci enabled sub
On Fri, Jun 13, 2025 at 4:36 AM Dmitry Koval wrote:
>
> Hi, Jian He!
>
> Thanks for the notes and patches (again).
> I read a part of emails, I hope to read the rest emails tomorrow.
>
hi.
in doc/src/sgml/ref/alter_table.sgml
Parameters section,
we also need explain
partition_name1
and
partition
On 07.04.25 21:15, Masahiko Sawada wrote:
On Sun, Apr 6, 2025 at 7:19 PM Zhijie Hou (Fujitsu)
wrote:
On Sat, Apr 5, 2025 at 1:45 AM Masahiko Sawada wrote:
Hi,
Thank you for updating the patch! Pushed with small cosmetic changes.
Thanks for pushing the feature !
I noticed one typo in the
Hi, Cary,
I have two comments:
1. Does table_beginscan_parallel_tidrange() need an assert of relid,
like what table_beginscan_parallel() did?
Assert(RelationGetRelid(relation) == pscan->phs_relid);
2. The new field phs_numblock in ParallelBlockTableScanDescData
structure has almost the same name
On 12.06.25 23:20, Jeff Davis wrote:
On Thu, 2025-06-12 at 21:16 +0200, Peter Eisentraut wrote:
Do we have other options that are order-sensitive?
I think most of them are. For example:
psql -p 5432 -p 5433
initdb --data-checksums --no-data-checksums
postgres --shared-buffers=1GB --shared-bu
-- Forwarded message -
보낸사람: Sungwoo Chang
Date: 2025년 6월 13일 (금) 오전 8:03
Subject: Re: dsm_registry: Add detach and destroy features
To: Nathan Bossart
> One of the reasons I avoided adding detach/destroy functionality originally
> is because this seems difficult to do correctly
"David G. Johnston" writes:
> On Thu, Jun 12, 2025 at 8:05 PM Fujii Masao
> wrote:
>> Therefore I see this as fixing an oversight in commit bba2fbc6238, so I'd
>> like to commit the 0001 patch as well in v18. Thought?
> You should get the concurrence of the RMT.
> ...
> Also, I was under the imp
On Thu, Jun 12, 2025 at 8:05 PM Fujii Masao
wrote:
> On 2025/06/04 20:18, Fujii Masao wrote:
>
> > I've also re-attached the 0001 patch that makes \conninfo report the full
> > protocol version, it's the same as the one I posted earlier in the
> thread.
>
> The 0001 patch changes \conninfo to rep
On Fri, Jun 13, 2025 at 6:23 AM Perumal Raj wrote:
>
> Hi Hou zj
>
> I have found some strange issue , but not sure if I am doing anything wrong.
>
> I am able to see logical slot at STANDBY even after promote. 👏
Good to know.
>
> Importantly Logical replication slot is persistance in STANDBYs w
On 2025/06/04 20:18, Fujii Masao wrote:
On 2025/06/03 20:22, Robert Treat wrote:
+1 on the idea to put it there; if someone gets confused about the
behavior, that seems like the place they'd go to look it up. Though I
would wordsmith the patch a little:
+ Note that the Client User
On Thu, Jun 12, 2025 at 09:53:13PM -0400, Greg Sabino Mullane wrote:
> On Thu, Jun 12, 2025 at 9:14 AM Peter Eisentraut
> wrote:
>> And this is not something users ever see, so the connection would not be
>> obvious. Maybe this should be called something more specific like
>> \close_stmt.
>
> Ma
On Fri, Jun 13, 2025 at 3:53 AM Nathan Bossart wrote:
>
> On Wed, Jun 11, 2025 at 07:35:39PM +0800, Junwang Zhao wrote:
> > I have created a cf entry to track this.
> >
> > https://commitfest.postgresql.org/patch/5815/
>
> I'll plan on committing this once v19 development begins.
Sure, I just che
On Thu, Jun 12, 2025 at 9:14 AM Peter Eisentraut
wrote:
> And this is not something users ever see, so the connection would not be
> obvious. Maybe this should be called something more specific like
> \close_stmt.
>
Maybe just \closeprepared ?
Cheers,
Greg
--
Crunchy Data - https://www.crunch
I think the overall idea is sound. But we need a better solution for the
truncate fk failure. Can we introspect somehow and do a truncate or do a
delete as necessary? I don't like the idea of simply ignoring the
constraint, or of throwing an error.
--
Cheers,
Greg
--
Crunchy Data - https://www.c
On Thu, Jun 12, 2025 at 4:12 PM Corey Huinker
wrote:
(peacefully skimming thread...)
...
> If we're hot to remove options, how about we remove the sections flags?
> Their utility is reliant upon the user understanding exactly which things
> go in which section, and further assumes that everything
Hi,
Thanks for the feedback!
On Thu, Jun 12, 2025 at 10:02 PM Fujii Masao
wrote:
>
>
> When I first suggested this idea, I used 10s as an example for
> the maximum sleep time. But thinking more about it now, 10s might
> be too long. Even if the target transaction has already finished,
> XactLoc
Hi Hou zj
I have found some strange issue , but not sure if I am doing anything wrong.
*I am able to see logical slot at STANDBY even after promote. 👏*
Importantly Logical replication slot is persistance in STANDBYs which
already established connection with Primary before logical replication slo
On 2025/06/12 23:52, Nathan Bossart wrote:
On Thu, Jun 12, 2025 at 10:18:56AM -0400, Robert Haas wrote:
On Fri, Jun 6, 2025 at 11:40 AM Nathan Bossart wrote:
On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
What is the purpose of the --with-data option? Dumping the data i
On 2025/06/13 6:12, Jeff Davis wrote:
On Thu, 2025-06-12 at 15:57 -0500, Nathan Bossart wrote:
FWIW I don't have a tremendously strong opinion about --statistics-
only.
Same here. I won't cast a vote on this particular issue, as long as the
functionality is available.
I prefer keeping it
Hi,
On 2025-06-09 12:59:20 +0900, Michael Paquier wrote:
> While hacking a different patch, I've noticed that a couple of %llu
> did not get the PRIu64 call in the AIO code, and I don't see why we
> could not switch them. These have been introduced in commits that got
> into the tree after Peter'
On Thu, Jun 12, 2025 at 09:56:28AM -0500, Nathan Bossart wrote:
> On Thu, Jun 12, 2025 at 07:16:37AM +0900, Michael Paquier wrote:
>> Thanks for the review. Adding the RMT in CC for more comments. Would
>> you be OK with the patch added to v18? The answer is probably yes,
>> but let's ask anyway
On Tue, 10 Jun 2025, Nathan Bossart wrote:
So, fseeko() starts winning around 4096 bytes. On macOS, the differences
aren't quite as dramatic, but 4096 bytes is the break-even point there,
too. I imagine there's a buffer around that size somewhere...
This doesn't fully explain the results you
On Thu, Jun 12, 2025 at 4:11 AM John Naylor wrote:
>
> Hi, are we still lacking test coverage for this on v17 and up?
Yep. I have been procrastinating on swapping all this back into my
brain. I'll start working on it today. I think I just take the
reverted test and make the UPDATE a DELETE, set m
Re: Tomas Vondra
> Introduce pg_shmem_allocations_numa view
This is acting up on Debian's 32-bit architectures, namely i386, armel
and armhf:
---
/build/reproducible-path/postgresql-18-18~beta1+20250612/src/test/regress/expected/numa.out
2025-06-12 12:21:21.0 +
+++
On Thu, 2025-06-12 at 21:16 +0200, Peter Eisentraut wrote:
> > Do we have other options that are order-sensitive?
>
> I think most of them are. For example:
>
> psql -p 5432 -p 5433
> initdb --data-checksums --no-data-checksums
> postgres --shared-buffers=1GB --shared-buffers=2GB
Interesting. I
On Thu, 2025-06-12 at 15:57 -0500, Nathan Bossart wrote:
> FWIW I don't have a tremendously strong opinion about --statistics-
> only.
Same here. I won't cast a vote on this particular issue, as long as the
functionality is available.
Regards,
Jeff Davis
On Thu, Jun 12, 2025 at 04:39:00PM -0400, Corey Huinker wrote:
> On Thu, Jun 12, 2025 at 4:22 PM Nathan Bossart
> wrote:
>> I do think this is useful functionality, I only suggested removing it
>> because AFAICT it is redundant, i.e., you can accomplish the same thing
>> with --with-statistics --n
On Thu, Jun 12, 2025 at 4:22 PM Nathan Bossart
wrote:
> On Thu, Jun 12, 2025 at 04:12:35PM -0400, Corey Huinker wrote:
> > The use case for --statistics-only is to extract the existing statistics
> > for the tables and indexes that are involved in a given query that is
> > giving you problems, al
On Thu, Jun 12, 2025 at 04:12:35PM -0400, Corey Huinker wrote:
> The use case for --statistics-only is to extract the existing statistics
> for the tables and indexes that are involved in a given query that is
> giving you problems, allowing you to apply those statistics to an existing
> QA/dev dat
On Thu, Jun 12, 2025 at 1:36 PM Robert Haas wrote:
> On Thu, Jun 12, 2025 at 11:58 AM Jeff Davis wrote:
> > On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> > > If the idea is to remove all options for default behavior, we'd be
> > > removing
> > > --no-statistics, --with-data, and --w
On Thu, Jun 12, 2025 at 12:15:03AM -0500, Sami Imseih wrote:
>> Attached patch removing extra comma. Otherwise LGTM.
>
> Thanks! For v4, the final comma in the list is grammatically correct,
> and it´s the style we use throughout the docs.
+1
> I marked the patch RFC.
Barring comments/objection
On Thu, Jun 12, 2025 at 10:07:05PM +0200, Laurenz Albe wrote:
> I must be missing something, but I think --no-statistics is sorely needed.
> How else can I get the effect of
>
> pg_dump --no-statistics mydb
This was recently changed to be the default behavior (see commit 34eb2a8).
--
nathan
On Thu, 2025-06-12 at 13:36 -0400, Robert Haas wrote:
> On Thu, Jun 12, 2025 at 11:58 AM Jeff Davis wrote:
> > On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> > > If the idea is to remove all options for default behavior, we'd be
> > > removing
> > > --no-statistics, --with-data, and --
On Thu, Mar 6, 2025 at 12:57 PM Jacob Champion
wrote:
> 3) There is a related performance bug on other platforms. If a Curl
> timeout happens partway through a request (so libcurl won't clear it),
> the timer-expired event will stay set and CPU will be burned to spin
> pointlessly on drive_request
On Wed, Jun 11, 2025 at 07:35:39PM +0800, Junwang Zhao wrote:
> I have created a cf entry to track this.
>
> https://commitfest.postgresql.org/patch/5815/
I'll plan on committing this once v19 development begins.
--
nathan
On 12.06.25 17:14, Jeff Davis wrote:
On Thu, 2025-06-12 at 15:47 +0200, Peter Eisentraut wrote:
My initial guess was that --with-data can override --no-data. That
would have been pretty standard "last option wins" behavior. But
pg_dump rejects that. Personally, I think that is kind of wrong.
> Okay, I've done this in the attached patch.
Thanks! v7 LGTM.
--
Sami
On Thu, Jun 12, 2025 at 11:32 AM Álvaro Herrera wrote:
>
> Hello,
>
> I have pushed that now,
thanks!
> and here's a rebase of patch 0003 to add support
> for PARAM_EXTERN. I'm not really sure about this one yet ...
see v11. I added a missing test to show how external param
normalization behav
On Thu, Jun 12, 2025 at 11:58 AM Jeff Davis wrote:
> On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> > If the idea is to remove all options for default behavior, we'd be
> > removing
> > --no-statistics, --with-data, and --with-schema at this point.
>
> That's OK with me.
Same.
> >
I wonder about the following in pg_restore.c.
Right now my implementation covers only parallel restore.
In the case of non-parallel restore, I want to make the behaviour
similar, i.e. each worker to issue a TRUNCATE before COPY starts.
But then the StartTransaction() doesn't make sense, as everyt
On Thu, Jun 12, 2025 at 08:58:15AM -0700, Jeff Davis wrote:
> On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
>> If the idea is to remove all options for default behavior, we'd be
>> removing
>> --no-statistics, --with-data, and --with-schema at this point.
>
> That's OK with me.
>
>>
Hi all,
I went back to my old patch about the "demote" action[1].
# Why?
The goal of the "demote" action is the opposite of the "promote" one: it
turns an "in production" instance to a standby one. This is a required step
to make cluster management easier, as instance, for switching over t
On Wed, Jun 11, 2025 at 7:34 PM Michael Paquier wrote:
>
> On Mon, May 26, 2025 at 10:04:05AM +0900, Sutou Kouhei wrote:
> > As I already said, I don't have a strong opinion on which
> > approach is better. My opinion for the (important) second
> > point is no. I feel that the pros of a. isn't rea
Hello,
I have pushed that now, and here's a rebase of patch 0003 to add support
for PARAM_EXTERN. I'm not really sure about this one yet ...
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"La victoria es para quien se atreve a estar solo"
>From 0a836189a2e3af3b
Hi,
On 2025-06-12 11:52:31 -0400, Andres Freund wrote:
> On 2025-06-12 17:22:22 +0300, Konstantin Knizhnik wrote:
> > On 12/06/2025 4:57 pm, Andres Freund wrote:
> > > The problem appears to be in that switch between "when submitted, by the
> > > IO
> > > worker" and "then again by the backend".
On Thu, 2025-06-12 at 09:52 -0500, Nathan Bossart wrote:
> If the idea is to remove all options for default behavior, we'd be
> removing
> --no-statistics, --with-data, and --with-schema at this point.
That's OK with me.
> Maybe we
> could go a step further and even rip out --statistics-only (i
On Wed, Jun 11, 2025 at 1:01 PM Florents Tselai
wrote:
>
>
>
> On Wed, Jun 11, 2025 at 12:51 PM Jim Jones
> wrote:
>
>> On 10.06.25 15:37, Florents Tselai wrote:
>> > EDIT: There are test under `src/psql/t` , not sure though how much
>> > coverage they have,
>> > but most importantly how it’d lo
Hi,
On 2025-06-12 17:22:22 +0300, Konstantin Knizhnik wrote:
> On 12/06/2025 4:57 pm, Andres Freund wrote:
> > The problem appears to be in that switch between "when submitted, by the IO
> > worker" and "then again by the backend". It's not concurrent access in the
> > sense of two processes writ
On Wed, Jun 11, 2025 at 05:15:36PM -0500, Sami Imseih wrote:
> I tested v6 and I think GetNamedDSA is a good addition. I did
> not find any issues with the code. However, I am still convinced
> that GetNamedDSMHash should not append " Hash" to the tranche
> name of the dshash [0]. I am ok with "
On 2025-Jun-12, Peter Eisentraut wrote:
> This new code uses the term "TLS" where the rest of PostgreSQL, including
> the rest of psql, uses the term "SSL". Making this different seems
> uselessly confusing. I suggest the attached patch to use "SSL" here as
> well.
Sure, let's do that for now.
On Thu, 2025-06-12 at 10:18 -0400, Robert Haas wrote:
> Am I too late to propose ripping this out?
As long as we keep the functionality, I'm fine changing the
options/names around at this point.
Regards,
Jeff Davis
On Thu, 2025-06-12 at 15:47 +0200, Peter Eisentraut wrote:
> My initial guess was that --with-data can override --no-data. That
> would have been pretty standard "last option wins" behavior. But
> pg_dump rejects that. Personally, I think that is kind of wrong.
Do we have other options that a
On Thu, Jun 12, 2025 at 07:16:37AM +0900, Michael Paquier wrote:
> On Wed, Jun 11, 2025 at 09:58:00AM +0200, Peter Eisentraut wrote:
>> On 09.06.25 05:59, Michael Paquier wrote:
>>> That's not necessarily mandatory for v18, for sure, but as this is new
>>> code we could as well clean it up before f
On Thu, Jun 12, 2025 at 10:18:56AM -0400, Robert Haas wrote:
> On Fri, Jun 6, 2025 at 11:40 AM Nathan Bossart
> wrote:
>> On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
>> > What is the purpose of the --with-data option? Dumping the data is the
>> > default. Is this to overri
On Thursday, June 12, 2025, Dimitrios Apostolou wrote:
>
> Why can't walwriter just refuse to write anything above a certain limit,
> thus freezing all other writers until the checkpointer frees a chunk of WAL?
There may be performance reasons discouraging this, but more likely it’s
just a lack
On Tue, 10 Jun 2025, Dimitrios Apostolou wrote:
Rebased and attached new patch. Should I add it to July's commitfest?
Added to commitfest:
https://commitfest.postgresql.org/patch/5817/
On Fri, 4 Apr 2025, Dimitrios Apostolou wrote:
Hello list,
based on the delays I experienced in pg_re
On 2025/06/12 22:47, Peter Eisentraut wrote:
On 06.06.25 17:39, Nathan Bossart wrote:
On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
We have
-a, --data-only dump only the data, not the schema or statistics
--no-data do not dump data
--with-data
On Tue, 10 Jun 2025, David G. Johnston wrote:
On Tuesday, June 10, 2025, Dimitrios Apostolou wrote:
Hello list,
I have previously raised an issue on pgsql-general, where PostgreSQL is
logging without any boundaries to the WAL directory, even if other writer
processes can't catch
yes of course, maybe for PG 19
Regards,
Fabrice
On Thu, Jun 12, 2025 at 12:31 PM Amit Kapila
wrote:
> On Thu, Jun 12, 2025 at 3:53 PM Fabrice Chapuis
> wrote:
> >
> > However, the problem still persists: it is currently not possible to
> perform an automatic switchover after creating a new sub
On Fri, Jun 6, 2025 at 11:40 AM Nathan Bossart wrote:
> On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
> > We have
> >
> > -a, --data-only dump only the data, not the schema or statistics
> > --no-datado not dump data
> > --with-data dump the data
On 21.02.25 19:19, Alvaro Herrera wrote:
I suggest the attached, which gets 99% there with 10% of the
complexity, and has \conninfo (no plus sign) output this:
Connection Information
Parámetro │ Valor
───┼
Base de
On 12/06/2025 4:57 pm, Andres Freund wrote:
The problem appears to be in that switch between "when submitted, by the IO
worker" and "then again by the backend". It's not concurrent access in the
sense of two processes writing to the same value, it's that when switching
from the worker updating
On 2025/06/08 23:33, Xuneng Zhou wrote:
Hi hackers,
This patch implements progressive backoff in XactLockTableWait() and
ConditionalXactLockTableWait().
As Kevin reported in this thread [1], XactLockTableWait() can enter a
tight polling loop during logical replication slot creation on standb
Hi,
On 2025-06-12 16:30:54 +0300, Konstantin Knizhnik wrote:
> On 12/06/2025 4:13 pm, Andres Freund wrote:
> > On 2025-06-12 15:12:00 +0300, Konstantin Knizhnik wrote:
> > I'm reasonably certain I found the issue, I think it's a missing memory
> > barrier on the read side. The CPU is reordering th
On 06.06.25 17:39, Nathan Bossart wrote:
On Fri, Jun 06, 2025 at 09:14:32AM +0200, Peter Eisentraut wrote:
We have
-a, --data-only dump only the data, not the schema or statistics
--no-datado not dump data
--with-data dump the data # this one is new
(and the
On Tue, Jun 10, 2025 at 4:52 PM Mark Dake wrote:
> Happy to clarify further or contribute a patch.
On Thu, Jun 12, 2025 at 9:23 AM Mark Drake wrote:
> Sorry, not a 'C' coder. A man must know his limits. ☹
Uh ... what?
--
Robert Haas
EDB: http://www.enterprisedb.com
On 12/06/2025 4:13 pm, Andres Freund wrote:
Hi,
On 2025-06-12 15:12:00 +0300, Konstantin Knizhnik wrote:
Reproduced it once again with with write-protected io handle.
But once again - no access violation, just assert failure.
Previously "op" field was overwritten somewhere between `pgaio_io_
On Thu, Jun 12, 2025 at 3:09 AM Amit Kapila wrote:
> cases like UPDATE_MISSING, DELETE_MISSING, the existing code
> ERRCODE_NO_DATA_FOUND seems to be an exact match. The LOG message
> appears when we don't find the row to be updated or deleted while
> applying changes. This can happen if someone d
Sorry, not a 'C' coder. A man must know his limits. ☹
-Original Message-
From: David E. Wheeler
Sent: Wednesday, June 11, 2025 11:49 AM
To: Mark Dake
Cc: pgsql-hack...@postgresql.org
Subject: Re: Inconsistent Behavior in JSONB Numeric Array Deletion
On Jun 7, 2025, at 16:20, Mark Dake
I am certainly not tied to the '-' operator, but I think the ability to remove
items from a numeric json array, based on a value would be something that
would benefit many users.
-Original Message-
From: David E. Wheeler
Sent: Wednesday, June 11, 2025 2:48 PM
To: Tom Lane
Cc: Robert
On 24.07.24 07:04, Michael Paquier wrote:
This commit introduces three additional commands: \parse, \bindx and
\close.
\parse creates a prepared statement using extended protocol.
\bindx binds and execute an existing prepared statement using extended
protocol.
\close closes an existing prepared s
Dagfinn Ilmari Mannsåker writes:
> Peter Eisentraut writes:
>
>> On 09.06.25 22:27, Dagfinn Ilmari Mannsåker wrote:
>>> I noticed that psql tab-completes every possible session-settable
>>> variable after RESET, not just the ones that have actually been set in
>>> the current session. However,
Hi,
On 2025-06-12 15:12:00 +0300, Konstantin Knizhnik wrote:
> Reproduced it once again with with write-protected io handle.
> But once again - no access violation, just assert failure.
>
> Previously "op" field was overwritten somewhere between `pgaio_io_reclaim`
> and `AsyncReadBuffers`:
>
> !
On Thu, Jun 12, 2025 at 2:32 PM Fabrice Chapuis wrote:
>
> Thanks for the reply Amit,
>
> I don't really understand the logic of the implementation. If the slot name
> matches that of the primary slot and this slot is in failover mode, how could
> it be any different on the standby slot?
>
On t
On Mon, 9 Jun 2025, Thomas Munro wrote:
On Tue, Jun 3, 2025 at 1:58 AM Dimitrios Apostolou wrote:
This sounds like the best solution IMO. People can then experiment with
different settings and filesystems, and that way we also learn in the
process. Thank you for the effort and patches so far.
Reproduced it once again with with write-protected io handle.
But once again - no access violation, just assert failure.
Previously "op" field was overwritten somewhere between
`pgaio_io_reclaim` and `AsyncReadBuffers`:
!!!pgaio_io_reclaim [20376]| ioh: 0x1019bc000, ioh->op: 0,
ioh->generatio
On Wed, Jun 11, 2025 at 1:44 AM Alexander Korotkov wrote:
>
> On Mon, Jun 9, 2025 at 7:09 PM Vitaly Davydov
> wrote:
> > > I think we can use this approach for HEAD and probably keep the
> > > previous idea for backbranches. Keeping some value in shared_memory
> > > per slot sounds risky to me i
hi.
one more minor issue.
+ * defaultPart: true if one of split partitions is DEFAULT
+ * pstate: pointer to ParseState struct for determining error position
+ */
+static void
+check_two_partitions_bounds_range(Relation parent,
+ RangeVar *first_name,
+ PartitionBoundSpec *first_bound,
+ RangeV
On Thu, Jun 12, 2025 at 11:34 AM Zhijie Hou (Fujitsu)
wrote:
>
>
> Here is the V35 patch set which includes the following changes:
>
Thank You for the patches. Few comments:
1)
Since now we create slot for rci enabled subscription, it will require
wal_level >= replica even on subscribers. We sha
On Thu, Jun 12, 2025 at 12:39 PM Amit Kapila wrote:
>
> On Wed, Jun 11, 2025 at 7:33 PM Robert Haas wrote:
> >
> > On Tue, Jun 10, 2025 at 2:09 AM Amit Kapila wrote:
> > > Can we instead try to use other suitable existing error codes?
> >
> > Why?
> >
> > I mean, I'm not 100% against using exist
On Thu, Jun 12, 2025 at 3:53 PM Fabrice Chapuis wrote:
>
> However, the problem still persists: it is currently not possible to perform
> an automatic switchover after creating a new subscription.
>
> Would it be reasonable to consider adding a GUC to address this issue?
> I can propose a patch i
The parameter* sync_replication_slots* could be tested if it is set to true
before doing any action on failover slots.
Regards,
Fabrice
On Thu, Jun 12, 2025 at 12:06 PM Amit Kapila
wrote:
> On Thu, Jun 12, 2025 at 3:07 PM Amit Kapila
> wrote:
> >
> > On Thu, Jun 12, 2025 at 2:32 PM Fabrice Cha
Hi,
On Thu, Jun 12, 2025 at 1:47 PM Shirisha Shirisha
wrote:
> We’d like to propose a change to improve DELETE and UPDATE behavior on
> partitioned tables
> containing foreign partitions.
>
> Currently, DELETE or UPDATE (D/U) on a partitioned table with foreign
> partitions fails with an error
However, the problem still persists: it is currently not possible to
perform an automatic switchover after creating a new subscription.
Would it be reasonable to consider adding a GUC to address this issue?
I can propose a patch in that sense if it seems appropriate.
What is your opinion
Regards
On Thu, Jun 12, 2025 at 3:07 PM Amit Kapila wrote:
>
> On Thu, Jun 12, 2025 at 2:32 PM Fabrice Chapuis
> wrote:
> >
>
> > After the first failover, the following failovers will work given that the
> > sync flag is true on both the primary and standby slots.
> >
> > After new sandby is attached
Dear Saito-san,
> Dear Ishii-san,
>
>> I wonder how your patches apply to non A4 format (letter). Can you
>> please share the PDF file in letter format after patching?
>
> I had not mentioned the US letter format before, but the patch also
> affects the US letter version.
> I attach a PDF of th
Thanks for the reply Amit,
I don't really understand the logic of the implementation. If the slot name
matches that of the primary slot and this slot is in failover mode, how
could it be any different on the standby slot?
After the first failover, the following failovers will work given that the
s
On Thu, Jun 12, 2025 at 4:08 PM Perumal Raj wrote:
> Hi Community,
>
> I have installed postgres version 17.5 with following setup,
>
> Primary
>-- Secondary A
>-- Secondary B
> -- Secondary C
>
> Config:
> wal_level = 'logical'
> max_wal_senders = '10'
> max
On Thu, Aug 1, 2024 at 4:47 AM Melanie Plageman
wrote:
>
> On Wed, Jul 31, 2024 at 4:38 PM Peter Geoghegan wrote:
> >
> > On Thu, Jun 20, 2024 at 7:42 PM Melanie Plageman
> > wrote:
> > > In back branches starting with 14, failing to remove tuples older than
> > > OldestXmin during pruning cause
Hi Community,
I have installed postgres version 17.5 with following setup,
*Primary *
-- Secondary A
-- Secondary B
-- Secondary C
*Config:*
wal_level = 'logical'
max_wal_senders = '10'
max_replication_slots = '10'
wal_keep_size = '512MB'
hot_standby = 'on'
sync_re
On Wed, Jun 11, 2025 at 7:27 PM Alexander Borisov wrote:
>
> 11.06.2025 10:13, John Naylor wrote:
> > On Tue, Jun 3, 2025 at 1:51 PM Alexander Borisov
> > wrote:
> >> 5. The server part "lost weight" in the binary, but the frontend
> >> "gained weight" a little.
> >>
> >> I read the old com
Hello, Sergey!
This is a great idea, so great as I have implemented it :) Check [0] and
[1] for details.
Review and comments are welcome.
[0]:
https://www.postgresql.org/message-id/flat/CADzfLwVOcZ9mg8gOG%2BKXWurt%3DMHRcqNv3XSECYoXyM3ENrxyfQ%40mail.gmail.com#52c97e004b8f628473124c05e3bf2da1
[1]
On Thu, Jun 12, 2025 at 4:00 AM Peter Smith wrote:
>
> On Wed, Jun 11, 2025 at 8:16 PM Ajin Cherian wrote:
> >
> > On Fri, Jun 6, 2025 at 5:07 PM Nisha Moond wrote:
> > >
> > >
> > > Attached v18 patch.
> > > - patch-001: modified error messages as suggested above.
> > > - patch-002: improved
On Tue, Jun 10, 2025 at 2:29 PM shveta malik wrote:
>
> On Fri, Jun 6, 2025 at 12:37 PM Nisha Moond wrote:
> >
> > Attached v18 patch.
> > - patch-001: modified error messages as suggested above.
> > - patch-002: improved pg_dump docs as per Shveta's off-list suggestions.
> >
>
> Thanks for the
hi.
+/*
+ * check_two_partitions_bounds_range
+ *
+ * (function for BY RANGE partitioning)
+ *
+ * This is a helper function for check_partitions_for_split() and
+ * calculate_partition_bound_for_merge().
check_partitions_for_split does not exist in v43-0001.
+ /*
+ * Rename the existing partiti
On Fri, 2025-02-07 at 11:19 -0800, Jeff Davis wrote:
>
> Attached v15. Just a rebase.
Attached v16.
> * commit this on the grounds that it's a desirable code improvement
> and
> the worst-case regression isn't a major concern; or
I plan to commit this soon after branching. There's a general con
On Wed, Jun 11, 2025 at 7:33 PM Robert Haas wrote:
>
> On Tue, Jun 10, 2025 at 2:09 AM Amit Kapila wrote:
> > Can we instead try to use other suitable existing error codes?
>
> Why?
>
> I mean, I'm not 100% against using existing error codes, but I feel
> like we might be distorting the meanings
On Wed, 2025-06-11 at 17:53 +0200, Christoph Berg wrote:
> I haven't implemented a WAIT option yet since I didn't want to decide
> that without more votes in either direction.
I had a look at it, and I have suggestions for the documentation.
> --- a/doc/src/sgml/ref/checkpoint.sgml
> +++ b/doc/sr
On Thu, May 29, 2025 at 11:30 PM Timur Magomedov
wrote:
>
> Hi Peter,
> I've noticed there are changes in Postgres code v4 patch that rollback
> the commit [1]. That commit optimizes TupleHashEntryData struct size
> and amount of memory allocations which improves performance (see
> discussion [2])
99 matches
Mail list logo
