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

From: Amit Kapila <amit(dot)kapila(at)huawei(dot)com>
To: "'Heikki Linnakangas'" <hlinnakangas(at)vmware(dot)com>
Cc: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "'PostgreSQL-development'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Plugging fd leaks (was Re: Switching timeline over streaming replication)
Date: 2012-11-26 14:17:33
Message-ID: 008201cdcbe0$c7726c10$56574430$@kapila@huawei.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-11-26 14:46:33 Re: Materialized views WIP patch
Previous Message Amit Kapila 2012-11-26 13:42:21 Re: Review: Patch to compute Max LSN of Data Pages