InvalidXLogRecPtr in docs
in [PgSql]
|
From: Fujii Masao on 15 Jun 2010 01:23 On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: >> Even then, we wouldn't need to start from the beginning of the WAL >> segment AFAICS. The point is to start from the Redo pointer, not from >> the checkpoint record, because as soon as we read the checkpoint record >> we'll need to start applying WAL from the Redo pointer, which is >> earlier. The WAL file boundaries don't come into play there. > > I don't believe it's a good idea to have SR not write full xlog segment > files. �Consider for example the following scenario: > > 1. SR writes some xlog file from the middle. > 2. Filesystem says "ah-hah, I know about sparse storage" and doesn't > � allocate the first half of the file. > 3. Failover: slave goes live. > 4. xlog file gets recycled for re-use. > 5. While reusing the file, we write into the first half ... or try to, > � but there's no disk space. > 6. PANIC. > > There are probably some other good reasons not to allow incomplete > copies of WAL files to exist on the slave system, anyway. > > I'm not sure if it's worth the trouble, or even a particularly smart > idea, to force the output of the status function to be monotonic > regardless of what happens underneath. �I think removing that claim > from the docs altogether is the easiest answer. We should (1) just remove "While streaming replication is in progress this will increase monotonically." from the description about pg_last_xlog_receive_location()? or (2) add "But if streaming replication is restarted this will back off to the beginning of current WAL file" into there? I'm for (2) since it's more informative. Thought? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- 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 15 Jun 2010 01:41 On 15/06/10 08:23, Fujii Masao wrote: > On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane<tgl(a)sss.pgh.pa.us> wrote: >> I'm not sure if it's worth the trouble, or even a particularly smart >> idea, to force the output of the status function to be monotonic >> regardless of what happens underneath. I think removing that claim >> from the docs altogether is the easiest answer. > > We should > > (1) just remove "While streaming replication is in progress this will > increase monotonically." from the description about > pg_last_xlog_receive_location()? > > or > > (2) add "But if streaming replication is restarted this will back off > to the beginning of current WAL file" into there? > > I'm for (2) since it's more informative. Thought? Something like (2) seems better, because even if we remove the note that it increases monotonically, people might still assume that. -- 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: Fujii Masao on 15 Jun 2010 04:22 On Tue, Jun 15, 2010 at 2:41 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > On 15/06/10 08:23, Fujii Masao wrote: >> >> On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane<tgl(a)sss.pgh.pa.us> wrote: >>> >>> I'm not sure if it's worth the trouble, or even a particularly smart >>> idea, to force the output of the status function to be monotonic >>> regardless of what happens underneath. I think removing that claim >>> from the docs altogether is the easiest answer. >> >> We should >> >> (1) just remove "While streaming replication is in progress this will >> increase monotonically." from the description about >> pg_last_xlog_receive_location()? >> >> or >> >> (2) add "But if streaming replication is restarted this will back off >> to the beginning of current WAL file" into there? >> >> I'm for (2) since it's more informative. Thought? > > Something like (2) seems better, because even if we remove the note that it > increases monotonically, people might still assume that. The attached patch adds the following: ------------- But when streaming replication is restarted this will back off to the replication starting position, which typically indicates the beginning of the WAL file including the record in the position which <function>pg_last_xlog_replay_location</> points to at the moment. ------------- Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
From: Robert Haas on 16 Jun 2010 21:37 On Tue, Jun 15, 2010 at 4:22 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Tue, Jun 15, 2010 at 2:41 PM, Heikki Linnakangas > <heikki.linnakangas(a)enterprisedb.com> wrote: >> On 15/06/10 08:23, Fujii Masao wrote: >>> >>> On Thu, Jun 10, 2010 at 11:06 PM, Tom Lane<tgl(a)sss.pgh.pa.us> �wrote: >>>> >>>> I'm not sure if it's worth the trouble, or even a particularly smart >>>> idea, to force the output of the status function to be monotonic >>>> regardless of what happens underneath. �I think removing that claim >>>> from the docs altogether is the easiest answer. >>> >>> We should >>> >>> (1) just remove "While streaming replication is in progress this will >>> � � increase monotonically." from the description about >>> pg_last_xlog_receive_location()? >>> >>> or >>> >>> (2) add "But if streaming replication is restarted this will back off >>> � � to the beginning of current WAL file" into there? >>> >>> I'm for (2) since it's more informative. Thought? >> >> Something like (2) seems better, because even if we remove the note that it >> increases monotonically, people might still assume that. > > The attached patch adds the following: > > ------------- > But when streaming replication is > restarted this will back off to the replication starting position, > which typically indicates the beginning of the WAL file including the > record in the position which <function>pg_last_xlog_replay_location</> > points to at the moment. > ------------- Applied with some additional wordsmithing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Pages: 1 2 3 Prev: [HACKERS] InvalidXLogRecPtr in docs Next: [HACKERS] fix use of posix_fadvise in xlog.c |