Re: xlog location arithmetic - Mailing list pgsql-hackers
From | Fujii Masao |
---|---|
Subject | Re: xlog location arithmetic |
Date | |
Msg-id | CAHGQGwEV==i8q50KpKBqpG+L6KMuE+XwUFc9FpuWb1+LMfUwDQ@mail.gmail.com Whole thread Raw |
In response to | Re: xlog location arithmetic (Euler Taveira de Oliveira <euler@timbira.com>) |
Responses |
Re: xlog location arithmetic
|
List | pgsql-hackers |
On Wed, Feb 8, 2012 at 2:29 AM, Euler Taveira de Oliveira <euler@timbira.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
pgsql-hackers by date: