Re: xlog location arithmetic

On Sun, Jan 22, 2012 at 1:13 AM, Euler Taveira de Oliveira
<euler@timbira.com> wrote:
> On 23-12-2011 12:05, Tom Lane wrote:
>> I too think a datatype is overkill, if we're only planning on providing
>> one function.  Just emit the values as numeric and have done.
>>
> Here it is. Output changed to numeric.

Thanks!

When I compiled the source with xlogdiff.patch, I got the following warnings.

xlogfuncs.c:511:2: warning: format '%lX' expects argument of type
'long unsigned int *', but argument 3 has type 'uint64 *' [-Wformat]
xlogfuncs.c:511:2: warning: format '%lX' expects argument of type
'long unsigned int *', but argument 4 has type 'uint64 *' [-Wformat]
xlogfuncs.c:515:2: warning: format '%lX' expects argument of type
'long unsigned int *', but argument 3 has type 'uint64 *' [-Wformat]
xlogfuncs.c:515:2: warning: format '%lX' expects argument of type
'long unsigned int *', but argument 4 has type 'uint64 *' [-Wformat]
xlogfuncs.c:524:3: warning: format '%lX' expects argument of type
'long unsigned int', but argument 2 has type 'uint64' [-Wformat]
xlogfuncs.c:528:3: warning: format '%lX' expects argument of type
'long unsigned int', but argument 2 has type 'uint64' [-Wformat]

When I tested the patch, I got the following error:

postgres=# SELECT pg_current_xlog_location();pg_current_xlog_location
--------------------------0/2000074
(1 row)

postgres=# SELECT pg_xlog_location_diff('0/2000074', '0/2000074');
ERROR:  xrecoff "2000074" is out of valid range, 0..A4A534C

In func.sgml  <para>   The functions shown in <xref   linkend="functions-admin-backup-table"> assist in making on-line
backups.  These functions cannot be executed during recovery.  </para> 

Since pg_xlog_location_diff() can be executed during recovery,
the above needs to be updated.

> While the output was int8 I could use
> pg_size_pretty but now I couldn't. I attached another patch that implements
> pg_size_pretty(numeric).

I agree it's necessary.
* Note: every entry in pg_proc.h is expected to have a DESCR() comment,* except for functions that implement
pg_operator.hoperators and don't* have a good reason to be called directly rather than via the operator. 

According to the above source code comment in pg_proc.h, ISTM
pg_size_pretty() for numeric also needs to have its own DESCR().

+            buf = DatumGetCString(DirectFunctionCall1(numeric_out,
NumericGetDatum(size)));
+            result = strcat(buf, " kB");

According to "man strcat", the dest string must have enough space for
the result.
"buf" has enough space?

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center