Re: Server instrumentation patch - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Server instrumentation patch |
Date | |
Msg-id | 200506241746.j5OHkXr05874@candle.pha.pa.us Whole thread Raw |
In response to | Re: Server instrumentation patch ("Dave Page" <dpage@vale-housing.co.uk>) |
List | pgsql-hackers |
Dave Page wrote: > > The current version of the patch only moves those functions he wants. > > Marc says he wants them all moved, and I agree. > > OK - did you see Andreas' response to why he hadn't done that (it was > actually posted in response to your original query, not Marcs)? In a > nutshell, the functions that had not been moved returned values that > were easily derived from the other functions, and thus could be > considered bloat? > > The functions included in the patch were: > > int8 pg_tablespace_size(oid) - Return the size of the tablespace in > bytes > int8 pg_database_size(oid) - Return the size of the database in > bytes > int8 pg_relation_size(oid) - Return the size of the relation in > bytes > text pg_size_pretty(int8) - Pretty-print the byte value > > The ones left out were: > > int8 database_size(name) - Return the size of the database in > bytes (by name) > int8 relation_size(text) - Return the size of the relation in > bytes (by name) > int8 indexes_size(text) - Return the size of the indexes on the > named relation > int8 total_relation_size(text) - Return relation_size(text) + > indexes_size(text) + relation_size(text->toast tables) > setof record relation_size_components(text) - return a pretty-print set > of values from above. > > I don't feel particularly strongly either way, but given the normal > desire not to bloat the backend necessarily, I have to question the need > to include the latter functions. OK, well, let's talk about what we want done, then someone can work up a patch. Does someone want to make a proposal here on what to do? > > Well, from the May, 2005 discussion URL you posted, I see a > > clear reply > > to the idea of adding the I/O functions to the backend: > > > > > > http://archives.postgresql.org/pgsql-hackers/2005-05/msg00874.php > > > > Now, you can agree or disagree that there are issues with the I/O > > functions, but the concern was raised in May, and not > > addressed at all, > > either via email or the patch. > > Maybe that's the wrong URL, but all I see there is a vague recollection > from Tom that there were security issues. In the next message, Andreas > recalls how you and he worked out the issues that were raised - I > believe this is the thread > http://archives.postgresql.org/pgsql-hackers/2004-07/msg00793.php. > Mhonarc has made a mess of the thread so it does seem to break in a few > places, and it is possible I've missed part. The security issue is that we didn't want the backend to be able to read/write outside of /pgdata, and I think we have that working, except that I have no idea how it will handle config files outside /pgdata. Maybe that was in the patch --- I don't know. I think we need to see a new patch with just the i/o functions so we can review it. I personally think the I/O functions are a good idea, but I need to be considerate of others in the community who have concerns. > > For the second, please supply a patch that moves _all_ of dbsize into > > the main server. I think we have agreement on that. > > If that remains the case having seen my comments above echoing Andreas' > concerns then sure, if that's what it takes to get them in, so be it. > Please confirm either way. Let's discuss what to move/delete/keep in contrib. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
pgsql-hackers by date: