Re: Plugging fd leaks (was Re: Switching timeline over streaming replication) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)
Date
Msg-id 008201cdcbe0$c7726c10$56574430$@kapila@huawei.com
Whole thread Raw
In response to Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Review: Patch to compute Max LSN of Data Pages
Next
From: Peter Eisentraut
Date:
Subject: Re: Materialized views WIP patch