Move tablespace
in [PgSql]
|
Prev: Should database = all in pg_hba.conf match a replication connection?
Next: recovery_connections cannot start (was Re: [HACKERS] master instandby mode croaks)
From: Tom Lane on 20 Apr 2010 21:03 Simon Riggs <simon(a)2ndQuadrant.com> writes: > Following patch writes a new WAL record that just says "copy foo to > newts" and during replay we flush buffers and then re-execute the copy > (but only when InArchiveRecovery). So the copy happens locally on the > standby, not copying from primary to standby. We do this just with a > little refactoring and a simple new WAL message. And what happens to crash-recovery replay? You can't have it both ways, either the data is in WAL or it's missing. > Objections? This is NOT the time to be rushing in marginal performance optimizations. I don't think you've thought through all the corner cases anyway. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 21 Apr 2010 02:50 On Tue, 2010-04-20 at 21:03 -0400, Tom Lane wrote: > Simon Riggs <simon(a)2ndQuadrant.com> writes: > > Following patch writes a new WAL record that just says "copy foo to > > newts" and during replay we flush buffers and then re-execute the copy > > (but only when InArchiveRecovery). So the copy happens locally on the > > standby, not copying from primary to standby. We do this just with a > > little refactoring and a simple new WAL message. > > And what happens to crash-recovery replay? You can't have it both ways, > either the data is in WAL or it's missing. The patch changes nothing in the case of crash recovery. There is no WAL written if !XLogIsNeeded, so we *must* have already made the decision that the absence of WAL is not a problem for crash recovery. Note that currently we flush the new table to disk just like we do for heap_sync(), whether or not WAL is written. > > Objections? > > This is NOT the time to be rushing in marginal performance > optimizations. I don't think you've thought through all the corner > cases anyway. The performance gain isn't marginal, otherwise I wouldn't have bothered writing it * We avoid writing GB of unnecessary WAL data on primary * We avoid streaming that WAL data to the standby If you can see a corner case that I do not, please say. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Heikki Linnakangas on 21 Apr 2010 07:37 Simon Riggs wrote: > On Tue, 2010-04-20 at 21:03 -0400, Tom Lane wrote: >> Simon Riggs <simon(a)2ndQuadrant.com> writes: >>> Following patch writes a new WAL record that just says "copy foo to >>> newts" and during replay we flush buffers and then re-execute the copy >>> (but only when InArchiveRecovery). So the copy happens locally on the >>> standby, not copying from primary to standby. We do this just with a >>> little refactoring and a simple new WAL message. >> And what happens to crash-recovery replay? You can't have it both ways, >> either the data is in WAL or it's missing. > > The patch changes nothing in the case of crash recovery. What happens if the record is replayed twice in archive recovery? For example if you stop and restart a standby server after it has replayed that record. What does the 2nd redo attempt do if the source file was already deleted by the 1st recovery. I also think we shouldn't be fiddling with this at this stage in the release cycle. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Simon Riggs on 21 Apr 2010 08:01 On Wed, 2010-04-21 at 14:37 +0300, Heikki Linnakangas wrote: > Simon Riggs wrote: > > On Tue, 2010-04-20 at 21:03 -0400, Tom Lane wrote: > >> Simon Riggs <simon(a)2ndQuadrant.com> writes: > >>> Following patch writes a new WAL record that just says "copy foo to > >>> newts" and during replay we flush buffers and then re-execute the copy > >>> (but only when InArchiveRecovery). So the copy happens locally on the > >>> standby, not copying from primary to standby. We do this just with a > >>> little refactoring and a simple new WAL message. > >> And what happens to crash-recovery replay? You can't have it both ways, > >> either the data is in WAL or it's missing. > > > > The patch changes nothing in the case of crash recovery. > > What happens if the record is replayed twice in archive recovery? For > example if you stop and restart a standby server after it has replayed > that record. What does the 2nd redo attempt do if the source file was > already deleted by the 1st recovery. If the source is absent then we know that replay had successfully copied the file and synced it, so we can just skip the record. > I also think we shouldn't be fiddling with this at this stage in the > release cycle. OK, but not because I see a problem with the technique. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 21 Apr 2010 11:53
Simon Riggs <simon(a)2ndQuadrant.com> writes: > On Wed, 2010-04-21 at 14:37 +0300, Heikki Linnakangas wrote: >> I also think we shouldn't be fiddling with this at this stage in the >> release cycle. > OK, but not because I see a problem with the technique. You made that plain already, but you have not convinced anyone else. More to the point, ALTER SET TABLESPACE is not an operation that happens so much that we ought to take any risks to optimize it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |