Re: Add the number of pinning backends to pg_buffercache's output

From: Rajeev rastogi <rajeev(dot)rastogi(at)huawei(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add the number of pinning backends to pg_buffercache's output
Date: 2014-07-02 08:55:05
Message-ID: BF2827DCCE55594C8D7A8F7FFD3AB7713DE13BC8@SZXEML508-MBX.china.huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2014-07-02 09:05:56 Re: gaussian distribution pgbench
Previous Message Yeb Havinga 2014-07-02 08:33:56 Re: RLS Design