Re: Hot standby status

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Hot standby status
Date: 2009-10-15 07:56:36
Message-ID: 1255593396.30088.1143.camel@ebony
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2009-10-15 08:00:30 Re: Rejecting weak passwords
Previous Message Dave Page 2009-10-15 07:54:09 Re: Rejecting weak passwords