Re: two questions related to tablespace in PG8.0.1

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: two questions related to tablespace in PG8.0.1
Date: 2005-03-09 06:49:23
Message-ID: d0m6i5$28im$1@news.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)postgresql(dot)org
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-03-09 06:58:13 Current CVS parallel test lock
Previous Message Vikram Kalsi 2005-03-09 06:24:41 Re: postgreSQL-8.0.1 configure --enable-thread-safety with icc-8.1 on RHEL-AS3 Itanium-2 gives error