Re: Add the number of pinning backends to pg_buffercache's output - Mailing list pgsql-hackers

From Rajeev rastogi
Subject Re: Add the number of pinning backends to pg_buffercache's output
Date
Msg-id BF2827DCCE55594C8D7A8F7FFD3AB7713DE13BC8@SZXEML508-MBX.china.huawei.com
Whole thread Raw
In response to Re: Add the number of pinning backends to pg_buffercache's output  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Add the number of pinning backends to pg_buffercache's output  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 23 June 2014 15:22, Andres Freund Wrote:
> > This may be harmless but pinning_backends should be defined as int4
> > rather than int8 because BufferDesc->refcount is just defined as
> > unsigned and it's converted to Datum by Int32GetDatum().
>
> Well, in theory a uint32 can't generally be converted to a int32.
> That's why I chose a int64 because it's guaranteed to have sufficient
> range. It's fairly unlikely to have that many pins, but using a int64
> seems cheap enough here.

But since we have declared pinning_backends as int8, we should use Int64GetDatum to form the tuple datum.

Using Int32GetDatum will lead to issue specially incase of WIN32 platform or any other platform where int8
is not considered as USE_FLOAT8_BYVAL (or FLOAT8PASSBYVAL as 0). On such platform while initializing the tuple,
type by value will be marked as false but still value (not address) will be passed to datum, which will lead to crash.

I have done testing to verify this on win32 and able to observe the crash where as it works fine on Linux.

Also can we change the description of function "pg_buffercache_pages" to include pinning_backend also in the
description.

Thanks and Regards,
Kumar Rajeev Rastogi







pgsql-hackers by date:

Previous
From: Yeb Havinga
Date:
Subject: Re: RLS Design
Next
From: Fabien COELHO
Date:
Subject: Re: gaussian distribution pgbench