Hello.
Is it possible that the pg_stat_tmp directory has been made non-writable? hard to tell if it was made non-writable during the outage. but now it is writable.
Thanks
On Tue, Aug 2, 2022 at 1:25 PM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
bruno da silva <brunogiovs@xxxxxxxxx> writes:
> Do you have a lot of especially long statements being tracked
> in the pg_stat_statements view?* well, the view was showing the query
> column null.*
> * but looking on pgss_query_texts.stat there are very large sql
> statements, of around ~ 400kb, multiple thousands. *
Hm. We try to recover from such failures by (a) resetting all the view's
query text fields to null and (b) truncating the file --- well, unlinking
it and creating it as empty. It seems like (a) happened and (b) didn't.
It's pretty hard to explain that from the code though. Are you quite
sure this is a 9.5.21 version of the pg_stat_statements extension?
Is it possible that the pg_stat_tmp directory has been made non-writable?
regards, tom lane
> Are there any other signs of distress
> in the postmaster log, like complaints about being unable to write
> pgss_query_texts.stat? *no, just complaints for reading it. *
> Thanks
> On Tue, Aug 2, 2022 at 11:59 AM Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
>> bruno da silva <brunogiovs@xxxxxxxxx> writes:
> After more investigation, we found that pgss_query_texts.stat of a size
>> of
> 2.2GB. and this deployment has a 32bit pg.
>>
>> Hm ... we've heard one previous report of pg_stat_statements' query text
>> file getting unreasonably large, but it's not clear how that can come
>> to be. Do you have a lot of especially long statements being tracked
>> in the pg_stat_statements view? Are there any other signs of distress
>> in the postmaster log, like complaints about being unable to write
>> pgss_query_texts.stat?
>>
>> regards, tom lane
>>
> --
> Bruno da Silva
Bruno da Silva
