On Wed, Oct 31, 2012 at 03:24:10PM +0100, Stefan Fuhrmann wrote:
> On Wed, Oct 31, 2012 at 2:54 PM, Philip Martin
> <philip.martin_at_wandisco.com>wrote:
>
> > Philip Martin <philip.martin_at_wandisco.com> writes:
> >
> > > Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> writes:
> > >
> > >> Excellent analysis, Philip! With r1404112, we use "plain"
> > >> APR mmap code with almost no coding overhead.
> > >> The only downside is that we now have a temporary
> > >> file sitting in the db folder.
> > >
> > > Error handling needs attention:
> > >
> > > $ svnadmin create repo
> > > $ svnadmin dump repo > /dev/null
> > > $ chmod -rw repo/db/rev-prop-atomicsShm
> > > $ svnadmin dump repo > /dev/null
> > > Segmentation fault
> >
> > We are mmaping a 64k file, that's bigger than a disk block on lots of
> > filesystems so updates are not atomic. Do we have to consider
> > corruption:
> >
> > $ svnadmin create repo
> > $ dd if=/dev/urandom of=repo/db/rev-prop-atomicsShm bs=64k count=1
> > $ svnadmin verify repo
> > Segmentation fault
> > $ svnadmin recover repo
> > Repository lock acquired.
> > Please wait; recovering the repository may take some time...
> >
> > Recovery completed.
> > The latest repos revision is 0.
> > $ svnadmin verify repo
> > Segmentation fault
> >
> > Perhaps recover should delete the file?
> >
>
> Done. Also, random data should no longer result in segfaults.
I just came across something that reminded me of this thread.
It seems PostgreSQL is doing something quite similar to what we
want to do here:
When the first PostgreSQL process attaches to the shared memory segment, it
checks how many processes are attached. If the result is anything other than
"one", it knows that there's another copy of PostgreSQL running which is
pointed at the same data directory, and it bails out.
http://rhaas.blogspot.nl/2012/06/absurd-shared-memory-limits.html
If this works for postgres I wonder why it wouldn't work for us.
Is this something we cannot do because APR doesn't provide the
necessary abstractions?
Received on 2012-11-04 10:41:05 CET