Hi,
On Sat, Apr 26, 2025 at 02:55:51PM -0400, Tom Lane wrote:
> Bertrand Drouvot writes:
> > On Sat, Apr 26, 2025 at 01:20:56AM -0400, Tom Lane wrote:
> >> Whatever it contains, we need to kill it with fire before the problem
> >> metastasizes like it did the last time
ot a simpler
> "wait_classes.h" that gets included by wait_event.h and
> wait_event_types.h?
Yeah, better. Done that way in the attached.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From c6d1883b6fef09e4c351
Hi,
On Sat, Apr 26, 2025 at 01:20:56AM -0400, Tom Lane wrote:
> Bertrand Drouvot writes:
> > While working on wait events I faced some compilation issues due to circular
> > header file dependency (introduced in fa88928470b5) between wait_event.h and
> > wait_event_types.h.
2 | #include "a.h"
"
So it looks like that our code base only contains those 2: plpy_util.h and
wait_event_types.h cases.
Thoughts?
[1]:
https://clang.llvm.org/extra/clang-tidy/checks/misc/header-include-cycle.html
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Op
back-patch as the issue is unlikely to
occur without custom stats. Adding a v18 open item then.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From b80bcbcf05e44d31cc90c1de2e3200899db1294f Mon Sep 17 00:00:00 200
Hi,
On Mon, Apr 21, 2025 at 10:17:40AM +0900, Michael Paquier wrote:
> On Tue, Apr 15, 2025 at 05:50:32AM +0000, Bertrand Drouvot wrote:
> > Sorry, can't look at the details right now but it might be linked to
> > 039549d70f6 which is recent enough and in this area. Will give
Hi,
On Sat, Apr 12, 2025 at 10:33:33AM -0400, Andres Freund wrote:
> I suspect that this is related to
>
> commit 039549d70f6aa2daa3714a13752a08fa8ca2fb05
+1
> We might just have to give up on that assertion, I guess?
Probably. I'll have a look at it next week.
Regards,
--
numa nodes
and
accessing their "local" memory first (and help with "remote" memory access if
there is still more work to do "remotely").
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
same host. One could
ensure that numa nodes are not shared across instances (cpu and memory resource
isolation per instance). Bonus point, adding Direct I/O into the game would
ensure that the OS page cache is not shared too.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
body have an idea?
Sorry, can't look at the details right now but it might be linked to
039549d70f6 which is recent enough and in this area. Will give it a look once
I've time.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Tue, Apr 08, 2025 at 03:27:41PM +0900, Michael Paquier wrote:
> On Tue, Apr 08, 2025 at 06:19:02AM +0000, Bertrand Drouvot wrote:
> > - A new injection_points_wakeup_detach() function that is holding the
> > spinlock
> > during the whole duration to ensure that n
From a glance, this seems to fall in the "new feature" bucket and
> should likely wait for v19.
Thank you both for providing your thoughts that confirm my initial doubt. Let's
come back to that one later then.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Sour
for buffers that are spread
across NUMA nodes though.
Does that sound like an idea worth to spend time on? (If so, I'd be happy to
work
on it).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
te for v18
post freeze (it looks more a feature enhancement than anything else)
- It's currently doing the changes in pg_buffercache v1.6 but will need to
create v1.7 for 19 (if the above stands true)
Looking forward to your feedback,
Regards,
--
Bertrand Drouvot
PostgreSQL Contributor
to use an empty one.
This is not needed here anymore (as we're using another injection point that the
one initially prooposed) but I'll open a dedicated thread for that for 19 when
the timing will be appropriate.
[1]:
https://www.postgresql.org/message-id/Z6oQXc8LmiTLfwLA%40ip-10-97-1-34.e
bvious but OTOH I think that would not hurt.
Something like in the attached?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From c22533a6c8a8526b75a95ccf0eb39b5d10cca1f2 Mon Sep 17 00:00:00 2001
From: Bertrand
Hi,
On Wed, Apr 09, 2025 at 12:03:06PM +0900, Michael Paquier wrote:
> On Tue, Apr 08, 2025 at 06:42:53AM +0000, Bertrand Drouvot wrote:
> > Fully agree. Will need to find another way to prevent a process to wait
> > between the
> > wakeup and the detach. I'll open a
om pg_buffercache);
count
---
65472
(1 row)
So it looks like that the new way to iterate on the buffers that has been
introduced
in v26/v27 has some issue?
[1]:
https://www.postgresql.org/message-id/Z64Pr8CTG0RTrGR3%40ip-10-97-1-34.eu-west-3.compute.internal
Regards,
--
Bertrand Dr
ifetime */
if (firstNumaTouch)
- pg_numa_touch_mem_if_required(touch,
os_page_ptrs[idx]);
+ pg_numa_touch_mem_if_required(touch,
buffptr + (j * os_page_size));
what do you think?
Regards,
on my side, let's keep it that way and don't make the slot
active.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
x27;s reports in [1]. So yeah, let's do as you suggested and do
not make the slot active for the vacuum full case too.
[1]: https://www.postgresql.org/message-id/386386.1737736...@sss.pgh.pa.us
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
As we now have 2 code paths I think we "really" need 2 tests. The attached
(to apply on top of v7) seems to do the job.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
commit e3d9337aa01539ce77553d95db47aa919d1f50
ery the statistics
related
view at more than a second interval anyway. Or are you concerned that we may not
enter the "When the WAL sender is caught up or has pending data to send"
frequently
enough?
> Based on my tests, using PGSTAT_MIN_INTERVAL seems to
> provide a better balance
WHERE slot_name = 'vacuum_full_activeslot' AND conflicting;"
+ WHERE slot_name = 'vacuum_full_inactiveslot' AND conflicting;"
);
" to be on the safe side of thing.
What do you think of the attached (to apply on top of v5-PG17-2)?
Regards,
"anonymous allocations" and
"unused memory" (i.e the ones reported with or NULL as name in the
pg_shmem_allocations view). Using output in this comment sounds confusing while
it makes sense in pg_get_shmem_allocations() because it really reports those.
I think that we could j
UM FULL on pg_class is
used, which prevents logical decoding from progressing after it started (due
to the logged AEL at the start of VACFULL).
"
meaning that the active slot is invalidated even if the catalog xmin's moves
forward due to xl_running_xacts.
[1]: https://www.postgresql.org/message-id/386386.1737736935%40sss.pgh.pa.us
[2]:
https://www.postgresql.org/message-id/zqypkuvtihtd2zbmwdfmcceujg4fuakrhojmjkxpp7t4udqkty%40couhenc7dsor
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
ed by TYPEALIGN_DOWN() is valid. It's before ent->location (or
> before the first shared buffer) ...
Yeah, I'm not 100% sure about that... Maybe for safety we could use
TYPEALIGN_DOWN()
for the reporting and use the actual buffer address when
pg_numa_touch_mem_if_required
s ...
I think that comes from the comments that are already in
pg_get_shmem_allocations().
I think that those are located here and worded that way to ease to understand
what is not in with pg_get_shmem_allocations_numa() if one look at both
functions. That said, I'm +1 to put this kind of comments in the f
cts/a xl_running_xacts/? in the second one? Also I'm not sure
"even here" is needed.
Apart from the above that LGTM.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
to the log file (if log level <= DEBUG2)
- the doc explains what the function does
- that name also makes sense from an API point of view as it calls
"LogStandbySnapshot"
> The other option could be pg_create_standby_snapshot(), which would be
> similar to the existing functio
A few random comments:
=== 1
It looks like that firstNumaTouch is not set to false anymore.
=== 2
+ pfree(os_page_status);
+ pfree(os_page_ptrs);
Not sure that's needed, we should be in a short-lived memory context here
(ExprContext or such).
=== 3
+ ro_volatile_var = *(uint64 *)ptr
space missing before "ptr"?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Thu, Apr 03, 2025 at 03:23:31PM +0530, vignesh C wrote:
> Can we add it to one of the subscription tests, such as 001_rep_changes.pl?
Yeah that sounds like a good place for it. Done in the attached.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databa
Hi Jakub,
On Thu, Apr 03, 2025 at 02:36:57PM +0200, Jakub Wartak wrote:
> On Thu, Apr 3, 2025 at 10:23 AM Bertrand Drouvot
> wrote:
> Right, we could also put it as a limitation. I would be happy to leave
> it as it must be a rare condition, but Tomas stated he's not.
>
>
) is better (given the examples you just
shared).
=== 6
> I find all of those non-user friendly and I'm afraid I won't be able
> to pull that alone in time...
Maybe we could add a few words in the doc to mention the "multiple nodes per
buffer" case? And try to impr
Hi,
On Thu, Apr 03, 2025 at 09:25:02AM +0530, vignesh C wrote:
> On Mon, 31 Mar 2025 at 18:35, Bertrand Drouvot
> wrote:
> >
> Couple of suggestions:
Thanks for looking at it!
> 1) I felt we can include a similar verification for one of the logical
> replication tests t
Hi Jakub,
On Wed, Apr 02, 2025 at 04:45:53PM +0200, Jakub Wartak wrote:
> On Tue, Apr 1, 2025 at 5:13 PM Bertrand Drouvot
> wrote:
> >
> > === 4
> >
> > + for (i = 0; i < NBuffers; i++)
> > + {
> > +
It looks like that check_slots_conflict_reason() is not called with
checks_active_slot
as argument.
=== 5
I think that we could remove the need for the drop_active_slot parameter in
drop_logical_slots() and just check if an active slot exists (and if so drop
it). That said I'm not sure it
Hi,
On Tue, Apr 01, 2025 at 04:55:06PM +0530, Amit Kapila wrote:
> On Tue, Apr 1, 2025 at 2:02 PM Bertrand Drouvot
> wrote:
>
> > But if we "really" want to produce a "new" WAL record, what about using
> > LogLogicalMessage()?
> >
>
> We a
Hi Jakub,
On Tue, Apr 01, 2025 at 12:56:06PM +0200, Jakub Wartak wrote:
> On Mon, Mar 31, 2025 at 4:59 PM Bertrand Drouvot
> wrote:
>
> > Hi,
>
> Hi Bertrand, happy to see you back, thanks for review and here's v18
> attached (an ideal fit for PG18 ;))
Thanks fo
" want to produce a "new" WAL record, what about using
LogLogicalMessage()? It could also be used for debugging purpose. Bonus point:
it does not need wal_level to be set to logical. Thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
pledesc->natts >= NUM_BUFFERCACHE_PAGES_ELEM - 1)
+ TupleDescInitEntry(tupledesc, (AttrNumber) 9,
"pinning_backends",
+ INT4OID, -1, 0);
I think we should not change the "expected_tupledesc->natts" check here until
v17-0003 is applied.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Wal(),
> actually. There is also a call to GetCurrentTimestamp() that we can
> rely on in this path.
I think it's better to flush the stats in a shared code path. I think it's
easier to maintain and that there is no differences between logical and
physical walsenders that would
bout PG16-v2-0001
Same as for PG17-v2-0001.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
for "beentry->st_procpid != pid".
I think we can simply move the pgstat_fetch_stat_backend() call at the end
of pgstat_fetch_stat_backend_by_pid(), like in the attached. With this in place
the issue is fixed on my side.
Thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contribut
e
would not be installed by default", in 041_checkpoint_at_promote.pl.
Thanks! I think that makes sense and will add it in the proposed patch (early
next week).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
use injection points
as
proposed as of 18 (as we need the injection points changes proposed in 0001
up-thread). Thoughts?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Wed, Mar 19, 2025 at 12:12:19PM +0530, Amit Kapila wrote:
> On Mon, Feb 10, 2025 at 8:12 PM Bertrand Drouvot
> wrote:
> >
> > Please find attached a patch to $SUBJECT.
> >
> > In rare circumstances (and on slow machines) it is possible that a
> > xl_r
ted by Andres in [1]. Thoughts?
Regards,
[1]:
https://www.postgresql.org/message-id/erpzwxoptqhuptdrtehqydzjapvroumkhh7lc6poclbhe7jk7l%40l3yfsq5q4pw7
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Wed, Mar 19, 2025 at 08:19:42AM +0900, Michael Paquier wrote:
>
> Done that part for now.
Thanks!
> It will be possible to look at the bug fix
> after the release freeze as it impacts stable branches as well.
Yes, let's do that. Adding a reminder on my side.
Regar
Hi,
On Tue, Mar 18, 2025 at 11:19:32AM +0100, Jakub Wartak wrote:
> On Mon, Mar 17, 2025 at 5:11 PM Bertrand Drouvot
> wrote:
>
> > Thanks for v13!
>
> Rebased and fixes inside in the attached v14 (it passes CI too):
Thanks!
> > === 9
> >
> > +
Hi,
On Tue, Mar 18, 2025 at 05:11:02PM +0900, Michael Paquier wrote:
> On Thu, Mar 13, 2025 at 01:18:45PM +0000, Bertrand Drouvot wrote:
> > This particular sub-patch needs a rebase though, done in the attached. 0001
> > remains unchanged as compared to the v4 one just shared up-
Hi,
On Mon, Mar 17, 2025 at 08:28:46AM +0100, Jakub Wartak wrote:
> On Fri, Mar 14, 2025 at 1:08 PM Bertrand Drouvot
> wrote:
> >
> > I did prepare a patch file (attached as .txt to not disturb the cfbot) to
> > apply
> > on top of v11 0002 (I just rebased it a bit
Hi,
On Thu, Mar 13, 2025 at 02:15:14PM +, Bertrand Drouvot wrote:
> > > === 19
> > >
> >
> > Can you please take a look again on this
>
> Sure, will do.
> I'll have a look at v11 soon.
About 0001:
=== 1
git am produces:
.git/rebase-ap
Hi,
On Fri, Mar 14, 2025 at 11:05:28AM +0100, Jakub Wartak wrote:
> On Thu, Mar 13, 2025 at 3:15 PM Bertrand Drouvot
> wrote:
>
> Hi,
>
> Thank you very much for the review! I'm answering to both reviews in
> one go and the results is attached v12, seems it all shoul
Hi,
On Tue, Mar 11, 2025 at 06:10:32AM +, Bertrand Drouvot wrote:
> WalSndWaitForWal() is being used only for logical walsender. So we'd need to
> find another location for the physical walsender case. One option is to keep
> the
> WalSndLoop() location and control the repo
Hi,
On Wed, Mar 12, 2025 at 04:41:15PM +0100, Jakub Wartak wrote:
> On Mon, Mar 10, 2025 at 11:14 AM Bertrand Drouvot
> wrote:
>
> > Thanks for the new version!
>
> v10 is attached with most fixes after review and one new thing
> introduced: pg_numa_available() for
re.
Yeah, I think that PGSTAT_MIN_INTERVAL is the one to use (that's why that's the
one the patch is using). I just mentioned PGSTAT_IDLE_INTERVAL as an open door
for conversation in case one prefers a "larger" frequency.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
kend_wal_have_pending()
check
has been added to pgstat_backend_have_pending_cb(). You're probably looking at
a version prior to 76def4cdd7c.
This particular sub-patch needs a rebase though, done in the attached. 0001
remains unchanged as compared to the v4 one just shared up-thread. If 0
ac should throttle
> itself if we're close to running out of available WAL buffers...
hmm, yeah I think that's an interesting idea OTOH that would mean to "delegate"
the WAL buffers flush to another backend.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Tue, Mar 04, 2025 at 03:24:26PM +, Bertrand Drouvot wrote:
> Like "more stats are always nice" I think that "more explanations in the doc"
> are
> always nice, so I don't see any reason why not to add this extra explanation.
Attached an attempt to
ngBackendStats
initializer (instead of adding extra braces). The reason is that I'm concerned
about padding bytes (that could be added to the struct in the future) not being
zeroed (see [1]).
Done that way in the attached.
[1]:
https://www.postgresql.org/message-id/Z8/W73%2BHVo%2B/pKHZ%4
Hi,
On Fri, Mar 07, 2025 at 03:29:14PM -0500, Melanie Plageman wrote:
> On Fri, Mar 7, 2025 at 6:16 AM Bertrand Drouvot
> wrote:
> > But at the end, what we're "really" interested in this thread, given its
> > $SUBJECT,
> > is to actually log the timin
Hi,
On Mon, Mar 10, 2025 at 09:23:50AM +0900, Michael Paquier wrote:
> On Mon, Mar 03, 2025 at 11:54:39AM +0000, Bertrand Drouvot wrote:
> > So it does not look like what we're adding here can be seen as a primary
> > bottleneck
> > but that is probably worth impl
s fine. That's also how pgstat_wal_have_pending_cb() has been
re-factored in 2421e9a51d2.
[1]:
https://www.postgresql.org/message-id/flat/Z0QjeIkwC0HNI16K%40ip-10-97-1-34.eu-west-3.compute.internal#16762c1767ffb168318e7c3734fa5f64
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Tue, Mar 11, 2025 at 09:06:27AM +0900, Michael Paquier wrote:
> On Mon, Mar 10, 2025 at 11:52:26AM +0000, Bertrand Drouvot wrote:
> > Hi,
> >
> > On Mon, Mar 10, 2025 at 04:46:53PM +0900, Michael Paquier wrote:
> > > On Sat, Mar 08, 2025 at 07:53:04AM
Hi,
On Thu, Sep 12, 2024 at 05:21:43AM +, Bertrand Drouvot wrote:
> Hi,
>
> On Wed, Sep 11, 2024 at 04:39:57PM +0300, Nazir Bilal Yavuz wrote:
> > Hi,
> >
> > On Wed, 11 Sept 2024 at 15:36, Bertrand Drouvot
> > wrote:
> > >
> >
Hi,
On Mon, Mar 10, 2025 at 02:52:42PM +, Bertrand Drouvot wrote:
> Hi,
>
> On Mon, Mar 10, 2025 at 09:23:50AM +0900, Michael Paquier wrote:
> > On Mon, Mar 03, 2025 at 11:54:39AM +, Bertrand Drouvot wrote:
> > > So it does not look like what we're adding
Hi,
On Mon, Mar 10, 2025 at 04:46:53PM +0900, Michael Paquier wrote:
> On Sat, Mar 08, 2025 at 07:53:04AM +0000, Bertrand Drouvot wrote:
> > That would not be an issue should we only access the struct
> > fields in the code, but that's not the case as
end/storage/lmgr/README.
=== 22
+#define MAX_NUMA_ZONES 32 /* FIXME? */
+ Sizezones[MAX_NUMA_ZONES];
could we rely on pg_numa_get_max_node() instead?
=== 23
+ if (s >= 0)
+ zones[s]++;
should we also check that s is below a limit?
=== 24
Regarding how we make use of pg_numa_get_max_node(), are we sure there is
no possible holes? I mean could a system have node 0,1 and 3 but not 2?
Also I don't think I'm a Co-author, I think I'm just a reviewer (even if I
did a little in 0001 though)
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Fri, Mar 07, 2025 at 12:09:35PM -0800, Masahiko Sawada wrote:
> Thank you for updating the patch. It looks mostly good to me. I've
> made some cosmetic changes and attached the updated version.
LGTM, thanks!
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS
Hi,
On Sat, Mar 08, 2025 at 10:57:38AM +0900, Michael Paquier wrote:
> On Fri, Mar 07, 2025 at 08:33:04AM +0000, Bertrand Drouvot wrote:
> > But when it's time to flush, then pgstat_backend_have_pending_cb() checks
> > for zeros in PendingBackendStats *without* any check
ECTION_READY_FOR_USE) &&
+ IsConnectionBackend(MyBackendType))
What about getting rid of reported_first_ready_for_query and check if
conn_timing.ready_for_use is zero instead?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Thu, Mar 06, 2025 at 11:41:03AM -0500, Melanie Plageman wrote:
>
> I still need to do some more manual testing and validation.
>
> On Thu, Mar 6, 2025 at 9:56 AM Bertrand Drouvot
> wrote:
>
> > + /* If an empty string was passed, we're done. *
Hi,
On Fri, Mar 07, 2025 at 10:26:23AM +0530, Amit Kapila wrote:
> On Fri, Mar 7, 2025 at 3:19 AM Masahiko Sawada wrote:
> >
> > On Wed, Mar 5, 2025 at 4:05 AM Bertrand Drouvot
> > wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Mar 05, 20
Hi,
On Thu, Mar 06, 2025 at 02:10:47PM -0500, Andres Freund wrote:
> On 2025-01-20 15:01:38 +0000, Bertrand Drouvot wrote:
> > /* If start_time is in the future or now, no time has elapsed */
> > if (start_time >= stop_time)
> > return 0;
> > "
Hi,
On Fri, Mar 07, 2025 at 02:42:13PM +0900, Michael Paquier wrote:
> On Thu, Mar 06, 2025 at 10:33:52AM +0000, Bertrand Drouvot wrote:
> > Indeed, there is no reason for pgstat_backend_have_pending_cb() to return
> > true if
> > pgstat_tracks_backend_bktype() is not sati
about 0002:
8
+ if (IsConnectionBackend(child_type))
IsConnectionBackend is fine by me.
=== 9
+ /* Calculate fork duration since we have start and end times. */
s/times./times/? (Looking at the one line comments around)
=== 10
+ /* Will be used to calculate total connectio
Hi,
On Thu, Mar 06, 2025 at 10:12:37AM +0900, Michael Paquier wrote:
> On Wed, Mar 05, 2025 at 08:04:44AM +0000, Bertrand Drouvot wrote:
> > On Wed, Mar 05, 2025 at 12:35:26PM +0900, Michael Paquier wrote:
> >> Perhaps there's a point in backpatching a portion of what'
Hi,
On Wed, Mar 05, 2025 at 05:26:40PM +, Bertrand Drouvot wrote:
> So yeah, back to the issue, we have to pay more attention for the WAL stats
> because pgWalUsage is "incremented" without any check with
> pgstat_tracks_backend_bktype()
> (that's not the case
Hi,
On Wed, Mar 05, 2025 at 11:28:23PM -0800, Masahiko Sawada wrote:
> On Wed, Mar 5, 2025 at 3:10 PM Tom Lane wrote:
> >
> > Bertrand Drouvot writes:
> > > yeah makes sense. Done in the attached, and bonus point I realized that
> > > the
> > > test
Hi,
On Wed, Mar 05, 2025 at 09:18:16AM -0500, Andres Freund wrote:
> Hi,
>
> On 2025-03-05 13:03:07 +, Bertrand Drouvot wrote:
> > But yeah, if 0002 in [1] does not go in, then your concern is valid, so
> > adding
> > the extra check in the attached.
>
>
al_write != 0 ||
>PendingWalStats.wal_sync != 0;
> }
Not since 2421e9a51d2. It looks like that you are looking at code prior to
2421e9a51d2.
> Another one is on:
> Bertrand Drouvot 于2025年3月3日周一 18:47写道：
>
> > Hi,
> >
> > On Mon, Mar 03, 2025 at 09:17:30AM +00
Hi,
On Wed, Mar 05, 2025 at 02:42:15PM +0530, Amit Kapila wrote:
> On Wed, Mar 5, 2025 at 12:47 PM Bertrand Drouvot
> wrote:
> >
> > Agree, PFA a patch doing so.
> >
>
> It would be better if you could add a few comments atop the
> permutation line to expla
Hi,
On Tue, Mar 04, 2025 at 06:25:42PM -0500, Melanie Plageman wrote:
> Attached v9 implements log_connections as an enum with a new third
> value "timings".
>
> On Mon, Mar 3, 2025 at 11:14 AM Bertrand Drouvot
> wrote:
> >
> >
> > On Fri, Feb 28,
Hi,
On Tue, Mar 04, 2025 at 05:47:26PM -0500, Melanie Plageman wrote:
> On Mon, Mar 3, 2025 at 9:07 AM Bertrand Drouvot
> wrote:
> >
> > I did not imagine that much ;-) I was just seeing this code being duplicated
> > and just thought about to avoid the duplication.
ng to write WAL data, for pg_stat_io.
+*/
+ start = pgstat_prepare_io_time(track_wal_io_timing);
+
+ pgstat_report_wait_start(WAIT_EVENT_WAL_WRITE);
byteswritten = pg_pwrite(recvFile, buf, segbytes, (off_t)
startoff);
+ pgstat_report_wait_end();
ct, context FROM pg_stat_io ORDER BY 1, 2, 3;
What about adding some extra paranoia like?
SELECT backend_type, object, context FROM pg_stat_io ORDER BY backend_type,
object, context COLLATE "C";
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
PFA a patch doing so.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
>From d590d3184d4345908f1b033aa8a5d19cf98e88ba Mon Sep 17 00:00:00 2001
From: Bertrand Drouvot
Date: Wed, 5 Mar 2025 07:06:58 +
Subject: [P
Hi,
On Tue, Mar 04, 2025 at 11:48:31AM +0100, Jakub Wartak wrote:
> Hi!
>
> On Thu, Feb 27, 2025 at 4:34 PM Bertrand Drouvot
> wrote:
>
> > I did some tests and it looks like it's giving correct results. I don't see
> > -2
> > anymore and every ba
luding cost based delaying)"?
Like "more stats are always nice" I think that "more explanations in the doc"
are
always nice, so I don't see any reason why not to add this extra explanation.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Hi,
On Mon, Mar 03, 2025 at 06:24:59PM -0500, Melanie Plageman wrote:
> On Mon, Mar 3, 2025 at 11:14 AM Bertrand Drouvot
> wrote:
> >
> >
> > On Fri, Feb 28, 2025 at 05:52:35PM -0500, Melanie Plageman wrote:
> >
> > +bool
> > +check_log_connections(cha
Hi,
On Tue, Mar 04, 2025 at 09:28:27AM +0900, Michael Paquier wrote:
> On Mon, Mar 03, 2025 at 09:17:30AM +0000, Bertrand Drouvot wrote:
> > On Mon, Mar 03, 2025 at 10:48:23AM +0900, Michael Paquier wrote:
> >> Something that's still not quite right is that the WAL re
Hi,
On Fri, Feb 28, 2025 at 05:52:35PM -0500, Melanie Plageman wrote:
> On Fri, Feb 28, 2025 at 12:54 AM Bertrand Drouvot
> wrote:
> >
> > On Thu, Feb 27, 2025 at 05:55:19PM -0500, Melanie Plageman wrote:
> > > It still needs polishing (e.g. I need to figure out wher
ments
above then I think we could just macro-ize the child_type check (as you
mentioned
up-thread). That would avoid the risk to forget to update the 3 locations doing
the
exact same check should we add a new child type in the game.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
Hi,
On Mon, Mar 03, 2025 at 10:51:19AM +0900, Michael Paquier wrote:
> On Fri, Feb 28, 2025 at 10:39:31AM +0000, Bertrand Drouvot wrote:
> > That sounds a good idea to measure the impact of those extra calls and see
> > if we'd need to mitigate the impacts. I'll collect
Hi,
On Mon, Mar 03, 2025 at 09:17:30AM +, Bertrand Drouvot wrote:
> hmm, that would work as long as PGSTAT_BACKEND_FLUSH_ALL represents things
> that need to be called from pgstat_report_wal(). But I think that's open
> door for issue should be add a new PGSTAT_BACKEND_FLUSH_XX
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
Hi,
On Fri, Feb 28, 2025 at 11:34:14AM +0900, Michael Paquier wrote:
> On Thu, Feb 27, 2025 at 07:47:09AM +0000, Bertrand Drouvot wrote:
> > That's how I did it initially but decided to move it to pgstat_backend.c.
> > The
> > reason was that it's fully linked
Hi,
On Fri, Feb 28, 2025 at 02:41:34PM +0900, Michael Paquier wrote:
> On Wed, Feb 26, 2025 at 09:48:50AM +0000, Bertrand Drouvot wrote:
> > Yeah I think that makes sense, done that way in the attached.
> >
> > Speaking about physical walsender, I moved the test to 001_strea
h). Idea looks similar excepts, among other things, that
log_connections is kept.
[1]:
https://www.postgresql.org/message-id/CAAKRu_asMtUpxDjts1J60batVqLsSGRodMOq4E9ryg1XdO8EZw%40mail.gmail.com
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
1 - 100 of 804 matches
Mail list logo
