8.1 system info / admin functions

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