On 2015-01-23 12:52:03 -0600, Jim Nasby wrote:
> On 1/22/15 3:18 PM, Andres Freund wrote:
> >>, but to then put it's entire contents into WAL? Blech.
> >Besides actually having a chance of being correct, doing so will save
> >having to do two checkpoints inside movedb(). I think it's pretty likely
> >that that actually saves overall IO, even including the WAL
> >writes. Especially if there's other databases in the cluster at the same
> >time.
>
> If you're moving a small amount of data, maybe. If you're moving
> several hundred GB or more? You're going to flood WAL and probably
> cause all replication/archiving to lag.
I have hard time believing many people do AD ST on a database a couple
hundred GB large. That'd mean the database is out of business for a
significant amount of time (remember, there can't be any connected users
during that time). I think realistically it's only used on smaller
databases.
The reason createdb()/movedb() work the way they do is imo simply
because they're old.
So far I can't see how the current solution can actually be made safe to
be executed on a not yet consistent database. And we obviously can't
wait for it to be consistent (as we're replaying a linear stream of WAL).
> Is there some way we can add an option to control this? I'm thinking
> that by default ADAT will error if a backup is running, but allow the
> user to over-ride that.
Why would we want to allow that? There's simply no way it's safe, so
...?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services