Tom Lane wrote:
> "Florian G. Pflug" <fgp@phlo.org> writes:
>> My basic assumption is that DDL is something quite uncommon on a
>> production system.
>
> I'm not sure I believe that, because of temp tables. There's also
> the problem that plain VACUUM (or ANALYZE) causes a relcache flush
> to update the relation-size statistics.>
> The real problem with the scheme you propose is that it turns a
> cache flush on one table into a system-wide cache flush.
Yes.. It really builds on the idea that those flushes happen not
too frequently.
> We might be able to do something about the temp-table case upstream:
> AFAICS there's no reason for backends to broadcast cache flushes for
> their own temp tables to other backends. But that's just a sketch
> of a thought at the moment.
I was actually hoping that some day temptables wouldn't be stored in
the pg_class and friends at all. I was actually wondering if it
wouldn't be possible to keep the information about them soley in
the catcache and relcache (Making the word cache a big lie). Didn't
check if that is feasible at all, though - just an idea I got at
one point.
> Anyway, if you believe that DDL is infrequent, why are you resistant
> to the idea of WAL-logging cache flushes?
For multiple reasons.
First, cache invalidations are not the only problem caused by replaying
system-table updates. The whole SnapshotNow
business doesn't exactly make things easier too. So it feels like a
lot of added complexity and code for little gain - unless a *lot*
more things (like locking requests) are logged too.
Second, I'm sure that people would insist on a GUC to turn logging
those records off if they don't need them in their setup. Similar to
that make_wal_compressable GUC that was proposed a few weeks ago.
And if it's a GUC, the slave should be able to verify that it was
set correctly on the master, otherwise this becomes a huge footgun.
Third, I try to keep the changes necessary on the master at a
minimum - I feel that this will make merging the code at some point
easier, because the risk of breaking something is smaller. Bugs
in the slave code will maybe cause crashes and wrong results, but
at least they won't cause data corruption on the master.
And last but not least, I have only limited time for this project -
so I try to find the simplest workable solution, and maybe tune things
later when pratical experience shows where the real bottlenecks are.
greetings, Florian Pflug