| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: where EXEC_BACKEND is defined |
| Date: | 2020-03-25 13:39:12 |
| Message-ID: | 137138ca-68bb-0741-a47d-6e5cb45c9c40@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2020-03-20 17:36, Tom Lane wrote:
> One small point is that I believe the existing code has the effect of
> "#define EXEC_BACKEND 1" not just "#define EXEC_BACKEND". I don't
> think this matters to anyplace in the core code, but it's conceivable
> that somebody has extension code written to assume the former.
> Nonetheless, I'm +1 for re-standardizing on the latter, because it's
> a couple less keystrokes when inserting a manual definition ;-).
> Might be worth mentioning in the commit log entry though.
Ok, done that way.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2020-03-25 13:41:13 | Re: potential stuck lock in SaveSlotToPath() |
| Previous Message | Stephen Frost | 2020-03-25 13:31:06 | Re: backup manifests |