Re: BUG #6200: standby bad memory allocations on SELECT
От | Robert Haas |
---|---|
Тема | Re: BUG #6200: standby bad memory allocations on SELECT |
Дата | |
Msg-id | CA+Tgmoaecqw4yiBJnkdcrWCys5eCfn4=5ahSqPxy2rcoh=6Kag@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #6200: standby bad memory allocations on SELECT (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: BUG #6200: standby bad memory allocations on SELECT
|
Список | pgsql-bugs |
On Wed, Feb 1, 2012 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> No, I wasn't thinking about a tuple descriptor mismatch. =A0I was >> imagining that the page contents themselves might be in flux while >> we're trying to read from it. > > Oh, gotcha. =A0Yes, that's a horribly plausible idea. =A0All it'd take is > one WAL replay routine that hasn't been upgraded to acquire sufficient > buffer locks. =A0Pre-hot-standby, there was no reason for them to be > careful about locking. > > On the other hand, if that were the cause, you'd expect the symptoms > to be a bit more variable... Well, OP has two: crash, and invalid memory allocation. Both share the common thread that they happen while trying to decode a tuple. It would be nice to get a dump of what PostgreSQL thought the entire block looked like at the time the crash happened. That information is presumably already in the core dump, but I'm not sure if there's a nice way to extract it using gdb. --=20 Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-bugs по дате отправления: