Re: TRUNCATE - timing of the return of disk space - caused by long-lived client?

Поиск
Список
Период
Сортировка
От Vince Negri
Тема Re: TRUNCATE - timing of the return of disk space - caused by long-lived client?
Дата
Msg-id FE71087DFC14A74C9C79C14DCA5860E74A4948@aslman2.asl.lan
обсуждение исходный текст
Ответ на Re: TRUNCATE - timing of the return of disk space - caused by long-lived client?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
Hi Tom (and all)

Yes, in the meantime I realised that the other relevant clients (the ones that
seemed to be holding the file handle) were ones that sat idle most of the time
and rarely executed any query. You are right, as each of these executed a query
(thus processing sinval) they released the filehandle.

Thanks for the pointers.


Vince

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: 26 October 2007 13:22
To: Vince Negri
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] TRUNCATE - timing of the return of disk space -
caused by long-lived client?


"Vince Negri" <vnegri@asl-electronics.co.uk> writes:
> What causes the file handles of the truncated table to be released by all postmaster processes?

It should happen when the other backends process the sinval message
about the TRUNCATE, which at the latest should be the next time they
begin command execution.  What were the other clients doing, just
sitting idle?

            regards, tom lane


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

Предыдущее
От: Gregory Stark
Дата:
Сообщение: Re: select count() out of memory
Следующее
От: Sam Mason
Дата:
Сообщение: Re: select count() out of memory