false when there are no tables
in subscription" is outdated now with your fix. Otherwise it looks
fine.
--
Regards,
Dilip Kumar
Google
On Wed, Aug 27, 2025 at 7:47 PM Peter Eisentraut wrote:
>
> >> Please find the revised patch with improved comments and commit messages.
> >>
> > Thanks for the improvements! LGTM.
>
> committed, thanks
>
Thanks Peter.
--
Regards,
Dilip Kumar
Google
en
retain_dead_tuples is disabled")
+ : errmsg("disabling retain_dead_tuples will render
max_conflict_retention_duration ineffective"));
}
I really don't like to make a function for a single ereport, even if
this is being called from multiple places.
--
Regards,
Dilip Kumar
Google
On Tue, Aug 26, 2025 at 11:31 AM Dilip Kumar wrote:
>
> On Sun, Aug 24, 2025 at 5:59 PM Srinath Reddy Sadipiralla
> wrote:
> >
> > Hi,
> > Thanks Dilip and Matheus for working on this , i reviewed the latest patch
> > given my Matheus and it LGTM but i have
this will not behave
correctly, so if we have any extra slash in path we need to retain the
$libdir
--
Regards,
Dilip Kumar
Google
On Fri, Aug 22, 2025 at 7:04 PM Matheus Alcantara
wrote:
>
> Hi,
>
> Thanks for reporting this!
>
> On Fri Aug 22, 2025 at 7:34 AM -03, Dilip Kumar wrote:
> > Simple test to reproduce:
> >
> > Change the module path for any extension as below, like I have do
On Fri, Aug 22, 2025 at 4:04 PM Dilip Kumar wrote:
>
> Simple test to reproduce:
>
> Change the module path for any extension as below, like I have done
> for amcheck and then copy the .so file at $libdir/test/ folder.
> module_pathname = '$libdir/test/amcheck'
>
&g
ibrary_path", "$libdir", pkglib_path);
if (full)
return full;
}
else
{
full = substitute_path_macro(name, "$libdir", pkglib_path);
if (pg_file_exists(full))
return full;
pfree(full
--
Regards,
Dilip Kumar
Google
On Wed, Aug 20, 2025 at 5:46 PM Amit Kapila wrote:
>
> On Wed, Aug 20, 2025 at 11:47 AM Dilip Kumar wrote:
> >
> > On Mon, Aug 18, 2025 at 12:25 PM Amit Kapila
> > wrote:
> > >
> >
> > > One idea to keep things simple for the first version is tha
On Mon, Aug 18, 2025 at 12:25 PM Amit Kapila wrote:
>
> On Fri, Aug 15, 2025 at 2:31 PM Dilip Kumar wrote:
> >
> > Yet another question is about table names, whether we keep some
> > standard name like conflict_log_history_$subid or let users pass the
> > name.
>
he opposite
> conclusion. But note that to make it behave similarly we need to store
> this value persistently in pg_subscription unless you have better
> ideas for this. Theoretically, there are two places where we can
> persist this information, one is with pg_subscription, and other in
> origin. I find it is closer to pg_subscription.
I think it makes sense to store this in pg_subscription to preserve
the decision across restart.
--
Regards,
Dilip Kumar
Google
On Wed, Aug 13, 2025 at 3:39 PM Amit Kapila wrote:
>
> On Fri, Aug 8, 2025 at 10:01 AM Dilip Kumar wrote:
> >
> > On Fri, Aug 8, 2025 at 8:58 AM shveta malik wrote:
> > >
> > > On Thu, Aug 7, 2025 at 3:08 PM Dilip Kumar wrote:
> > > >
> &g
On Tue, Aug 12, 2025 at 3:02 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Tuesday, August 12, 2025 5:01 PM Dilip Kumar wrote:
>
> Hi,
>
> >
> > On Tue, Aug 12, 2025 at 2:21 PM Amit Kapila
> > wrote:
> > >
> > > On Tue, Aug 12, 2025 at
_tuples is false.
> >
>
> How about disallowing this combination?
+1 to disallow that.
--
Regards,
Dilip Kumar
Google
On Fri, Aug 8, 2025 at 8:58 AM shveta malik wrote:
>
> On Thu, Aug 7, 2025 at 3:08 PM Dilip Kumar wrote:
> >
> > So logically for PostgreSQL its an
> > user table but yeah this is created and managed by the extension.
> >
>
> Any idea if the user can alter/dr
should be fine to provide the subscription option first and
if we see complaints about inconvenience we may consider GUC as well
in the future.
--
Regards,
Dilip Kumar
Google
On Thu, Aug 7, 2025 at 1:43 PM shveta malik wrote:
>
> On Thu, Aug 7, 2025 at 12:25 PM shveta malik wrote:
Thanks Shveta for your opinion on the design.
> > On Tue, Aug 5, 2025 at 5:54 PM Dilip Kumar wrote:
> > >
> > > This proposal aims to address thes
local_tuple JSON,
);
Credit: Thanks to Amit Kapila for discussing this offlist and
providing some valuable suggestions.
--
Regards,
Dilip Kumar
Google
t because it changed existing behavior and
hadn't received any complaints, a recent complaint suggests that it's
now better to improve the back branches as well.
--
Regards,
Dilip Kumar
Google
On Fri, Aug 1, 2025 at 9:16 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Friday, August 1, 2025 7:42 PM Dilip Kumar wrote:
> >
> > On Fri, Aug 1, 2025 at 5:02 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> > > > 2.
> > > >
> > > > +
single central function would streamline the
> caller, reducing code duplication. So, maybe we could move the retaindeadtuple
> check into this function as well for consistency. Thoughts ?
Fine with either way, actually I wanted both the check
'retaindeadtuple' and 'track_commit_timestamp' at the same place.
--
Regards,
Dilip Kumar
Google
On Fri, Aug 1, 2025 at 4:46 PM Amit Kapila wrote:
>
> On Fri, Aug 1, 2025 at 4:20 PM Amit Kapila wrote:
> >
> > On Fri, Aug 1, 2025 at 3:58 PM Dilip Kumar wrote:
> > >
> > > 4.
> > > + /*
> > > +* Instead of invoking Ge
emovable_xid is not used here,
+* as it is maintained only by the leader apply worker and unavailable to
+* table sync and parallel apply workers.
+*/
+ slot = SearchNamedReplicationSlot(CONFLICT_DETECTION_SLOT, true);
This comment seems a bit confusing to me, Isn't it actually correct to
just use the "conflict detection slot.xmin" even without any other
reasoning?
--
Regards,
Dilip Kumar
Google
d. Please let me know if you
> need my help in doing so, if we decide to backport the fix.
I think you missed to add the link to the "relevant thread [1] "
--
Regards,
Dilip Kumar
Google
On Fri, Jul 25, 2025 at 9:23 AM Tom Lane wrote:
>
> Dilip Kumar writes:
> > OTOH, we can have a common function and pass object type as parameter
> > i.e. select pg_get_ddl('table', 'mytable'), with this the same
> > function can be extended for
nction and pass object type as parameter
i.e. select pg_get_ddl('table', 'mytable'), with this the same
function can be extended for different object types.
--
Regards,
Dilip Kumar
Google
On Mon, Jul 21, 2025 at 2:36 PM vignesh C wrote:
>
> On Mon, 21 Jul 2025 at 11:15, Dilip Kumar wrote:
> >
> > On Mon, Jul 21, 2025 at 10:36 AM Dilip Kumar wrote:
> > >
> > > I was just trying a different test, so I realized that ALTER
> > > PUBLICAT
On Mon, Jul 21, 2025 at 2:23 PM vignesh C wrote:
>
> On Mon, 21 Jul 2025 at 10:36, Dilip Kumar wrote:
> >
> > I was just trying a different test, so I realized that ALTER
> > PUBLICATION ADD SEQUENCE is not supported, any reason for the same?
> >
> > postgres
On Mon, Jul 21, 2025 at 10:08 AM shveta malik wrote:
>
> On Sat, Jul 19, 2025 at 5:10 PM Amit Kapila wrote:
> >
> > On Fri, Jul 18, 2025 at 11:31 AM Dilip Kumar wrote:
> > >
> > > On Fri, Jul 18, 2025 at 11:25 AM shveta malik
> > > wrote:
> &g
On Mon, Jul 21, 2025 at 10:36 AM Dilip Kumar wrote:
>
> I was just trying a different test, so I realized that ALTER
> PUBLICATION ADD SEQUENCE is not supported, any reason for the same?
>
> postgres[154731]=# ALTER PUBLICATION pub ADD sequence s1;
> ERROR: 42601: invalid publi
On Sun, Jul 20, 2025 at 7:48 PM vignesh C wrote:
>
> On Fri, 18 Jul 2025 at 14:11, Dilip Kumar wrote:
> >
> > On Fri, Jul 18, 2025 at 10:44 AM Dilip Kumar wrote:
> > >
> > > On Thu, Jul 17, 2025 at 4:52 PM vignesh C wrote:
> > > >
> >
>
On Fri, Jul 18, 2025 at 10:44 AM Dilip Kumar wrote:
>
> On Thu, Jul 17, 2025 at 4:52 PM vignesh C wrote:
> >
I was looking at the high level idea of sequence sync worker patch
i.e. 0005, so far I haven't found anything problematic there, but I
haven't completed the review
bility here as it
was not behaving sanely before, so I am fine with providing the
behaviour we are doing with the patch.
--
Regards,
Dilip Kumar
Google
On Fri, Jul 18, 2025 at 10:45 AM shveta malik wrote:
>
> On Fri, Jul 18, 2025 at 10:14 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 17, 2025 at 9:34 AM shveta malik wrote:
> > >
> > > On Wed, Jul 16, 2025 at 3:47 PM Ajin Cherian wrote:
> > > >
&
On Thu, Jul 17, 2025 at 4:52 PM vignesh C wrote:
>
> On Wed, 16 Jul 2025 at 11:15, Dilip Kumar wrote:
> >
> > On Mon, Jul 14, 2025 at 10:03 AM vignesh C wrote:
> > >
> > > On Fri, 11 Jul 2025 at 14:26, shveta malik wrote:
> > > >
> > I ha
tion. After that, synchronization
> can be performed either manually by calling pg_sync_replication_slots
> on the standby, or automatically by enabling sync_replication_slots on
> the standby. When sync_replication_slots is enabled, the failover
> slots are periodically synchronized by the slot sync worker. For the
> synchronization to work, .
I am wondering if we should provide an optional parameter to
pg_sync_replication_slots(), to control whether to wait for the slot
to be synced or just return with ERROR as it is doing now, default can
be wait.
--
Regards,
Dilip Kumar
Google
On Thu, Jul 17, 2025 at 4:44 PM shveta malik wrote:
>
> On Thu, Jul 17, 2025 at 9:56 AM Dilip Kumar wrote:
> >
> > I was just thinking about what are the most practical use cases where
> > a user would need multiple active writer nodes. Most applications
> > typical
when
‘retain_conflict_info’ is set to ON. If this setting is enabled, it
should only be used where absolutely essential. Additionally, the user
or DBA must carefully consider other factors. For instance, if they
use a single subscriber in each zone and subscribe to everything
across all zones, performance will significantly degrade. However, if
managed properly by subscribing only to data relevant to each zone and
using multiple subscribers for parallel apply of different
tables/partitions to reduce delay, it should work fine.
Anyway this is just my thought and others may think differently. And
I am open to hearing others thoughts as well.
--
Regards,
Dilip Kumar
Google
al use.
Maybe at least the commit message of this patch should give some
details on why we need to expose this field.
--
Regards,
Dilip Kumar
Google
On Fri, 11 Jul 2025 at 8:27 PM, Nathan Bossart
wrote:
> On Fri, Jul 11, 2025 at 08:43:05AM +0530, Dilip Kumar wrote:
> > Thanks now, looks good to me.
>
> Thanks for reviewing.
>
> > Additionally IMHO it would be good to add tests with FLUSH_UNLOGGED TRUE
> > and F
t
> of locking can become a dominant part of query startup time.
That's right
> I do not have a better solution right now, but it is worth keeping
> this tradeoff in mind.
I agree. Thanks for your opinion on this.
--
Regards,
Dilip Kumar
Google
On Fri, Jul 11, 2025 at 9:34 AM Zhang Mingli wrote:
>
> On Jul 11, 2025 at 11:36 +0800, Dilip Kumar , wrote:
>
>
> This seems to be quite useful to me, initially I thought if we can
> print the relation and database name then this could be even better
> but it might be a
>
This seems to be quite useful to me, initially I thought if we can
print the relation and database name then this could be even better
but it might be a bad idea to fetch the object name while we are in
error callback. And anyway deadlock error is also reported in the
same format so this makes sense.
--
Regards,
Dilip Kumar
Google
t for the same in attached file.
--
Regards,
Dilip Kumar
Google
extra_test.patch
Description: Binary data
> > note in documentation or is it ok not to mention?
> > 2.b) Currently WAL removal will not happen during upgrade because of
> > max_slot_wal_keep_size, should we add a note about this.
> >
>
> We skip or do a few special things in other parts of the code during
> BinaryUpgrade, but don't mention those, so don't think we need to
> mention this one as well.
Make sense
--
Regards,
Dilip Kumar
Google
On Thu, Jul 10, 2025 at 11:18 AM Dilip Kumar wrote:
>
> On Thu, Jul 10, 2025 at 11:11 AM vignesh C wrote:
> >
> > On Wed, 9 Jul 2025 at 17:47, Dilip Kumar wrote:
> > >
> > > On Wed, Jul 9, 2025 at 5:29 PM Álvaro Herrera
> > > wrote:
>
On Thu, Jul 10, 2025 at 11:11 AM vignesh C wrote:
>
> On Wed, 9 Jul 2025 at 17:47, Dilip Kumar wrote:
> >
> > On Wed, Jul 9, 2025 at 5:29 PM Álvaro Herrera wrote:
> > >
> > > On 2025-Jul-09, Dilip Kumar wrote:
> > >
> > > > O
On Thu, Jul 10, 2025 at 10:34 AM Dilip Kumar wrote:
>
> On Thu, Jul 10, 2025 at 9:55 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 10, 2025 at 9:31 AM Fujii Masao
> > wrote:
> > >
> > >
> > >
> > > On 2025/07/10 4:26, Nathan Bossart wro
On Thu, Jul 10, 2025 at 9:55 AM Dilip Kumar wrote:
>
> On Thu, Jul 10, 2025 at 9:31 AM Fujii Masao
> wrote:
> >
> >
> >
> > On 2025/07/10 4:26, Nathan Bossart wrote:
> > > Here is what I have staged for commit, which I'm planning to do on
ngs, so it needs
> double quotes around each.
I agree that it makes more sense to treat them as 2 separate strings.
--
Regards,
Dilip Kumar
Google
eave them to avoid the risk of breaking any
> > application?
>
> It's impossible to believe that any extension is calling those
> functions.
Right..
--
Regards,
Dilip Kumar
Google
On Wed, Jul 9, 2025 at 5:29 PM Álvaro Herrera wrote:
>
> On 2025-Jul-09, Dilip Kumar wrote:
>
> > On Wed, Jul 9, 2025 at 9:07 AM Dilip Kumar wrote:
>
> > > After further consideration, I believe your proposed method is
> > > superior to forcing the max_slot_
On Wed, Jul 9, 2025 at 9:07 AM Dilip Kumar wrote:
>
> On Tue, Jul 8, 2025 at 5:24 PM Amit Kapila wrote:
> >
> > On Tue, Jul 8, 2025 at 4:49 PM Dilip Kumar wrote:
> > >
> > > On Tue, Jul 8, 2025 at 2:29 PM Amit Kapila
> > > wrote:
> > >
On Tue, Jul 8, 2025 at 5:24 PM Amit Kapila wrote:
>
> On Tue, Jul 8, 2025 at 4:49 PM Dilip Kumar wrote:
> >
> > On Tue, Jul 8, 2025 at 2:29 PM Amit Kapila wrote:
> > >
> > > On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar wrote:
> > > >
> &g
On Tue, Jul 8, 2025 at 2:29 PM Amit Kapila wrote:
>
> On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar wrote:
> >
> > On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote:
> > >
> >
> > > There's a bigger picture here, though. The fundamental thing that
&
On Tue, Jul 8, 2025 at 11:32 AM Dilip Kumar wrote:
>
> On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote:
> >
> > Dilip Kumar writes:
> > >> IMHO we can just query the 'max_slot_wal_keep_size' after
> > >> start_postmaster() and check what is t
On Mon, Jul 7, 2025 at 11:22 PM Tom Lane wrote:
>
> Dilip Kumar writes:
> >> IMHO we can just query the 'max_slot_wal_keep_size' after
> >> start_postmaster() and check what is the final resultant value. So now
> >> we will only throw an error
On Mon, Jul 7, 2025 at 9:47 AM Dilip Kumar wrote:
>
> On Sun, Jul 6, 2025 at 11:57 PM Tom Lane wrote:
> >
> > [ resurrecting an old thread ]
> >
> > Amit Kapila writes:
> > > +bool
> > > +check_max_slot_wal_keep_size(int *newval, void **
y or make
> it do something else, but I think what it's presently doing is
> wrong.
IMHO we can just query the 'max_slot_wal_keep_size' after
start_postmaster() and check what is the final resultant value. So now
we will only throw an error if the final value is not -1. And we can
remove the hook from the server all together. Thoughts?
--
Regards,
Dilip Kumar
Google
On Sat, Jul 5, 2025 at 2:26 PM Dilip Kumar wrote:
>
> On Fri, Jul 4, 2025 at 4:48 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Wed, Jul 2, 2025 at 3:28 PM Hou, Zhijie wrote:
> > > Kindly use the latest patch set for performance testing.
> >
> > D
n after we implement conflict
resolution is it possible that node A will just left with (2,2),
because (1,11) will be deleted while applying the changes from Node C
whereas node C has detected the indirect conflicting update from Node
A as update missing and has inserted the row and it will left with
(1,11) and (2,2). So can it cause divergence as I explained here, or
it will not? If not then can you explain how?
--
Regards,
Dilip Kumar
Google
On Fri, Jul 4, 2025 at 9:56 PM Tom Lane wrote:
>
> Dilip Kumar writes:
> > On Fri, Jul 4, 2025 at 1:22 AM Tom Lane wrote:
> >> There's no initplan in the given test case, so I don't see how
> >> that idea is going to fix it. Also, allowing initplans
On Thu, Jul 3, 2025 at 4:21 PM Amit Kapila wrote:
>
> On Thu, Jul 3, 2025 at 10:57 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 3, 2025 at 10:43 AM Amit Kapila wrote:
> > >
> > > On Thu, Jul 3, 2025 at 10:26 AM Dilip Kumar wrote:
> > > >
> >
On Fri, Jul 4, 2025 at 1:22 AM Tom Lane wrote:
>
> Dilip Kumar writes:
> > On Tue, May 20, 2025 at 1:45 PM DIPESH DHAMELIYA
> > wrote:
> >> I understand but aren't we blocking parallelism for genuine cases with
> >> a very complex query where parallelis
On Thu, Jul 3, 2025 at 10:43 AM Amit Kapila wrote:
>
> On Thu, Jul 3, 2025 at 10:26 AM Dilip Kumar wrote:
> >
> > On Wed, Jul 2, 2025 at 12:58 PM Zhijie Hou (Fujitsu)
> > wrote:
> > >
> >
> > > During local testing, I discovered a bug caused b
fective_xmin = new_xmin;
+ MyReplicationSlot->data.xmin = new_xmin;
+ SpinLockRelease(&MyReplicationSlot->mutex);
+
+ elog(DEBUG1, "updated xmin: %u", MyReplicationSlot->data.xmin);
+
+ ReplicationSlotMarkDirty();
+ ReplicationSlotsComputeRequiredXmin(false);
..
}
--
Regards,
Dilip Kumar
Google
e first code to do it and another reason is if this has to
lock millions of partitions (in case we find matching tuple from
multiple partition during scan) then locking all of them on the fly
from index AM code might not be the best idea.
What's your thought on this? I would appreciate if @Robert Haas can
also share his thoughts.
--
Regards,
Dilip Kumar
Google
On Tue, Jul 1, 2025 at 3:39 PM Zhijie Hou (Fujitsu)
wrote:
>
> On Tue, Jul 1, 2025 at 5:07 PM Dilip Kumar wrote:
> >
> > On Tue, Jul 1, 2025 at 2:24 PM Amit Kapila wrote:
> > >
> > > On Tue, Jul 1, 2025 at 10:53 AM Dilip Kumar wrote:
> > > >
>
On Tue, Jul 1, 2025 at 7:12 PM Amit Langote wrote:
>
> Hi Dilip,
>
> Happy to see you working on this. It’s clear a lot of thought has
> gone into the design.
Thanks, Amit. And thanks for your comment.
> On Tue, Jul 1, 2025 at 6:27 PM Dilip Kumar wrote:
> > 6) Need
On Tue, Jul 1, 2025 at 2:24 PM Amit Kapila wrote:
>
> On Tue, Jul 1, 2025 at 10:53 AM Dilip Kumar wrote:
> >
> > On Tue, Jul 1, 2025 at 10:31 AM Dilip Kumar wrote:
> > >
> > > On Mon, Jun 30, 2025 at 6:59 PM Zhijie Hou (Fujitsu)
> > > wrote:
> &g
On Tue, Jul 1, 2025 at 10:31 AM Dilip Kumar wrote:
>
> On Mon, Jun 30, 2025 at 6:59 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Mon, Jun 30, 2025 at 7:22 PM Amit Kapila wrote:
> > >
>
> I was looking at 0001, it mostly looks fine to me except this one
>
nflict detection.
+ * See maybe_advance_nonremovable_xid.
+ */
+ committs = GetCurrentTimestamp();
}
--
Regards,
Dilip Kumar
Google
-
> HEAD | 804965.6 | 331639.7
> Patch | 804942.6 | 321198.6
>
> The performance results show that the patch does not introduce any
> noticeable overhead across varying message sizes, I felt there was no
> impact because of the additional page header read.
Yeah, that doesn't seem like a regression.
--
Regards,
Dilip Kumar
Google
re.
> I suggest using appropriate macros for 1 and 0 values.
>
> Please, see attached patch (targeted on the master branch).
IMHO, it makes sense to use macros when it's already present for
consistency. So +1 or making this change and the attached patch LGTM
--
Regards,
Dilip Kumar
Google
On Thu, Jun 26, 2025 at 3:20 AM Alexander Korotkov wrote:
>
> On Wed, Jun 25, 2025 at 11:25 AM Dilip Kumar wrote:
> > On Wed, Jun 25, 2025 at 1:18 PM Hayato Kuroda (Fujitsu)
> > wrote:
> > > Another idea is to call ReplicationSlotsComputeRequiredLSN() when at
&
On Thu, Jun 26, 2025 at 11:47 AM Michael Paquier wrote:
>
> On Thu, Jun 26, 2025 at 08:48:32AM +0530, Dilip Kumar wrote:
> > On Thu, Jun 26, 2025 at 6:22 AM Michael Paquier wrote:
> >> So you are suggesting the addition of an extra ReadPageInternal() that
> >>
ouldn't the checks on xlp_rem_len be done a bit earlier than what
> you are proposing in this patch?
I did not get the point, IMHO it has to be validated after the record
on the next page has been read.
--
Regards,
Dilip Kumar
Google
that makes sense, if there is nothing updated on disk then we
can avoid computing this.
--
Regards,
Dilip Kumar
Google
hutdown)
* Recompute the required LSN as SaveSlotToPath() updated
* last_saved_restart_lsn for slots.
*/
- ReplicationSlotsComputeRequiredLSN();
+ if (max_replication_slots > 0)
+ ReplicationSlotsComputeRequiredLSN();
}
--
Regards,
Dilip Kumar
Google
r it returns seems like a
> pretty straightforward answer to me.
Yeah that makes sense, we can not simply wait on another latch which
is not managed by CHECK_FOR_INTERRUPTS(), and IMHO the proposed patch
looks simple for resolving this issue.
--
Regards,
Dilip Kumar
Google
On Wed, Jun 18, 2025 at 4:38 AM Masahiko Sawada wrote:
>
> On Sat, Jun 14, 2025 at 2:32 AM Dilip Kumar wrote:
> >
Thanks for your opinion, Sawada-San.
> Does it need to keep holding dead TIDs for each partition until it
> completes vacuuming all partitions that are cov
up. We could later add a timeout parameter to control maximum
> wait time if this approach seems acceptable.
>
> I tested that, when pgbench TPC-B is running on the primary, calling
> pg_sync_replication_slots() on the standby correctly blocks until I advance
> the
> primary
On Mon, Jun 9, 2025 at 3:28 PM Dilip Kumar wrote:
>
> On Mon, Jun 9, 2025 at 2:03 PM Nikita Malakhov wrote:
> > 4) Update-heavy partitioned tables that should run vacuum frequently.
> > Significant
> > vacuum slowdown would result in going beyond SLAs without corre
On Wed, Jun 11, 2025 at 8:02 PM Dilip Kumar 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?
>
gical replication conflicts, I suggest we consider
defining a dedicated class of error codes, much like we have for FDWs.
IMHO this would be a more future-proof approach, given the potential
for many new conflict detection types in the future.
--
Regards,
Dilip Kumar
Google
erwrite
> existing slots though not sure if it's worth it.
>
> From a database user's perspective, it's necessary to clean up any leftover
> slots on a new standby following a switchover, regardless of whether the
> failover slot feature is supported. Because those leftover slots could lead to
> excessive WAL accumulation.
It's logical for users to clean up existing replication slots on a new
standby. Therefore, the current behavior might not be overly
inconvenient. However, providing a GUC to force slot overwrites could
streamline switchovers, allowing users to do nothing post-switchover.
I'm curious to hear others' thoughts on this.
--
Regards,
Dilip Kumar
Google
On Tue, Jun 10, 2025 at 12:14 PM Dilip Kumar wrote:
>
> On Tue, Jun 10, 2025 at 11:39 AM Amit Kapila wrote:
> >
> > On Mon, Jun 9, 2025 at 7:14 PM Dilip Kumar wrote:
> > >
> > > I was reviewing the code for conflict reporting and beca
On Wed, Jun 11, 2025 at 1:08 AM Bruce Momjian wrote:
>
> On Mon, Jun 9, 2025 at 05:51:25PM -0400, Bruce Momjian wrote:
> > On Mon, Jun 9, 2025 at 03:28:38PM +0530, Dilip Kumar wrote:
> > There are certainly use cases where this would be helpful, but I think
> > the bi
On Tue, Jun 10, 2025 at 3:21 AM Bruce Momjian wrote:
Thanks Bruce for your thoughts on this.
> On Mon, Jun 9, 2025 at 03:28:38PM +0530, Dilip Kumar wrote:
> > On Mon, Jun 9, 2025 at 2:03 PM Nikita Malakhov wrote:
> > > Global Indexes is a very interesting functiona
On Tue, Jun 10, 2025 at 1:25 AM Robert Haas wrote:
>
> On Mon, Jun 9, 2025 at 9:45 AM Dilip Kumar wrote:
> > I was reviewing the code for conflict reporting and became curious
> > about the choice of ERRCODE_T_R_SERIALIZATION_FAILURE. This error code
> > typically s
On Tue, Jun 10, 2025 at 11:39 AM Amit Kapila wrote:
>
> On Mon, Jun 9, 2025 at 7:14 PM Dilip Kumar wrote:
> >
> > I was reviewing the code for conflict reporting and became curious
> > about the choice of ERRCODE_T_R_SERIALIZATION_FAILURE. This error code
> > typic
On Mon, Jun 9, 2025 at 6:55 PM Xuneng Zhou wrote:
>
> Hi Dilip,
>
> Thanks for looking into this!
>
> On Mon, Jun 9, 2025 at 6:56 PM Dilip Kumar wrote:
>>
>> > Thanks for updating the patch! It looks good to me.
>> >
>> > I think we can
rcode(ERRCODE_T_R_SERIALIZATION_FAILURE);
}
Assert(false);
return 0; /* silence compiler warning */
}
--
Regards,
Dilip Kumar
Google
before
> > submitting patches and sending emails.😂
>
> Thanks for updating the patch! It looks good to me.
>
> I think we can mark it as "Ready for Committer" in the CommitFest.
> Unless there are any objections, I'll commit it once v19 development opens.
LGTM, except I suggest using WAIT_EVENT_XACT_COMPLETE instead of
WAIT_EVENT_XACT_DONE. I think it sounds better.
--
Regards,
Dilip Kumar
Google
rd with prioritizing a VACUUM optimization
solution for partitioned tables with global indexes. My initial
proposal touched on a proof-of-concept experiment, which indicated no
significant performance hit with global index after the optimization.
I'll share the detailed VACUUM optimization proposal in this thread
within the next couple of days.
--
Regards,
Dilip Kumar
Google
On Fri, Jun 6, 2025 at 1:01 PM wenhui qiu wrote:
>
> Hi Dilip Kumar
>Thank you for your working on this ,I remember six years ago there was
> talk about global index ，You can see if this mailing list has any references
> to
> (https://www.postgresql.org/message-id/CAL
On Thu, Jun 5, 2025 at 3:59 PM Amit Kapila wrote:
>
> On Thu, Jun 5, 2025 at 2:53 PM Dilip Kumar wrote:
> >
> > On Tue, Jun 3, 2025 at 11:05 AM Nisha Moond
> > wrote:
> > >
> > >
> > > Attached v17 patches. Added a top-up patch 0002
all at once, then (2) is clearly
better.
I'm aiming to submit the first WIP patch set before the July
commitfest. It won't have all the issues ironed out yet, but the main
design will be functional.
Thanks, Robert, for many of the key design ideas and regular
discussion throughout designing this. I'd also like to thank Joe,
Peter Geoghegan, Alvaro, and Masahiko Sawada for discussing the
independent issues with me offlist.
--
Regards,
Dilip Kumar
Google
On Thu, Jun 5, 2025 at 3:59 PM Amit Kapila wrote:
>
> On Thu, Jun 5, 2025 at 2:53 PM Dilip Kumar wrote:
> >
> > On Tue, Jun 3, 2025 at 11:05 AM Nisha Moond
> > wrote:
> > >
> > >
> > > Attached v17 patches. Added a top-up patch 0002
On Thu, Jun 5, 2025 at 2:53 PM Dilip Kumar wrote:
>
> On Tue, Jun 3, 2025 at 11:05 AM Nisha Moond wrote:
> >
> >
> > Attached v17 patches. Added a top-up patch 0002 implementing the idea
> > suggested by Amit above.
>
> I have started reviewing this, althoug
1 - 100 of 1222 matches
Mail list logo
