Re: PATCH: tracking temp files in pg_stat_database

From: "Tomas Vondra" <tv(at)fuzzy(dot)cz>
To: "Magnus Hagander" <magnus(at)hagander(dot)net>
Cc: "Tomas Vondra" <tv(at)fuzzy(dot)cz>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PATCH: tracking temp files in pg_stat_database
Date: 2012-01-26 13:54:28
Message-ID: 4136c64fb9e9a4b24d384a14ff0bd54a.squirrel@sq.gransy.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 26 Leden 2012, 14:44, Magnus Hagander wrote:
> On Sat, Jan 21, 2012 at 20:12, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>> On 21 Leden 2012, 18:13, Magnus Hagander wrote:
>>> On Sat, Jan 21, 2012 at 18:02, Tomas Vondra <tv(at)fuzzy(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-01-26 14:14:42 Re: WIP patch for parameterized inner paths
Previous Message Magnus Hagander 2012-01-26 13:44:17 Re: PATCH: tracking temp files in pg_stat_database