Re: Hot standby status - Mailing list pgsql-hackers
From | Simon Riggs |
---|---|
Subject | Re: Hot standby status |
Date | |
Msg-id | 1255593396.30088.1143.camel@ebony Whole thread Raw |
In response to | Hot standby status (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Responses |
Re: Hot standby status
|
List | pgsql-hackers |
On Thu, 2009-10-15 at 10:33 +0300, Heikki Linnakangas wrote: > There's been a lot of churn in hot standby since the beginning of the > commitfest, so I thought it would be good to summarize where we are. > > Attached is the latest and greatest patch against CVS head, taken from > the hs-riggs branch in my git repository where I've been working on this. > > Here's a list of TODOs/issues that've already been mentioned. > > - clarify default_transaction_read_only and transaction_read_only > http://archives.postgresql.org/message-id/4AB75A61.6040505@enterprisedb.com Yes, still outstanding. This is the only unfixed issue I am aware of. It's not that big a deal, hence why its bottom of the pile. Anyway, will fix. The other issues are fixed in one or other of the current dev trees. > - allow connections after a shutdown checkpoint > > - don't clear locks belonging to prepared transactions at startup > > - rename references to "loggable locks" to "AccessExclusiveLocks in > master" or similar > > - race condition in xact_redo_commit/abort > (http://archives.postgresql.org/message-id/4ABF539F.8050305@enterprisedb.com) Not sure about those ones, as yet, but I do have 9 unapplied patches to move from my tree to the shared one. > - connection goes out of sync when an idle-in-transaction transaction is > killed > (http://archives.postgresql.org/message-id/4ACF77A5.1070706@enterprisedb.com) I reported that myself in September and fixed it before your report. So I guess there is some more code to move across as well. > Before this is committed, there's some debug code that ought to be removed: > > - PostAuthDelay in startup process. Or maybe that should be left in, but > some doc changes would then be in order. I'm inclined to remove it though. Happy if you'd like to remove it. > - the CleanupWaitStats stuff. If we want something like this, I'd like > to see it integrated into existing pg_stat views. Would like to leave it in, but only for now. We can always remove it before production. So far I've never seen it block there, so I'm interested in whether its worth the effort to track it more formally through stats. I regard this as in the same area as "trace_sort", i.e. developer info. > Let me know if I'm missing something. And please feel free to help, by > testing, by reviewing and commenting on the patch, or by addressing any > of the above issues. I will continue working on this, but this is a big > patch so any help is much appreciated. Hopefully this comment isn't at me! I've been down for a few days with laptop problems, slowly re-installing everything (for those laughing, yes, I had a backup). -- Simon Riggs www.2ndQuadrant.com
pgsql-hackers by date: