BTW, just for the archives' sake: it took a good long time to develop a
reproducible test case for this. It seems that 99% of the WAL replay
code does *not* depend on the missing state. I was eventually able to
reproduce the case originally reported, namely a crash during
btree_xlog_cleanup; but
On Mon, 2010-04-19 at 14:34 -0400, Tom Lane wrote:
> Anyone see any obvious holes in the idea?
Nothing springs to mind, so worth a try.
--
Simon Riggs www.2ndQuadrant.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
I wrote:
> The point is that a standalone backend will fail to execute recovery
> correctly:
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01297.php
After digging around a bit, it seems like the cleanest solution would be
to move the responsibility for calling StartupXLOG in a standalo
Simon Riggs writes:
> On Mon, 2010-04-19 at 11:19 -0400, Tom Lane wrote:
>> If you think we're at the point where this item is the main thing
>> standing between us and beta, I'll go do something about it. I've
>> been waiting for the HS code to settle before trying to design a
>> solution...
>
On Mon, Apr 19, 2010 at 11:19 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Mar 22, 2010 at 9:32 PM, Bruce Momjian wrote:
>>> OK, I re-read it and still don't understand, but I don't have to.
>
>> I re-read it too and I don't understand either.
>
> The point is that a standalone backend
On Mon, 2010-04-19 at 11:19 -0400, Tom Lane wrote:
> If you think we're at the point where this item is the main thing
> standing between us and beta, I'll go do something about it. I've
> been waiting for the HS code to settle before trying to design a
> solution...
I'm not hugely interested in
Robert Haas writes:
> On Mon, Mar 22, 2010 at 9:32 PM, Bruce Momjian wrote:
>> OK, I re-read it and still don't understand, but I don't have to.
> I re-read it too and I don't understand either.
The point is that a standalone backend will fail to execute recovery
correctly:
http://archives.pos
On Mon, Mar 22, 2010 at 9:32 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> >> [This is an open item for 9.0, hence the response to an apparently old
>> >> hackers thread]
>>
>> > Thanks for the reply; 9.0 open item removed.
>>
>> I think you misread his reply. Please pu
Tom Lane wrote:
> Bruce Momjian writes:
> >> [This is an open item for 9.0, hence the response to an apparently old
> >> hackers thread]
>
> > Thanks for the reply; 9.0 open item removed.
>
> I think you misread his reply. Please put that back.
OK, I re-read it and still don't understand, bu
Bruce Momjian writes:
>> [This is an open item for 9.0, hence the response to an apparently old
>> hackers thread]
> Thanks for the reply; 9.0 open item removed.
I think you misread his reply. Please put that back.
regards, tom lane
--
Sent via pgsql-hackers mailing
Simon Riggs wrote:
> On Sat, 2009-09-19 at 13:21 -0400, Tom Lane wrote:
> > I realized the truth of $SUBJECT while reading this report:
> > http://archives.postgresql.org/pgsql-general/2009-09/msg00712.php
>
> ...
>
> > Also, does this have any impact on the Hot Standby stuff?
>
> It could poten
On Sat, 2009-09-19 at 13:21 -0400, Tom Lane wrote:
> I realized the truth of $SUBJECT while reading this report:
> http://archives.postgresql.org/pgsql-general/2009-09/msg00712.php
...
> Also, does this have any impact on the Hot Standby stuff?
It could potentially, but there is not much HS-rela
On Monday 21 September 2009 14:24:07 Tom Lane wrote:
> Alvaro Herrera writes:
> > So if you need to enter standalone mode, you'll have to start
> > postmaster, wait for replay to finish, stop it and restart standalone.
>
> Yeah, that's the case at the moment.
>
> > Would this be a problem when you
Alvaro Herrera writes:
> So if you need to enter standalone mode, you'll have to start
> postmaster, wait for replay to finish, stop it and restart standalone.
Yeah, that's the case at the moment.
> Would this be a problem when you need standalone mode in an emergency,
> for example when the dat
Tom Lane wrote:
> Fixing this will require rearranging things around InitPostgres
> (in particular, I think InitBufferPoolBackend will have to be
> called directly from postgres.c). Since that code got rearranged
> quite a bit last month, I'd be hesitant to try to back-patch whatever
> fix we com
I realized the truth of $SUBJECT while reading this report:
http://archives.postgresql.org/pgsql-general/2009-09/msg00712.php
In a standalone backend, postgres.c tries to run StartupXLOG after
having done only BaseInit(), which means that we don't have a PGPROC
(hence can't take LWLocks much less
16 matches
Mail list logo
