| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Greg Stark <stark(at)mit(dot)edu>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reopen logfile on SIGHUP |
| Date: | 2018-04-10 19:40:11 |
| Message-ID: | CA+TgmobqVugbJFoeP=ZiBQ_pA7-710fsuYNtvDv48uzBgRvtQA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 10, 2018 at 3:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> We, as in the core project, are not shipping it.
+1 for what JD said on that subject.
> I'm also unclear
> on why you want to exclude "fix the RPM packaging" as a reasonable
> solution.
Mostly because the complaint was about the *Debian* packaging. Other
than that, it's possible that that's the way forward.
> It seems likely that some change in that packaging would
> be necessary anyway, as it wouldn't know today about any signaling
> method we might choose to adopt.
>
> Having said that, I'm not averse to providing a solution if it's robust,
> not too invasive and doesn't break other use-cases. So far we've not
> seen a patch that meets those conditions.
Fair enough.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua D. Drake | 2018-04-10 19:51:01 | Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS |
| Previous Message | Joshua D. Drake | 2018-04-10 19:23:14 | Re: Reopen logfile on SIGHUP |