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 по дате отправления: