Hi,
> Thanks for the patch! I haven't reviewed it yet, but since this is
> a v19 item, please add it to the next CommitFest so we don't lose
> track of it.
>
> Also, I think it would be better to split the addition of the wait event
> and the introduction of exponential backoff in XactLockTableWai
Hi,
> Just idea, if XactLockTableWait() is expected to finish within a few seconds
> after acquiring the lock, how about this approach: keep sleeping for 1ms
> until the total sleep time reaches 10s (10s is just an example),
> and after that, start doubling the sleep duration each cycle, up to
> a
Hi Fujii,
Thanks a lot for reviewing!
> > This update amends the previous patch by replacing the global
> > XactLockTableWait_us with a local wait_us variable inside
> > XactLockTableWait. Now each call resets its backoff to 1 ms, doubling
> > up to 1 s when oper == XLTW_None. This eliminates shar
Hi all,
This update amends the previous patch by replacing the global
XactLockTableWait_us with a local wait_us variable inside
XactLockTableWait. Now each call resets its backoff to 1 ms, doubling
up to 1 s when oper == XLTW_None. This eliminates shared‐state bugs
(where multiple backends or succ
On 2025/06/03 13:35, Xuneng Zhou wrote:
Hi all,
This update amends the previous patch by replacing the global
XactLockTableWait_us with a local wait_us variable inside
XactLockTableWait. Now each call resets its backoff to 1 ms, doubling
up to 1 s when oper == XLTW_None. This eliminates share
Hi all,
Thank you for the earlier pushed patch—after testing it, things work
well. Per Fujii’s and Kevin’s ideas and suggestions[1], [2], I’ve
tried to extend it to add a new wait event and a progressive backoff
mechanism for XactLockTableWait in logical replication scenarios.
New wait event
• X
On 2025/05/29 5:40, Kevin K Biju wrote:
Hi Fujii,
The WaitEvent sounds good to me, I will submit a separate patch for that when I
find time.
Kevin
On Wed, May 28, 2025 at 5:06 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
On 2025/05/27 4:43, Kevin K Biju wrote:
> H
Hi Fujii,
The WaitEvent sounds good to me, I will submit a separate patch for that
when I find time.
Kevin
On Wed, May 28, 2025 at 5:06 PM Fujii Masao
wrote:
>
>
> On 2025/05/27 4:43, Kevin K Biju wrote:
> > Hi Fujii,
> >
> > Thanks for the review.
>
> So unless there are any objections, I'm p
On 2025/05/27 4:43, Kevin K Biju wrote:
Hi Fujii,
Thanks for the review.
So unless there are any objections, I'm planning to commit
the patch with the following commit message.
---
Make XactLockTableWait() and ConditionalXactLockTableWait() interruptable more.
Previously, Xact
Hi Fujii,
Thanks for the review.
> Just an idea: how about calling pgstat_report_wait_start() and _end()
around pg_usleep(), similar to what WaitExceedsMaxStandbyDelay() does?
I was thinking about this as well, but the question is what do we report
the wait event here as? The one that makes sens
On 2025/05/24 5:41, Kevin K Biju wrote:
Hi,
While creating a logical replication slot, we wait for older transactions to complete to
reach a "consistent point", which can take a while on busy databases. If we're
creating a slot on a primary instance, it's pretty clear that we're waiting on
Hi,
While creating a logical replication slot, we wait for older transactions
to complete to reach a "consistent point", which can take a while on busy
databases. If we're creating a slot on a primary instance, it's pretty
clear that we're waiting on a transaction:
postgres=# SELECT pid,wait_eve
12 matches
Mail list logo
