On Wed, Sep 7, 2011 at 00:34, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
