Alvaro Herrera writes:
> Excerpts from Tom Lane's message of lun nov 08 22:29:28 -0300 2010:
>> I think we need to re-order the operations there to ensure that the
>> unlink will still happen if the ereport gets interrupted.
> Would it work to put the removal inside a PG_CATCH block?
Well, that
Excerpts from Tom Lane's message of lun nov 08 22:29:28 -0300 2010:
> Hmm. If you look at FileClose() in fd.c, you'll discover that that
> "temporary file" log message is emitted immediately before unlink'ing
> the file. It looks pretty safe ... but, scratching around, I notice
> that there's a
Michael Glaesemann writes:
> On Nov 8, 2010, at 16:03 , Tom Lane wrote:
>> That's very peculiar. Do you keep query logs? It would be useful to
>> try to correlate the temp files' PIDs and timestamps with the specific
>> queries that must have created them.
> We don't log all of them, but I chec
On Nov 8, 2010, at 16:03 , Tom Lane wrote:
> Michael Glaesemann writes:
>> We've got over 250GB of files in a pgsql_tmp directory, some with
>> modification timestamps going back to August 2010 when the server was last
>> restarted.
>
> That's very peculiar. Do you keep query logs? It would
Michael Glaesemann writes:
> We've got over 250GB of files in a pgsql_tmp directory, some with
> modification timestamps going back to August 2010 when the server was last
> restarted.
That's very peculiar. Do you keep query logs? It would be useful to
try to correlate the temp files' PIDs an
We've got over 250GB of files in a pgsql_tmp directory, some with modification
timestamps going back to August 2010 when the server was last restarted.
select pg_postmaster_start_time();
pg_postmaster_start_time
---
2010-08-08 22:53:31.999804-04
(1 row)
I'm not s
