Open Items
I have annotated the open items:
---------------------------------------------------------------------------
PostgreSQL 8.0 Open Items
=========================
Current version at http://candle.pha.pa.us/cgi-bin/pgopenitems.
Changes
-------
* Win32
o fix query cancel in psql
This requires a new thread to handle the control-C signal
o fix shared memory on Win2k terminal server
We might be able to just mark this as not supported.
o Handle "lost signals" on backend startup (eg. shutdown,
config file changes, etc); signals are SIG_DFL on startup
The problem here is that the postmaster might send signals to a
child before the signal handlers are installed. We don't have
this problem on unix because we fork and inherit the signal
handlers.
* Tablespace
o fix ambiguity for objects using default tablespaces
CREATE TABLE test(a int4) tablespace loc;
CREATE UNIQUE INDEX test_a_idx3 ON test(a) tablespace pg_default;
Index test_a_idx3 has a tablespace value of zero. pg_get_indexdef()
thinks the index is in loc even though it is in pg_default. And
if you move test the index is thought to move too. The confusion
is that there are not separate defaults for database/schema/table.
o fix case where template db already uses target tablespace
-- from database test
CREATE tablespace blah location '/bjm/tmp';
CREATE TABLE foo (i int) tablespace blah;
CREATE DATABASE foo tablespace blah template test;
ERROR: could not initialize database directory
DETAIL: Directory "/u/pgsql/data/pg_tblspc/17232/17235" already exists.
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variable
This same method is used for WITH/WITHOUT OIDS.
* allow libpq to check parameterized data types
* adjust bgwriter defaults, allow disabling
* synchonize supported encodings and docs
Completed Since Previoius Beta
------------------------------
* cleanup FRONTEND use in /port, malloc, elog
* update encoding list to include win1250
* make pgxs install by default
* Tablespace
o fix error message when creating objects in schema that has a
dropped tablespace as its default
* Win32
o disable readline-required psql options
o fix SSL compiles
o add binary version stamps
o fix signal-safe socket handler for SSL
o start pg_autovacuum easily
o remove log timezone string from log_line_prefix '%t'
o fix MinGW libpq to export only required symbols
o fix MSVC build to export SSL symbols
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Bruce Momjian <pgman@candle.pha.pa.us> writes:
o fix ambiguity for objects using default tablespaces
CREATE TABLE test(a int4) tablespace loc;
CREATE UNIQUE INDEX test_a_idx3 ON test(a) tablespace pg_default;
Index test_a_idx3 has a tablespace value of zero. pg_get_indexdef()
thinks the index is in loc even though it is in pg_default. And
if you move test the index is thought to move too. The confusion
is that there are not separate defaults for database/schema/table.
I don't think it's nearly as complicated as all that; it's just a thinko
in pg_get_indexdef.
regards, tom lane
Bruce Momjian <pgman@candle.pha.pa.us> writes:
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variable
I'm coming around to the conclusion that this is simply a bad idea.
The problem with having such a SET variable is that it plays hob with
the existing definition about where schemas and tables get a default
tablespace from. Which source wins (the database or schema default
tablespace, or the SET variable)? And why? The only really clean way
to have a SET variable for this is to forget about schema- or
table-based defaults. Do we want to do that? (Hey, it'd solve the
problem with schema tablespaces being droppable, because there wouldn't
*be* any such thing as a schema's tablespace anymore. But on the whole
this seems like a step backward in usability.)
What we might want to do is invent a --notablespace option for pg_dump,
comparable to --noowner, to let someone make a dump that contains no
TABLESPACE clauses.
regards, tom lane
On Sun, 17 Oct 2004, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variableI'm coming around to the conclusion that this is simply a bad idea.
I feel the same way for more or less the reasons you outline.
What we might want to do is invent a --notablespace option for pg_dump,
comparable to --noowner, to let someone make a dump that contains no
TABLESPACE clauses.
That's a useful feature but I'm not sure it solves the problem people
originally put (to me at least). User has data in a tablespace on a
seperate device. The device crashes fatally and the user needs to restore
the database. All the user's dumps contain tablespace clauses because the
user did not anticipate the device dying. This, I think, is why people
wanted to either ignore tablespace clauses, have an override or something
else.
I still think, however, that a workable solution is to bring up a new
system, create the tablespaces on some online partition, and pg_restore
the dump. pg_dump does not dump CREATE TABLESPACE so we wont encounter
problems there.
Have I missed something there? (Highly likely as I am still pre-coffee).
Gavin
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
o fix ambiguity for objects using default tablespaces
CREATE TABLE test(a int4) tablespace loc;
CREATE UNIQUE INDEX test_a_idx3 ON test(a) tablespace pg_default;Index test_a_idx3 has a tablespace value of zero. pg_get_indexdef()
thinks the index is in loc even though it is in pg_default. And
if you move test the index is thought to move too. The confusion
is that there are not separate defaults for database/schema/table.I don't think it's nearly as complicated as all that; it's just a thinko
in pg_get_indexdef.
OK, I see that now. Item marked as done.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variableI'm coming around to the conclusion that this is simply a bad idea.
The problem with having such a SET variable is that it plays hob with
the existing definition about where schemas and tables get a default
tablespace from. Which source wins (the database or schema default
tablespace, or the SET variable)? And why? The only really clean way
to have a SET variable for this is to forget about schema- or
table-based defaults. Do we want to do that? (Hey, it'd solve the
problem with schema tablespaces being droppable, because there wouldn't
*be* any such thing as a schema's tablespace anymore. But on the whole
this seems like a step backward in usability.)
Agreed, a step backwards, but see below.
What we might want to do is invent a --notablespace option for pg_dump,
comparable to --noowner, to let someone make a dump that contains no
TABLESPACE clauses.
Yea, that would work, but we went through so much work to allow SQL
standard DDL statements, and it seems a shame to break it just for
tablespaces.
And, having it be a separate SET would also allow the tablespace
creation to fail and still get the objects created. (If the
explicit_tablespace doesn't exist during CREATE, we throw a warning.
This would contrast with a create _failure_ when the tablespace doesn't
exist and you say 'TABLESPACE t1' in CREATE.)
So there were actually two uses for this, one for standards compliance,
and the other was for flexibility in restoring to a system where the
tablespaces can't be created. The SET could give us different behavior
(warning vs. error) which would be useful for pg_dump.
Could we call it "explicit_tablespace" and when it is "", it is the
default, but when it isn't it is just like using 'TABLESPACE t1' in the
CREATE, but throws a warning instead of an error if the tablespace
doesn't exist?
My assumption is that it would not be like the default_with_oids
variable usage by pg_dump because it would be reset to '' (default) by
pg_dump after each time it is used. I assume explicit_tablespace would
always override the schema or database tablespace because it is
"explicit".
In fact this would partially fix the TODO we have:
* Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will attempt to be created
in their original locations. If this fails, the user must be able to
adjust the restore process.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Gavin Sherry wrote:
On Sun, 17 Oct 2004, Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variableI'm coming around to the conclusion that this is simply a bad idea.
I feel the same way for more or less the reasons you outline.
What we might want to do is invent a --notablespace option for pg_dump,
comparable to --noowner, to let someone make a dump that contains no
TABLESPACE clauses.That's a useful feature but I'm not sure it solves the problem people
originally put (to me at least). User has data in a tablespace on a
seperate device. The device crashes fatally and the user needs to restore
the database. All the user's dumps contain tablespace clauses because the
user did not anticipate the device dying. This, I think, is why people
wanted to either ignore tablespace clauses, have an override or something
else.
See my posting about using 'explicit_tablespace' and having it issue a
warning if it doesn't exist during create.
I still think, however, that a workable solution is to bring up a new
system, create the tablespaces on some online partition, and pg_restore
the dump. pg_dump does not dump CREATE TABLESPACE so we wont encounter
problems there.
pg_dumpall does dump CREATE TABLESPACE. It depends if he is using
pg_dump on individual databases or pg_dumpall. If he is using pg_dump
he is also pg_dumpall --globals-only and the global restore is where he
can made the adjustments. Of course, the 'explicit_tablespace' works
with pg_dumpall too because everything destined for a non-existant
tablespace goes into the default for that object.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073One additional idea for this item is to use CREATE to first create the
object, then move it using ALTER, and the ALTER might fail if the
tablespace doesn't exist. The only problem with that is this TODO item:
o Allow databases and schemas to be moved to different tablespaces
One complexity is whether moving a schema should move all existing
schema objects or just define the location for future object creation.
If we add a new SET variable and use it in pg_dump we will have to
support it forever even if there is no practical use for it.
(ALTER was originally part of the open item but I removed it thinking we
might not have space to load the table in the default location, but I
forgot we create it empty and could move it before we load it.)
One interesting side-affect of allowing tablespace specification to fail
is that it might give users enough control that we can mark this item as
done:
* Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will attempt to be created
in their original locations. If this fails, the user must be able to
adjust the restore process.
One idea would be that users could create any tablespaces or objects
they want to change before they do the restore and the restore would use
their new configuration and just error/skip the items they already
created. (This would also behave well if you load the dump and say stop
on any errors.)
For example, if you want to eliminate a tablespace, you just don't
create the directory and load your dump. Tablespace create will fail,
and all objects that use that tablespace will fail their ALTER and will
remain in their default locations. This actually seems less error-prone
than the idea of them manually changing things in the dump file.
---------------------------------------------------------------------------
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variableI'm coming around to the conclusion that this is simply a bad idea.
The problem with having such a SET variable is that it plays hob with
the existing definition about where schemas and tables get a default
tablespace from. Which source wins (the database or schema default
tablespace, or the SET variable)? And why? The only really clean way
to have a SET variable for this is to forget about schema- or
table-based defaults. Do we want to do that? (Hey, it'd solve the
problem with schema tablespaces being droppable, because there wouldn't
*be* any such thing as a schema's tablespace anymore. But on the whole
this seems like a step backward in usability.)Agreed, a step backwards, but see below.
What we might want to do is invent a --notablespace option for pg_dump,
comparable to --noowner, to let someone make a dump that contains no
TABLESPACE clauses.Yea, that would work, but we went through so much work to allow SQL
standard DDL statements, and it seems a shame to break it just for
tablespaces.And, having it be a separate SET would also allow the tablespace
creation to fail and still get the objects created. (If the
explicit_tablespace doesn't exist during CREATE, we throw a warning.
This would contrast with a create _failure_ when the tablespace doesn't
exist and you say 'TABLESPACE t1' in CREATE.)So there were actually two uses for this, one for standards compliance,
and the other was for flexibility in restoring to a system where the
tablespaces can't be created. The SET could give us different behavior
(warning vs. error) which would be useful for pg_dump.Could we call it "explicit_tablespace" and when it is "", it is the
default, but when it isn't it is just like using 'TABLESPACE t1' in the
CREATE, but throws a warning instead of an error if the tablespace
doesn't exist?My assumption is that it would not be like the default_with_oids
variable usage by pg_dump because it would be reset to '' (default) by
pg_dump after each time it is used. I assume explicit_tablespace would
always override the schema or database tablespace because it is
"explicit".In fact this would partially fix the TODO we have:
* Allow database recovery where tablespaces can't be created
When a pg_dump is restored, all tablespaces will attempt to be created
in their original locations. If this fails, the user must be able to
adjust the restore process.-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
Dear Tom,
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variableI'm coming around to the conclusion that this is simply a bad idea.
I agree that the "set" approach is error prone.
Another idea was to issue an "ALTER" after the CREATE.
That would move the empty table from one tablespace to another, at small
cost. If it fails, it is simply ignored by the restoration process,
but the table was already created so it exists.
What we might want to do is invent a --notablespace option for pg_dump,
comparable to --noowner, to let someone make a dump that contains no
TABLESPACE clauses.
(1) --notablespace would be useful, but it would not fix the problem
I had in mind, i.e. the transfer (possibly after a crash) of data
to another base which would not have these tablespaces. If the disk
is crashed, I cannot redo the pg_dump.
(2) thus it would help to be able to decide this at "restore" time.
I think that one of the implementation idea was to store the
information into some headers.
(3) possible current workaround for the desperate admin:
(a) create fake tablespaces as necessary...
(b) pg_restore ... | sed 's/TABLESPACE .*//' | psql ...
Have a nice day,
--
Fabien Coelho - coelho@cri.ensmp.fr
I just posted this idea with a new heading. ALTER seems like the right
approach, but notice we need to complete another TODO item to allow
tablespace movement of databases and schemas.
---------------------------------------------------------------------------
Fabien COELHO wrote:
Dear Tom,
o remove non-portable TABLESPACE clause from CREATE TABLE and
use a new default_tablespace SET variableI'm coming around to the conclusion that this is simply a bad idea.
I agree that the "set" approach is error prone.
Another idea was to issue an "ALTER" after the CREATE.
That would move the empty table from one tablespace to another, at small
cost. If it fails, it is simply ignored by the restoration process,
but the table was already created so it exists.What we might want to do is invent a --notablespace option for pg_dump,
comparable to --noowner, to let someone make a dump that contains no
TABLESPACE clauses.(1) --notablespace would be useful, but it would not fix the problem
I had in mind, i.e. the transfer (possibly after a crash) of data
to another base which would not have these tablespaces. If the disk
is crashed, I cannot redo the pg_dump.(2) thus it would help to be able to decide this at "restore" time.
I think that one of the implementation idea was to store the
information into some headers.(3) possible current workaround for the desperate admin:
(a) create fake tablespaces as necessary...
(b) pg_restore ... | sed 's/TABLESPACE .*//' | psql ...Have a nice day,
--
Fabien Coelho - coelho@cri.ensmp.fr---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
o fix shared memory on Win2k terminal server
We might be able to just mark this as not supported.
I have attached a patch that I think fixes this. The problem I saw
and fixed is, that the shmem created in a terminal services client is not
visible to the console (or services.msc).
It was necessary to differenciate OS versions, this might be better put
elsewhere.
I think in addition the system global name "sharemem.1" should be made more
pg specific, like "PostgreSQL.1". I have not done this since a new compile
would not detect a running old beta. But now would be the time (or never).
Andreas
Attachments:
shmem.win32.patchapplication/octet-stream; name=shmem.win32.patchDownload+12-5
Import Notes
Resolved by subject fallback
Bruce Momjian <pgman@candle.pha.pa.us> writes:
One additional idea for this item is to use CREATE to first create the
object, then move it using ALTER, and the ALTER might fail if the
tablespace doesn't exist.
This seems fairly impractical, at least for indexes where there is no
way to do the ALTER before the object is filled with data.
If we add a new SET variable and use it in pg_dump we will have to
support it forever even if there is no practical use for it.
Yeah, that's one thing that bothers me.
One interesting side-affect of allowing tablespace specification to fail
is that it might give users enough control that we can mark this item as
done:
Hmm, here's a variant idea: how about a GUC variable named something like
"soft_tablespace_specs" which when TRUE would mean that a nonexistent
tablespace name in a TABLESPACE clause is ignored (maybe with a WARNING)
rather than being an error, and so the object is created in whatever the
default tablespace for it would be. You wouldn't even necessarily want
to have pg_dump set this true for itself, but people could turn it on
when they needed to load a dump with wrong tablespace names in it.
(If we didn't have pg_dump turn it on automatically, then we'd not be
beholden to support it forever.)
regards, tom lane
Agreed on the memory name change and I will do it when I apply the
patch.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Zeugswetter Andreas DAZ SD wrote:
o fix shared memory on Win2k terminal server
We might be able to just mark this as not supported.
I have attached a patch that I think fixes this. The problem I saw
and fixed is, that the shmem created in a terminal services client is not
visible to the console (or services.msc).It was necessary to differenciate OS versions, this might be better put
elsewhere.I think in addition the system global name "sharemem.1" should be made more
pg specific, like "PostgreSQL.1". I have not done this since a new compile
would not detect a running old beta. But now would be the time (or never).Andreas
Content-Description: shmem.win32.patch
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073Tom Lane wrote:
Bruce Momjian <pgman@candle.pha.pa.us> writes:
One additional idea for this item is to use CREATE to first create the
object, then move it using ALTER, and the ALTER might fail if the
tablespace doesn't exist.This seems fairly impractical, at least for indexes where there is no
way to do the ALTER before the object is filled with data.If we add a new SET variable and use it in pg_dump we will have to
support it forever even if there is no practical use for it.Yeah, that's one thing that bothers me.
One interesting side-affect of allowing tablespace specification to fail
is that it might give users enough control that we can mark this item as
done:Hmm, here's a variant idea: how about a GUC variable named something like
"soft_tablespace_specs" which when TRUE would mean that a nonexistent
tablespace name in a TABLESPACE clause is ignored (maybe with a WARNING)
rather than being an error, and so the object is created in whatever the
default tablespace for it would be. You wouldn't even necessarily want
to have pg_dump set this true for itself, but people could turn it on
when they needed to load a dump with wrong tablespace names in it.
(If we didn't have pg_dump turn it on automatically, then we'd not be
beholden to support it forever.)
That's a nice idea in that it doesn't require a SET for every object
that uses tablespace, and allows user control over tablespace failure.
The only downside is that it prevents SQL-compliant CREATE syntax in
dumps. I was thinking you could use ALTER just for tables but then the
tablespace failure rules would be different for tables and other
objects, which is unacceptable.
--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
o fix shared memory on Win2k terminal server
We might be able to just mark this as not supported.
I have attached a patch that I think fixes this. The problem I saw
and fixed is, that the shmem created in a terminal services
client is not
visible to the console (or services.msc).
Does this actually fix the problem for you?
Because, as I have previously posted I think, it does *not* solve the
problem on any of my test machines. I still get the shmget() error
message when running from a TS session.
(Yes, I tried specifically with your patch, since I thought maybe I got
something wrong before)
I'm on Windows 2000 Server, tested both DC and non-DC machines. What are
you testing on?
Also, I don't really see how the visibility of the shmem segment
matters. We can't *create* the first instance of it, which should not
affect this at all. And if we passed that, all backends are still
execute in the same session, so there is no effect on it.
services.msc only interacts with the SCM, it has nothing at all to do
with shmem.
//Magnus
Import Notes
Resolved by subject fallback
At 03:15 AM 19/10/2004, Bruce Momjian wrote:
The only downside is that it prevents SQL-compliant CREATE syntax in
dumps.
One idea that may be worth considering: we currently dump a complete SQL
statement including a TABLESPACE clause, which makes it hard to allow
pg_restore to have a 'no tablespaces' option (it is fixed by pg_dump).
To solve this, we should dump the table definition as a format string and
dump the tablespace clause (ie. ' TABLESPACE ts') as a separate part of the
table definition TOC entry. If the user wants the tablespace to be dumped,
then we substitute the tablespace clause, otherwise a blank string. This
could be a useful general approach in the future.
The main issue will be quoting the clause identifiers (if we use
'%%tablespace%%' then we have to handle columns or tables whose names
contain '%%tablespace%%'. Simplest would be to backslash quote all '%' and
'\' then do subs.
Also, I like the option of a soft-tablespace option, but also liked the
idea of the fake/logical/virtual tablespaces someone suggested earlier; if
restoring into a database without a required tablespace, then create a
virtual tablespace that points to pg_default.
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/
o fix shared memory on Win2k terminal server
We might be able to just mark this as not supported.
I have attached a patch that I think fixes this. The problem I saw
and fixed is, that the shmem created in a terminal services client is not
visible to the console (or services.msc).Does this actually fix the problem for you?
Because, as I have previously posted I think, it does *not* solve the
problem on any of my test machines. I still get the shmget() error
message when running from a TS session.
I think you are having another problem.
I can create it here (with or without the patch). I am running
W2000 5.00.2195 SP4. Maybe you are having a permissions problem?
I am using a user with near Administrator privs.
Also, I don't really see how the visibility of the shmem segment
matters.
If it really does not matter, please don't apply my patch Bruce.
(still do the rename though please)
We can't *create* the first instance of it, which should not
affect this at all. And if we passed that, all backends are still
execute in the same session, so there is no effect on it.
Yes it only matters if postmaster is started/trying to start from different
TS Sessions. I think we need to determine global existance of the shm segment
to get rid of old processes/segments.
services.msc only interacts with the SCM, it has nothing at all to do
with shmem.
I meant if "run as a service", which is the same TS session as the console.
Andreas
Import Notes
Resolved by subject fallback
Philip Warner <pjw@rhyme.com.au> writes:
To solve this, we should dump the table definition as a format string and
dump the tablespace clause (ie. ' TABLESPACE ts') as a separate part of the
table definition TOC entry. If the user wants the tablespace to be dumped,
then we substitute the tablespace clause, otherwise a blank string. This
could be a useful general approach in the future.
I think the tricky part of that would be inserting the tablespace clause
in the right place; for CREATE INDEX this seems to require nontrivial
parsing. (Both the index column definitions and the WHERE clause could
be arbitrarily complicated expressions.) If we can get around that part
then this wouldn't be too hard.
Also, I like the option of a soft-tablespace option, but also liked the
idea of the fake/logical/virtual tablespaces someone suggested earlier; if
restoring into a database without a required tablespace, then create a
virtual tablespace that points to pg_default.
Given that tablespaces are fundamentally only directories, there isn't
any particularly strong reason to not just make a real tablespace. You
aren't going to constrain space allocation or anything by having another
directory in/alongside $PGDATA. So I think the "virtual tablespace"
idea is basically pointless.
The real crux of all this, I think, is "what if I want to restore as
a non-superuser, and so I don't have privilege to create tablespaces
to match what the dump wants?" The soft-failure option provides an
answer here, but creating either real or virtual tablespaces wouldn't
fly. A "--notablespace" option in pg_restore would solve it too, but
only if you'd done an -Fc or -Ft dump; with a plain text dump you
still got trouble.
regards, tom lane
At 03:06 AM 20/10/2004, Tom Lane wrote:
I think the tricky part of that would be inserting the tablespace clause
in the right place; for CREATE INDEX this seems to require nontrivial
parsing. (Both the index column definitions and the WHERE clause could
be arbitrarily complicated expressions.) If we can get around that part
then this wouldn't be too hard.
I may be missing something here; I was assuming that pg_dump would dump
would build the CREATE INDEX/TABLE/etc commands with the %%tablespace%%
already embedded. pg_restore would not need to do any parsing. Or is there
something I don't understand?
----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 03 5330 3172 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp.mit.edu:11371 |/
Philip Warner <pjw@rhyme.com.au> writes:
At 03:06 AM 20/10/2004, Tom Lane wrote:
I think the tricky part of that would be inserting the tablespace clause
in the right place; for CREATE INDEX this seems to require nontrivial
parsing. (Both the index column definitions and the WHERE clause could
be arbitrarily complicated expressions.) If we can get around that part
then this wouldn't be too hard.
I may be missing something here; I was assuming that pg_dump would dump
would build the CREATE INDEX/TABLE/etc commands with the %%tablespace%%
already embedded. pg_restore would not need to do any parsing. Or is there
something I don't understand?
Maybe there's something I don't understand. How are you expecting
pg_restore to control whether it outputs the command with a TABLESPACE
clause embedded or not, if pg_dump has already built the command string
that way? I thought you were envisioning that pg_restore would insert,
or not insert, a TABLESPACE clause into a command that didn't initially
have one.
regards, tom lane
