Skip site navigation (1) Skip section navigation (2)

Re: xlog location arithmetic

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Euler Taveira de Oliveira <euler(at)timbira(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: xlog location arithmetic
Date: 2012-02-08 12:35:15
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


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?


Fujii Masao
NTT Open Source Software Center

In response to


pgsql-hackers by date

Next:From: Peter EisentrautDate: 2012-02-08 12:47:01
Subject: Re: ecpglib use PQconnectdbParams
Previous:From: Shigeru HanadaDate: 2012-02-08 12:24:40
Subject: Re: pgsql_fdw, FDW for PostgreSQL server

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group