Re: [HACKERS] 8.1 system info / admin functions
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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.1 system info / admin functions
Tom Lane wrote: Neil Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] 8.1 system info / admin functions
* Tom Lane ([EMAIL PROTECTED]) wrote: Neil Conway [EMAIL PROTECTED] 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 signature.asc Description: Digital signature
Re: [HACKERS] 8.1 system info / admin functions
Stephen Frost wrote: * Tom Lane ([EMAIL PROTECTED]) wrote: Neil Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.1 system info / admin functions
Neil Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 8.1 system info / admin functions
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 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 system info / admin functions
Neil Conway [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] 8.1 system info / admin functions
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 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org