On Fri, Apr 29, 2016 at 5:02 PM, Bruce Momjian <bruce@momjian.us> wrote:
>> > I think pg_dump is reasonably proof against DDL on tables. It is not
>> > at all proof against DDL on other sorts of objects, such as functions,
>> > because of the fact that the syscache will follow catalog updates that
>> > occur after pg_dump's transaction snapshot.
>>
>> Hmm, OK. I'll need to go look at that.
>>
>> I thought that the backend running the pg_dump would fill it's syscache
>> when it took all the locks and then not update them during the actual
>> dump. If that's not the case then it's a bit scary, yes.
>>
>> It seems to make a good case for physical backups vs. logical.
>
> I think another issue is that the pg_dump backend gets cache
> invalidations from other backends that cause it to reload the cache with
> new contents, so even if you pre-loaded the cache at snapshot time, you
> would still need to ignore cache invalidations from other backends.
If you temporarily nailed the backend's snapshot for syscache lookups
to some specific MVCC snapshot, as Tom was suggesting, then it
wouldn't matter if it processed invalidations, because reload would
pull the same entries as before back into the cache. So I don't think
you'd *have* to do this, but you might want to do it as an
optimization.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company