From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Yury Zhuravlev <u(dot)zhuravlev(at)postgrespro(dot)ru> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Why is a newly created index contains the invalid LSN? |
Date: | 2016-08-26 02:56:38 |
Message-ID: | CAA4eK1J5hgayxL-pquthsXGubx3EmRFTSyMwhxOieZhfPzpC=w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Aug 25, 2016 at 7:55 PM, Yury Zhuravlev
<u(dot)zhuravlev(at)postgrespro(dot)ru> wrote:
> Hello hackers.
>
> I have a small question. While working on an incremental backup I noticed a
> strange thing.
> Newly created index is contains the invalid LSN (0/0).
> Exmaple:
> postgres=# select lsn from page_header(get_raw_page('test_a_idx2',0));
> lsn -----
> 0/0
> (1 row)
>
> Can you explain me why?
>
For some of the indexes like btree which are built outside shared
buffers, we don't write WAL unless wal_level >= REPLICA. I think
Robert has explained it very well how we handle the crash recovery
situation for such indexes. However, for some other indexes which
don't bypass shared buffers like BRIN, GIN we do write WAL for such
cases as well, so you must see LSN for those type of indexes. I am
less sure, if there will be any problem, if don't write WAL for those
indexes as well when wal_level < REPLICA.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tsunakawa, Takayuki | 2016-08-26 02:57:52 | Re: [bug fix] Cascading standby cannot catch up and get stuck emitting the same message repeatedly |
Previous Message | Bruce Momjian | 2016-08-26 02:55:39 | Re: Renaming of pg_xlog and pg_clog |