Re: two questions related to tablespace in PG8.0.1 - Mailing list pgsql-hackers

From Qingqing Zhou
Subject Re: two questions related to tablespace in PG8.0.1
Date
Msg-id d0m6i5$28im$1@news.hub.org
Whole thread Raw
In response to two questions related to tablespace in PG8.0.1  ("Qingqing Zhou" <zhouqq@cs.toronto.edu>)
List pgsql-hackers
> There is no such thing as crash without redo: that is what WAL is all
> about.  The creation of the tablespace will be correctly replayed from
> WAL.  (Of course, this claim depends on various assumptions about
> whether fsync behaves per spec ... but if it does not, tablespace
> creation is hardly the only thing that will fail.)

Yes, if replayed, the creation will be ok. But the case I mentioned will not
replay the WAL. The point is that current mdsync() implementation does not
take care of streams, so the files opened by AllocateFile() will not get
flushed. Most files like "pg_fsm.cache" are ok, since we don't expect them
to survive after crash. But is PG_VERSION in creation of tablespace ok?

> > 2. possible race on "set_short_version(location)" while creating
> > tablespace - what if two processes reach this point at the same time?
>
> There is no "race" --- the point of that code is to ensure that if
> two users concurrently try to create two tablespaces pointing at the
> same directory, only one will succeed.  In any case, since tablespace
> creation requires superuser permissions, there is no issue about
> whether the user might be malicious ... an attacker who has gained
> database superuser can already break things in arbitrary ways.
>

understood.

> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
>




pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Current CVS parallel test lock
Next
From: Tom Lane
Date:
Subject: Re: Current CVS parallel test lock