Skip site navigation (1) Skip section navigation (2)

Re: Tablespaces

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: tswan(at)idigx(dot)com,Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>,"Alex J(dot) Avriette" <alex(at)posixnap(dot)net>,Dennis Bjorklund <db(at)zigo(dot)dhs(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tablespaces
Date: 2004-02-28 03:49:39
Message-ID: 25130.1077940179@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> writes:
> I do not intend to work on such a system for the initial introduction of
> table spaces. The problem is, of course, knowing when you're actually out
> of space in a table space in any given transaction.

It should not be that hard, at least not on local filesystems.  When PG
realizes that a new page must be added to a table, it does a write() to
append a page of zeroes to the physical table.  This happens
immediately.  It's true that actual data may not be written into that
section of the file till long after commit, but the kernel should do
space allocation checking upon the first write.

I have heard tell that this may not happen when you are dealing with NFS
(yet another reason not to run databases across NFS) but on all local
filesystems I know of, out-of-space should result in a failure before
transaction commit.

I say "should" because I suspect this isn't a very heavily tested code
path in Postgres.  But in theory it should work.  Feel free to submit
bug reports if you find it doesn't.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Greg StarkDate: 2004-02-28 04:04:06
Subject: Re: [pgsql-www] Collaboration Tool Proposal
Previous:From: Mark LubrattDate: 2004-02-28 03:32:43
Subject: Schema comparisons

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group