| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: xlog location arithmetic |
| Date: | 2012-03-09 14:55:09 |
| Message-ID: | 28804.1331304909@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
I wrote:
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>> Euler proposed one more patch upthread, which replaces pg_size_pretty(bigint)
>> with pg_size_pretty(numeric) so that pg_size_pretty(pg_xlog_location_diff())
>> succeeds. It's also worth committing this patch?
> Why would it be useful to use pg_size_pretty on xlog locations?
> -1 because of the large expense of bigint->numeric->whatever conversion
> that would be added to existing uses.
Actually ... now that I look at it, isn't it completely bogus to be
using numeric for the result of pg_xlog_location_diff? There's no way
for the difference of two xlog locations to be anywhere near as wide as
64 bits. That'd only be possible if XLogFileSize exceeded 1GB, which we
don't let it get anywhere near.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2012-03-09 15:00:55 | Re: xlog location arithmetic |
| Previous Message | Robert Haas | 2012-03-09 14:53:38 | Re: logging in high performance systems. |