Обсуждение: pgsql: Fix crash bug in RestoreSnapshot.

Fix crash bug in RestoreSnapshot.

If serialized_snapshot->subxcnt > 0 and serialized_snapshot->xcnt == 0,
the old coding would do the wrong thing and crash.  This can happen
on standby servers.

Report by Andreas Seltenreich.  Patch by Thomas Munro, reviewed by
Amit Kapila and tested by Andreas Seltenreich.

Branch
------
REL9_5_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/8f4a369c28be28351ce64e12ac895db515dd5916

Modified Files
--------------
src/backend/utils/time/snapmgr.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

On Fri, Jul 1, 2016 at 9:34 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> "This can happen on standby servers"
>
> The commit message doesn't mention, but it applies only to parallel query?
>
> Why then is this backpatched to 9.5?

Because that's where the code was added.  In 9.5, it would only matter
for extensions using the ParallelContext machinery.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Simon Riggs <simon@2ndquadrant.com> writes:
> On 1 July 2016 at 16:04, Robert Haas <robertmhaas@gmail.com> wrote:
>> Because that's where the code was added.  In 9.5, it would only matter
>> for extensions using the ParallelContext machinery.

> It seems strange to me to make an unnecessary change to a production
> release, that's all.
> My understanding was that we backpatched only as far as a bug occurs,
> rather than as far as patch can be applied.

I think Robert is saying that the problem *is* reachable in 9.5, given
a suitable extension.  In that case fixing it is appropriate, whether
or not we know of such an extension today.

            regards, tom lane

On Fri, Jul 1, 2016 at 10:43 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
>> On 1 July 2016 at 16:04, Robert Haas <robertmhaas@gmail.com> wrote:
>>> Because that's where the code was added.  In 9.5, it would only matter
>>> for extensions using the ParallelContext machinery.
>
>> It seems strange to me to make an unnecessary change to a production
>> release, that's all.
>> My understanding was that we backpatched only as far as a bug occurs,
>> rather than as far as patch can be applied.
>
> I think Robert is saying that the problem *is* reachable in 9.5, given
> a suitable extension.  In that case fixing it is appropriate, whether
> or not we know of such an extension today.

Right.  This is no different from any of the other fixes for parallel
infrastructure which have been back-patched to the releases in which
the relevant code was added - in particular, see commits
038aa89af53ee6ee26dfc9e73704d4e94701588f,
5eca6cf99411bfd47f43fc742552c9a2ae459bc8,
87abcb4ebd48f5d8f7244236f8839854c1861537,
e9215461d2a6081812d9c3619c9ec81e5682fe0f,
e72f2115ef6d574c64f42ea8b4cbe96accee08b2,
df58a17df29f7ec0ffc8389deee46e81a2a58a60,
c98605cc47fe42fac5f685d611db2a0c1afa2fcf,
73d71cde5751e06d372431178e740835284eb132,
14129d1c9e2d3afa064651012a55c9c84aa6821a,
26981d292758c6ee9185332e4abc990ff19c81a2, and
91d97f03ca2a9ed56b322b69dde0392db835f722.  There are probably others.
I think it's our standard practice to back-patch bug fixes to the
point at which the code was introduced, even if in that release the
code can only be reached by an extension.  I can't actually understand
why we would do anything else.  There's no benefit to leaving that
code broken in 9.5.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company