Re: pg_upgrade and epoch

On Wed, Apr 23, 2014 at 07:08:42AM +0400, Sergey Burladyan wrote:
> On Wed, Apr 23, 2014 at 6:38 AM, Sergey Konoplev <gray(dot)ru(at)gmail(dot)com> wrote:
>
>
> BTW, I didn't manage to make a test case yet. Recently, when I was
> migrating several servers to skytools3 and upgrading from 9.0 to 9.2,
> I noticed that epoch was copied, timeline id was >0 after upgrade, but
>
> ...
>
> This is strange, if I not mistaken XID copied by  copy_clog_xlog_xid(void):
> http://doxygen.postgresql.org/pg__upgrade_8c_source.html#l00398
> and there is no epoch (-e XIDEPOCH) in pg_resetxlog call args
...
> 34359739064 switched to 756 after upgrade

Yes, that looks about right, though not exact:

34359739064 - 8 * 2^32 = 696

I looked at this last night and am trying to figure out the extent of
the bug. We have had timestamp epochs since pg_upgrade was created and
this is the first time I am hearing that not preserving timestamp epochs
is a problem.

Do we store the timestamp epoch anywhere in the data files, or just in
pg_controldata? (pg_upgrade does not preserve WAL files.) I know we
have talked about using epochs on data pages but I am not sure we have
ever done it. Sergey, are you seeing a problem only because you are
interacting with other systems that didn't reset their epoch?

It is an easy fix, but I need to understand the scope of the problem.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +