Re: Summary and Plan for Hot Standby
От | Tatsuo Ishii |
---|---|
Тема | Re: Summary and Plan for Hot Standby |
Дата | |
Msg-id | 20091116.132321.21931036.t-ishii@sraoss.co.jp обсуждение исходный текст |
Ответ на | Summary and Plan for Hot Standby (Simon Riggs <simon@2ndQuadrant.com>) |
Ответы |
Re: Summary and Plan for Hot Standby
Re: Summary and Plan for Hot Standby |
Список | pgsql-hackers |
Just a question: - Does Hot Standby allow to use prepared query (not prepared transaction) in standby? I mean: Parse message from frontendcan be accepted by standby? - Can we create tempory tables in standby? -- Tatsuo Ishii SRA OSS, Inc. Japan > After some time thinking about the best way forward for Hot Standby, I > have some observations and proposals. > > First, the project is very large. We have agreed ways to trim the patch, > yet it remains large. Trying to do everything in one lump is almost > always a bad plan, so we need to phase things. > > Second, everybody is keen that HS hits the tree, so we can have alpha > code etc.. There are a few remaining issues that should *not* be rushed. > The only way to remove this dependency is to decouple parts of the > project. > > Third, testing the patch is difficult and continuous change makes it > harder to guarantee everything is working. > > There are two remaining areas of significant thought/effort: > > * Issues relating to handling of prepared transactions > * How fast Hot Standby mode is enabled in the standby > > I propose that we stabilise and eventually commit a version of HS that > circumvents/defers those issues and then address the issues with > separate patches afterwards. This approach will allow us to isolate the > areas of further change so we can have a test blitz to remove silly > mistakes, then follow it with a commit to CVS, and then release as Alpha > to allow further testing. > > Let's look at the two areas of difficulty in more detail > > * 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. > > * 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.) > > Phasing the commit seems like the only way. > > Please can we agree a way forwards? > > -- > Simon Riggs www.2ndQuadrant.com > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
В списке pgsql-hackers по дате отправления: