as the subject says - the upgrade.bat in the b2
release thats currently being mirrored points to the installation files
of 8.1 instead of the 8.2 ones.
best regards,
thomas
Thanks, fixed in CVS.
Regards, Dave.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Thomas
H.Sent: 25 October 2006 12:16To:
pgsql-bugs@postgresql.orgSubject: [BUGS] 8.2b2: update.bad in
windows release points to wrong .msi
as the subject says - the upg
> > The same problem exists in 8.1 too. See this thread
> > http://archives.postgresql.org/pgsql-bugs/2006-04/msg00177.php
> > Tom and Magnus tracked down a cause, but I don't think a
> fix was ever
> > implemented.
>
> Thomas seems to have two different issues there: the "could
> not rename
I'm not in a position to test this though. Magnus or Bruce?
I haven't reproduced this on my box. But if you can give me a patch to
try I can build binaries for Thomas to test, if he can do testing but
not building.
a binary would be marvelous. if too much hasle, i can setup a msvc++ 2005
h
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> I haven't reproduced this on my box. But if you can give me a patch to
> try I can build binaries for Thomas to test, if he can do testing but
> not building.
Utterly untested ... BTW, why does pgrename have an #if to check
either GetLastError() or e
Tom Lane wrote:
> "Magnus Hagander" <[EMAIL PROTECTED]> writes:
> > I haven't reproduced this on my box. But if you can give me a patch to
> > try I can build binaries for Thomas to test, if he can do testing but
> > not building.
>
> Utterly untested ... BTW, why does pgrename have an #if to chec
just a small update: this problem is also present in beta 2.
not a big problem for the moment, as we currently have disabled fulltext
search capabilities on the website.
regards,
thomas
- Original Message -
From: <[EMAIL PROTECTED]>
To: "Tom Lane" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesd
I found the root cause of the bug I reported at:
http://archives.postgresql.org/pgsql-bugs/2006-10/msg00211.php
What happens is this:
* Out of memory condition causes an ERROR
* ERROR triggers an AbortTransaction()
* AbortTransaction() calls RecordTransactionAbort()
* RecordTransactionAbort calls
Jeff Davis wrote:
> I found the root cause of the bug I reported at:
>
> http://archives.postgresql.org/pgsql-bugs/2006-10/msg00211.php
>
> What happens is this:
> * Out of memory condition causes an ERROR
> * ERROR triggers an AbortTransaction()
> * AbortTransaction() calls RecordTransactionAbor
On Wed, 2006-10-25 at 16:20 -0300, Alvaro Herrera wrote:
> Jeff Davis wrote:
> > I found the root cause of the bug I reported at:
> >
> > http://archives.postgresql.org/pgsql-bugs/2006-10/msg00211.php
> >
> > What happens is this:
> > * Out of memory condition causes an ERROR
> > * ERROR triggers
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Jeff Davis wrote:
>> * smgrGetPendingDeletes() calls palloc()
>> * palloc() fails, resulting in ERROR, causing infinite recursion
> Hmm, maybe we could have AbortTransaction switch to ErrorContext, which
> has some preallocated space, before calling Rec
As for fixing the problem we do understand: ISTM it's just an
awful idea for pgrename and pgunlink to be willing to loop
forever. I think they should time out and report the failure
after some reasonable period (say between 10 sec and a minute).
is the main problem realy in the rename/delete fu
"Thomas H." <[EMAIL PROTECTED]> writes:
> it is defenitely the writer process that blocks the db. but in every case
> the writer process seems to fail to rename the file due to another
> postgresql still holding a filehandle to the very xlog file that should be
> renamed.
Right, all you need is
13 matches
Mail list logo
