Hi!
On 09.12.2024 11:03, Bertrand Drouvot wrote:
There is a missing space. I think that should be " at server..." or "...%llu ".
Thanks for pointing this out. In the other code the elog messages are all on
one line,
regardless of their length. Did the same in v3.
On 10.12.2024 09:42, Bertra
Hi,
On Tue, Dec 10, 2024 at 09:54:36AM +0900, Michael Paquier wrote:
> On Mon, Dec 09, 2024 at 08:03:54AM +, Bertrand Drouvot wrote:
> > Right. OTOH I think that could help the tap test added in da99fedf8c to not
> > rely on assert enabled build (the tap test could "simply" check for the
> > W
On Mon, Dec 09, 2024 at 08:03:54AM +, Bertrand Drouvot wrote:
> Right. OTOH I think that could help the tap test added in da99fedf8c to not
> rely on assert enabled build (the tap test could "simply" check for the
> WARNING in the logfile instead).
That's true. Still, the coverage that we hav
Hi,
On Mon, Dec 09, 2024 at 02:39:58PM +0900, Michael Paquier wrote:
> On Sat, Dec 07, 2024 at 12:31:46PM +0300, Anton A. Melnikov wrote:
> > Completely agree that the original comment needs to be revised,
> > since it implies that it is normal for deleted entries to be here,
> > but it is not the
On Sat, Dec 07, 2024 at 12:31:46PM +0300, Anton A. Melnikov wrote:
> Completely agree that the original comment needs to be revised,
> since it implies that it is normal for deleted entries to be here,
> but it is not the case.
Yep, so applied v2-0001 to document that, and backpatched it as it is
Hi!
On 04.12.2024 18:24, Bertrand Drouvot wrote:
Thanks! I've the feeling that something has to be fixed, see my comments in
[1]. It might be that the failed assertion does not handle a "valid" scenario.
[1]:
https://www.postgresql.org/message-id/Z1BzI/eMTCOKA%2Bj6%40ip-10-97-1-34.eu-west-3.co
Hi,
On Thu, Dec 05, 2024 at 05:13:13PM +0900, Michael Paquier wrote:
> On Thu, Dec 05, 2024 at 07:37:27AM +, Bertrand Drouvot wrote:
> > That said, I think that's worth to update the comment a bit (like in the
> > attached?) as I think that answers a legitimate question someone could have
> >
On Thu, Dec 05, 2024 at 07:37:27AM +, Bertrand Drouvot wrote:
> That said, I think that's worth to update the comment a bit (like in the
> attached?) as I think that answers a legitimate question someone could have
> while
> reading this code.
>
> - /* we may have some "dropped"
Hi,
On Thu, Dec 05, 2024 at 02:43:43PM +0900, Michael Paquier wrote:
> On Wed, Dec 04, 2024 at 03:24:55PM +, Bertrand Drouvot wrote:
> > Thanks! I've the feeling that something has to be fixed, see my comments in
> > [1]. It might be that the failed assertion does not handle a "valid"
> > sce
On Wed, Dec 04, 2024 at 03:24:55PM +, Bertrand Drouvot wrote:
> Thanks! I've the feeling that something has to be fixed, see my comments in
> [1]. It might be that the failed assertion does not handle a "valid" scenario.
>
> [1]:
> https://www.postgresql.org/message-id/Z1BzI/eMTCOKA%2Bj6%40ip
Hi,
On Wed, Dec 04, 2024 at 04:00:53AM +0300, Anton A. Melnikov wrote:
>
> On 03.12.2024 18:07, Andres Freund wrote:
> > Hi,
> >
> > On 2024-12-03 13:37:48 +0300, Anton A. Melnikov wrote:
> > > Found a place in the code of this patch that is unclear to me:
> > > https://github.com/postgres/postg
On 03.12.2024 18:07, Andres Freund wrote:
Hi,
On 2024-12-03 13:37:48 +0300, Anton A. Melnikov wrote:
Found a place in the code of this patch that is unclear to me:
https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
Owi
Hi,
On 2024-12-03 13:37:48 +0300, Anton A. Melnikov wrote:
> Found a place in the code of this patch that is unclear to me:
> https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
>
> Owing assert() the next if() should never
Hi!
Found a place in the code of this patch that is unclear to me:
https://github.com/postgres/postgres/blob/1acf10549e64c6a52ced570d712fcba1a2f5d1ec/src/backend/utils/activity/pgstat.c#L1658
Owing assert() the next if() should never be performed, but the comment above
says the opposite.
Is thi
Hi,
On 2022-08-22 11:32:14 +0900, Kyotaro Horiguchi wrote:
> At Wed, 10 Aug 2022 14:02:34 +0200, "Drouvot, Bertrand"
> wrote in
> > what about?
> >
> > + /*
> > + * Acquire the LWLock directly instead of using
> > pg_stat_lock_entry_shared()
> > + *
At Wed, 10 Aug 2022 14:02:34 +0200, "Drouvot, Bertrand"
wrote in
> what about?
>
> + /*
> + * Acquire the LWLock directly instead of using
> pg_stat_lock_entry_shared()
> + * which requires a reference.
> + */
>
>
> I think that's mor
Hi,
On 8/18/22 9:51 PM, Andres Freund wrote:
Hi,
On 2022-08-18 15:26:31 -0400, Greg Stark wrote:
And indexes of course. It's a bit frustrating since without the
catalog you won't know what table the index actually is for... But
they're pretty important stats.
FWIW, I think we should split rel
Hi,
On 2022-08-18 15:26:31 -0400, Greg Stark wrote:
> And indexes of course. It's a bit frustrating since without the
> catalog you won't know what table the index actually is for... But
> they're pretty important stats.
FWIW, I think we should split relation stats into table and index
stats. His
On Thu, 18 Aug 2022 at 02:27, Drouvot, Bertrand wrote:
>
> What I had in mind is to provide an API to retrieve stats for those that
> would need to connect to each database individually otherwise.
>
> That's why I focused on PGSTAT_KIND_RELATION that has
> PgStat_KindInfo.accessed_across_databases
Hi,
On 2022-08-17 15:46:42 -0400, Greg Stark wrote:
> Isn't there also a local hash table used to find the entries to reduce
> traffic on the shared hash table? Even if you don't take a snapshot
> does it get entered there? There are definitely still parts of this
> I'm working on a pretty vague u
On Tue, 16 Aug 2022 at 08:49, Drouvot, Bertrand wrote:
>
>
> + if (p->key.kind != PGSTAT_KIND_RELATION)
> + continue;
Hm. So presumably this needs to be extended. Either to let the caller
decide which types of stats to return or to somehow return all the
stats
On Thu, 11 Aug 2022 at 02:11, Drouvot, Bertrand wrote:
>
> As Andres was not -1 about that idea (as it should be low cost to add
> and maintain) as long as somebody cares enough to write something: then
> I'll give it a try and submit a patch for it.
I agree it would be a useful feature. I think
Hi,
On 8/10/22 11:25 PM, Greg Stark wrote:
On Wed, 10 Aug 2022 at 04:05, Drouvot, Bertrand wrote:
Hi,
On 8/9/22 6:00 PM, Greg Stark wrote:
On Tue, 9 Aug 2022 at 06:19, Drouvot, Bertrand wrote:
What do you think about adding a function in core PG to provide such
functionality? (means being
Hi,
On 2022-08-10 15:48:15 -0400, Greg Stark wrote:
> One thing that's bugging me is that the names we use for these stats
> are *all* over the place.
Yes. I had a huge issue with this when polishing the patch. And Horiguchi-san
did as well. I had to limit the amount of cleanup done to make it f
Hi,
On 2022-08-10 14:18:25 -0400, Greg Stark wrote:
> > I don't think that's a large enough issue to worry about unless you're
> > polling at a very high rate, which'd be a bad idea in itself. If a backend
> > can't get the lock for some stats change it'll defer flushing the stats a
> > bit,
> >
On Wed, 10 Aug 2022 at 04:05, Drouvot, Bertrand wrote:
>
> Hi,
>
> On 8/9/22 6:00 PM, Greg Stark wrote:
> > On Tue, 9 Aug 2022 at 06:19, Drouvot, Bertrand wrote:
> >>
> >> What do you think about adding a function in core PG to provide such
> >> functionality? (means being able to retrieve all th
One thing that's bugging me is that the names we use for these stats
are *all* over the place.
The names go through three different stages
pgstat structs -> pgstatfunc tupledescs -> pg_stat_* views
(Followed by a fourth stage where pg_exporter or whatever names for
the monitoring software)
On Tue, 9 Aug 2022 at 12:48, Andres Freund wrote:
> > The reason I want a C function is I'm trying to get as far as I can
> > without a connection to a database, without a transaction, without
> > accessing the catalog, and as much as possible without taking locks.
>
> I assume you don't include
At Tue, 9 Aug 2022 09:53:19 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-08-09 17:24:35 +0900, Kyotaro Horiguchi wrote:
> > If I'm not missing something, it's strange that pgstat_lock_entry()
> > only takes LW_EXCLUSIVE.
>
> I think it makes some sense, given that there's a larger number of
Hi,
On 2022-08-09 17:24:35 +0900, Kyotaro Horiguchi wrote:
> At Mon, 8 Aug 2022 11:53:19 -0400, Greg Stark wrote in
> > I'm trying to wrap my head around the shared memory stats collector
> > infrastructure from
> > <20220406030008.2qxipjxo776dw...@alap3.anarazel.de> committed in
> > 5891c7a8ed8f
Hi,
On 2022-08-09 12:00:46 -0400, Greg Stark wrote:
> I was more aiming at a C function that extensions could use directly
> rather than an SQL function -- though I suppose having the former it
> would be simple enough to implement the latter using it. (though it
> would have to be one for each st
Hi,
On 2022-08-09 12:18:47 +0200, Drouvot, Bertrand wrote:
> What do you think about adding a function in core PG to provide such
> functionality? (means being able to retrieve all the stats (+ eventually add
> some filtering) without the need to connect to each database).
I'm not that convinced
On Tue, 9 Aug 2022 at 06:19, Drouvot, Bertrand wrote:
>
>
> What do you think about adding a function in core PG to provide such
> functionality? (means being able to retrieve all the stats (+ eventually
> add some filtering) without the need to connect to each database).
I'm working on it myself
At Mon, 8 Aug 2022 11:53:19 -0400, Greg Stark wrote in
> I'm trying to wrap my head around the shared memory stats collector
> infrastructure from
> <20220406030008.2qxipjxo776dw...@alap3.anarazel.de> committed in
> 5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd.
>
> I have one question about locking
I'm trying to wrap my head around the shared memory stats collector
infrastructure from
<20220406030008.2qxipjxo776dw...@alap3.anarazel.de> committed in
5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd.
I have one question about locking -- afaics there's nothing protecting
reading the shared memory stats.
On Wed, 20 Jul 2022 at 15:09, Andres Freund wrote:
>
> Each backend only had stats for things it touched. But the stats collector
> read all files at startup into hash tables and absorbed all generated stats
> into those as well.
Fascinating. I'm surprised this didn't raise issues previously fo
Hi,
On July 20, 2022 8:41:53 PM GMT+02:00, Greg Stark wrote:
>On Wed, 20 Jul 2022 at 12:08, Tom Lane wrote:
>>
>> AFAIR, the previous stats collector implementation had no such provision
>> either: it'd just keep adding hashtable entries as it received info about
>> new objects. The only thing
On Wed, 20 Jul 2022 at 12:08, Tom Lane wrote:
>
> AFAIR, the previous stats collector implementation had no such provision
> either: it'd just keep adding hashtable entries as it received info about
> new objects. The only thing that's changed is that now those entries are
> in shared memory inst
Hi,
On 2022-07-20 12:08:35 -0400, Tom Lane wrote:
> AFAIR, the previous stats collector implementation had no such provision
> either: it'd just keep adding hashtable entries as it received info about
> new objects.
Yep.
> The only thing that's changed is that now those entries are in shared
>
Melanie Plageman writes:
> On Wed, Jul 20, 2022 at 11:35 AM Greg Stark wrote:
>> It seems like if we really think the total number of database objects
>> is reasonably limited to scales that fit in RAM there would be a much
>> simpler database design that would just store the catalog tables in
>>
Hi,
On 2022-07-20 11:35:13 -0400, Greg Stark wrote:
> Is it true that the shared memory allocation contains the hash table
> entry and body of every object in every database?
Yes. However, note that that was already the case with the old stats
collector - it also kept everything in memory. In add
On Wed, Jul 20, 2022 at 11:35 AM Greg Stark wrote:
> On the one hand the rest of Postgres seems to be designed on the
> assumption that the number of tables and database objects is limited
> only by disk space. The catalogs are stored in relational storage
> which is read through the buffer cache
So I'm finally wrapping my head around this new code. There is
something I'm surprised by that perhaps I'm misreading or perhaps I
shouldn't be surprised by, not sure.
Is it true that the shared memory allocation contains the hash table
entry and body of every object in every database? I guess I w
Hi,
On 2022-04-13 17:55:18 -0700, Andres Freund wrote:
> On 2022-04-13 16:56:45 -0700, David G. Johnston wrote:
> > On Wed, Apr 13, 2022 at 4:34 PM David G. Johnston <
> > david.g.johns...@gmail.com> wrote:
> > Sorry, apparently this "2000-01-01" behavior only manifests after crash
> > recovery on
On Wed, Apr 13, 2022 at 04:56:45PM -0700, David G. Johnston wrote:
> Sorry, apparently this "2000-01-01" behavior only manifests after crash
> recovery on v15 (didn't check v14); after a clean initdb on v15 I got the
> same initdb timestamp.
>
> Feels like we should still report the "end of crash
Hi,
On 2022-04-13 16:56:45 -0700, David G. Johnston wrote:
> On Wed, Apr 13, 2022 at 4:34 PM David G. Johnston <
> david.g.johns...@gmail.com> wrote:
> Sorry, apparently this "2000-01-01" behavior only manifests after crash
> recovery on v15 (didn't check v14); after a clean initdb on v15 I got th
On Wed, Apr 13, 2022 at 4:34 PM David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
>
>> Here comes v70:
>>
>>
> One thing I just noticed while peeking at pg_stat_slru:
>
> The stats_reset column for my newly initdb'd cluster is showing me
On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
> Here comes v70:
>
>
One thing I just noticed while peeking at pg_stat_slru:
The stats_reset column for my newly initdb'd cluster is showing me
"2000-01-01 00:00:00" (v15). I was expecting null, though a non-null value
restriction does make s
On Sat, Apr 9, 2022 at 12:07 PM Andres Freund wrote:
>
> > ... specific counters. In particular, replay will not increment
> > pg_stat_database or pg_stat_all_tables columns, and the startup process
> > will not report reads and writes for the pg_statio views.
> >
> > It would helpful to give at
Hi,
On 2022-04-07 21:39:55 -0700, David G. Johnston wrote:
> On Thu, Apr 7, 2022 at 8:59 PM Andres Freund wrote:
>
> >
> >
> >Cumulative statistics are collected in shared memory. Every
> >PostgreSQL process collects statistics
> > locally
> >then updates the shared data at approp
Hi,
On April 8, 2022 4:49:48 AM PDT, Ranier Vilela wrote:
>Hi,
>
>Per Coverity.
>
>pgstat_reset_entry does not check if lock it was really blocked.
>I think if shared_stat_reset_contents is called without lock,
>is it an issue not?
I don't think so - the nowait parameter is say to false, so the
Hi,
Per Coverity.
pgstat_reset_entry does not check if lock it was really blocked.
I think if shared_stat_reset_contents is called without lock,
is it an issue not?
regards,
Ranier Vilela
0001-avoid-reset-stats-without-lock.patch
Description: Binary data
At Thu, 7 Apr 2022 20:59:21 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-04-08 11:10:14 +0900, Kyotaro Horiguchi wrote:
> > I can read it. But I'm not sure that the difference is obvious for
> > average users between "starting a standby from a basebackup" and
> > "starting a standby after a n
On Thu, Apr 7, 2022 at 8:59 PM Andres Freund wrote:
>
>
>Cumulative statistics are collected in shared memory. Every
>PostgreSQL process collects statistics
> locally
>then updates the shared data at appropriate intervals. When a server,
>including a physical replica, shuts do
On 2022-04-07 16:37:51 -0700, Andres Freund wrote:
> On 2022-04-07 00:28:45 -0700, Andres Freund wrote:
> > I've gotten through the main commits (and then a fix for the apparently
> > inevitable bug that's immediately highlighted by the buildfarm), and the
> > first
> > test. I'll call it a night
Hi,
On 2022-04-07 20:59:21 -0700, Andres Freund wrote:
>
>
>Cumulative statistics are collected in shared memory. Every
>PostgreSQL process collects statistics locally
>then updates the shared data at appropriate intervals. When a server,
>including a physical replica, shuts d
Hi,
On 2022-04-07 20:51:10 -0700, David G. Johnston wrote:
> On Thu, Apr 7, 2022 at 7:10 PM Kyotaro Horiguchi
> wrote:
> > I can read it. But I'm not sure that the difference is obvious for
> > average users between "starting a standby from a basebackup" and
> > "starting a standby after a normal
Hi,
On 2022-04-08 11:10:14 +0900, Kyotaro Horiguchi wrote:
> At Thu, 7 Apr 2022 16:37:51 -0700, Andres Freund wrote
> in
> > Hi,
> >
> > On 2022-04-07 00:28:45 -0700, Andres Freund wrote:
> > > I've gotten through the main commits (and then a fix for the apparently
> > > inevitable bug that's
On Thu, Apr 7, 2022 at 7:10 PM Kyotaro Horiguchi
wrote:
> At Thu, 7 Apr 2022 16:37:51 -0700, Andres Freund
> wrote in
> > Hi,
> >
> > On 2022-04-07 00:28:45 -0700, Andres Freund wrote:
> > > I've gotten through the main commits (and then a fix for the apparently
> > > inevitable bug that's immed
At Thu, 7 Apr 2022 16:37:51 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-04-07 00:28:45 -0700, Andres Freund wrote:
> > I've gotten through the main commits (and then a fix for the apparently
> > inevitable bug that's immediately highlighted by the buildfarm), and the
> > first
> > test. I'l
Hi,
On 2022-04-07 00:28:45 -0700, Andres Freund wrote:
> I've gotten through the main commits (and then a fix for the apparently
> inevitable bug that's immediately highlighted by the buildfarm), and the first
> test. I'll call it a night now, and work on the other tests & docs tomorrow.
I've got
At Thu, 7 Apr 2022 00:28:45 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-04-05 20:00:08 -0700, Andres Freund wrote:
> > It'll be a few hours to get to the main commit - but except for 0001 it
> > doesn't make sense to push without intending to push later changes too. I
> > might squash a few
At Wed, 6 Apr 2022 18:58:52 -0700, Andres Freund wrote in
> Hi,
>
> On 2022-04-07 10:36:30 +0900, Kyotaro Horiguchi wrote:
> > At Wed, 6 Apr 2022 09:04:09 -0700, Andres Freund wrote
> > in
> > > I think there's no switches left now, so it's not actually providing too
> > > much.
> >
> > (Ou
Hi,
On 2022-04-05 20:00:08 -0700, Andres Freund wrote:
> It'll be a few hours to get to the main commit - but except for 0001 it
> doesn't make sense to push without intending to push later changes too. I
> might squash a few commits togther.
I've gotten through the main commits (and then a fix f
Hi,
On 2022-04-07 10:36:30 +0900, Kyotaro Horiguchi wrote:
> At Wed, 6 Apr 2022 09:04:09 -0700, Andres Freund wrote
> in
> > > + * Don't define an INVALID value so switch() statements can warn if some
> > > + * cases aren't covered. But define the first member to 1 so that
> > > + * uninitia
At Wed, 6 Apr 2022 09:04:09 -0700, Andres Freund wrote in
> > +* Don't define an INVALID value so switch() statements can warn if some
> > +* cases aren't covered. But define the first member to 1 so that
> > +* uninitialized values can be detected more easily.
> >
> > FWIW, I like t
Hi,
On 2022-04-06 17:01:17 -0700, David G. Johnston wrote:
> On Wed, Apr 6, 2022 at 4:12 PM Andres Freund wrote:
>
> The fact there is just the one outlier here suggests that this is indeed the
> better option.
FWIW, the outlier also uses pgstat_reset(), just with a small wrapper doing
the trans
On Wed, Apr 6, 2022 at 4:12 PM Andres Freund wrote:
>
> On 2022-04-06 15:32:39 -0700, David G. Johnston wrote:
> > On Wednesday, April 6, 2022, Andres Freund wrote:
> >
> >
> > I like having the SQL function paired with a matching implementation in
> > this scheme.
>
> It would have gotten thing
Hi,
On 2022-04-06 15:32:39 -0700, David G. Johnston wrote:
> On Wednesday, April 6, 2022, Andres Freund wrote:
>
> >
> >
> > I'd go for
> > pgstat_reset_slru_counter() -> pgstat_reset_slru()
> > pgstat_reset_subscription_counter() -> pgstat_reset_subscription()
> > pgstat_reset_subscription_coun
On Wednesday, April 6, 2022, Andres Freund wrote:
>
>
> I'd go for
> pgstat_reset_slru_counter() -> pgstat_reset_slru()
> pgstat_reset_subscription_counter() -> pgstat_reset_subscription()
> pgstat_reset_subscription_counters() -> pgstat_reset_all_subscriptions()
> pgstat_reset_replslot_counter()
Hi,
On 2022-04-05 20:00:08 -0700, Andres Freund wrote:
> It'll be a few hours to get to the main commit - but except for 0001 it
> doesn't make sense to push without intending to push later changes too. I
> might squash a few commits togther.
I just noticed an existing incoherency that I'm wonder
On Wed, Apr 6, 2022 at 12:34 PM Justin Pryzby wrote:
> On Wed, Apr 06, 2022 at 12:27:34PM -0700, Andres Freund wrote:
> > > > + next use of statistical information will cause a new snapshot to
> be built
> > > > + or accessed statistics to be cached.
> > >
> > > I believe this should be an "a
On Wed, Apr 06, 2022 at 12:27:34PM -0700, Andres Freund wrote:
> > > + next use of statistical information will cause a new snapshot to be
> > > built
> > > + or accessed statistics to be cached.
> >
> > I believe this should be an "and", not an "or". (next access builds both a
> > new snapsh
Hi,
On 2022-04-06 12:14:35 -0700, Lukas Fittl wrote:
> On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
>
> > Here comes v70:
> >
>
> Some small nitpicks on the docs:
Thanks!
> > From 13090823fc4c7fb94512110fb4d1b3e86fb312db Mon Sep 17 00:00:00 2001
> > From: Andres Freund
> > Date: Sat,
On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
> Here comes v70:
>
Some small nitpicks on the docs:
> From 13090823fc4c7fb94512110fb4d1b3e86fb312db Mon Sep 17 00:00:00 2001
> From: Andres Freund
> Date: Sat, 2 Apr 2022 19:38:01 -0700
> Subject: [PATCH v70 14/27] pgstat: update docs.
> ...
Hi,
On 2022-04-06 16:24:28 +0700, John Naylor wrote:
> On Wed, Apr 6, 2022 at 10:00 AM Andres Freund wrote:
> > - while working on the above point, I noticed that hash_bytes() showed up
> > noticeably in profiles, so I replaced it with a fixed-width function
>
> I'm curious about this -- could
Hi,
On 2022-04-06 13:31:31 +0200, Alvaro Herrera wrote:
> Just skimming a bit here ...
Thanks!
> On 2022-Apr-05, Andres Freund wrote:
>
> > From 0532b869033595202d5797b148f22c61e4eb4969 Mon Sep 17 00:00:00 2001
> > From: Andres Freund
> > Date: Mon, 4 Apr 2022 16:53:16 -0700
> > Subject: [PAT
Hi,
On 2022-04-06 18:11:04 +0900, Kyotaro Horiguchi wrote:
> 0004:
>
> I can see padding_pgstat_send and fun:pgstat_send in valgrind.supp
Those shouldn't be affected by the patch, I think? But I did indeed forget to
remove those in 0010.
> 0006:
>
> I'm fine with the categorize for now.
>
> +
Just skimming a bit here ...
On 2022-Apr-05, Andres Freund wrote:
> From 0532b869033595202d5797b148f22c61e4eb4969 Mon Sep 17 00:00:00 2001
> From: Andres Freund
> Date: Mon, 4 Apr 2022 16:53:16 -0700
> Subject: [PATCH v70 10/27] pgstat: store statistics in shared memory.
> + PgStatsData
>
On Wed, Apr 6, 2022 at 10:00 AM Andres Freund wrote:
> - while working on the above point, I noticed that hash_bytes() showed up
> noticeably in profiles, so I replaced it with a fixed-width function
I'm curious about this -- could you direct me to which patch introduces this?
--
John Naylor
At Tue, 5 Apr 2022 20:00:08 -0700, Andres Freund wrote in
> Hi,
>
> Here comes v70:
> - extended / polished the architecture comment based on feedback from Melanie
> and David
> - other polishing as suggested by David
> - addressed the open issue around pgstat_report_stat(), as described in
>
On Tue, Apr 5, 2022 at 8:14 PM Andres Freund wrote:
>
> On 2022-04-05 20:00:50 -0700, David G. Johnston wrote:
>
> * Statistics are loaded from the filesystem during startup (by the startup
> * process), unless preceded by a crash, in which case all stats are
> * discarded. They are written ou
Hi,
On 2022-04-05 23:11:07 -0400, Greg Stark wrote:
> I've never tried to review a 24-patch series before. It's kind of
> intimidating Is there a good place to start to get a good idea of
> the most important changes?
It was more at some point :). And believe me, I find this whole project
int
On Tue, Apr 5, 2022 at 8:11 PM Greg Stark wrote:
> I've never tried to review a 24-patch series before. It's kind of
> intimidating Is there a good place to start to get a good idea of
> the most important changes?
>
It isn't as bad as the number makes it sound - I just used "git am" to
appl
Hi,
On 2022-04-05 20:00:50 -0700, David G. Johnston wrote:
> On Tue, Apr 5, 2022 at 4:16 PM Andres Freund wrote:
> > On 2022-04-05 14:43:49 -0700, David G. Johnston wrote:
> > > On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
> > > > I guess I should add a paragraph about snapshots / fetch c
I've never tried to review a 24-patch series before. It's kind of
intimidating Is there a good place to start to get a good idea of
the most important changes?
On Tue, Apr 5, 2022 at 8:00 PM Andres Freund wrote:
>
> Here comes v70:
>
> I think this is basically ready, minus a a few comment adjustments here and
> there. Unless somebody protests I'm planning to start pushing things
> tomorrow
> morning.
>
>
Nothing I've come across, given my area of exper
On Tue, Apr 5, 2022 at 4:16 PM Andres Freund wrote:
> On 2022-04-05 14:43:49 -0700, David G. Johnston wrote:
> > On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
>
> >
> > > I guess I should add a paragraph about snapshots / fetch consistency.
> > >
> >
> > I apparently confused/combined the
On 2022-04-05 14:43:49 -0700, David G. Johnston wrote:
> On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
>
> >
> > On 2022-04-05 13:51:12 -0700, David G. Johnston wrote:
> >
> > >, but rather add to the shared queue
> >
> > Queue? Maybe you mean the hashtable?
> >
>
> Queue implemented by a
On Tue, Apr 5, 2022 at 2:23 PM Andres Freund wrote:
>
> On 2022-04-05 13:51:12 -0700, David G. Johnston wrote:
>
> >, but rather add to the shared queue
>
> Queue? Maybe you mean the hashtable?
>
Queue implemented by a list...? Anyway, I think I mean this:
/*
* List of PgStat_EntryRefs with u
Hi,
On 2022-04-05 13:51:12 -0700, David G. Johnston wrote:
> On Mon, Apr 4, 2022 at 8:05 PM Andres Freund wrote:
>
> > - added an architecture overview comment to the top of pgstat.c - not sure
> > if
> > it makes sense to anybody but me (and perhaps Horiguchi-san)?
> >
> >
> I took a look at
On Mon, Apr 4, 2022 at 8:05 PM Andres Freund wrote:
> - added an architecture overview comment to the top of pgstat.c - not sure
> if
> it makes sense to anybody but me (and perhaps Horiguchi-san)?
>
>
I took a look at this, diff attached. Some typos and minor style stuff,
plus trying to bring
Hi,
On 2022-04-02 01:16:48 -0700, Andres Freund wrote:
> I just noticed that the code doesn't appear to actually work like that right
> now. Whenever the timeout is reached, pgstat_report_stat() is called with
> force = true.
>
> And even if the backend is busy running queries, once there's conte
On Tuesday, April 5, 2022, Andres Freund wrote:
> Hi,
>
> On 2022-04-05 08:49:36 -0700, David G. Johnston wrote:
> > On Mon, Apr 4, 2022 at 7:36 PM Andres Freund wrote:
> >
> > >
> > > I think all this is going to achieve is to making code more
> complicated.
> > > There
> > > is a *single* non-
Hi,
On 2022-04-05 08:49:36 -0700, David G. Johnston wrote:
> On Mon, Apr 4, 2022 at 7:36 PM Andres Freund wrote:
>
> >
> > I think all this is going to achieve is to making code more complicated.
> > There
> > is a *single* non-assert use of accessed_across_databases and now a single
> > asserti
On Mon, Apr 4, 2022 at 7:36 PM Andres Freund wrote:
>
> I think all this is going to achieve is to making code more complicated.
> There
> is a *single* non-assert use of accessed_across_databases and now a single
> assertion involving it.
>
> What would having PGSTAT_KIND_CLUSTER and PGSTAT_KIND
Hi,
On 2022-04-04 19:03:13 -0700, David G. Johnston wrote:
> > > (if this is true...but given this is an optimization category I'm
> > thinking
> > > maybe it doesn't actually matter...)
> >
> > It is true. Not sure what you mean with "optimization category"?
> >
> >
> I mean that distinguishing b
On Mon, Apr 4, 2022 at 3:44 PM Andres Freund wrote:
> Hi,
>
> On 2022-04-04 15:24:24 -0700, David G. Johnston wrote:
> > Replacing the existing assert(!kind->fixed_amount) with
> > assert(!kind->accessed_across_databases) produces the same result as the
> > later presently implies the former.
>
>
Hi,
On 2022-03-23 10:42:03 -0700, Andres Freund wrote:
> On 2022-03-23 17:27:50 +0900, Kyotaro Horiguchi wrote:
> > + /*
> > +* When starting with crash recovery, reset pgstat data - it might not
> > be
> > +* valid. Otherwise restore pgstat data. It's safe to do this here,
> > +* b
Hi,
On 2022-04-04 15:24:24 -0700, David G. Johnston wrote:
> Replacing the existing assert(!kind->fixed_amount) with
> assert(!kind->accessed_across_databases) produces the same result as the
> later presently implies the former.
I wasn't proposing to replace, but to add...
> Now I start to dis
1 - 100 of 278 matches
Mail list logo
