From: | Katsuhiko Okano <k_okano(at)po(dot)ntts(dot)co(dot)jp> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
Subject: | Re: Object like pg_class.relkind = 's' or 'c' have on-disk |
Date: | 2005-03-17 09:37:09 |
Message-ID: | 42394FC5.3030103@po.ntts.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
OK.understand.
I'll exclude relkind IN( 's' , 'c' ) file in backup set.
THANKS Qingqing Zhou & tom lane!
Tom Lane wrote:
> "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
>
>>Pg_xactlock is always there as a special relation.
>
>
> pg_xactlock isn't really a relation. The way I think about it is that
> it's a dummy entry in pg_class that exists to reserve a relation OID
> for a specific purpose --- namely, we can lock transaction IDs by
> locking what would otherwise be a page of that relation.
>
> There was some talk recently about reorganizing the locktag design
> so that transaction lock tags would be clearly distinguishable from
> any lock associated with a relation. If we got that done, there'd
> be no need for the pg_xactlock entry at all.
>
>
>>I am not sure about 'c'.
>
>
> 'c' entries in pg_class are for composite types. They don't have
> any associated disk storage either.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
--
----------------------------------------
Katsuhiko Okano
k_okano(at)po(dot)ntts(dot)co(dot)jp
NTT Software Corp. (division "NBRO-PT6")
From | Date | Subject | |
---|---|---|---|
Next Message | Együd Csaba (Freemail) | 2005-03-17 09:47:41 | Re: Best practices: Handling Daylight-saving time |
Previous Message | Phil Daintree | 2005-03-17 08:18:35 | Query performance problem |