From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Michael Paquier <michael@paquier.xyz>,
        "Tsunakawa,
    Takayuki" <tsunakawa.takay@jp.fujitsu.com>,
        Robert Haas <robertmhaas@gmail.com>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: removal of dangling temp tables
In-reply-to: <30125.1546014939@sss.pgh.pa.us>
References: <201812281623.qlyp5nygu3pt@alvherre.pgsql>
 <30125.1546014939@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Fri, 28 Dec 2018 11:35:39 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <30573.1546015645.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 28 Dec 2018 11:47:25 -0500
Message-ID: <30574.1546015645@sss.pgh.pa.us>
Precedence: bulk

I wrote:
> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
>> I looked at =

>> https://github.com/postgrespro/pg_wait_sampling/blob/master/pg_wait_sam=
pling.c
>> https://github.com/citusdata/citus/search?q=3Dpgproc&unscoped_q=3Dpgpro=
c
>> and skimmed a few others can't find any instance where the full struct
>> is used, as opposed to just a pointer to it.

> No, the point Michael is making is that the array stride in the ProcArra=
y
> is part of our ABI.  For example, accessing a PGPROC from its pgprocno
> using the GetPGProcByNumber macro will be broken if we change the
> struct size.  I do not think you can assume that no extension does that.

In fact, there's a counterexample right here in pg_wait_sampling:

https://github.com/postgrespro/pg_wait_sampling/blob/master/pg_wait_sampli=
ng.c#L343

			regards, tom lane