Re: Back-branch update releases coming in a couple weeks - Mailing list pgsql-hackers
From | MauMau |
---|---|
Subject | Re: Back-branch update releases coming in a couple weeks |
Date | |
Msg-id | 68C7BD37CBC845768A7B1CEC67501AFC@maumau Whole thread Raw |
In response to | Re: Back-branch update releases coming in a couple weeks (Fujii Masao <masao.fujii@gmail.com>) |
Responses |
Re: Back-branch update releases coming in a couple weeks
|
List | pgsql-hackers |
From: "Fujii Masao" <masao.fujii@gmail.com> > On Thu, Jan 24, 2013 at 11:53 PM, MauMau <maumau307@gmail.com> wrote: >> I'm wondering if the fix discussed in the above thread solves my problem. >> I >> found the following differences between Horiguchi-san's case and my case: >> >> (1) >> Horiguchi-san says the bug outputs the message: >> >> WARNING: page 0 of relation base/16384/16385 does not exist >> >> On the other hand, I got the message: >> >> >> WARNING: page 506747 of relation base/482272/482304 was uninitialized >> >> >> (2) >> Horiguchi-san produced the problem when he shut the standby immediately >> and >> restarted it. However, I saw the problem during failover. >> >> >> (3) >> Horiguchi-san did not use any index, but in my case the WARNING message >> refers to an index. >> >> >> But there's a similar point. Horiguchi-san says the problem occurs after >> DELETE+VACUUM. In my case, I shut the primary down while the application >> was doing INSERT/UPDATE. As the below messages show, some vacuuming was >> running just before the immediate shutdown: >> >> ... >> LOG: automatic vacuum of table "GOLD.scm1.tbl1": index scans: 0 >> pages: 0 removed, 36743 remain >> tuples: 0 removed, 73764 remain >> system usage: CPU 0.09s/0.11u sec elapsed 0.66 sec >> LOG: automatic analyze of table "GOLD.scm1.tbl1" system usage: CPU >> 0.00s/0.14u sec elapsed 0.32 sec >> LOG: automatic vacuum of table "GOLD.scm1.tbl2": index scans: 0 >> pages: 0 removed, 12101 remain >> tuples: 40657 removed, 44142 remain system usage: CPU 0.06s/0.06u sec >> elapsed 0.30 sec >> LOG: automatic analyze of table "GOLD.scm1.tbl2" system usage: CPU >> 0.00s/0.06u sec elapsed 0.14 sec >> LOG: received immediate shutdown request >> ... >> >> >> Could you tell me the details of the problem discussed and fixed in the >> upcoming minor release? I would to like to know the phenomenon and its >> conditions, and whether it applies to my case. > > http://www.postgresql.org/message-id/20121206.130458.170549097.horiguchi.kyotaro@lab.ntt.co.jp > > Could you read the discussion in the above thread? Yes, I've just read the discussion (it was difficult for me...) Although you said the fix will solve my problem, I don't feel it will. The discussion is about the crash when the standby "re"starts after the primary vacuums and truncates a table. On the other hand, in my case, the standby crashed during failover (not at restart), emitting a message that some WAL record refers to an "uninitialized" page (not a non-existent page) of an "index" (not a table). In addition, fujii_test.sh did not reproduce the mentioned crash on PostgreSQL 9.1.6. I'm sorry to cause you trouble, but could you elaborate on how the fix relates to my case? Regards MauMau
pgsql-hackers by date: