Re: [HACKERS] "recovering prepared transaction" after serverrestart

From: Richard Troy <rtroy(at)ScienceTools(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>, <pgsql-docs(at)postgresql(dot)org>
Subject: Re: [HACKERS] "recovering prepared transaction" after serverrestart
Date: 2006-11-03 15:13:26
Message-ID: Pine.LNX.4.33.0611030653520.1126-100000@denzel.in
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers


On Fri, 3 Nov 2006, Tom Lane wrote:
>
> > Is there a way to see prepared transactions where the original session
> > that prepared then has died? Perhaps the message at startup should be
> > "you have at least one prepared transaction that needs resolution".
>
> I am completely baffled by this focus on database startup time. That's
> not where the problem is.
>
> regards, tom lane
>

I'm not alluding to anyone in particular, just responding to the focus on
startup time; When I joined Ingres as a Consultant (back when that was a
revered job), we saw this a lot, too, bubbling through the ranks from
technical support. Engineering was having a cow over it. We Consultants
were expected to backline such problems and be the interface between
engineering and the rest of the world. What we found was that in what we'd
call the ligitimate cases, the cause for concern over startup time had to
do with bugs that forced, one way or another, a server restart.

Illigitimate cases - the VAST majority - were the result of, well, let's
call them less-than-successful DBAs, thrashing their installations with
their management breathing down their necks, often with flailing arms and
fire coming out of their mouths saying things like, "I bet my business on
this!"... The usual causes there were inappropriate configurations, and a
critical cause of _that_ was an instalation toolset that didn't help
people size/position things properly. Often a sales guy or trainee would
configure a test system and then the customer would put that into
production without ever reexamining the settings.

I realized there was an opportunity here; I put together a training
program and we sold it as a service along with installation to new
customers to help them get off on the right foot. Once we did that, new
customers were essentially put on notice that they could either pay us to
help set them up, or they could do it, but that continuing along with what
the salesman or junior techie had done wasn't sufficient for a production
environment that you could bet your business on. ...The complaint and
concern about startup time dropped out of sight nearly immediately...

Opportunity here, for PostgreSql: A Technical Document of some kind
entitled something like: "How to move your testing environment into
production."

No, unfortunately, I can't volunteer to be the point person on this one.
And to the underlying question: is this the case with PostgreSql? I can't
say...

Regards,
Richard

--
Richard Troy, Chief Scientist
Science Tools Corporation
510-924-1363 or 202-747-1263
rtroy(at)ScienceTools(dot)com, http://ScienceTools.com/

In response to

Browse pgsql-docs by date

  From Date Subject
Next Message Theo Kramer 2006-11-08 18:07:19 Documentation update for PQexecParams
Previous Message Heikki Linnakangas 2006-11-03 15:06:50 Re: "recovering prepared transaction" after serverrestart message

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-11-03 16:25:09 Re: Bug in WAL backup documentation
Previous Message Heikki Linnakangas 2006-11-03 15:06:50 Re: "recovering prepared transaction" after serverrestart message