Re: [COMMITTERS] pgsql: Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset()
От | Simon Riggs |
---|---|
Тема | Re: [COMMITTERS] pgsql: Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset() |
Дата | |
Msg-id | 1270712783.24910.6836.camel@ebony обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Forbid using pg_xlogfile_name() and pg_xlogfile_name_offset() (Fujii Masao <masao.fujii@gmail.com>) |
Список | pgsql-hackers |
On Thu, 2010-04-08 at 16:41 +0900, Fujii Masao wrote: > >> > Why? The tli of the last WAL record received is always the > >> > recovery target tli currently. > >> > >> True. > > > > Only in streaming mode. If you use the current TLI as I have suggested > > then it will be correct in more cases. > > pg_last_xlog_receive_location() might be executed also after archive > recovery ends. In this case, using the current tli seems not correct > because it's always different from the recovery target tli after recovery. Which is why the code I write says "if (RecoveryInProgress())" > >> Hmm, currently pg_last_xlog_receive_location() returns the last location > >> streamed via streaming replication. Should that be changed so that it > >> also advances when a WAL segment is restored from archive? It seems > >> strange that pg_last_xlog_receive_location() can be smaller than > >> pg_last_xlog_replay_location(). > > > > Yes, it should be changed. > > Should it advance when WAL file in pg_xlog is read? If not, > pg_last_xlog_receive_location() can be smaller than > pg_last_xlog_replay_location(). > > And, how far should it advance when WAL file is > partially-filled for some reasons? Just make pg_last_xlog_receive_location() do exactly the same thing as pg_last_xlog_replay_location() when working with files. No need to try to keep two things exactly in sync. -- Simon Riggs www.2ndQuadrant.com
В списке pgsql-hackers по дате отправления: