Re: Summary and Plan for Hot Standby

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Summary and Plan for Hot Standby
Дата
Msg-id 9837222c0911150100n1881459fq60acd088ad31a0a@mail.gmail.com
обсуждение исходный текст
Ответ на Summary and Plan for Hot Standby  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Summary and Plan for Hot Standby
Список pgsql-hackers
On Sun, Nov 15, 2009 at 09:06, Simon Riggs <simon@2ndquadrant.com> wrote:
> * Issues relating to handling of prepared transactions
> There are some delicate issues surrounding what happens at the end of
> recovery if there is a prepared transaction still holding an access
> exclusive lock. It is straightforward to say, as an interim measure,
> "Hot Standby will not work with max_prepared_transactions > 0". I see
> that this has a fiddly, yet fairly clear solution.

If that restriction will solve issues we have now, I find that a
perfectly reasonable restriction. Even if it were to still be there
past release, and only get fixed in a future release. The vast
majority of our users don't use 2PC at all. Most cases where people
had it enalbed used to be because it was enabled by default, and the
large majority of cases where I've seen people increase it has
actually been because they thought it meant prepared statements, not
prepared transactions.

So definitely +1.


> * How fast Hot Standby mode is enabled in the standby
> We need to have full snapshot information on the standby before we can
> allow connections and queries. There are two basic approaches: i) we
> wait until we *know* we have full info or ii) we try to collect data and
> inject a correct starting condition. Waiting (i) may take a while, but
> is clean and requires only a few lines of code. Injecting the starting
> condition (ii) requires boatloads of hectic code and we have been unable
> to agree a way forwards. If we did have that code, all it would give us
> is a faster/more reliable starting point for connections on the standby.
> Until we can make approach (ii) work, we should just rely on the easy
> approach (i). In many cases, the starting point is very similar. (In
> some cases we can actually make (i) faster because the overhead of data
> collection forces us to derive the starting conditions minutes apart.)

That also seems perfectly reasonable, depending on how long the
waiting on (i) will be :-) What does the time depend on?


> Phasing the commit seems like the only way.

Yeah, we usually recommend that in other cases, so I don't see why it
shouldn't apply to HS. Seems like a good way forward.

-- Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Simon Riggs
Дата:
Сообщение: Summary and Plan for Hot Standby
Следующее
От: George Gensure
Дата:
Сообщение: commitfest patch move unavailable