Re: tracking commit timestamps
От | Fujii Masao |
---|---|
Тема | Re: tracking commit timestamps |
Дата | |
Msg-id | CAHGQGwFhJ3CnHo1CELEfay18yg_RA-XZT-7D8NuWUoYSZ90r4Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: tracking commit timestamps (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: tracking commit timestamps
|
Список | pgsql-hackers |
On Thu, Dec 4, 2014 at 12:08 PM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Wed, Dec 3, 2014 at 11:54 PM, Alvaro Herrera > <alvherre@2ndquadrant.com> wrote: >> Pushed with some extra cosmetic tweaks. > > I got the following assertion failure when I executed pg_xact_commit_timestamp() > in the standby server. > > =# select pg_xact_commit_timestamp('1000'::xid); > TRAP: FailedAssertion("!(((oldestCommitTs) != ((TransactionId) 0)) == > ((newestCommitTs) != ((TransactionId) 0)))", File: "commit_ts.c", > Line: 315) > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > The connection to the server was lost. Attempting reset: 2014-12-04 > 12:01:08 JST sby1 LOG: server process (PID 15545) was terminated by > signal 6: Aborted > 2014-12-04 12:01:08 JST sby1 DETAIL: Failed process was running: > select pg_xact_commit_timestamp('1000'::xid); > > The way to reproduce this problem is > > #1. set up and start the master and standby servers with > track_commit_timestamp disabled > #2. enable track_commit_timestamp in the master and restart the master > #3. run some write transactions > #4. enable track_commit_timestamp in the standby and restart the standby > #5. execute "select pg_xact_commit_timestamp('1000'::xid)" in the standby > > BTW, at the step #4, I got the following log messages. This might be a hint for > this problem. > > LOG: file "pg_commit_ts/0000" doesn't exist, reading as zeroes > CONTEXT: xlog redo Transaction/COMMIT: 2014-12-04 12:00:16.428702+09; > inval msgs: catcache 59 catcache 58 catcache 59 catcache 58 catcache > 45 catcache 44 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 > catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 catcache 7 > catcache 6 catcache 7 catcache 6 catcache 7 catcache 6 snapshot 2608 > relcache 16384 This problem still happens in the master. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: