| From: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Streaming replication and non-blocking I/O |
| Date: | 2010-01-16 12:55:12 |
| Message-ID: | m2eilqp5u7.fsf@hi-media.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> The module doesn't need to touch backend internals much at all, no
> tinkering with shared memory for example, so I would feel much better
> about moving that out of src/backend. Not sure where, though; it's not
> an executable, so src/bin is hardly the right place, but I wouldn't want
> to put it in contrib either, because it should still be built and
> installed by default. So I'm inclined to still leave it in
> src/backend/replication/
It should be possible to be in contrib and installed by default, even
with the current tool set, by tweaking initdb to install the contrib
into template1. But that would be a packaging / dependency issue I guess
then.
Of course the extension system would ideally "create extension foo;" for
all foo in contrib at initdb time, then a user would have to "install
extension foo;" and be done with it.
Regards,
--
dim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2010-01-16 13:08:21 | Re: Hot Standby and handling max_standby_delay |
| Previous Message | Robert Haas | 2010-01-16 12:39:50 | Re: attoptions |