Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 |
Дата | |
Msg-id | CA+TgmoY6VCYUJrxs=x2sBCPPYO0Jsm0dwYoBaCorQW8eoSP09g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access status of transaction 1 (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Re: 9.4.1 -> 9.4.2 problem: could not access
status of transaction 1
|
Список | pgsql-general |
On Tue, Jun 2, 2015 at 5:22 PM, Andres Freund <andres@anarazel.de> wrote: >> > Hm. If GetOldestMultiXactOnDisk() gets the starting point by scanning >> > the disk it'll always get one at a segment boundary, right? I'm not sure >> > that's actually ok; because the value at the beginning of the segment >> > can very well end up being a 0, as MaybeExtendOffsetSlru() will have >> > filled the page with zeros. >> > >> > I think that should be harmless, the worst that can happen is that >> > oldestOffset errorneously is 0, which should be correct, even though >> > possibly overly conservative, in these cases. >> >> Uh oh. That seems like a real bad problem for this approach. What >> keeps that from being the opposite of too conservative? There's no >> "safe" value in a circular numbering space. > > I think it *might* (I'm really jetlagged) be fine because that'll only > happen after a upgrade from < 9.3. And in that case we initialize > nextOffset to 0. That ought to safe us? That's pretty much betting the farm on the bugs we know about today being the only ones there are. That seems imprudent. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-general по дате отправления: