Re: Sync Rep for 2011CF1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Aidan Van Dyk <aidan(at)highrise(dot)ca>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Sync Rep for 2011CF1
Date: 2011-01-21 18:03:22
Message-ID: 14761.1295633002@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jan 21, 2011 at 12:23 PM, Aidan Van Dyk <aidan(at)highrise(dot)ca> wrote:
>> When no sync slave is connected, yes, I want to stop things hard.

> What you're proposing is to fail things earlier than absolutely
> necessary (when they try to XLOG, rather than at commit) but still
> later than what I think Simon is proposing (not even letting them log
> in).

I can't see a reason to disallow login, because read-only transactions
can still run in such a situation --- and, indeed, might be fairly
essential if you need to inspect the database state on the way to fixing
the replication problem. (Of course, we've already had the discussion
about it being a terrible idea to configure replication from inside the
database, but that doesn't mean there might not be views or status you
would wish to look at.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aidan Van Dyk 2011-01-21 18:09:45 Re: Sync Rep for 2011CF1
Previous Message Robert Haas 2011-01-21 17:54:53 Re: [HACKERS] Large object corruption during 'piped' pg_restore