>> IIRC there was discussion about the location of the files
>(Peter I think
>> it was suggesting creating a new directory - I'll happily leave that
>> part up to an eventual committer).
>>
>> Another discussion was about binary files in the tree (not
>being source
>> files - the source is a bi
>>>How about an environment variable that points to a .pgpass type file.
>>
>>You can do that today: point $HOME at some temp directory or other.
>>AFAIR pg_dump doesn't make any other use of $HOME ...
>>
>>>Or we could even play games with PGPASSWORD - if it names an
>existing file
>>>that satis
On Wed, Aug 18, 2004 at 10:12:53PM -0400, Bruce Momjian wrote:
> Magnus Hagander wrote:
> >
> > Another discussion was about binary files in the tree (not being source
> > files - the source is a binary .AI file (AFAIK that's Adobe
> > Illustrator)). The question was raised wether ImageMagick coul
Thanks Tom,
Yes, this is beta1, not the CVS tip, so all is golden.
Paul
Tom Lane wrote:
Paul Ramsey <[EMAIL PROTECTED]> writes:
I started the database from "/home/pramsey/pgtest/8.0/bin" using
"./pg_ctl start -D /home/pramsey/pgtest/8.0/data"
Ah-hah ... and this is 8.0beta1, right, not anything l
Paul Ramsey <[EMAIL PROTECTED]> writes:
> I started the database from "/home/pramsey/pgtest/8.0/bin" using
> "./pg_ctl start -D /home/pramsey/pgtest/8.0/data"
Ah-hah ... and this is 8.0beta1, right, not anything later?
I fixed some problems associated with "." and ".." in the executable's
path l
Things definately do not like to be run from within "bin". I added
/home/pramsey/pgtest/8.0/bin to my PATH and then ran everything without
a direct path reference:
[EMAIL PROTECTED] 8.0]$ pg_ctl start -D /home/pramsey/pgtest/8.0/data
postmaster starting
LOG: database system was shut down at 200
Sounds like we are getting close. From strace:
stat64("/home/pramsey/pgtest/8.0/bin/lib/postgresql/plpgsql",
0xbfffe480) = -1 ENOENT (No such file or directory)
stat64("/home/pramsey/pgtest/8.0/bin/lib/postgresql/plpgsql.so",
0xbfffe480) = -1 ENOENT (No such file or directory)
stat64("$libdir/plp
I am afraid it gets crazier...
I put /home/pramsey/pgtest/8.0/bin on my $PATH
Now:
[EMAIL PROTECTED] 8.0]$ pg_config --pkglibdir
/home/pramsey/pgtest/8.0/lib/postgresql
Hm, correct.
[EMAIL PROTECTED] 8.0]$ ./bin/pg_config --pkglibdir
/home/pramsey/pgtest/8.0/./lib/postgresql
Also correct, but getti
Paul Ramsey <[EMAIL PROTECTED]> writes:
> ... It is the actual binaries that seem to not know
> where $libdir is supposed to be.
Where do they think it is?
A useful way to check would be to strace the backend while you're
executing "createlang" or another command that tries to load a
dynamic lib
Ah, what is your $bindir? Is it /home/pramsey/pgtest/8.0/bin/postgresql?
---
Paul Ramsey wrote:
> Check this out!
>
> [EMAIL PROTECTED] bin]$ ./pg_config --pkglibdir
> /home/pramsey/pgtest/8.0/bin/lib/postgresql
>
Check this out!
[EMAIL PROTECTED] bin]$ ./pg_config --pkglibdir
/home/pramsey/pgtest/8.0/bin/lib/postgresql
^^^
And yet:
./port/pg_config_paths.h:#define PKGLIBDIR
"/home/pramsey/pgtest/8.0/lib/postgresql"
Could the problem be here? (port/path.c):
/*
* get_pkglib_pa
Tom Lane wrote:
> Robert Treat <[EMAIL PROTECTED]> writes:
> > If the location doesn't exist will postgresql try to create it? istm it could
> > do this and if it fails then you are no worse off, but if it were to succeed
> > you're that much better off.
>
> I think this would be fairly pointless
Robert Treat wrote:
> On Wednesday 18 August 2004 21:39, you wrote:
> > Christopher Kings-Lynne wrote:
> > > > It is a little bit different because a schema, a table or a function
> > > > are database application issues and are normally addressed by pg_dump
> > > > and pg_restore, although tablespa
Robert Treat <[EMAIL PROTECTED]> writes:
> If the location doesn't exist will postgresql try to create it? istm it could
> do this and if it fails then you are no worse off, but if it were to succeed
> you're that much better off.
I think this would be fairly pointless. In most of the practical
The expansions in the build scripts all seem correct, and in fact, all
the libraries are installed in the right place, both the system stuff
(plpgsql.so) and the contrib stuff (libpostgis.so) ends up in
/opt/foo/lib/postgresql. It is the actual binaries that seem to not know
where $libdir is su
On Wednesday 18 August 2004 21:39, you wrote:
> Christopher Kings-Lynne wrote:
> > > It is a little bit different because a schema, a table or a function
> > > are database application issues and are normally addressed by pg_dump
> > > and pg_restore, although tablespaces are more an administration
Tom Lane wrote:
It's deprecated because it's insecure, on platforms where other users can
see the environment variables passed to pg_dump (which apparently is
quite a few variants of Unix). You wouldn't pass the password on the
command line either ...
Painful as .pgpass may be for an admin tool, I
Devrim GUNDUZ wrote:
>
> Hi,
>
> On Wed, 18 Aug 2004, Paul Ramsey wrote:
>
> > When installing PgSQL into a non-standard location (like /opt/foo) the
> > configure script decides to install all the contrib libraries and
> > plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
I'm trying to build RPMS for 7.3.7 but I have a problem.
contrib/earthdistance seems empty, so configure exits with error:
make[1]: Leaving directory
`/usr/src/redhat/SOURCES/postgresql-7.3.7/contrib/dbsize'
make[1]: Entering directory
`/usr/src/redhat/SOURCES/postgresql-7.3.7/contrib/earthdist
Hi,
On Wed, 18 Aug 2004, Paul Ramsey wrote:
> When installing PgSQL into a non-standard location (like /opt/foo) the
> configure script decides to install all the contrib libraries and
> plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
> backend does not recognize this d
Short bug report:
When installing PgSQL into a non-standard location (like /opt/foo) the
configure script decides to install all the contrib libraries and
plpglsq into /opt/foo/lib/postgresql. This would be fine, except that
backend does not recognize this directory as a place to be searched fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I'm trying to build RPMS for 7.3.7 but I have a problem.
contrib/earthdistance seems empty, so configure exits with error:
make[1]: Leaving directory
`/usr/src/redhat/SOURCES/postgresql-7.3.7/contrib/dbsize'
make[1]: Entering directory
`/usr/
Added to open items:
* Fix Solaris for single-host netmasks in pg_hba.conf, use CIDR?
---
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Andrew Dunstan <[EMAIL PROTECTED]> writes:
> >
> >
> >>>Seems unlikely
On Wed, Aug 18, 2004 at 10:12:53PM -0400, Bruce Momjian wrote:
> These binary files are almost never going to be changed so I see no
> problem with adding them to CVS, and putting whatever source we can into
> CVS. If we can't we just document how we created the binary. Can you
> export the imag
Added to TODO:
> o Allow COPY to optionally include column headings as the first
I know Tom didn't like it but there were others who did.
---
Andrew Dunstan wrote:
>
>
> Tom Lane wrote:
>
> >Bruce Momjian <[EMAIL
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
How about an environment variable that points to a .pgpass type file.
You can do that today: point $HOME at some temp directory or other.
AFAIR pg_dump doesn't make any other use of $HOME ...
Or we could even play games with PGP
Magnus Hagander wrote:
> >>win32 binary version stamps
> >
> >Magnus has just gone on holiday for a couple of weeks but
> >before he left
> >he did tell me he'd submitted what was hopefully the final patch for
> >this. I haven't seen it yet though - is it stuck in the queue?
>
> I did, and I
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> How about an environment variable that points to a .pgpass type file.
You can do that today: point $HOME at some temp directory or other.
AFAIR pg_dump doesn't make any other use of $HOME ...
> Or we could even play games with PGPASSWORD - if it names
Tom Lane wrote:
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
After some tests, I found that using the PGPASSWORD environment variable
will do the job. I'm a bit irritated that it's marked "deprecated" in
the docs, the .pgpass solution isn't a good one for tool managed passwords.
I've just noticed that there are some severe bugs in the column-aliasing
feature in the presence of dropped columns. For instance
regression=# create table t1(f1 int, f2 int, f3 int);
CREATE TABLE
regression=# select * from t1 as t(a,b);
a | b | f3-- okay, as expe
It's deprecated because it's insecure, on platforms where other users can
see the environment variables passed to pg_dump (which apparently is
quite a few variants of Unix). You wouldn't pass the password on the
command line either ...
Painful as .pgpass may be for an admin tool, I do not know of
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.
---
Ph
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> After some tests, I found that using the PGPASSWORD environment variable
>> will do the job. I'm a bit irritated that it's marked "deprecated" in
>> the docs, the .pgpass solution isn't a good one for tool managed passwords.
> I didn't notic
Christopher Kings-Lynne wrote:
> > It is a little bit different because a schema, a table or a function are
> > database application issues and are normally addressed by pg_dump and
> > pg_restore, although tablespaces are more an administration issue wrt disk
> > layout and the like, which are lik
The first is to add a parameter to CREATE TABLESPACE and ALTER TABLESPACE
called RANDOMPAGECOST (or something like that) which allows users to set
the random page cost for a given tablespace. I'm undecided as to whether
they should be able to set the sequential scan cost. That seems
reasonable too
While fixing the gui for pg_dump and pg_restore, I painfully noticed
there's no option for the password.
After some tests, I found that using the PGPASSWORD environment variable
will do the job. I'm a bit irritated that it's marked "deprecated" in
the docs, the .pgpass solution isn't a good one
It is a little bit different because a schema, a table or a function are
database application issues and are normally addressed by pg_dump and
pg_restore, although tablespaces are more an administration issue wrt disk
layout and the like, which are likely to be different from one machine to
another
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
> Gavin Sherry wrote:
>
> > On Wed, 18 Aug 2004, Gaetano Mendola wrote:
> >>-BEGIN PGP SIGNED MESSAGE-
> >>Hash: SHA1
> >>
> >>Hi all,
> >>now that we have the tablespace support don't you think that
> >>each tablespace needs his own costs instea
> Manfred Spraul
> [EMAIL PROTECTED] wrote:
>
> >>Tom Lane wrote
> >>
> >>
> >>>NOT LOGGED options on CREATE INDEX and COPY, to allow users to take
> >>>advantage of the no logging optimization without turning off
> PITR system
> >>>wide. (Just as this is possible in Oracle and Teradata).
> >>>
> >
While fixing the gui for pg_dump and pg_restore, I painfully noticed
there's no option for the password.
After some tests, I found that using the PGPASSWORD environment variable
will do the job. I'm a bit irritated that it's marked "deprecated" in
the docs, the .pgpass solution isn't a good one
Joe Conway wrote:
> I'm seeing "gcc: unrecognized option `-pthreads'" over and over when
> building from cvs tip.
>
> # pg_config --configure
> '--prefix=/usr/local/pgsql-8.0' '--with-pgport=55435' '--with-perl'
> '--with-tcl' '--with-tclconfig=/usr/lib' '--without-tk' '--with-python'
> '--enab
Magnus Hagander wrote:
> > > There is a fixed buffer of 1024 bytes. I have a feeling
> > ythat one has
> > > to be changed to dynamic.
> > >
> > You're quite right. The 'InfoBufferSize' denotes 1122 bytes
> > after this call.
> >
> > if(!GetTokenInformation(AccessToken,TokenGroups,InfoBuffer,1
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > I need to call canonicalize_path() in the macro.
>
> There is only one use of get_home_path in libpq. Lose it and do
> a direct getenv(HOMEDIR). You do not really need to do a
> canonicalize_path there; it'd be sufficient to insert
New package has been built for 7.4.5 ... just have 7.2 left to package up
...
On Tue, 17 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
let me know when you are ready ...
I've committed the patch itself. I have to leave for a few hours,
but I can update the release note
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I have just noticed that \d+ tablename doesn't show the table
comment/description - should it? Is this a TODO?
\dt+ tablename shows this, in what is probably a more convenient format
than \d+ would be able to use.
Not if you
I'm seeing "gcc: unrecognized option `-pthreads'" over and over when
building from cvs tip.
# pg_config --configure
'--prefix=/usr/local/pgsql-8.0' '--with-pgport=55435' '--with-perl'
'--with-tcl' '--with-tclconfig=/usr/lib' '--without-tk' '--with-python'
'--enable-nls' '--enable-debug' '--enab
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I have just noticed that \d+ tablename doesn't show the table
> comment/description - should it? Is this a TODO?
\dt+ tablename shows this, in what is probably a more convenient format
than \d+ would be able to use. The \d printout is already awfully
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I need to call canonicalize_path() in the macro.
There is only one use of get_home_path in libpq. Lose it and do
a direct getenv(HOMEDIR). You do not really need to do a
canonicalize_path there; it'd be sufficient to insert the appropriate
directory se
I have just noticed that \d+ tablename doesn't show the table
comment/description - should it? Is this a TODO?
cheers
andrew
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmail
Bruce Momjian wrote:
> Tom Lane wrote:
> > Karel Zak <[EMAIL PROTECTED]> writes:
> > > I tried compile some program with latest CVS libpq:
> >
> > > gcc -O2 -O2 -g -pipe -march=i386 -mcpu=i686 -I/usr/include/httpd
> > > -Wall -I/usr/lib/postgresql/include -DLIBAPMOM_FUNCALL=1 -Wall
> > > -Wmis
Tom Lane wrote:
> Karel Zak <[EMAIL PROTECTED]> writes:
> > I tried compile some program with latest CVS libpq:
>
> > gcc -O2 -O2 -g -pipe -march=i386 -mcpu=i686 -I/usr/include/httpd
> > -Wall -I/usr/lib/postgresql/include -DLIBAPMOM_FUNCALL=1 -Wall
> > -Wmissing-prototypes -Wmissing-declarati
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Seems unlikely. I suppose you could argue that we shouldn't be using
getaddrinfo on the netmask field at all; there's certainly not any value
in doing a DNS lookup on it, for instance. Maybe we should go back to
using plain ol' inet_a
Karel Zak <[EMAIL PROTECTED]> writes:
> I tried compile some program with latest CVS libpq:
> gcc -O2 -O2 -g -pipe -march=i386 -mcpu=i686 -I/usr/include/httpd
> -Wall -I/usr/lib/postgresql/include -DLIBAPMOM_FUNCALL=1 -Wall
> -Wmissing-prototypes -Wmissing-declarations `xml2-config --cflags`
>
Bruce Momjian wrote:
Uh, we are passing 255.255.255.255 to getaddrinfo()? Why would we do that?
Any non-CIDR netmask is passed to getaddrinfo to turn it into a binary
mask. see src/backend/libpq/hba.c For CIDR masks we make the binary
version ourselves.
cheers
andrew
--
Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Seems unlikely. I suppose you could argue that we shouldn't be using
>> getaddrinfo on the netmask field at all; there's certainly not any value
>> in doing a DNS lookup on it, for instance. Maybe we should go back to
>> using plain ol' inet_aton for
[EMAIL PROTECTED] wrote:
Tom Lane wrote
NOT LOGGED options on CREATE INDEX and COPY, to allow users to take
advantage of the no logging optimization without turning off PITR system
wide. (Just as this is possible in Oracle and Teradata).
Isn't this in direct conflict with your opinion a
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
I thought the report was that *only* 255.255.255.255 failed. The
question is why?
The impression I got was that some internal subroutine of getaddrinfo
had a broken error-handling convention (ie, "return a numeric address
value or
Joe Conway wrote:
Tom Lane wrote:
Well, *Marc* is working on including less stuff; the rest of us don't
necessarily agree. In particular I've got to re-incorporate any major
pieces that get removed from the core distribution, since people expect
to find those in the RPM set. (In principle I supp
Tom Lane wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > I thought the report was that *only* 255.255.255.255 failed. The
> > question is why?
>
> The impression I got was that some internal subroutine of getaddrinfo
> had a broken error-handling convention (ie, "return a numeric address
Joe Conway <[EMAIL PROTECTED]> writes:
> On that, note that I specifically removed jdbc and tcl options from the
> spec file because the 8.0.0 release notes said they were removed from
> the distribution. I suppose at lease jdbc should be put back? It didn't
> seem right to include the 7.4 jdbc
Tom Lane wrote:
Well, *Marc* is working on including less stuff; the rest of us don't
necessarily agree. In particular I've got to re-incorporate any major
pieces that get removed from the core distribution, since people expect
to find those in the RPM set. (In principle I suppose they could be
h
The OSDL provides two services to aid in development processes: The
Patch Lifecycle Manager (PLM) and the Scalable Test Platform (STP).
Recent releases allow software other than the linux kernel to be
actively tested.
PLM (http://www.osdl.org/plm-cgi/plm) can be used for storing a series
of patch
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> I thought the report was that *only* 255.255.255.255 failed. The
> question is why?
The impression I got was that some internal subroutine of getaddrinfo
had a broken error-handling convention (ie, "return a numeric address
value or -1 on error").
> A
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> In the PG case a
>> single specfile currently aggregates the core server, jdbc, and
>> pygresql ... and I'm getting pressure to include more stuff.
> How does that compute, considering that everyone else appears to be
> working on
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Agreed, but from a clarity perspective, are we better moving to the CIDR
format for hostnames in pg_hba.conf anyway?
Possibly --- it'd be easier to sell on that argument anyway ;-)
s/hostnames/netmas
Tom Lane wrote:
> In the PG case a
> single specfile currently aggregates the core server, jdbc, and
> pygresql ... and I'm getting pressure to include more stuff.
How does that compute, considering that everyone else appears to be
working on including less stuff?
> The init script is a differen
Bruce Momjian <[EMAIL PROTECTED]> writes:
> True, but at least it would work. Are they saying the masks don't work
> at all? Why haven't we heard this before?
The specific case of mask = all ones has got a problem (and I think
there are some other conditions involved too). We have heard reports
Tom Lane wrote:
Gaetano Mendola <[EMAIL PROTECTED]> writes:
BTW I have bitten recently on the attempt of change the default port.
I did it as usual changing it in postgresql.conf but that parameter
is overriden by:
PGPORT=5432
present on the start up script.
There is any reason to still pa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Agreed, but from a clarity perspective, are we better moving to the CIDR
> > format for hostnames in pg_hba.conf anyway?
>
> Possibly --- it'd be easier to sell on that argument anyway ;-)
>
> > Also, I think we would accept a patch
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Agreed, but from a clarity perspective, are we better moving to the CIDR
> format for hostnames in pg_hba.conf anyway?
Possibly --- it'd be easier to sell on that argument anyway ;-)
> Also, I think we would accept a patch that modified pg_hba.conf for
Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> writes:
> > Since the default config now allows TCP/IP connections from localhost,
> > maybe we should tweak the default pg_hba.conf to work around this
> > problem? (e.g. use the /32 syntax which works ok)
>
> Maybe we should press Sun to fix
Gavin Sherry wrote:
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
now that we have the tablespace support don't you think that
each tablespace needs his own costs instead of a system wide
one ?
I searched in the archives and on the TODO list witho
Gaetano Mendola <[EMAIL PROTECTED]> writes:
> BTW I have bitten recently on the attempt of change the default port.
> I did it as usual changing it in postgresql.conf but that parameter
> is overriden by:
> PGPORT=5432
> present on the start up script.
> There is any reason to still pass thi
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Isn't there a way to generate this automatically? Why isn't the .spec
> file (and the debian directory, for that matter) part of the source
> tree?
Can't speak for Debian, but Red Hat at least would not use such a spec
file anyway. RH's procedures inv
> > There is a fixed buffer of 1024 bytes. I have a feeling
> ythat one has
> > to be changed to dynamic.
> >
> You're quite right. The 'InfoBufferSize' denotes 1122 bytes
> after this call.
>
> if(!GetTokenInformation(AccessToken,TokenGroups,InfoBuffer,102
> 4,&InfoBufferSize))
Ah.
Your st
Dear Robert,
> Chris, help me understand this will you?
I'm not Chris, but it looks like Robert may eventually share my concerns,
so I'm happy not to be alone on this one ;-)
> On my production system I have a few very large tables I want to move
> into their own tablespace so I can but them a
On Wednesday 18 August 2004 04:39, Christopher Kings-Lynne wrote:
> > shell> pg_dump coelho | grep TABLESPACE
> > CREATE SCHEMA test AUTHORIZATION coelho TABLESPACE test;
> >
> > "TABLESPACE" appears in a basic pg_dump SQL output. If the test
> > tablespace does not exist, the command will fail, an
Hi,
I tried compile some program with latest CVS libpq:
gcc -O2 -O2 -g -pipe -march=i386 -mcpu=i686 -I/usr/include/httpd
-Wall -I/usr/lib/postgresql/include -DLIBAPMOM_FUNCALL=1 -Wall
-Wmissing-prototypes -Wmissing-declarations `xml2-config --cflags`
`Wand-config --cppflags` -o jsn-importe
On Wed, 18 Aug 2004, Gaetano Mendola wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
> now that we have the tablespace support don't you think that
> each tablespace needs his own costs instead of a system wide
> one ?
>
> I searched in the archives and on the TODO list withou
Joe Conway wrote:
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Hopefully the third try is a charm ;-)
Version 3 is now available: fixes the init script. Previously
/etc/init.d/postgresql worked the first time used (i.e. would initdb
and start postgres) but not the second and subsequent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
now that we have the tablespace support don't you think that
each tablespace needs his own costs instead of a system wide
one ?
I searched in the archives and on the TODO list without success.
Regards
Gaetano Mendola
-BEGIN PGP SIGNATURE
Alvaro Herrera wrote:
> Why isn't the
> .spec file (and the debian directory, for that matter) part of the
> source tree?
Since packaging usually happens after a release, or at least continues
well after a release, such files or directories would be perpetually
outdated.
--
Peter Eisentraut
ht
Dear Christopher,
> > "TABLESPACE" appears in a basic pg_dump SQL output. If the test tablespace
> > does not exist, the command will fail, and so my whole restoration.
> >
> > Thus I still stick to my opinion;-)
>
> Your complaint was that you need a way of continuing a restore if the
> _tablesp
shell> pg_dump coelho | grep TABLESPACE
CREATE SCHEMA test AUTHORIZATION coelho TABLESPACE test;
"TABLESPACE" appears in a basic pg_dump SQL output. If the test tablespace
does not exist, the command will fail, and so my whole restoration.
Thus I still stick to my opinion;-)
Your complaint was that
> > I'm not thinking about pg_dumpall but pg_dump/pg_restore.
>
> Tablespaces are dumped by pg_dumpall, not pg_dump.
If so, indeed it would be a non-issue. However,
shell> pg_dump coelho | grep TABLESPACE
CREATE SCHEMA test AUTHORIZATION coelho TABLESPACE test;
"TABLESPACE" appears in a basic p
On Tue, Aug 17, 2004 at 08:27:58PM -0700, Joe Conway wrote:
> Tom Lane wrote:
> >Joe Conway <[EMAIL PROTECTED]> writes:
> >
> >>Hopefully the third try is a charm ;-)
> >
> >>Version 3 is now available: fixes the init script. Previously
> >>/etc/init.d/postgresql worked the first time used (i.e. w
At restore time it doesn't do anything since pg_dumpall is a text format
only.
I'm not thinking about pg_dumpall but pg_dump/pg_restore.
Tablespaces are dumped by pg_dumpall, not pg_dump.
Chris
---(end of broadcast)---
TIP 4: Don't 'kill -9' the post
Dear Christopher,
> > Allow database recovery where tablespaces can't be created
>
> How is that at all a problem?
It is enough a small problem to be put in the todo list.
> It's no different to the requirement to have installed all your contrib
> .so's before running your restore, what's s
88 matches
Mail list logo
