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.ru@gmail.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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +