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...@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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
