Обсуждение: [HACKERS] pg_dump does not refresh matviews from extensions
I think $SUBJECT is a bug. While it would be unusual for an extension to have a matview, it's still allowed, and as it stands right now that view won't be refreshed at the end of a restore, unlike other matviews. I started looking into a patch for this, but I'm not sure of the best way to handle it. One possibility is to glom this in with the code that handles extension config tables, but that doesn't feel right since matviews aren't really config. Would the best option be to change selectDumpableTable(), but I suspect that'd have to use the same "dumpobj" logic that processExtensionTables() uses. -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
Jim, * Jim Nasby (Jim.Nasby@BlueTreble.com) wrote: > I think $SUBJECT is a bug. While it would be unusual for an > extension to have a matview, it's still allowed, and as it stands > right now that view won't be refreshed at the end of a restore, > unlike other matviews. > > I started looking into a patch for this, but I'm not sure of the > best way to handle it. One possibility is to glom this in with the > code that handles extension config tables, but that doesn't feel > right since matviews aren't really config. > > Would the best option be to change selectDumpableTable(), but I > suspect that'd have to use the same "dumpobj" logic that > processExtensionTables() uses. As I noted elsewhere, I'd kind of like to see processExtensionTables() go away in favor of doing more in selectDumpableTable(), since we can now track the fact that we should restore just the data for a given table through the dump bitmap. As for $SUBJECT, I feel like it really depends, doesn't it? If the extension creates the matview w/ no data in it, and doesn't mark it as a config table, should we really refresh it? On the other hand, if the extension creates the matview and either refreshes it, or something else refreshes it later, then perhaps we should do so too, to get us back to the same state. Of course, we also need to consider pg_upgrade and make sure that, whatever we do, what happens with pg_upgrade makes sense. Thanks! Stephen
On 2/21/17 2:05 PM, Stephen Frost wrote: > As for $SUBJECT, I feel like it really depends, doesn't it? If the > extension creates the matview w/ no data in it, and doesn't mark it as a > config table, should we really refresh it? On the other hand, if the > extension creates the matview and either refreshes it, or something > else refreshes it later, then perhaps we should do so too, to get us > back to the same state. I didn't think to test marking the matview as dumpable. If I do that then a refresh item does get created, and it's actually based on whether the view contains any data. We should at least document that. Now that I know that, I guess I'm kinda on the fence about doing it automatically, because AFAIK there'd be no way to override that automatic behavior. I can't really conceive of any reason you wouldn't want the refresh, but since it's not happening today... -- Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX Experts in Analytics, Data Architecture and PostgreSQL Data in Trouble? Get it in Treble! http://BlueTreble.com 855-TREBLE2 (855-873-2532)
On Thu, Feb 23, 2017 at 5:11 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote: > Now that I know that, I guess I'm kinda on the fence about doing it > automatically, because AFAIK there'd be no way to override that automatic > behavior. I can't really conceive of any reason you wouldn't want the > refresh, but since it's not happening today... Well, it would make pg_dump run longer to do something you may not care about. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company