From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, oonishitk(at)nttdata(dot)co(dot)jp, pgsql-docs <pgsql-docs(at)postgresql(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [DOCS] max_worker_processes on the standby |
Date: | 2015-12-09 21:11:14 |
Message-ID: | CA+TgmoZ8dsJnFbR88hHzPnteSRw3H-kzUFBdPTcHbH=2rZdafA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers |
On Mon, Dec 7, 2015 at 8:33 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Sat, Dec 5, 2015 at 12:56 AM, Alvaro Herrera
> <alvherre(at)2ndquadrant(dot)com> wrote:
>> Fujii Masao wrote:
>>
>>> Sorry for not reviewing the patch before you push it...
>>>
>>> In HEAD, I ran very simple test case:
>>>
>>> 1. enable track_commit_timestamp
>>> 2. start the server
>>> 3. run some transactions
>>> 4. execute pg_last_committed_xact() -- returns non-null values
>>> 5. shutdown the server with immdiate mode
>>> 6. restart the server -- crash recovery happens
>>> 7. execute pg_last_committed_xact()
>>>
>>> The last call of pg_last_committed_xact() returns NULL values, which means
>>> that the xid and timestamp information of the last committed transaction
>>> disappeared by crash recovery. Isn't this a bug?
>>
>> Hm, not really, because the status of the "last" transaction is kept in
>> shared memory as a cache and not expected to live across a restart.
>> However, I tested the equivalent scenario:
>>
>> alvherre=# create table fg();
>> CREATE TABLE
>>
>> alvherre=# select ts.* from pg_class,pg_xact_commit_timestamp(xmin) ts where relname = 'fg';
>> ts
>> -------------------------------
>> 2015-12-04 12:41:48.017976-03
>> (1 fila)
>>
>> then crash the server, and after recovery the data is gone:
>>
>> alvherre=# select ts.*, xmin, c.relname from pg_class c,pg_xact_commit_timestamp(xmin) ts where relname = 'fg';
>> ts | xmin | relname
>> ----+------+---------
>> | 630 | fg
>> (1 fila)
>>
>> Not sure what is going on; my reading of the code certainly says that
>> the data should be there. I'm looking into it.
>>
>> I also noticed that I didn't actually push the whole of the patch
>> yesterday -- I neglected to "git add" the latest changes, the ones that
>> fix the promotion scenario :-( so the commit messages is misleading
>> because it describes something that's not there.
>
> So firstly you will push those "latest" changes soon?
It seems like these changes haven't been pushed yet, and unfortunately
that's probably a beta blocker.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2015-12-09 21:21:21 | Re: [HACKERS] max_worker_processes on the standby |
Previous Message | Fujii Masao | 2015-12-07 13:33:43 | Re: [HACKERS] max_worker_processes on the standby |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-12-09 21:18:03 | Re: Some questions about the array. |
Previous Message | Robert Haas | 2015-12-09 19:40:10 | Re: [PROPOSAL] VACUUM Progress Checker. |