Views aren't updated after the swap

[shayonj]

Views aren't updated after the swap

[jfrost]

My opinion: Since the whole spirit of pg-osc is to minimize locking during schema changes, we should do the view replacement outside the other transaction so we don't hold that AccessExlusive any longer than necessary. That said, replacing a view should be nearly instantaneous, so I could see the counter argument. My vote is: outside replay_and_swap and before drop_and_cleanup.

[brycethornton]

Thanks once again for the great work!

[jfrost]

This is a good callout. We should at least mention this in the caveats. Any chance you want to make a PR?

[shayonj]

Yeah that’s a caveat! I think documentation might have had it at some point. Will add it.

I will try to take a pass it this weekend and see if we can support this feature.

[shayonj]

Updated README to reflect the caveat.

[shayonj]

So, had a chance to think more. Here is a quick summary

I think we can re-create the view in the transaction after we swap the table names here. However, the downside here is we could've kept the exclusive lock open for a while, basically depending on how long it takes to re-create the view. Which can affect performance/reliability of the app.

The other option is - instead of re-creating the view from replay_and_swap! (like above), it might be worth re-creating it right before drop_and_cleanup. The assumption here: Having delayed refreshed data within a view is much more preferable than a longer swap time w/ reliability concerns. And, after the views are refreshed, we can successfully drop the old tables too. And if adding/replacing views take a while, thats ok during this part of the proess.

We can use pg_get_viewdef to get the view definition and swap the name of the op_table* name with the parent table and perform a CREATE OR REPLACE VIEW...