Re: [PATCH] Log crashed backend's query (activity string)

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: [PATCH] Log crashed backend's query (activity string)
Дата
Msg-id CABRT9RDkvJgU-_cykw3W=mNZLbSoEC82vAgjLVX9P=bmhp+Zbg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Log crashed backend's query (activity string)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Sep 7, 2011 at 00:34, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> No, I don't think your attempts to validate the data are
> adequate, nor do I believe they can be made adequate.

Can you think of any concrete situations that would fail the current validation?

As far as I can tell, the only pointer I'm following from the shm
region is vbeentry->st_activity, which is being validated that it
still points to the BackendActivityBuffer.

The rest -- BackendStatusArray, BackendActivityBuffer, MaxBackends and
pgstat_track_activity_query_size -- are process-local variables and
initialized at startup time. Given that other backends cannot change
these variables, nor deallocate postmaster's shm regions, we can take
for granted that they still point to the shm region.

Whether the data contained in shm is corrupt or not, we really don't
care. If we don't find the matching PID, we just return a placeholder
string. In the worst case, the activity buffer is corrupt and the user
gets a kilobyte of garbage in their log file.

Ok, well there's a worse case -- if a backend keeps incrementing
vbeentry->st_changecount at a faster rate. However, this seems pretty
unlikely if the backend has already terminated. We could terminate
other backends *first* before logging the query to make sure they
can't touch it.

Regards,
Marti


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [PATCH] Log crashed backend's query (activity string)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Log crashed backend's query (activity string)