Re: [HACKERS] AbortTransaction and not in in-progress state - Mailing list pgsql-hackers

From Thomas G. Lockhart
Subject Re: [HACKERS] AbortTransaction and not in in-progress state
Date
Msg-id 35FC8750.269E0C2B@alumni.caltech.edu
Whole thread Raw
In response to Re: [HACKERS] AbortTransaction and not in in-progress state  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
> Great, checked cvs tree and vacuum analyze works fine on regression
> database as well on my test database !
> BUT !!!
> I just notice, that when I start postmaster from my script i used to
> run postgres in production vacuum analyze on my test database produces
> the same error as before ! And just checked it fails and on regression
> database !
> After playing with options I found this happens with  -B 1024 !!!

It works fine on my system with "-B 1024". However, I don't usually use
the -F flag. And I don't usually compile with the Russian/Cyrillic
character set :)

> export LC_CTYPE=koi8-r
> export LC_COLLATE=koi8-r
> /usr/local/pgsql/bin/postmaster -i -B 1024 -S -D/usr/local/pgsql/data/ -o '-Fe'

From the man page:
-F     Disable automatic fsync() call after each transaction.  This
       option improves performance, but an operating system crash while
       a transaction is in progress will probably cause data loss.

I ran the regression test with the -F flag; I can see why you might be
tempted to take the risk since it speeds the regression test by 50%.
Pretty impressive.

So what we should do is at least have an fsync() happen when a
transaction completes (when an explicit END WORK statement is executed).
But that's a digression...

No problems with -B 1024 -o '-F' on my system, trying to "vacuum
analyze" the regression database. Try running your tests with the -F
flag omitted just to see what happens...

                    - Tom

pgsql-hackers by date:

Previous
From: Oleg Bartunov
Date:
Subject: Re: [HACKERS] AbortTransaction and not in in-progress state
Next
From: The Hermit Hacker
Date:
Subject: BETA1 Snapshot built...