Thread: 8.1 system info / admin functions
Two minor gripes about these new functions: (1) I think pg_total_relation_size() is a bit more concise and clear than pg_complete_relation_size(). (2) pg_cancel_backend(), pg_reload_conf(), and pg_rotate_logfile() all return an int indicating success (1) or failure (0). Why shouldn't these functions return a boolean? (Presumably there is a good reason why these functions return a status code at all, rather than aborting via elog on error -- right?) -Neil
Neil Conway <neilc@samurai.com> writes:
> Two minor gripes about these new functions:
> (1) I think pg_total_relation_size() is a bit more concise and clear
> than pg_complete_relation_size().
> (2) pg_cancel_backend(), pg_reload_conf(), and pg_rotate_logfile() all
> return an int indicating success (1) or failure (0). Why shouldn't these
> functions return a boolean?
> (Presumably there is a good reason why these functions return a status
> code at all, rather than aborting via elog on error -- right?)
I agree with both of those criticisms: total is more in line with our
nomenclature than complete, and the other functions should return void
and ereport when they are unhappy. (Saying "I failed" and not having
any mechanism to report why sucks.)
If we weren't already forcing an initdb for beta2, I'd say it's a bit
late to be complaining ... but we can fix them "for free" right now,
so why not?
regards, tom lane
Tom Lane wrote: > If we weren't already forcing an initdb for beta2, I'd say it's a bit > late to be complaining ... but we can fix them "for free" right now, > so why not? Ok, I'll take a look. While we're on the subject, the units used by pg_size_pretty() are incorrect, at least according to the IEC: for example, "MB" is strictly-speaking one million bytes, not 1024^2 bytes. 1024^2 bytes is 1 MiB (similarly for KiB, GiB, and TiB). I'll take a look at fixing this as well, barring any objections. -Neil
Neil Conway <neilc@samurai.com> writes:
> While we're on the subject, the units used by pg_size_pretty() are
> incorrect, at least according to the IEC: for example, "MB" is
> strictly-speaking one million bytes, not 1024^2 bytes. 1024^2 bytes is 1
> MiB (similarly for KiB, GiB, and TiB). I'll take a look at fixing this
> as well, barring any objections.
[ itch... ] The IEC may think they get to define what's correct, but
I don't think that squares with common usage. The only people who
think MB is measured in decimal are disk-manufacturer marketroids.
regards, tom lane
Tom Lane wrote: > [ itch... ] The IEC may think they get to define what's correct, but > I don't think that squares with common usage. The only people who > think MB is measured in decimal are disk-manufacturer marketroids. Well, just them and the IEEE :) While common usage has been to use kB to mean 1024 bytes, that isn't even consistent with the use of the "kilo" prefix for other units (for example, a kilometer is 1000 meters, not 1024). "Common usage" is simply mistaken here, IMHO. (Of course, it doesn't really matter in this case because pg_pretty_size() is an approximation anyway.) -Neil
Tom Lane wrote: > I agree with both of those criticisms: total is more in line with our > nomenclature than complete, and the other functions should return void > and ereport when they are unhappy. (Saying "I failed" and not having > any mechanism to report why sucks.) From reading the code, it suggests that one reason these functions don't elog on error is that they are intended to be used in loops, and that a particular function call might fail for some harmless reason (e.g. because the backend you're trying to cancel has already exited on its own). So if you're doing "SELECT pg_cancel_backend(backend_pid), backend_pid FROM list_of_backends", you might not want to abort the entire query if a particular pg_cancel_backend() fails. I'm not convinced: return codes are ugly, and savepoints and PL/PgSQL exceptions can be used to avoid aborting the entire current transaction if a particular function call fails. Or the above loop can just be done on the client-side. -Neil
Tom Lane wrote: > Neil Conway <neilc@samurai.com> writes: > >>(2) pg_cancel_backend(), pg_reload_conf(), and pg_rotate_logfile() all >>return an int indicating success (1) or failure (0). Why shouldn't these >>functions return a boolean? I would have used boolean as return code for success and failure, but the previously existing pg_cancel_backend did return int so I matched that behaviour. > >>(Presumably there is a good reason why these functions return a status >>code at all, rather than aborting via elog on error -- right?) > > > I agree with both of those criticisms: total is more in line with our > nomenclature than complete, and the other functions should return void > and ereport when they are unhappy. (Saying "I failed" and not having > any mechanism to report why sucks.) These functions will only handle being called from a non-superuser as fatal error, failures from normal executions (i.e. returning 0) will give an elog WARNING and thus complete report about the cause, if needed. Nonexecution of these functions isn't really a problem (and not synchronizable in transactions for following statements anyway), OTOH having to deal with errors in the client that could be safely ignored or add savepoints sounds like overkill and a solution for a non-problem. Regards, Andreas
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Neil Conway <neilc@samurai.com> writes:
> > While we're on the subject, the units used by pg_size_pretty() are
> > incorrect, at least according to the IEC: for example, "MB" is
> > strictly-speaking one million bytes, not 1024^2 bytes. 1024^2 bytes is 1
> > MiB (similarly for KiB, GiB, and TiB). I'll take a look at fixing this
> > as well, barring any objections.
>
> [ itch... ] The IEC may think they get to define what's correct, but
> I don't think that squares with common usage. The only people who
> think MB is measured in decimal are disk-manufacturer marketroids.
That isn't entirely accurate, unfortunately. Telecom also generally
uses decimal. I'm as unhappy with the current situation as anyone but
it's not just disk makers & marketing folks, even amoung the computing
industry.
Thanks,
Stephen
Stephen Frost wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > >>Neil Conway <neilc@samurai.com> writes: >> >>>While we're on the subject, the units used by pg_size_pretty() are >>>incorrect, at least according to the IEC: for example, "MB" is >>>strictly-speaking one million bytes, not 1024^2 bytes. 1024^2 bytes is 1 >>>MiB (similarly for KiB, GiB, and TiB). I'll take a look at fixing this >>>as well, barring any objections. >> >>[ itch... ] The IEC may think they get to define what's correct, but >>I don't think that squares with common usage. The only people who >>think MB is measured in decimal are disk-manufacturer marketroids. > > > That isn't entirely accurate, unfortunately. Telecom also generally > uses decimal. I'm as unhappy with the current situation as anyone but > it's not just disk makers & marketing folks, even amoung the computing > industry. Telcos don't tend to follow standard computer industry thinking... Kilo, Mega and so on are used as decimal exponent multiples to SI units, like meter, gram, .... There's no such thing as a byte as physical unit, it's completely artificial. pg_size_pretty follows the standard of "df -h" or "du -h" and so on, which use the well-known 1024-multiples, as every sane user of bytes will. Regards, Andreas