Re: xlog location arithmetic

On Wed, Feb 8, 2012 at 2:29 AM, Euler Taveira de Oliveira
<euler(at)timbira(dot)com> wrote:
> On 26-01-2012 06:19, Fujii Masao wrote:
>
> Thanks for your review. Comments below.
>
>> 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]
>>
> What is your compiler? I'm using gcc 4.6.2. I refactored the patch so I'm now
> using XLogRecPtr and %X.

gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)

$ uname -a
Linux hermes 3.0.0-15-generic #26-Ubuntu SMP Fri Jan 20 15:59:53 UTC
2012 i686 i686 i386 GNU/Linux

In the updated version of the patch, I got no warnings at the compile time.
But initdb failed because the OID which you assigned to pg_xlog_location_diff()
has already been used for other function. So you need to update pg_proc.h.

>> postgres=# SELECT pg_xlog_location_diff('0/2000074', '0/2000074');
>> ERROR:  xrecoff "2000074" is out of valid range, 0..A4A534C
>>
> Ugh? I can't reproduce that. It seems to be related to long int used by the
> prior version.

Maybe.

But another problem happened. When I changed pg_proc.h so that the unused
OID was assigned to pg_xlog_location_diff(), and executed the above again,
I encountered the segmentation fault:

LOG: server process (PID 14384) was terminated by signal 11: Segmentation fault
DETAIL: Failed process was running: SELECT
pg_xlog_location_diff('0/2000074', '0/2000074');
LOG: terminating any other active server processes

ISTM that the cause is that int8_numeric() is executed for uint32 value. We
should use int4_numeric(), instead?

>>> 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 realized that it collides with the pg_size_pretty(int8) if we don't specify
> a type. Hence, I decided to drop the pg_size_pretty(int8) in favor of
> pg_size_pretty(numeric). It is slower than the former but it is not a
> performance critical function.

I'm OK with this.

-DATA(insert OID = 2288 ( pg_size_pretty PGNSP PGUID 12 1 0 0 0 f f
f t f v 1 0 25 "20" _null_ _null_ _null_ _null_ pg_size_pretty _null_
_null_ _null_ ));
-DESCR("convert a long int to a human readable text using size units");
+DATA(insert OID = 3158 ( pg_size_pretty PGNSP PGUID 12 1 0 0 0 f f
f t f v 1 0 25 "1700" _null_ _null_ _null_ _null_ pg_size_pretty
_null_ _null_ _null_ ));
+DESCR("convert a numeric to a human readable text using size units");

Why OID needs to be reassigned?

Regards,

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