Re: Object like pg_class.relkind = 's' or 'c' have on-disk

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")

In response to

Browse pgsql-general by date

  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