testing cvs HEAD - HS/SR - xlog timeline 0 pg_xlogfile_name_offset
in [PgSql]
|
Prev: [HACKERS] Probably badly timed suggestion: pl/perl calling style same as Cstyle
Next: [HACKERS] Streaming rep - why log shipping is necessary?
From: Heikki Linnakangas on 25 Feb 2010 03:10 Fujii Masao wrote: > On Thu, Feb 25, 2010 at 9:31 AM, Erik Rijkers <er(a)xs4all.nl> wrote: >> On Wed, February 24, 2010 20:40, Erik Rijkers wrote: >>> >>> pg_last_xlog_receive_location | pg_xlogfile_name_offset >>> -------------------------------+----------------------------------- >>> E2/C012AD90 | (00000000000000E2000000C0,1224080) >>> (1 row) >>> >>> These zero-timeline filenames look suspicious, no? >> Sorry, I've only now noticed that this issue is already on the v9.0 TODO for Streaming Replication: >> >> "pg_xlogfile_name(pg_last_xlog_receive/replay_location()) might report the wrong name. Because a >> backend cannot know the actual timeline which is related to the location. >> " >> >> http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12(a)mail.gmail.com >> >> so, nevermind.. > > Yeah, since I thought that the current behavior that you reported > would annoy many users, I added it to the TODO list. Yeah, returning a filename with TLI 0 sure doesn't seem right. A quick fix would be to just throw an error if you try to use pg_xlog_filename() during hot standby. But there seems to be good reasons to call pg_xlog_filename() during hot standby, given that both of you ran into the same issue. What exactly were you trying to achieve with it? -- 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: Heikki Linnakangas on 25 Feb 2010 05:22
Fujii Masao wrote: > On Thu, Feb 25, 2010 at 5:10 PM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> A quick fix would be to just throw an error if you try to use >> pg_xlog_filename() during hot standby. But there seems to be good >> reasons to call pg_xlog_filename() during hot standby, given that both >> of you ran into the same issue. What exactly were you trying to achieve >> with it? > > Nothing ;) Frankly I just found that problem while testing the > combination of SR and system administration functions. But on > second thought, calling pg_xlogfile_name() during HS seems useful > to remove old WAL files from the archive that is shared from > multiple standbys. In this case, '%r' in restore_command cannot > be used, so we would need to calculate the name of the WAL files > that are not required for the subsequent recovery yet by using > pg_xlogfile_name() and pg_controldata etc. Yeah. The current pg_*_last_location() functions don't cut it though, you need to retain logs back to the redo location of the last restartpoint. That's what %r returns. Maybe we should add another function? -- 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 |