Re: PATCH: tracking temp files in pg_stat_database
От | Tomas Vondra |
---|---|
Тема | Re: PATCH: tracking temp files in pg_stat_database |
Дата | |
Msg-id | 4136c64fb9e9a4b24d384a14ff0bd54a.squirrel@sq.gransy.com обсуждение исходный текст |
Ответ на | Re: PATCH: tracking temp files in pg_stat_database (Magnus Hagander <magnus@hagander.net>) |
Список | pgsql-hackers |
On 26 Leden 2012, 14:44, Magnus Hagander wrote: > On Sat, Jan 21, 2012 at 20:12, Tomas Vondra <tv@fuzzy.cz> wrote: >> On 21 Leden 2012, 18:13, Magnus Hagander wrote: >>> On Sat, Jan 21, 2012 at 18:02, Tomas Vondra <tv@fuzzy.cz> wrote: >>> Though I just looked at the tabstat code again, and we already split >>> that message up at regular intervals. Which would make it quite weird >>> to have global counters in it as well. >>> >>> But instead of there, perhaps we need a general "non table, but more >>> than one type of data" message sent out at the same time. There is >>> other stuff in the queue for it. >>> >>> I'm not convinced either way - I'm not against the original way in >>> your patch either. I just wanted to throw the idea out there, and was >>> hoping somebody else would have an opinion too :-) >> >> Let's make that in a separate patch. It seems like a good thing to do, >> but >> I don't think it should be mixed with this patch. > > Yeah, I'm not sure we even want to do that yet, when we go down this > road. We might eventually, of course. Yes, that's one of the reasons why I suggested to do that in a separate patch (that might be rejected if we find it's a bad idea). > I've cleaned up the patch a bit and applied it - thanks! > > Other than cosmetic, I changed the text in the description around a > bit (sol if that's worse now, that's purely my fault) and added docs > to the section about pg_stat_database that you'd forgotten. Great. Thanks for the fixes. > Also, I'd like to point you in the direction of the > src/include/catalog/find_unused_oids and duplicate_oids scripts. The > oids you'd picked conflicted with the pg_extension catalog from a year > ago. Easy enough to fix, and there are often conflicts with more > recent oids that the committer has to deal with anyway, but cleaning > those up before submission always helps a little bit. For the next one > :-) Aha! I've been wondering how the commiters identify duplicate oids etc. but I was unaware of those scripts. Tomas
В списке pgsql-hackers по дате отправления: