Correctly handle relcache invalidation corner case during logical decoding.
Correctly handle relcache invalidation corner case during logical decoding.

When using a historic snapshot for logical decoding it can validly
happen that a relation that's in the relcache isn't visible to that
historic snapshot.  E.g. if a newly created relation is referenced in
the query that uses the SQL interface for logical decoding and a
sinval reset occurs.

The earlier commit that fixed the error handling for that corner case
already improves the situation as a ERROR is better than hitting an
assertion... But it's obviously not good enough.  So additionally
allow that case without an error if a historic snapshot is set up -
that won't allow an invalid entry to stay in the cache because it's a)
already marked invalid and will thus be rebuilt during the next access
b) the syscaches will be reset at the end of decoding.

There might be prettier solutions to handle this case, but all that we
could think of so far end up being much more complex than this quite
simple fix.

This fixes the assertion failures reported by the buildfarm (markhor,
tick, leech) after the introduction of new regression tests in
89fd41b390a4. The failure there weren't actually directly caused by
CLOBBER_CACHE_ALWAYS but the extraordinary long runtimes due to it
lead to sinval resets triggering the behaviour.

Discussion: 22459.1418656530@sss.pgh.pa.us

Backpatch to 9.4 where logical decoding was introduced.

greenplum-db/gpdb,adam8157/gpdb,adam8157/gpdb,ovr/postgres-xl,adam8157/gpdb,ashwinstar/gpdb,lisakowen/gpdb,Postgres-XL/Postgres-XL,jmcatamney/gpdb,50wu/gpdb,Postgres-XL/Postgres-XL,lisakowen/gpdb,greenplum-db/gpdb,techdragon/Postgres-XL,pavanvd/postgres-xl,pavanvd/postgres-xl,xinzweb/gpdb,oberstet/postgres-xl,lisakowen/gpdb,yazun/postgres-xl,jmcatamney/gpdb,zeroae/postgres-xl,50wu/gpdb,lisakowen/gpdb,ashwinstar/gpdb,ovr/postgres-xl,techdragon/Postgres-XL,greenplum-db/gpdb,zeroae/postgres-xl,xinzweb/gpdb,ovr/postgres-xl,xinzweb/gpdb,techdragon/Postgres-XL,jmcatamney/gpdb,Postgres-XL/Postgres-XL,adam8157/gpdb,jmcatamney/gpdb,greenplum-db/gpdb,50wu/gpdb,jmcatamney/gpdb,adam8157/gpdb,50wu/gpdb,ashwinstar/gpdb,zeroae/postgres-xl,xinzweb/gpdb,greenplum-db/gpdb,zeroae/postgres-xl,greenplum-db/gpdb,pavanvd/postgres-xl,xinzweb/gpdb,yazun/postgres-xl,lisakowen/gpdb,ovr/postgres-xl,ashwinstar/gpdb,pavanvd/postgres-xl,zeroae/postgres-xl,oberstet/postgres-xl,oberstet/postgres-xl,ashwinstar/gpdb,ashwinstar/gpdb,pavanvd/postgres-xl,xinzweb/gpdb,lisakowen/gpdb,50wu/gpdb,50wu/gpdb,Postgres-XL/Postgres-XL,50wu/gpdb,greenplum-db/gpdb,adam8157/gpdb,oberstet/postgres-xl,techdragon/Postgres-XL,jmcatamney/gpdb,ashwinstar/gpdb,yazun/postgres-xl,Postgres-XL/Postgres-XL,50wu/gpdb,xinzweb/gpdb,jmcatamney/gpdb,lisakowen/gpdb,techdragon/Postgres-XL,ovr/postgres-xl,greenplum-db/gpdb,xinzweb/gpdb,ashwinstar/gpdb,yazun/postgres-xl,jmcatamney/gpdb,yazun/postgres-xl,adam8157/gpdb,oberstet/postgres-xl,lisakowen/gpdb,adam8157/gpdb