Re: xlog location arithmetic

On Sun, Jan 22, 2012 at 1:13 AM, Euler Taveira de Oliveira
<euler(at)timbira(dot)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.h operators 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