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

Re: Reviewing temp_tablespaces GUC patch

From: "Jaime Casanova" <systemguards(at)gmail(dot)com>
To: "Bernd Helmle" <mailings(at)oopsware(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reviewing temp_tablespaces GUC patch
Date: 2007-05-26 23:34:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 5/25/07, Bernd Helmle <mailings(at)oopsware(dot)de> wrote:
> --On Freitag, Mai 25, 2007 00:02:06 +0000 Jaime Casanova
> <systemguards(at)gmail(dot)com> wrote:
> > sounds good. can we see the new patch?
> Attached tablespace.c.diff shows my current changes to use an OID  lookup
> list.

on second thought, what happens if someone drops an empty tablespace,
that already is in the temp_tablespace GUC, and recreate it (one
scenario for this is if you want to move the tablespace to a newer
better/faster location). then will have an invalid oid until at least
you execute a new SET temp_tablespaces. And we know some "DBA's"
doesn't read the manual, so maybe this behaviour will be unexpected
for them...

> >
> > the reason for those messages is that the tablespace can get full or
> > can be dropped before use, so we throw the message for the dba to take
> > actions. if no one thinks is a good idea the message can be removed.
> >
> I could imagine that this could irritate DBA's (at least, that is what
> happened to me during testing).

Well at least with this message they will be alerted, but still seems
silly to me... (make a SET with the same list just for updating cached

Jaime Casanova

"Programming today is a race between software engineers striving to
build bigger and better idiot-proof programs and the universe trying
to produce bigger and better idiots.
So far, the universe is winning."
                                       Richard Cook

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-05-27 03:59:03
Subject: Re: Error correction for n_dead_tuples
Previous:From: Tom LaneDate: 2007-05-26 18:23:46
Subject: Re: Constraint exclusion crashes 8.3devel

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