Re: [HACKERS] pg_dump does not refresh matviews from extensions - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] pg_dump does not refresh matviews from extensions
Date
Msg-id 20170221200519.GI9812@tamriel.snowman.net
Whole thread Raw
In response to [HACKERS] pg_dump does not refresh matviews from extensions  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: [HACKERS] pg_dump does not refresh matviews from extensions
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: [HACKERS] Change in "policy" on dump ordering?
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Measuring replay lag