On 3/2/16 5:41 PM, Tom Lane wrote:
Jim Nasby <jim.na...@bluetreble.com> writes:
On 3/2/16 4:21 PM, Peter Geoghegan wrote:
I think you should commit this. The chances of anyone other than you
and Masahiko recalling that you developed this tool in 3 years is
essentially nil. I think that the cost of committing a developer-level
debugging tool like this is very low. Modules like pg_freespacemap
currently already have no chance of being of use to ordinary users.
All you need to do is restrict the functions to throw an error when
called by non-superusers, out of caution.

It's a problem that modules like pg_stat_statements and
pg_freespacemap are currently lumped together in the documentation,
but we all know that.


Would it make any sense to stick it under src/test/modules/ instead of
contrib/ ?  That would help make it clear that it's a debugging tool
and not something we expect end users to use.

I haven't looked at it in detail; is there something inherently dangerous about it?

When I'm forced to wear a DBA hat, I'd really love to be able to find out what VM status for a large table is. If it's in contrib they'll know the tool is there; if it's under src then there's about 0 chance of that. I'd think SU-only and any appropriate warnings would be enough heads-up for DBAs to be careful with it.
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to