Re: Memory use in 8.3 plpgsql with heavy use of xpath()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Memory use in 8.3 plpgsql with heavy use of xpath()
Дата
Msg-id 22701.1215057354@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Memory use in 8.3 plpgsql with heavy use of xpath()  ("Matt Magoffin" <postgresql.org@msqr.us>)
Ответы Re: Memory use in 8.3 plpgsql with heavy use of xpath()  ("Matt Magoffin" <postgresql.org@msqr.us>)
Re: Memory use in 8.3 plpgsql with heavy use of xpath()  (Gregory Stark <stark@enterprisedb.com>)
Список pgsql-general
"Matt Magoffin" <postgresql.org@msqr.us> writes:
>> So there may be a second issue remaining to be found.  Can you put
>> together a test case for the long-term small leak?

> Hmm, I'm not sure what else to add to this test case. This test case was a
> good example of what our database is doing with xpath(); it is using quite
> a number of them, that's all. Is there something else in particular you'd
> be looking for in another test case?

Well, you tell me --- *you* reported a behavior that isn't obviously
explained by the bug we found.

It's possible that what you were seeing was an indirect effect of the
now-known bug: if the xpath leak were to occur repeatedly on a large
scale in a long-lived session, I think it's possible that memory
allocation behavior might suffer due to fragmentation effects.
I feel that that's a pretty hand-wavy explanation though.

Probably the right thing for you to do now is just to install the known
fix, and keep an eye on your server for awhile to see if you still see
any indication of the long-term leak behavior.

            regards, tom lane

В списке pgsql-general по дате отправления:

Предыдущее
От: J Ottery
Дата:
Сообщение: Date Formatting for dd/mm/yyyy
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pg_dump - lost synchronization with server: got message type "d", length 6036499