Skip site navigation (1) Skip section navigation (2)

Re: Streaming replication and non-blocking I/O

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: (view raw, whole thread or download thread mbox)
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

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.


In response to


pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2010-01-16 13:08:21
Subject: Re: Hot Standby and handling max_standby_delay
Previous:From: Robert HaasDate: 2010-01-16 12:39:50
Subject: Re: attoptions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group