On 10.10.2024 18:14, Fujii Masao wrote:
Thanks for the review! Pushed.
Thanks a lot!
With the best regards,
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 2024/10/08 23:16, Anton A. Melnikov wrote:
On 08.10.2024 15:42, Fujii Masao wrote:
On 2024/09/30 12:26, Fujii Masao wrote:
In 0002.patch, I also modified the description of num_requested from
"Number of backend requested checkpoints" to remove "backend," as it can
be confusing since num_
On 08.10.2024 15:42, Fujii Masao wrote:
On 2024/09/30 12:26, Fujii Masao wrote:
In 0002.patch, I also modified the description of num_requested from
"Number of backend requested checkpoints" to remove "backend," as it can
be confusing since num_requested includes requests from sources other th
On 2024/09/30 12:26, Fujii Masao wrote:
In 0002.patch, I also modified the description of num_requested from
"Number of backend requested checkpoints" to remove "backend," as it can
be confusing since num_requested includes requests from sources other than
the backend. Thought?
Agreed. E.g. f
On 2024/09/30 16:00, Anton A. Melnikov wrote:
On 30.09.2024 06:26, Fujii Masao wrote:
Thanks for the review! I've pushed the 0001 patch.
Thanks a lot!
As for switching in the pg_proc.dat entries the idea was to put them in order
so that the pg_stat_get_checkpointer* functions were groupe
On 30.09.2024 06:26, Fujii Masao wrote:
Thanks for the review! I've pushed the 0001 patch.
Thanks a lot!
As for switching in the pg_proc.dat entries the idea was to put them in order
so that the pg_stat_get_checkpointer* functions were grouped together.
I don't know if this is the common an
On 2024/09/22 13:55, Anton A. Melnikov wrote:
On 20.09.2024 19:19, Fujii Masao wrote:
I've attached the updated version (0001.patch). I made some cosmetic changes,
including reverting the switch in the entries for
pg_stat_get_checkpointer_write_time
and pg_stat_get_checkpointer_sync_time in
On 20.09.2024 19:19, Fujii Masao wrote:
I've attached the updated version (0001.patch). I made some cosmetic changes,
including reverting the switch in the entries for
pg_stat_get_checkpointer_write_time
and pg_stat_get_checkpointer_sync_time in pg_proc.dat, as I didn’t think
that change was nec
On 2024/09/19 19:16, Anton A. Melnikov wrote:
On 18.09.2024 21:04, Fujii Masao wrote:
- CreateCheckPoint(flags);
- ckpt_performed = true;
+ ckpt_performed = CreateCheckPoint(flags);
This change could result in the next scheduled checkpoint being
On 18.09.2024 21:04, Fujii Masao wrote:
- CreateCheckPoint(flags);
- ckpt_performed = true;
+ ckpt_performed = CreateCheckPoint(flags);
This change could result in the next scheduled checkpoint being
triggered in 15 seconds if a checkpoint is skippe
On 2024/09/18 23:35, Anton A. Melnikov wrote:
Fujii, Alexander thanks a lot!
On 17.09.2024 05:47, Fujii Masao wrote:
Regarding the patch:
if (do_restartpoint)
PendingCheckpointerStats.restartpoints_performed++;
+ else
+
On 2024/09/18 21:22, Alexander Korotkov wrote:
Patch attached.
Unless there are any objections, I plan to commit this and back-patch it to v17.
I've checked this patch, it looks good to me.
Generally, it looks like I should be in charge for this, given I've
committed previous patch by Anton
Fujii, Alexander thanks a lot!
On 17.09.2024 05:47, Fujii Masao wrote:
Regarding the patch:
if (do_restartpoint)
PendingCheckpointerStats.restartpoints_performed++;
+ else
+ PendingCheckpointerStats.num_performed++;
I ex
On Wed, Sep 18, 2024 at 1:21 PM Fujii Masao wrote:
> On 2024/09/17 11:47, Fujii Masao wrote:
> >
> >
> > On 2024/09/16 23:30, Anton A. Melnikov wrote:
> >> +1
> >> This idea seems quite tenable to me.
> >>
> >> There is a small clarification. Now if there were no skipped restartpoints
> >> then
>
On 2024/09/17 11:47, Fujii Masao wrote:
On 2024/09/16 23:30, Anton A. Melnikov wrote:
+1
This idea seems quite tenable to me.
There is a small clarification. Now if there were no skipped restartpoints then
restartpoints_done will be equal to restartpoints_timed + restartpoints_req.
Similar
On 2024/09/16 23:30, Anton A. Melnikov wrote:
+1
This idea seems quite tenable to me.
There is a small clarification. Now if there were no skipped restartpoints then
restartpoints_done will be equal to restartpoints_timed + restartpoints_req.
Similar for checkpoints.
So i tried to introduce n
Hi!
On 13.09.2024 18:20, Fujii Masao wrote:
If I understand correctly, restartpoints_timed and restartpoints_done were
separated because a restartpoint can be skipped. restartpoints_timed counts
when a restartpoint is triggered by a timeout, whether it runs or not,
while restartpoints_done only
On 2024/03/14 9:19, Alexander Korotkov wrote:
On Mon, Mar 11, 2024 at 11:48 AM Alexander Korotkov
wrote:
On Mon, Mar 11, 2024 at 5:43 AM Anton A. Melnikov
wrote:
On 11.03.2024 03:39, Alexander Korotkov wrote:
Now that we distinguish stats for checkpoints and
restartpoints, we need to upd
On 14.03.2024 03:19, Alexander Korotkov wrote:
Pushed.
Thanks!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Mon, Mar 11, 2024 at 11:48 AM Alexander Korotkov
wrote:
>
> On Mon, Mar 11, 2024 at 5:43 AM Anton A. Melnikov
> wrote:
> > On 11.03.2024 03:39, Alexander Korotkov wrote:
> > > Now that we distinguish stats for checkpoints and
> > > restartpoints, we need to update the docs. Please, check the
On Mon, Mar 11, 2024 at 5:43 AM Anton A. Melnikov
wrote:
> On 11.03.2024 03:39, Alexander Korotkov wrote:
> > Now that we distinguish stats for checkpoints and
> > restartpoints, we need to update the docs. Please, check the patch
> > attached.
>
> Maybe bring the pg_stat_get_checkpointer_buffers
On 11.03.2024 03:39, Alexander Korotkov wrote:
Now that we distinguish stats for checkpoints and
restartpoints, we need to update the docs. Please, check the patch
attached.
Maybe bring the pg_stat_get_checkpointer_buffers_written() description in
consistent with these changes?
Like that:
--
On Sat, Mar 9, 2024 at 4:38 PM Magnus Hagander wrote:
> Per the docs, the sync_time, write_time and buffers_written only apply
> to checkpoints, not restartpoints. Is this correct? AFAICT from a
> quick look at the code they include both checkpoints and restartpoints
> in which case I think the do
On Fri, Dec 22, 2023 at 11:04 PM Alexander Korotkov
wrote:
>
> Hi, Anton!
>
> On Mon, Dec 4, 2023 at 3:50 AM Anton A. Melnikov
> wrote:
>>
>> Thanks for remarks!
>>
>> On 28.11.2023 21:34, Alexander Korotkov wrote:
>> > After examining the second patch
>> > ("v2-0001-Add-restartpoint-stats.patch
On 25.12.2023 02:38, Alexander Korotkov wrote:
Pushed!
Thanks a lot!
With the best regards!
--
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Sat, Dec 23, 2023 at 12:04 AM Alexander Korotkov
wrote:
> On Mon, Dec 4, 2023 at 3:50 AM Anton A. Melnikov
> wrote:
>>
>> Thanks for remarks!
>>
>> On 28.11.2023 21:34, Alexander Korotkov wrote:
>> > After examining the second patch
>> > ("v2-0001-Add-restartpoint-stats.patch"), it appears th
Hi, Anton!
On Mon, Dec 4, 2023 at 3:50 AM Anton A. Melnikov
wrote:
> Thanks for remarks!
>
> On 28.11.2023 21:34, Alexander Korotkov wrote:
> > After examining the second patch
> > ("v2-0001-Add-restartpoint-stats.patch"), it appears that adding
> > additional statistics as outlined in the patch
Thanks for remarks!
On 28.11.2023 21:34, Alexander Korotkov wrote:
After examining the second patch
("v2-0001-Add-restartpoint-stats.patch"), it appears that adding
additional statistics as outlined in the patch is the most suitable
approach to address the concerns raised. This solution provides
Hi, Anton!
On Thu, Mar 16, 2023 at 2:39 PM Anton A. Melnikov wrote:
> On 15.03.2023 21:29, Gregory Stark (as CFM) wrote:
>
> > These patches that are "Needs Review" and have received no comments at
> > all since before March 1st are these. If your patch is amongst this
> > list I would suggest an
Hello!
On 15.03.2023 21:29, Gregory Stark (as CFM) wrote:
These patches that are "Needs Review" and have received no comments at
all since before March 1st are these. If your patch is amongst this
list I would suggest any of:
1) Move it yourself to the next CF (or withdraw it)
2) Post to the
Hello!
On 06.12.2022 21:44, Andres Freund wrote:
Hi,
On 2022-09-19 01:29:21 +0300, Anton A. Melnikov wrote:
Corrected patch is attached (v2-0001-Fix-burst-checkpoint_req-growth.patch).
This patch doesn't pass the main regression tests tests successfully:
https://cirrus-ci.com/task/550270001
Hi,
On 2022-09-19 01:29:21 +0300, Anton A. Melnikov wrote:
> Corrected patch is attached (v2-0001-Fix-burst-checkpoint_req-growth.patch).
This patch doesn't pass the main regression tests tests successfully:
https://cirrus-ci.com/task/5502700019253248
diff -U3 /tmp/cirrus-ci-build/src/test/regr
Hello!
Thank you very much for your feedback and essential remarks.
On 07.09.2022 10:39, Kyotaro Horiguchi wrote:
It lets XLogPageRead run the same check with what CreateRestartPoint
does, so it basically works (it is forgetting a lock, though. The
reason for omitting the lock in CreateRestart
At Tue, 6 Sep 2022 14:02:53 +0300, "Anton A. Melnikov"
wrote in
> Can we treat such behavior as a bug?
Depends on how we see the counter value. I think this can be annoying
but not a bug. CreateRestartPoint already handles that case.
While standby is well catching up, startup may make requests
Hello!
Found a periodic spike growth of the checkpoint_req counter on replica by 20-30
units
after large insert (~350Mb) on master.
Reproduction on master and replica with default conf:
1) execute the command "insert into test values (generate_series(1,1E7));".
This leads to the table's growth b
35 matches
Mail list logo
