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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: PATCH: tracking temp files in pg_stat_database
Следующее
От: Abhijit Menon-Sen
Дата:
Сообщение: Re: Simulating Clog Contention