Re: [PATCH] Log crashed backend's query (activity string) - Mailing list pgsql-hackers

From Marti Raudsepp
Subject Re: [PATCH] Log crashed backend's query (activity string)
Date
Msg-id CABRT9RDkvJgU-_cykw3W=mNZLbSoEC82vAgjLVX9P=bmhp+Zbg@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Log crashed backend's query (activity string)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Log crashed backend's query (activity string)
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Log crashed backend's query (activity string)