On Tue, Sep 18, 2012 at 09:09:13PM +0900, Fujii Masao wrote:
> On Tue, Sep 18, 2012 at 3:48 PM, Heikki Linnakangas
> wrote:
> > On 18.09.2012 09:46, Craig Ringer wrote:
> >>
> >> On 09/18/2012 07:57 AM, Fujii Masao wrote:
> >>>
> >>> If you change the max_connections on the master, you need to tak
On Tue, Sep 18, 2012 at 3:48 PM, Heikki Linnakangas
wrote:
> On 18.09.2012 09:46, Craig Ringer wrote:
>>
>> On 09/18/2012 07:57 AM, Fujii Masao wrote:
>>>
>>> If you change the max_connections on the master, you need to take a
>>> fresh backup from the master and start the standby from it.
>>
>>
>
On 18.09.2012 09:46, Craig Ringer wrote:
On 09/18/2012 07:57 AM, Fujii Masao wrote:
If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.
WTF, really?
No. It's enough to bump up max_connections on the standby, and rest
On 09/18/2012 07:57 AM, Fujii Masao wrote:
If you change the max_connections on the master, you need to take a
fresh backup from the master and start the standby from it.
WTF, really?
What else breaks the replication and forces a re-clone?
--
Craig Ringer
--
Sent via pgsql-bugs mailing list
On 17.9.2012 16.57, Fujii Masao wrote:
> On Tue, Sep 18, 2012 at 3:51 AM, wrote:
>> The following bug has been logged on the website:
>>
>> Bug reference: 7549
>> Logged by: Petteri Räty
>> Email address: pet...@petteriraty.eu
>> PostgreSQL version: 9.2.0
>> Operating system:
On Tue, Sep 18, 2012 at 3:51 AM, wrote:
> The following bug has been logged on the website:
>
> Bug reference: 7549
> Logged by: Petteri Räty
> Email address: pet...@petteriraty.eu
> PostgreSQL version: 9.2.0
> Operating system: Linux or OS X
> Description:
>
> On a streaming
