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:

Previous
From: Dave Page
Date:
Subject: Re: Rejecting weak passwords
Next
From: Dave Page
Date:
Subject: Re: Rejecting weak passwords