On Tue, Jul 04, 2023 at 09:48:23AM +0200, Daniel Gustafsson wrote:
>> On 17 Mar 2023, at 10:16, Amit Kapila wrote:
>
>> Few minor comments:
>
> Have you had a chance to address the comments raised by Amit in this thread?
Not yet, sorry.
--
Nathan Bossart
Amazon Web Services: https://aws.amazo
> On 17 Mar 2023, at 10:16, Amit Kapila wrote:
> Few minor comments:
Have you had a chance to address the comments raised by Amit in this thread?
--
Daniel Gustafsson
On Fri, Mar 17, 2023 at 5:52 AM Nathan Bossart wrote:
>
> I've attached a minimally-updated patch that doesn't yet address the bigger
> topics under discussion.
>
> On Thu, Mar 16, 2023 at 03:30:37PM +0530, Amit Kapila wrote:
> > On Wed, Feb 1, 2023 at 5:35 AM Nathan Bossart
> > wrote:
> >> On S
I've attached a minimally-updated patch that doesn't yet address the bigger
topics under discussion.
On Thu, Mar 16, 2023 at 03:30:37PM +0530, Amit Kapila wrote:
> On Wed, Feb 1, 2023 at 5:35 AM Nathan Bossart
> wrote:
>> On Sat, Jan 28, 2023 at 10:26:25AM +0530, Amit Kapila wrote:
>> > BTW, do
On Wed, Feb 1, 2023 at 5:35 AM Nathan Bossart wrote:
>
> On Sat, Jan 28, 2023 at 10:26:25AM +0530, Amit Kapila wrote:
> > On Fri, Jan 27, 2023 at 4:07 AM Tom Lane wrote:
> >> Returning to the prior patch ... I don't much care for this:
> >>
> >> +/* Maybe there will be a free
On Sat, Jan 28, 2023 at 10:26:25AM +0530, Amit Kapila wrote:
> On Fri, Jan 27, 2023 at 4:07 AM Tom Lane wrote:
>> Returning to the prior patch ... I don't much care for this:
>>
>> +/* Maybe there will be a free slot in a second... */
>> +retry_time = Timest
On Fri, Jan 27, 2023 at 4:07 AM Tom Lane wrote:
>
> Thanks, pushed.
>
> Returning to the prior patch ... I don't much care for this:
>
> +/* Maybe there will be a free slot in a second... */
> +retry_time = TimestampTzPlusSeconds(now, 1);
> +
Nathan Bossart writes:
> On Thu, Jan 26, 2023 at 04:09:51PM -0500, Tom Lane wrote:
>> Right, so more like this.
> LGTM
Thanks, pushed.
Returning to the prior patch ... I don't much care for this:
+/* Maybe there will be a free slot in a second... */
+ret
On Thu, Jan 26, 2023 at 04:09:51PM -0500, Tom Lane wrote:
> Right, so more like this.
LGTM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
Nathan Bossart writes:
> On Thu, Jan 26, 2023 at 03:04:30PM -0500, Tom Lane wrote:
>> Hmm. I'm disinclined to add an assumption that the epoch is in the past,
>> but I take your point that the subtraction would overflow with
>> TIMESTAMP_INFINITY and a negative finite timestamp. Maybe we should
On Thu, Jan 26, 2023 at 03:04:30PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> I wonder if we should explicitly reject negative timestamps to eliminate
>> any chance of int64 overflow, too.
>
> Hmm. I'm disinclined to add an assumption that the epoch is in the past,
> but I take your poin
Nathan Bossart writes:
> On Thu, Jan 26, 2023 at 01:54:08PM -0500, Tom Lane wrote:
>> - * Both inputs must be ordinary finite timestamps (in current usage,
>> - * they'll be results from GetCurrentTimestamp()).
>> + * At least one input must be an ordinary finite timestamp, else the "diff"
>> + *
On Thu, Jan 26, 2023 at 01:54:08PM -0500, Tom Lane wrote:
> After looking closer, I see that TimestampDifferenceMilliseconds
> already explicitly states that its output is intended for WaitLatch
> and friends, which makes it perfectly sane for it to clamp the result
> to [0, INT_MAX] rather than de
I wrote:
>>> It'd probably be reasonable to file down that sharp edge by instead
>>> specifying that TimestampDifferenceMilliseconds will clamp overflowing
>>> differences to LONG_MAX. Maybe there should be a clamp on the underflow
>>> side too ... but should it be to LONG_MIN or to zero?
After l
Thomas Munro writes:
> On Thu, Jan 26, 2023 at 3:28 PM Tom Lane wrote:
>> It'd probably be reasonable to file down that sharp edge by instead
>> specifying that TimestampDifferenceMilliseconds will clamp overflowing
>> differences to LONG_MAX. Maybe there should be a clamp on the underflow
>> si
On Thu, Jan 26, 2023 at 3:28 PM Tom Lane wrote:
> Nathan Bossart writes:
> > I think we might risk overflowing "long" when all the wakeup times are
> > DT_NOEND:
>
> >* This is typically used to calculate a wait timeout for WaitLatch()
> >* or a related function. The choice of "l
Nathan Bossart writes:
> I think we might risk overflowing "long" when all the wakeup times are
> DT_NOEND:
>* This is typically used to calculate a wait timeout for WaitLatch()
>* or a related function. The choice of "long" as the result type
>* is to harmonize with that
On Thu, Jan 26, 2023 at 01:23:41PM +1300, Thomas Munro wrote:
> Can we also use TimestampDifferenceMilliseconds()? It knows about
> rounding up for WaitLatch().
I think we might risk overflowing "long" when all the wakeup times are
DT_NOEND:
* This is typically used to calculate a wait
On Thu, Jan 26, 2023 at 12:50 PM Nathan Bossart
wrote:
> I did this in v3. I noticed that many of your comments also applied to the
> similar patch that was recently applied to walreceiver.c, so I created
> another patch to fix that up.
Can we also use TimestampDifferenceMilliseconds()? It know
On Tue, Jan 24, 2023 at 06:45:08PM -0500, Tom Lane wrote:
> I took a look through this, and have a number of mostly-cosmetic
> issues:
Thanks for the detailed review.
> * It seems wrong that next_sync_start isn't handled as one of the
> wakeup[NUM_LRW_WAKEUPS] entries. I see that it needs to be
Nathan Bossart writes:
> [ v2-0001-suppress-unnecessary-wakeups-in-logical-worker.c.patch ]
I took a look through this, and have a number of mostly-cosmetic
issues:
* It seems wrong that next_sync_start isn't handled as one of the
wakeup[NUM_LRW_WAKEUPS] entries. I see that it needs to be acces
rebased for cfbot
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
>From 2466001a3ae6f94aac8eff45b488765e619bea1b Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Thu, 1 Dec 2022 20:50:21 -0800
Subject: [PATCH v2 1/1] suppress unnecessary wakeups in logical/worker.c
---
src/bac
On Mon, Dec 05, 2022 at 01:00:19PM +, Hayato Kuroda (Fujitsu) wrote:
> But in your patch, the apply worker calcurates wakeup[LRW_WAKEUP_PING] and
> wakeup[LRW_WAKEUP_TERMINATE] again when it gets SIGHUP, so the worker never
> sends
> ping with requestReply = true, and never exits due to the ti
Dear Nathan,
Thank you for making the patch! I tested your patch, and it basically worked
well.
About following part:
```
ConfigReloadPending = false;
ProcessConfigFile(PGC_SIGHUP);
+ now = GetCurrentTimestamp();
+
Hi hackers,
I've attached an attempt at porting a similar change to 05a7be9 [0] to
logical/worker.c. The bulk of the patch is lifted from the walreceiver
patch, but I did need to add a hack for waking up after
wal_retrieve_retry_interval to start sync workers. This hack involves a
new wakeup var
25 matches
Mail list logo
