Re: Streaming replication and non-blocking I/O - Mailing list pgsql-hackers

From Dimitri Fontaine
Subject Re: Streaming replication and non-blocking I/O
Date
Msg-id m2eilqp5u7.fsf@hi-media.com
Whole thread Raw
In response to Re: Streaming replication and non-blocking I/O  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Streaming replication and non-blocking I/O  (Euler Taveira de Oliveira <euler@timbira.com>)
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: attoptions
Next
From: Dimitri Fontaine
Date:
Subject: Re: Hot Standby and handling max_standby_delay