Re: Back-branch update releases coming in a couple weeks
От | Fujii Masao |
---|---|
Тема | Re: Back-branch update releases coming in a couple weeks |
Дата | |
Msg-id | CAHGQGwGaJf9rim4Zf2zAiv_yT22sejiN3Yv_BHKy7_MNGUuBnw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Back-branch update releases coming in a couple weeks ("MauMau" <maumau307@gmail.com>) |
Ответы |
Re: Back-branch update releases coming in a couple weeks
|
Список | pgsql-hackers |
On Sun, Jan 27, 2013 at 12:17 AM, MauMau <maumau307@gmail.com> wrote: > 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? Maybe I had not been understanding your problem correctly. Could you show the self-contained test case which reproduces the problem? Is the problem still reproducible in REL9_1_STABLE? Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления:
Следующее
От: Josh BerkusДата:
Сообщение: Re: Cascading replication: should we detect/prevent cycles?