Hi,
On Fri, Dec 13, 2024 at 11:02:53AM +0900, Michael Paquier wrote:
> On Thu, Dec 12, 2024 at 02:02:38PM +0000, Bertrand Drouvot wrote:
>
> Anyway, isn't it possible that this lookup loop finishes by finding
> nothing depending on concurrent updates of other beentries? It so
Hi,
On Thu, Dec 12, 2024 at 10:15:18AM -0600, Nathan Bossart wrote:
> On Thu, Dec 12, 2024 at 04:36:21AM +0000, Bertrand Drouvot wrote:
> > --- a/src/backend/catalog/system_views.sql
> > +++ b/src/backend/catalog/system_views.sql
> > @@ -1222,7 +1222,8 @@ CREATE VIEW pg_st
Hi,
On Thu, Dec 19, 2024 at 05:50:43PM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> On Thu, 19 Dec 2024 at 08:50, Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Wed, Dec 18, 2024 at 11:55:11AM -0500, Andres Freund wrote:
> > > Yea, i think it'
16%3A28%3A58
Thanks for the report! I was not able able to reproduce (even with asan-enabled)
but I think the test is wrong. Indeed the backend could fsync too during the
test
(see register_dirty_segment() and the case where the request queue is full).
I think the test should look like the atta
Hi,
On Thu, Dec 19, 2024 at 06:12:04AM +, Bertrand Drouvot wrote:
> On Thu, Dec 19, 2024 at 01:21:54PM +0900, Michael Paquier wrote:
> > bumped the two version counters, and done.
> >The existing structure could be expanded in the
> >future to add more in
On Thu, Dec 19, 2024 at 09:57:31AM -0600, Nathan Bossart wrote:
> On Thu, Dec 19, 2024 at 09:36:17AM -0600, Nathan Bossart wrote:
> > On Thu, Dec 19, 2024 at 07:25:30AM +, Bertrand Drouvot wrote:
> >> - errmsg(&quo
Hi,
On Thu, Nov 21, 2024 at 07:18:24AM +0900, Michael Paquier wrote:
> On Wed, Nov 20, 2024 at 02:20:18PM +0000, Bertrand Drouvot wrote:
> > Right. I did not had in mind to go that far here (for the per backend stats
> > needs). My idea was "just" to move the new p
Hi,
On Wed, Dec 04, 2024 at 02:49:11PM +0300, Nazir Bilal Yavuz wrote:
> On Thu, 28 Nov 2024 at 16:39, Bertrand Drouvot
> wrote:
> >
> You are right, no need to have this check; it can not be less than 0.
> I completely removed the function now.
Thanks! Yeah I think that makes
ld be acceptable. Do you agree?
> I didn't see any comments regarding this, so I wanted to confirm.
Added a comment to make it clear, thanks!
[1]:
https://www.postgresql.org/message-id/CAD21AoDOu%3DDZcC%2BPemYmCNGSwbgL1s-5OZkZ1Spd5pSxofWNCw%40mail.gmail.com
Regards,
--
Bertrand Drouvot
PostgreSQL
Hi,
On Wed, Jan 08, 2025 at 03:21:26PM +0900, Michael Paquier wrote:
> On Tue, Jan 07, 2025 at 08:48:51AM +0000, Bertrand Drouvot wrote:
> > Now that commit 9aea73fc61 added backend-level statistics to pgstats (and
> > per backend IO statistics), we can more easily add per bac
Hi,
On Thu, Jan 09, 2025 at 01:03:15PM +0900, Michael Paquier wrote:
> On Wed, Jan 08, 2025 at 11:11:59AM +0000, Bertrand Drouvot wrote:
> > Yeah, that's more elegant as it also means that the main callback will not
> > change
> > (should we add even more stats in the
Hi,
On Wed, Jan 08, 2025 at 02:32:24PM -0500, Andres Freund wrote:
> On 2025-01-08 14:48:21 +0000, Bertrand Drouvot wrote:
> > === 2
> >
> > + default:
> > + /* all signals sent by postmaster should be listed
> > here */
&
ially" above. That would
make it more clear in case one just look for "building index" in the log.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
n.
s/postmaster.c/PostmasterStateMachine()/?
=== 4
+ * too. That allows checkpointer to perform some last bits of of
Typo "of of"
I'll give 0004 a closer look once it leaves the WIP state but want to share that
it looks like a good way to fix the issue.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
the pending stats
> data.
Yeah, makes sense, thanks!
Please find attached v4 taking into account 2c14037bb5.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From c424cd02baba3f441768b1f049a5ec6ad11bc3ce Mon Se
rg/message-id/c70fcc72-eed6-475b-81c8-508422299351%40dalibo.com
[3]:
https://www.postgresql.org/message-id/e8a6db36-073e-4ca3-b38c-b42d7094cba8%40dalibo.com
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
wrote:
> > > >
> > > > On Fri, Jan 3, 2025, at 10:14 AM, Bertrand Drouvot wrote:
> > > >
> > > > If we don't want to force wal_level = logical to enable logical
> > > > decoding (your
> > > > second idea) then I think that i
Hi,
On Fri, Jan 17, 2025 at 08:43:57AM +0900, Michael Paquier wrote:
> On Thu, Jan 16, 2025 at 12:44:20PM -0500, Andres Freund wrote:
> > On 2025-01-16 17:11:09 +, Bertrand Drouvot wrote:
> >> So, do you think that the initial proposal that has been made here (See
> &g
Hi,
On Thu, Jan 23, 2025 at 05:05:30PM +0900, Michael Paquier wrote:
> On Tue, Jan 21, 2025 at 07:19:55AM +0000, Bertrand Drouvot wrote:
> > PFA v6 that now relies on the new PendingBackendStats variable introduced in
> > 4feba03d8b9.
> >
> > Remark: I moved PendingBa
to start writing WAL records with logical information. We
> have a good facility for that: EmitProcSignalBarrier() and
> WaitForProcSignalBarrier(). That way, we don't need to wait for
> transaction finishes.
That sounds like a plan.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ecause it
depends of the amount of data indexed (I mean if the index has a very few
leaf pages, say < 5, then it's easy to be << 90 since it's an average). That's
probably not the majority of indexes though so maybe just nuance the sentence a
bit.
Regards,
--
Bertrand Drouvo
7994+00
(1 row)
postgres=# select sum(write_bytes),stats_reset from pg_stat_io where object =
'wal' group by stats_reset;
sum| stats_reset
--+---
12853248 | 2025-01-24 14:17:28.507988+00
(1 row)
Is that expected?
Regards,
--
Bertrand D
Hi Frédéric,
On Thu, Jan 23, 2025 at 10:00:27AM +0100, Frédéric Yhuel wrote:
> On 1/22/25 12:34, Bertrand Drouvot wrote:
> > I'm not sure it's good to describe something as the inverse of "something
> > else". See my proposal below.
> >
>
> Yeah..
Hi,
On Mon, Jan 20, 2025 at 09:11:16PM +0900, Michael Paquier wrote:
> On Mon, Jan 20, 2025 at 11:10:40AM +0000, Bertrand Drouvot wrote:
> > I think that it would be better to make the distinction based on
> > "local/static"
> > vs "dynamic memory" pendi
ing it in 0002).
PFA:
0001: which is full rebase
0002: the Copyright fix
.txt: the changes I've made on top of your 0002 (to not confuse the cfbot and
to ease your review).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws
systems that support CLOCK_MONOTONIC) then
pg_clock_gettime_ns() should not be affected by system time change IIUC.
Though time changes are "rare", given the fact that those metrics could provide
"inaccurate" measurements during that particular moment (time change) then it
might be wort
e as we are not in a hot path here.
> should just do the attached, which is simpler and addresses your
> use-case. Note also that the end time is acquired while the entries
> are not locked in the report routines, and some tweaks in the docs and
> comments.
LGTM.
Regards,
--
Bert
Hi,
On Fri, Jan 24, 2025 at 03:06:17PM -0500, Andres Freund wrote:
> On 2025-01-15 08:38:33 +0000, Bertrand Drouvot wrote:
> > Fair enough. I'll look at the remaining pieces once this stuff goes in.
>
> Cool. I did try writing the change, but it does indeed seem better a
validation is logged with vacuum on pg_authid'\r\r
> drongo | REL_17_STABLE | 2025-01-24 04:21:44 | recoveryCheck | # Failed
> test 'activeslot slot invalidation is logged with vacuum on pg_authid'\r\r
Out of curiosity, how did you generate this output? (that looks wery useful)
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ction on the primary this would be
> easy, but we can't.
Another idea that I had ([1]) was to make use of injection points
around places where RUNNING_XACTS is emitted. IIRC I tried to work on this but
that was not simple as it sounds as we need the startup process not to be
block
heck and that still looks green(ish) (and when it's not,
it does not seem related to this change).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Fri, Jan 24, 2025 at 06:29:46PM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> Thanks for looking into this!
>
> On Fri, 24 Jan 2025 at 17:20, Bertrand Drouvot
> wrote:
> >
> > I did not look at the code yet but did a few tests.
> > I can see diff bet
Hi,
On Mon, Jan 27, 2025 at 09:28:57AM -0500, Tom Lane wrote:
> Bertrand Drouvot writes:
> > On Fri, Jan 24, 2025 at 11:42:15AM -0500, Tom Lane wrote:
> >> PS: FTR, the hits I got on this in the past 90 days were
> >>
> >> sysname |branch
e another GUC like
> track_wal_io_timing to track WAL I/Os' timings.
That's true but OTOH track_wal_io_timing is already there since years (it's not
like we are adding it).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Mon, Jan 27, 2025 at 03:07:01PM +, Bertrand Drouvot wrote:
> On Fri, Jan 24, 2025 at 03:06:17PM -0500, Andres Freund wrote:
> > but in case of an immediate *restart* (via pg_ctl restart -m immediate)
> > we'll
> > not have such hint. postmaster.c doesn't
ing, it's treated as as a reason to crash-restart:
> /*
>* Any unexpected exit of the checkpointer
> (including FATAL
>* exit) is treated as a crash.
>*/
> HandleChildCrash(pid, exitstatus,
>
> _("checkpointer process"));
>
I do agree. I was trying to reach this code path while replying to one of
the above comments (about PM_WAIT_DEAD_END ordering) but had to replace with
another if condition to reach it during testing.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
RelationGetRelid(rel));
+ starttime = GetCurrentTimestamp();
I wonder if it wouldn't make more sense to put the GetCurrentTimestamp() call
before the pgstat_progress_start_command() call. That would be aligned with the
"endtime" being after the pgstat_progress_end_command(
Hi,
On Tue, Jan 14, 2025 at 12:58:44AM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-01-13 12:20:39 +, Bertrand Drouvot wrote:
> > > We have
> > > multiple copies of code to go to FatalError, that doesn't seem great.
> >
> > + * FIXME: This sh
Hi,
On Tue, Dec 24, 2024 at 02:35:16PM +0900, Michael Paquier wrote:
> On Fri, Dec 20, 2024 at 09:57:19AM +0000, Bertrand Drouvot wrote:
> > BTW, now that the per backend I/O statistics is done, I'll start working on
> > per
> > backend wal statistics.
>
>
On Fri, Jan 03, 2025 at 09:47:58AM -0500, Andres Freund wrote:
> On 2024-12-30 19:12:54 +0900, Michael Paquier wrote:
> > On Mon, Dec 30, 2024 at 09:44:45AM +, Bertrand Drouvot wrote:
> > > I think that replicating stats that are used by autovacuum would be an
> > &g
Hi,
On Tue, Dec 03, 2024 at 10:31:15AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Fri, Nov 29, 2024 at 08:52:13PM +0500, Kirill Reshke wrote:
> > On Fri, 29 Nov 2024 at 20:20, Bertrand Drouvot
> > wrote:
> > > On Fri, Nov 29, 2024 at 11:23:12AM +0500, Kirill Res
Hi,
On Mon, Dec 30, 2024 at 07:12:54PM +0900, Michael Paquier wrote:
> On Mon, Dec 30, 2024 at 09:44:45AM +0000, Bertrand Drouvot wrote:
> > I think that replicating stats that are used by autovacuum would be an
> > additional
> > benefit, so +1 for the idea number 2). Th
g() usage.
Michael mentioned in [2] that is not really consistent with the rest (what I
agree with) and that "we should rethink a bit the way pending entries are
retrieved". I did not think about it yet but that might be the way to
go, thoughts?
[1]:
https://www.postgresql.org/message-i
\
+}
I did propose "double" up-thread to be consistent with the code around. That
would mean to also cast to "double". That's just for consistency purpose. What
do
you think?
Appart from the above that LGTM.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors
Hi,
On Tue, Jan 14, 2025 at 06:55:03PM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-01-14 13:06:31 +, Bertrand Drouvot wrote:
> > On Tue, Jan 14, 2025 at 12:58:44AM -0500, Andres Freund wrote:
> > > The current code has the weird behaviour of going through
&
Hi,
On Wed, Jan 15, 2025 at 06:27:22PM +0900, Michael Paquier wrote:
> On Wed, Jan 15, 2025 at 08:30:20AM +0000, Bertrand Drouvot wrote:
> > On Wed, Jan 15, 2025 at 11:03:54AM +0300, Nazir Bilal Yavuz wrote:
> >> With this commit it may not be possible to count IOs in the crit
how much I could
> break, and this was one pattern once I've forced the pending part. I
> didn't get through the whole exercise.
I'll look at it and come back with a proposal as part of [1].
[1]: https://www.postgresql.org/message-id/z4drlnuhsq3hp...@paquier.xyz
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ed "fix".
>From what I can see, the above proposal does (at least) silent the warning
here (clang 5.0.1 and same as demoiselle): https://godbolt.org/z/cGosfzGne (we
can see the warning by using the current define and that the warning is gone
with the new define).
Let's see on
Hi,
On Thu, Jan 16, 2025 at 06:48:58AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Jan 16, 2025 at 09:55:10AM +0900, Michael Paquier wrote:
> > On Wed, Jan 15, 2025 at 05:20:57PM +0300, Nazir Bilal Yavuz wrote:
> > > I think allowing only pgSt
Hi,
On Wed, Jan 15, 2025 at 03:11:32PM +0900, Michael Paquier wrote:
> On Fri, Jan 10, 2025 at 09:40:38AM +0000, Bertrand Drouvot wrote:
> > Please find attached v4 taking into account 2c14037bb5.
>
> +} PgStat_WalCounters;
> +
> +typedef struct PgStat_WalStats
> +{
&g
Hi,
On Thu, Jan 16, 2025 at 11:38:47AM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-01-16 15:59:31 +, Bertrand Drouvot wrote:
> > On Wed, Jan 15, 2025 at 03:11:32PM +0900, Michael Paquier wrote:
> > > On Fri, Jan 10, 2025 at 09:40:38AM +, Bertrand Drouvot wrot
Hi,
On Thu, Dec 19, 2024 at 06:12:04AM +, Bertrand Drouvot wrote:
> I think I'll start a dedicated thread to discuss the
> stats_fetch_consistency/'snapshot'
> point (will be easier to follow than resuming the discussion in this thread).
I gave more thoughts on it
total_autoanalyze_time; /* autovacuum initiated */
Those comments look weird to me.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Fri, Jan 10, 2025 at 10:15:52AM +0300, Nazir Bilal Yavuz wrote:
> Hi,
>
> On Fri, 10 Jan 2025 at 04:47, Michael Paquier wrote:
> >
> > On Thu, Jan 09, 2025 at 03:30:37PM +0000, Bertrand Drouvot wrote:
> > > We first use an Assert in is_ioop_tracked_in_byte
ts of pgstatfuncs.c
Yup.
> v4 attached.
One comment:
+ PG_RETURN_FLOAT8(result);\
The "\" indentation looks wrong for this line (was ok in v3).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
f1...@ip-10-97-1-34.eu-west-3.compute.internal
>
> I could tweak that around the beginning of next week with a proposal
> of patch. Bertrand, perhaps you'd prefer hack on this one?
Yeah, I had in mind to work on it (in the exact same line as you are describing
above). I'll work o
Hi,
On Fri, Jan 17, 2025 at 03:12:36PM +0900, Michael Paquier wrote:
> On Fri, Jan 17, 2025 at 06:06:35AM +0000, Bertrand Drouvot wrote:
> > On Fri, Jan 17, 2025 at 09:08:02AM +0900, Michael Paquier wrote:
> >> I could tweak that around the beginning of next week with a prop
Hi,
On Tue, Jan 07, 2025 at 10:19:36PM +0100, Tomas Vondra wrote:
> On 1/7/25 21:42, Robert Treat wrote:
> > On Tue, Jan 7, 2025 at 10:44 AM Bertrand Drouvot
> > wrote:
> >>
> >> ...
> >>
> >> Another idea regarding the storage of those metric
SIGINT, ReqShutdownXLOG); /* trigger shutdown checkpoint */
=== 6
+ * Wait until we're asked to shut down. By seperating the writing of the
Typo: s/seperating/separating/
I don't really anything else in 0006 and 0007 but as you said it's probably
worth a few more eyes as the code
mething like?
#define is_ioop_tracked_in_bytes(io_op) \
((io_op) < IOOP_NUM_TYPES && (io_op) >= IOOP_EXTEND)
v7-0002:
I wonder if it wouldn't make more sense to remove pgstat_count_io_op() first
and then implement what currently is in v7-0001. What v7-0002 is removing is
not produced by v7-0001.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
n
additional
benefit, so +1 for the idea number 2). This is an "issue" that has been raised
multiple times (like in [1]).
[1]:
https://www.postgresql.org/message-id/20240607033806.6gwgolihss72cj6r%40awork3.anarazel.de
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
hands).
So it seems to me that the "migrating WAL stats thread" is a better place to
discuss about it.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Wed, Feb 12, 2025 at 11:13:13AM -0600, Nathan Bossart wrote:
> On Wed, Feb 12, 2025 at 06:19:12AM +0000, Bertrand Drouvot wrote:
> > Thanks! Regarding 0003 I think it's ok to keep it in this thread (and not
> > create a dedicated one), as it still fits well with $SU
.
> Looking forward to feedback on this approach.
> If there is agreement, I will work on preparing the patches.
That sounds like a plan for me but better to wait for others to share their
thoughts too.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Tue, Feb 11, 2025 at 04:42:26PM -0600, Nathan Bossart wrote:
> On Tue, Feb 11, 2025 at 08:51:15AM +0000, Bertrand Drouvot wrote:
> > On Mon, Feb 10, 2025 at 02:52:46PM -0600, Nathan Bossart wrote:
> >> Off-list, I've asked Bertrand to gauge the feasibility of addin
free to consider all of this as Nits if you
feel it deviates too much from the initial intend of this thread.
[1]:
https://www.postgresql.org/message-id/flat/C1EE64B0-D4DB-40F3-98C8-0CED324D34CB%40amazon.com
[2]: https://www.postgresql.org/message-id/1058306.1680467858%40sss.pgh.pa.us
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
could use get_mempolicy() only on "valid" buffers i.e
((buf_state & BM_VALID) && (buf_state & BM_TAG_VALID)), thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Fri, Feb 14, 2025 at 03:24:22PM +0900, Michael Paquier wrote:
> On Tue, Feb 11, 2025 at 09:37:37AM +0000, Bertrand Drouvot wrote:
> > While at it, adding 0004 to report wal_buffers_full in VACUUM/ANALYZE
> > (VERBOSE).
>
> Thanks for summarizing the histor
Hi,
On Fri, Feb 14, 2025 at 12:17:48AM -0800, Masahiko Sawada wrote:
> On Tue, Feb 11, 2025 at 11:44 PM Bertrand Drouvot
> wrote:
> Looking at the latest custodian worker patch, the basic architecture
> is to have a single custodian worker and processes can ask it for some
&g
Hi,
On Mon, Feb 17, 2025 at 04:25:46PM +0900, Michael Paquier wrote:
> On Mon, Feb 17, 2025 at 06:59:40AM +0000, Bertrand Drouvot wrote:
> > There is still something that would simplify what is done here: it's the
> > "the elimination of the write & sync columns
Hi,
On Thu, Feb 06, 2025 at 10:28:48AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Thu, Feb 06, 2025 at 10:38:55AM +0900, Michael Paquier wrote:
> > On Wed, Feb 05, 2025 at 02:28:08PM +, Bertrand Drouvot wrote:
> > > Agree, I'll start a dedicated thread for tha
Hi,
On Thu, Feb 20, 2025 at 02:37:18PM +0900, Michael Paquier wrote:
> On Wed, Feb 19, 2025 at 09:24:41AM +0000, Bertrand Drouvot wrote:
> > That's right but that would mean almost duplicating the pg_stat_wal related
> > stuff (because it can't be removed from the doc
%s in single-user mode", "function_name"" maybe? (that
would
somehow match the existing ""user-defined types cannot use subscripting
function %s")
=== 2
+ "pg_copy_replication_slot")));
s/pg_copy_replication_slot/copy_replication_slot/ maybe? As it i
nto account.
Maybe we could also add a comment in multixact.c to update the doc accordingly
if
the computation changes? (I think that will be easy to miss).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Tue, Feb 25, 2025 at 02:20:48PM +0900, Michael Paquier wrote:
> On Mon, Feb 24, 2025 at 01:08:03PM +0000, Bertrand Drouvot wrote:
> > I agree that we've to put everything in the picture (system with or without
> > cheap timing functions, lock contention and WAL flush di
Hi,
On Mon, Feb 24, 2025 at 09:57:49AM +0900, Michael Paquier wrote:
> On Thu, Feb 20, 2025 at 08:11:12AM +0000, Bertrand Drouvot wrote:
> > LGTM.
>
> Applied this one.
Thanks!
> Now, to the part about the backend stats and WAL,
> which should be the last piece..
Yup,
Hi,
On Wed, Feb 19, 2025 at 07:28:49AM +0900, Michael Paquier wrote:
> On Tue, Feb 18, 2025 at 10:45:29AM +0000, Bertrand Drouvot wrote:
> > Agree, done that way in the dedicated thread ([1]).
> >
> > [1]:
> > https://www.postgresql.org/message-id/flat/Z7RkQ0EfYaqqjgz
gmail.com
[2]:
https://www.postgresql.org/message-id/Z6CcglxJF8XW%2BR7W%40ip-10-97-1-34.eu-west-3.compute.internal
[3]:
https://www.postgresql.org/message-id/CAN55FZ0thZHTBbXwAsNhfrRdgmDwxWbLPiZyh%2BTG9CrC1V8TeA%40mail.gmail.com
[4]: https://www.postgresql.org/message-id/Z6HH150-Aw6ilQYE%40paquier.xyz
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Mon, Feb 24, 2025 at 06:15:53AM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-02-24 10:54:54 +, Bertrand Drouvot wrote:
> > a051e71e28a added the "timing tracking" in the WAL code path with "only"
> > track_io_timing enabled (and track_wal_i
nk we should go with your v2 patch
> > approach for HEAD and back-branches.
> >
>
> Any opinion on how to proceed here?
As far I'm concerned, I did not change my mind since [1] and think the same i.e:
go with v2 for HEAD and back-branches.
[1]:
https://www.postgresql.org/message-id/Z6W7GtSzeDcZec%2Bf%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ady shared to have valid result with
non
tiny shared buffer size). I'll look closely at the code for sure once we all
agree
on the design part of it.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi Jakub,
On Mon, Feb 17, 2025 at 01:02:04PM +0100, Jakub Wartak wrote:
> On Thu, Feb 13, 2025 at 4:28 PM Bertrand Drouvot
> wrote:
>
> Hi Bertrand,
>
> Thanks for playing with this!
>
> > Which makes me wonder if using numa_move_pages()/move_pages is the right
>
h. Also,
removed a ";" in "#endif;" in the non-NUMA code path.
v5-0006-meson.build-changes.txt.
Those apply on top of your v5.
Also the pg_buffercache test fails without the libnuma configure option. Maybe
some tests should depend of the libnuma
l fork duration in child backend for logging */
+ if (child_type == B_BACKEND)
+ {
+ INSTR_TIME_SET_CURRENT(conn_timing.fork_duration);
+ INSTR_TIME_SUBTRACT(conn_timing.fork_duration,
+ ((BackendStartupData *)
startup_data)->fork_time);
+ }
worth to add a helper function to avoid code duplication?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Wed, Feb 26, 2025 at 04:52:13PM +0900, Michael Paquier wrote:
> On Tue, Feb 25, 2025 at 03:00:35PM +0000, Bertrand Drouvot wrote:
> > That makes fully sense. Done in 0004 attached. Somehow related to that, I've
> > a patch in progress to address some of Rahila'
feguard" is not perfect but probably better
than none).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Wed, Feb 26, 2025 at 03:37:10PM +0900, Michael Paquier wrote:
> On Tue, Feb 25, 2025 at 01:42:08PM +0000, Bertrand Drouvot wrote:
> > Now we can see that the numbers increased for the relation object and that
> > we
> > get non zeros numbers for the wal object too (wh
Hi,
On Tue, Feb 25, 2025 at 03:50:38PM +0900, Michael Paquier wrote:
> On Mon, Feb 24, 2025 at 09:07:39AM +0000, Bertrand Drouvot wrote:
> > Now that 2421e9a51d2 is in, let's resume working in this thread. PFA a
> > rebase to
> > make the CF bot happy. Nothing has
[1]:
https://www.postgresql.org/message-id/flat/Z3zqc4o09dM/Ezyz%40ip-10-97-1-34.eu-west-3.compute.internal
[2]:
https://www.postgresql.org/message-id/Z6oRgmD8m7zBo732%40ip-10-97-1-34.eu-west-3.compute.internal
Looking forward to your feedback,
Regards,
--
Bertrand Drouvot
PostgreSQL Contribut
Hi Jakub,
On Wed, Feb 26, 2025 at 09:48:41AM +0100, Jakub Wartak wrote:
> On Mon, Feb 24, 2025 at 5:11 PM Bertrand Drouvot
> wrote:
> >
> > Hi,
> >
> > On Mon, Feb 24, 2025 at 09:06:20AM -0500, Andres Freund wrote:
> > > Does the issue with "new"
Hi,
On Mon, Feb 17, 2025 at 07:59:26AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Feb 17, 2025 at 04:25:46PM +0900, Michael Paquier wrote:
> > On Mon, Feb 17, 2025 at 06:59:40AM +, Bertrand Drouvot wrote:
> > > There is still something that would simplify wha
that on its own because this
> is actually the case on HEAD? (No need to post an updated patch for
> this remark.)
That's right but that would mean almost duplicating the pg_stat_wal related
stuff (because it can't be removed from the doc until the f
Hi,
On Mon, Feb 17, 2025 at 12:07:56PM -0800, Masahiko Sawada wrote:
> On Fri, Feb 14, 2025 at 2:35 AM Bertrand Drouvot
> wrote:
> > Yeap, that was exactly my point when I mentioned the custodian thread
> > (taking
> > into account Tom's comment quoted above).
>
at_prepare_io_time() to get a parameter.
[1]:
https://www.postgresql.org/message-id/Z7NSc5j6M4g2r1HD%40ip-10-97-1-34.eu-west-3.compute.internal
Looking forward to your feedback,
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.am
Hi,
On Tue, Feb 18, 2025 at 08:34:32AM +0900, Michael Paquier wrote:
> On Mon, Feb 17, 2025 at 03:14:59PM +0000, Bertrand Drouvot wrote:
> > PFA the whole picture. 0001 is implementing the fields removal in
> > pg_stat_wal
> > (and also PendingWalStats). I think that
uge if there is interest to add this extension in contrib (would certainly
need some polishing and code work to meet the "contrib" expectations though).
[1]:
https://www.postgresql.org/message-id/flat/7ff08868-843a-c39c-c96d-7e7f77fe5f5c%40amazon.com
Regards,
--
Bertrand Drouvot
Postgr
many more: that could "help" the user experience, or are you
more concerned about the code maintenance?
Just did a quick test, (did not look closely at the code), and it looks like
that:
'all': does not report the "received" (but does report authenticated and
authorized)
'received': does not work?
'authenticated': works
'authorized': works
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ns) as compare to a really slow timestamp function.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
e == B_WAL_SENDER))
{
instr_time fork_time = ((BackendStartupData *)
startup_data)->fork_time;
conn_timing.fork_duration = INSTR_TIME_GET_DURATION_SINCE(fork_time);
}
"
into a dedicated helper function.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Mon, Mar 03, 2025 at 10:48:23AM +0900, Michael Paquier wrote:
> On Fri, Feb 28, 2025 at 09:26:08AM +0000, Bertrand Drouvot wrote:
> > Also attaching the patch I mentioned up-thread to address some of Rahila's
> > comments ([1]): It adds a Auxiliary
601 - 700 of 812 matches
Mail list logo
