Re: pgsql: Add relation fork support to pg_relation_size() function. - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: pgsql: Add relation fork support to pg_relation_size() function.
Date
Msg-id 48E9B80D.2020101@enterprisedb.com
Whole thread Raw
In response to Re: pgsql: Add relation fork support to pg_relation_size() function.  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgsql: Add relation fork support to pg_relation_size() function.
List pgsql-hackers
Tom Lane wrote:
> I don't believe for a moment that EDB, or anyone else competent enough
> to put in a private fork definition, can't manage to add it to enum
> ForkNumber.  They'd probably be well advised to operate with a private
> setting of catversion anyway, which would ensure that installations
> using this private fork wouldn't interoperate with backends not knowing
> about it.  Once you've done that there's no need to worry about
> conflicts.

Agreed.

> I have no particular objection to the .fsm idea though --- that could be
> implemented fairly simply with a lookup table while forming the file name.

Yeah, I think it's a good idea nevertheless. While users don't need to 
poke around in the data directory, for those people who do, it's more 
pleasant if the files have self-explanatory names.

If we go with the ".fsm" extension, we'll get "12345.fsm.1" when the FSM 
grows large enough to be segmented. Does anyone have a problem with a 
filename with two dots? Shouldn't be a problem, I guess.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Subtransaction commits and Hot Standby
Next
From: Magnus Hagander
Date:
Subject: Re: pgsql: Add relation fork support to pg_relation_size() function.