Thread: Object like pg_class.relkind = 's' or 'c' have on-disk file?
Hi. I'm writing backup guide and script. I will look up on-disk-filename should be backuped in a pg_class, like: >SELECT oid,relfilenode,relname,relkind FROM pg_class; it return like: > 17173 | 17173 | sql_packages | r > 17182 | 17182 | pg_toast_17178_index | i > 17180 | 17180 | pg_toast_17178 | t > 376 | 0 | pg_xactlock | s I'll include backup set relkind='r' or 'i' or 'S' or 'v' or 't'. but PostgreSQL 8.0.1 Documentation "41.9. pg_class" say >c = composite type, s = special 1)relkind = 's' is always have not on-disk file? 2)when exist relkind='s' object except pg_xactlock? user(administrator) can create it? 3)relkind = 'c' is always have not on-disk file? (I create TYPE. but no file exist.) I will only include pg_type relation in backup set. is it OK ? 4)any other advice to backup? :-) Regards, -- ---------------------------------------- Katsuhiko Okano k_okano _at_ po.ntts.co.jp NTT Software Corp. (division "NBRO-PT6")
Pg_xactlock is always there as a special relation. It has no footprint on disk. Transactions will keep a record in pg_xactlock at the beginning and remove the record at the end. Once any conflicting update happens, the latter transaction will use this relation to wait for the former transaction's result. AFAIK, since lock tag always needs a relationalId as a parameter, so we create this special relation for this usage. I am not sure about 'c'. Regards, Qingqing "Katsuhiko Okano" <k_okano@po.ntts.co.jp> writes > Hi. > I'm writing backup guide and script. > > I will look up on-disk-filename should be backuped > in a pg_class, like: > >SELECT oid,relfilenode,relname,relkind FROM pg_class; > it return like: > > 17173 | 17173 | sql_packages | r > > 17182 | 17182 | pg_toast_17178_index | i > > 17180 | 17180 | pg_toast_17178 | t > > 376 | 0 | pg_xactlock | s > > I'll include backup set relkind='r' or 'i' or 'S' or 'v' or 't'. > but PostgreSQL 8.0.1 Documentation "41.9. pg_class" say > >c = composite type, s = special > > 1)relkind = 's' is always have not on-disk file? > > 2)when exist relkind='s' object except pg_xactlock? > user(administrator) can create it? > > 3)relkind = 'c' is always have not on-disk file? > (I create TYPE. but no file exist.) > I will only include pg_type relation in backup set. is it OK ? > > 4)any other advice to backup? :-) > > > Regards, > -- > ---------------------------------------- > Katsuhiko Okano > k_okano _at_ po.ntts.co.jp > NTT Software Corp. (division "NBRO-PT6") > > > ---------------------------(end of broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings >
"Qingqing Zhou" <zhouqq@cs.toronto.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
OK.understand. I'll exclude relkind IN( 's' , 'c' ) file in backup set. THANKS Qingqing Zhou & tom lane! Tom Lane wrote: > "Qingqing Zhou" <zhouqq@cs.toronto.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@po.ntts.co.jp NTT Software Corp. (division "NBRO-PT6")