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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
