Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)
Дата
Msg-id 008201cdcbe0$c7726c10$56574430$@kapila@huawei.com
обсуждение исходный текст
Ответ на Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Monday, November 26, 2012 7:01 PM Heikki Linnakangas wrote:
> On 26.11.2012 14:53, Amit Kapila wrote:
> > I have one usecase in feature (SQL Command to edit postgresql.conf)
> very
> > similar to OpenFile/CloseFile, but I want that when CloseFile is
> called from
> > abort, it should remove(unlink) the file as well and during open it
> has to
> > retry few times if open is not success.
> > I have following options:
> > 1. Extend OpenFile/CloseFile or PathNameOpenFile
> > 2. Write new functions similar to OpenFile/CloseFile, something like
> > OpenConfLockFile/CloseConfLockFile
> > 3. Use OpenFile/CloseFile  and handle my specific case with PG_TRY ..
> > PG_CATCH
> >
> > Any suggestions?
> 
> Hmm, if it's just for locking purposes, how about using a lwlock or a
> heavy-weight lock instead?

Its not only for lock, the main idea is that we create temp file and write
modified configuration in that temp file.
In end if it's success, then we rename temp file to .conf file but if it
error out then at abort we need to delete temp file.

So in short, main point is to close/rename the file in case of success (at
end of command) and remove in case of abort.

With Regards,
Amit Kapila.




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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Review: Patch to compute Max LSN of Data Pages
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Materialized views WIP patch