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
ility? because
if a user wants to use both the options together then after creating
the slot they need to track when is the right time to enable the other
option? Not sure if anyone else has this concern or it's just me?
--
Regards,
Dilip Kumar
Google
_extension entries from
> pg_description.
> Attaching the patch for the same.
>
> Thoughts?
>
Attached patch seems to be fixing the issue.
--
Regards,
Dilip Kumar
Google
On Tue, May 20, 2025 at 1:45 PM DIPESH DHAMELIYA
wrote:
>
> > On Tue, May 20, 2025 at 11:57 AM Dilip Kumar wrote:
> >
> > I don't think we can remove the 'maxtuples' parameter from
> > exec_run_select(). In this particular case, the query itself is
&g
On Sun, Jun 1, 2025 at 5:51 PM Daniil Davydov <3daniss...@gmail.com> wrote:
>
> Hi,
>
> On Sun, Jun 1, 2025 at 5:31 PM Dilip Kumar wrote:
> >
> > On Sun, Jun 1, 2025 at 7:52 AM Michael Paquier wrote:
> > >
> > > I doubt that it would be a good ide
from
generate_series(1,100) as i;
ANALYZE ;
select relpages from pg_class where relname='test';
TRUNCATE TABLE test;
ROLLBACK;
--
Regards,
Dilip Kumar
Google
On Tue, May 27, 2025 at 11:45 AM Amit Kapila wrote:
>
> On Mon, May 26, 2025 at 12:46 PM Zhijie Hou (Fujitsu)
> wrote:
> >
> > On Sun, May 25, 2025 at 4:36 PM Dilip Kumar wrote:
> >
> > >
> > > I am thinking can't we make it more deterministic su
s.
> Maybe any thoughts on that?
I haven't reviewed the complete patch or tested it, but I don't see
any issues with it.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
it is not
necessary, don't you think it will impact performance on standby?
because now it has to loop through the procarray on standby to check
whether there is any conflict before applying this WAL.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
case is not harmful?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Sat, May 24, 2025 at 11:00 AM Amit Kapila wrote:
>
> On Sat, May 24, 2025 at 10:29 AM Dilip Kumar wrote:
> >
> > On Sat, May 24, 2025 at 10:04 AM Dilip Kumar wrote:
> > >
> > > On Fri, May 23, 2025 at 9:21 PM Xuneng Zhou wrote:
> > > >
> &
On Sat, May 24, 2025 at 10:04 AM Dilip Kumar wrote:
>
> On Fri, May 23, 2025 at 9:21 PM Xuneng Zhou wrote:
> >
> Looking at v31-0001 again, most of it looks fine except this logic of
> getting the commit_ts after marking the transaction in commit. I see
> in RecordTransa
nmsgs, invalMessages,
RelcacheInitFileInval,
MyXactFlags,
InvalidTransactionId, NULL /*
plain commit */ );
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
SELECT email FROM users);
RETURN user_email;
END;
$$ LANGUAGE plpgsql;
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
ver restart. If we can address
that by making the GUCs reloadable via SIGHUP, that might be enough.
On the other hand, if the goal is to make the behavior fully dynamic,
then we should go all the way, decouple it from wal_level. For
example, we could start logging the extra WAL needed for logical
decoding as soon as a logical slot is created, and stop once all
logical slots are dropped, even if wal_level is still set to logical.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
btree" index, yet also states the
> relation
> is a "btree" index, which can seem contradictory. The actual issue is
> that
> the index is a btree partitioned index, but this detail is missing,
> causing
> possible confusion.
Yes, I found the error message confusing during testing as well, so it
makes sense to improve it.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, May 15, 2025 at 3:14 PM Fujii Masao wrote:
>
>
>
> On 2025/05/15 18:20, Dilip Kumar wrote:
> > On Thu, May 15, 2025 at 2:22 PM Masahiro Ikeda
> > wrote:
> >>
> >> Hi,
> >>
> >> I encountered an assertion failure when a part
k that instead of checking
the relnumber is valid, we shall check whether it's a partitioned rel
and give a separate error that prewarm is not supported for
partitioned tables? And in fact, we can think of supporting this for
the partitioned tables as well in the future, where we c
On Wed, May 14, 2025 at 9:16 AM Amit Kapila wrote:
>
> On Tue, May 13, 2025 at 4:22 PM Dilip Kumar wrote:
> >
> > On Tue, May 13, 2025 at 3:48 PM shveta malik wrote:
> > >
> > > Hi All,
> > >
> > > It is a spin-off thread from earlier discu
On Wed, May 14, 2025 at 12:15 PM Amit Kapila wrote:
>
> On Wed, May 14, 2025 at 11:59 AM Dilip Kumar wrote:
> >
> > On Wed, May 14, 2025 at 9:16 AM Amit Kapila wrote:
> > >
> > > On Tue, May 13, 2025 at 4:22 PM Dilip Kumar wrote:
> > > >
>
y, have we analyzed if there’s a way
to prevent the subscriber from moving the LSN backward in the first
place? That might lead to a cleaner and more robust solution overall.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
omain constraints.
>
> The attached patch addresses this problem.
This makes sense, and the patch also looks good to me.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
You
can just try to apply using git am, and it will report those
whitespace warnings. And for fixing, you can just use
"--whitespace=fix" along with git am.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
On Thu, May 1, 2025 at 7:35 PM Tom Lane wrote:
>
> Bruce Momjian writes:
> > On Thu, May 1, 2025 at 11:05:56AM +0530, Dilip Kumar wrote:
> >> Does it make sense to load "shared_preload_libraries" during binary
> >> upgrade mode?
>
> > Well, the
ase. While it's
true that extensions should ideally handle this themselves, wouldn't
it be safer if we could avoid loading them at all during the binary
upgrade mode?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
1 - 100 of 1198 matches
Mail list logo
