On Tue, Aug 10, 2004 at 12:24:06PM -0400, Tom Lane wrote:
> It may be that we do not care because pg_subtrans doesn't have to be
> valid after a crash, but I haven't seen any proof of that theory.
Let's suppose we crash between creating a child transaction and marking
it as done. What we have to
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> Has anyone tested inheritance with tablespaces? ie. child in different
> tablespace to parent, select query that goes over both...?
They're at completely different levels of the system ... I'd be as
surprised to hear of a bug here as to hear
We already have some TODO items about sorting out exactly how the
defaulting behavior works here. In particular, what if anything is the
difference between a child object inheriting a default tablespace TS,
and explicitly saying "TABLESPACE TS" in its definition? If we attempt
to reload this mess
Actually I think we'd just revert the ruleutils.c change that showed
TABLESPACE in pg_get_indexdef. The real question is to be sure that
pg_dump could get along without it. If Philip wants to fix pg_dump,
I'm content to just stay out of his way ;-)
Well my original patch did without it, someone
Philip Warner <[EMAIL PROTECTED]> writes:
> Just to confirm; it's only tables and indexes that have tablespaces, and I
> can issue some kind of SET command. Any idea of the syntax?
> As an aside: should a database be allowed to have a default tablespace?
Well, tables and indexes definitely have
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Good point(s) ... but, what would that give an attacker? Being able to
> isolate the random seed, that is?
Well, the random seed determines the salt values that will be used to
challenge password logins. So it might help you execute a
password-re
At 02:27 PM 20/08/2004, Tom Lane wrote:
Actually I think we'd just revert the ruleutils.c
Just to confirm; it's only tables and indexes that have tablespaces, and I
can issue some kind of SET command. Any idea of the syntax?
As an aside: should a database be allowed to have a default tablespace?
On Fri, 20 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Fri, 20 Aug 2004, Gavin Sherry wrote:
However, I'm not sure why an uptime is all that useful?
Bragging rights? :)
The folks who have a legitimate interest in that number can surely find
it out from "ps". What I
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> One point here is the handling of index tablespaces. I added TABLESPACE
>> as part of "pg_get_indexdef" output, but we'd need a different solution
>> if we want to go down this path.
> Another parameter to pg_get_indexdef() :(
Actually I thi
On Fri, 20 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Thu, 19 Aug 2004, Tom Lane wrote:
I'd like to see more than one person requesting this (and with solider
rationales) before it gets added to TODO. If I wanted to be picky I
would suggest that knowledge of the se
What have I missed? I can do the pg_dump stuff if noone else wants to.
I'm all of a sudden really busy :( Extra karate at nights + new
responsibilities at work, so my plan on doing the stuff listed for
pg_dump under TODO (specifically comments on index and composite type
columns) is rather lagg
One point here is the handling of index tablespaces. I added TABLESPACE
as part of "pg_get_indexdef" output, but we'd need a different solution
if we want to go down this path. Maybe it's not a problem given this
idea about where pg_dump is going to specify tablespace. But someone
needs to take
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Fri, 20 Aug 2004, Gavin Sherry wrote:
>> However, I'm not sure why an uptime is all that useful?
> Bragging rights? :)
The folks who have a legitimate interest in that number can surely find
it out from "ps". What I'm having a hard time with he
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Thu, 19 Aug 2004, Tom Lane wrote:
>> I'd like to see more than one person requesting this (and with solider
>> rationales) before it gets added to TODO. If I wanted to be picky I
>> would suggest that knowledge of the server start time might be
At 01:47 PM 20/08/2004, Tom Lane wrote:
But someone
needs to take a close look at pg_dump's logic to see if this can work.
Not sure where the issues lie, but anything that can reside in a tablespace
(table, index,...anything else?), needs to dump it's definition without
reference to a tablespace,
Marc G. Fournier wrote:
> On Thu, 19 Aug 2004, Tom Lane wrote:
>
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> >> Is the uptime kept internally anywhere? Or even the start time?
> >
> > No, and no (at least not in any globally accessible variable).
> >
> >> If it is, it would be quite trivial
On Thu, 19 Aug 2004, Tom Lane wrote:
Alvaro Herrera <[EMAIL PROTECTED]> writes:
Is the uptime kept internally anywhere? Or even the start time?
No, and no (at least not in any globally accessible variable).
If it is, it would be quite trivial to provide access to it
Not really --- in the EXEC_BACK
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> The problem with ALTER TABLE is that it can be hugely expensive, I think.
As long as you did it before loading any data, it wouldn't be too bad.
But certainly a preceding SET would be cheaper than pushing even
zero-size files around.
I don't have any p
Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Is the uptime kept internally anywhere? Or even the start time?
>
> No, and no (at least not in any globally accessible variable).
>
> > If it is, it would be quite trivial to provide access to it
>
> Not really --- in the EXEC_BA
Alvaro Herrera wrote:
> On Fri, Aug 20, 2004 at 01:26:39PM +1000, Philip Warner wrote:
> > At 01:09 PM 20/08/2004, Tom Lane wrote:
> > >It seemed like a reasonable idea to me...
> >
> > Do we have a "SET DEFAULT TABLESPACE"? Can we add one for this release? If
> > not, we probably need to go with
On Fri, Aug 20, 2004 at 01:26:39PM +1000, Philip Warner wrote:
> At 01:09 PM 20/08/2004, Tom Lane wrote:
> >It seemed like a reasonable idea to me...
>
> Do we have a "SET DEFAULT TABLESPACE"? Can we add one for this release? If
> not, we probably need to go with the ALTER TABLE. Although a SET D
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Is the uptime kept internally anywhere? Or even the start time?
No, and no (at least not in any globally accessible variable).
> If it is, it would be quite trivial to provide access to it
Not really --- in the EXEC_BACKEND case, we'd have to do some
Marc G. Fournier wrote:
> On Fri, 20 Aug 2004, Gavin Sherry wrote:
>
>>
>> On Thu, 19 Aug 2004, Alvaro Herrera wrote:
>>
>>> On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne
>>> wrote:
> It seems that there is no way to know the postgres uptime, a sort
> of uptime() fun
At 01:09 PM 20/08/2004, Tom Lane wrote:
It seemed like a reasonable idea to me...
Do we have a "SET DEFAULT TABLESPACE"? Can we add one for this release? If
not, we probably need to go with the ALTER TABLE. Although a SET DEFAULT
TABLESPACE would be convenent in general.
On Fri, 20 Aug 2004, Gavin Sherry wrote:
On Thu, 19 Aug 2004, Alvaro Herrera wrote:
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detec
Philip Warner <[EMAIL PROTECTED]> writes:
> At 12:37 PM 20/08/2004, Bruce Momjian wrote:
>> But that doesn't fix ascii dumps loaded via psql.
> It does; the ascii dump file is generated by exactly the same technique as
> pg_restore.
Right. Philip's suggestion would essentially use the same tech
On Thu, 19 Aug 2004, Alvaro Herrera wrote:
> On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
> > >It seems that there is no way to know the postgres
> > >uptime, a sort of uptime() function could be usefull.
> > >I had recently the necessity of detect a node fail over,
>
Added to TODO:
* Add a function that returns the 'uptime' of the postmaster
---
Alvaro Herrera wrote:
> On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
> > >It seems that there is no way to
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> What about people who are parsing the error messages?
Does anyone really have an application that is looking specifically for
"parse error"? And is going to do something useful when it finds it
that it would not do with an unrecognized error m
On Fri, Aug 20, 2004 at 09:43:13AM +0800, Christopher Kings-Lynne wrote:
> >It seems that there is no way to know the postgres
> >uptime, a sort of uptime() function could be usefull.
> >I had recently the necessity of detect a node fail over,
> >and the only way I can do it with a SQL connection i
At 12:37 PM 20/08/2004, Bruce Momjian wrote:
But that doesn't fix ascii dumps loaded via psql.
It does; the ascii dump file is generated by exactly the same technique as
pg_restore.
Internally, pg_dump builds a TOC, then calls RestoreArchive to dump the
text. It was designed this way for a bunch
On Thu, 19 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Done, and done ... sizes look alot better now:
Almost there, but you didn't pick up my regression test patches :-(
Fixed ...
Also, I still see these in the top directory of the full tarfile:
-rw-r--r-- 1 tgl
Philip Warner wrote:
> At 02:33 AM 20/08/2004, Bruce Momjian wrote:
> > > Could we 'set default tablespace xxx', then have pg_dump/restore use a
> > > 'create table' that does not refer to the tablespace?
> >
> >That is what I was assuming. You can't retroactively change the dump
> >file during re
At 02:33 AM 20/08/2004, Bruce Momjian wrote:
> Could we 'set default tablespace xxx', then have pg_dump/restore use a
> 'create table' that does not refer to the tablespace?
That is what I was assuming. You can't retroactively change the dump
file during restore so we would have some SET varaiable
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detect a node fail over,
and the only way I can do it with a SQL connection is asking
the engine uptime. Of course I can do it with PS but
now that windows versio
If you want to proceed, let me know and I'll commit the updated
regression outputs into the 7.2 branch, and then we can re-wrap.
Let's go with the updated regression outputs ... probably better then
going and reverting down flex/bison just for packaging :(
What about people who are parsing the er
On Thursday 19 August 2004 16:04, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > Let's go with the updated regression outputs ... probably better then
> > going and reverting down flex/bison just for packaging :(
>
> That's what I thought too. Patches committed --- rewrap whe
Andreas Krennmair <[EMAIL PROTECTED]> writes:
> The first fix is that PostgreSQL relies on that, when reading the output
> of postgres -V, all the output can be read with a single read call (or
> whatever call is used, it comes down to read(2) in the end) when called
> from initdb.
Hmm. This is a
Clinging to sanity, [EMAIL PROTECTED] (Shahbaz Javeed) mumbled into her beard:
> # This message was accidentally sent only to Bruce. It's pasted here
> for comment from the rest of the list too :)
>
> Folks,
>
> While on the topic of Ingres and open source, I was wondering
> whether there's intere
> Seems to me you are hacking on way more than you want to. Take another
> look at your design and see if there isn't a smaller design struggling
> to get out. In particular, why are you touching any of the executor
> (which hardly deals in column names at all) rather than implementing the
> alia
Friends,
I would like to know if PostgreSQL can run as a Distributed Data Base
Management System. Is possible, throught PostgreSQL, to implement
horizontal partition, this is, to fragment tables horizontally?
For example, can I have a Data Base with 1 table, where it is
horizontally fragmented a
Christopher Kings-Lynne wrote:
>> Thanks for your response, but this is what I get:
>>
>> column, Type, and Modifiers
>> +
>> Indexes and foreign key contraints.
>> No triggers.
>
> It lists triggers. Trust me, I wrote it.
(Sorry for late response)
Hi Chris,
You wrote it?!?
Ok, in that case I
Hi hackers,
can this be made a TODO?
Thanks
--
Markus Bertheau <[EMAIL PROTECTED]>
--- Begin Message ---
Markus Bertheau wrote:
Hi,
PostgreSQL doesn't allow the creation of a foreign key to a combination
of fields that has got no dedicated unique key but is unique nonetheless
because a subset o
Since I needed this feature badly, I added the -n / --schema switch to
pg_restore. It restores the given schemaname only. It can be used in
conjunction with the -t and other switches to make the selection very
fine grained.
This patches works for me, but it could use more testing.
Please Cc me
* Tom Lane <[EMAIL PROTECTED]> [gmane.comp.db.postgresql.devel.general]:
> Andreas Krennmair <[EMAIL PROTECTED]> writes:
> > creating template1 database in data/base/1 ... FATAL: XX000: failed to
> > initialize lc_monetary to "C"
> > LOCATION: InitializeGUCOptions, guc.c:2337
> > child process e
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Done, and done ... sizes look alot better now:
Almost there, but you didn't pick up my regression test patches :-(
Also, I still see these in the top directory of the full tarfile:
-rw-r--r-- 1 tglusers 70 Aug 19 19:47
postgre
On Thu, 19 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
'k, I'm blind ... build scripts for both 7.2 and 7.3 are identical, except
for which man.tar.gz it pulls in, and what directories in ftp they get
written to ...
Oh, I see the problem. In doc/Makefile, recent versio
Hi all,
It seems that there is no way to know the postgres
uptime, a sort of uptime() function could be usefull.
I had recently the necessity of detect a node fail over,
and the only way I can do it with a SQL connection is asking
the engine uptime. Of course I can do it with PS but
now that window
Tom Lane wrote:
> Oh, I see the problem. In doc/Makefile, recent versions pass the
> "make distclean" operation down to doc/src, but 7.2's doesn't.
> Peter, any idea why it was like that back then?
The doc tree isn't built by default, so I guess no one had ever thought
of cleaning it by default
Josh Berkus wrote:
> Tom,
>
> > Right at the moment my feeling is that there are issues here that are
> > considerably more subtle than we realized, and rather than risk creating
> > unforeseen problems, we ought to bounce the whole issue back to the TODO
> > list for 8.1.
>
> Agreed. I will sub
Simon Riggs wrote:
Joe Conway writes
I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:
When I say aggressive, I mean up to 6 simultaneous COPY processes. It is
different from the issue Tom solved the other day in that we don't
Tom,
> Right at the moment my feeling is that there are issues here that are
> considerably more subtle than we realized, and rather than risk creating
> unforeseen problems, we ought to bounce the whole issue back to the TODO
> list for 8.1.
Agreed. I will submit a new patch that simply adds a
> Joe Conway writes
> I'm seeing the following errors after a few hours of fairly aggressive
> bulk load of a database running on Postgres 7.4.2:
>
> When I say aggressive, I mean up to 6 simultaneous COPY processes. It is
> different from the issue Tom solved the other day in that we don't get
>
Bruce Momjian <[EMAIL PROTECTED]> writes:
> By removing comments from postgresql.conf, I am afraid we are making all
> environment value useless.
Good point.
> I suppose the easiest fix would be to re-command the postgresql.conf
> values that can be over-ridden with environment variables, or make
I had a problem with this patch. By removing the comment from 'port',
the postgresql.conf 'port' value is used in the regression tests rather
than the environment value. I see in guc.c
env = getenv("PGPORT");
if (env != NULL)
SetConfigOption("port", env, PGC_POSTMASTER, PGC_S_EN
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> there, this one looks *much* better ... a couple of k smaller still:
The 7.3.7 tarball looks good to me too. 2 down, 1 to go ...
regards, tom lane
---(end of broadcast)---
TI
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> 'k, I'm blind ... build scripts for both 7.2 and 7.3 are identical, except
> for which man.tar.gz it pulls in, and what directories in ftp they get
> written to ...
Oh, I see the problem. In doc/Makefile, recent versions pass the "make
distclean"
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> The section for docs is:
> cd doc/src
> gmake postgres.tar.gz
> mv postgres.tar.gz ..
> cp /var/spool/ftp/pub/dev/doc/man-7.3.tar.gz ../man.tar.gz
> cd ../..
> gmake split-dist=yes dist
> gmake maintainer-clean
Shouldn't there be a "gmake clean" in
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Let's go with the updated regression outputs ... probably better then
> going and reverting down flex/bison just for packaging :(
That's what I thought too. Patches committed --- rewrap whenever you
have a chance.
regards,
On Thu, 19 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
I just got 7.2.5 done now ... I pulled the man.tar.gz file from 7.2.4 and
put a copy of it into ~ftp/pub/dev/doc/man-7.2.tar.gz (in case its needed
in the future) ...
The 7.2.5 tarball is considerably bigger than 7.
there, this one looks *much* better ... a couple of k smaller still:
%ls -lt postgresql-7.3.7.tar.gz ../v7.3.6/postgresql-7.3.6.tar.gz
-rw-r--r-- 1 pgsql pgsql 11284024 Aug 19 16:27 postgresql-7.3.7.tar.gz
-rw-r--r-- 1 pgsql pgsql 11288430 Mar 4 21:35 ../v7.3.6/postgresql-7.3.6.tar.gz
On Th
On Thu, 19 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
I never got any feedback on v7.3.7's packaging, so I'm guessing that it
looked okay to everyone, even though it was substantially smaller?
I diff'd the 7.3.6 and 7.3.7 tarballs, and got these unexpected
differences:
On Thu, 19 Aug 2004, Tom Lane wrote:
One other little problem with the 7.2.5 package: I see you rebuilt the
flex and bison output files with our current versions of those tools.
I think this is probably okay, but it changes the expected output of
some of the regression tests, eg
*** ./expected/stri
I've just done a re-export of teh CVS for 7.3.7 ... this time,
earthdistance appears to be in there properly ... not sure what happened,
but am building a new package for it, and will check sizes again when
finished ...
On Thu, 19 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]>
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:
cyspec=# select version();
ERROR: root page 43 of "pg_proc_proname_args_nsp_index" has level 0,
expected 2
[ scratches
Joe Conway <[EMAIL PROTECTED]> writes:
> I'm seeing the following errors after a few hours of fairly aggressive
> bulk load of a database running on Postgres 7.4.2:
> cyspec=# select version();
> ERROR: root page 43 of "pg_proc_proname_args_nsp_index" has level 0,
> expected 2
[ scratches head
I'm seeing the following errors after a few hours of fairly aggressive
bulk load of a database running on Postgres 7.4.2:
cyspec=# select version();
ERROR: root page 43 of "pg_proc_proname_args_nsp_index" has level 0,
expected 2
cyspec=# select * from pg_class;
ERROR: root page 3 of "pg_attrib
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
At this stage of the game I would just change pg_hba.conf.sample to use
'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'.
Yeah, that's probably the path of least resistance. Note that the
comments and possibly the SGML docs
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> At this stage of the game I would just change pg_hba.conf.sample to use
> '127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'.
Yeah, that's probably the path of least resistance. Note that the
comments and possibly the SGML docs need to be adjusted
Tom Lane wrote:
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
Bruce Momjian wrote:
Added to open items:
* Fix Solaris for single-host netmasks in pg_hba.conf, use CIDR?
At this stage of the game I would just change pg_hba.conf.sample to use
'127.0.0.1/32' instead of '127.0.0.1 255.255.255.255'. No need for a
Solaris-specific fix for the default setup i
Dear Tom,
> > as many dummy and unknown ... tablespaces
>
> There are any number of ways to find it out --- read the output of
> "pg_restore -s", or just try the restore and observe the errors.
Ok, you're right on this point.
But I'm looking for something cleaner than grepping pg_restore output
Oliver Elphick <[EMAIL PROTECTED]> writes:
> It really isn't necessary to do that. If you are entering commands into
> psql manually, either they are so few that you can easily repeat them,
> using readline editing,
That's what I meant by feeling like I was typing a C program using "cat".
> o
Philip Warner wrote:
> At 12:21 AM 20/08/2004, Tom Lane wrote:
> >You can give it a new paint job in 8.1, if you like.
>
> To side-step the issue, is there a tablespace equivalent of a default schema?
>
> Could we 'set default tablespace xxx', then have pg_dump/restore use a
> 'create table' tha
The good news is that the 7.4.5 package looks right ;-)
regards, tom lane
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
Tom Lane wrote:
> Fabien COELHO <[EMAIL PROTECTED]> writes:
> > Just call that a kludge as it means that the admin is expected to create
> > as many dummy and unknown (if you have a custom dump file)
> > tablespaces
>
> There are any number of ways to find it out --- read the output of
> "pg_resto
One other little problem with the 7.2.5 package: I see you rebuilt the
flex and bison output files with our current versions of those tools.
I think this is probably okay, but it changes the expected output of
some of the regression tests, eg
*** ./expected/strings.out Fri Jun 1 13:49:17 200
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I never got any feedback on v7.3.7's packaging, so I'm guessing that it
> looked okay to everyone, even though it was substantially smaller?
I diff'd the 7.3.6 and 7.3.7 tarballs, and got these unexpected
differences:
Only in postgresql-7.3.6/cont
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I just got 7.2.5 done now ... I pulled the man.tar.gz file from 7.2.4 and
> put a copy of it into ~ftp/pub/dev/doc/man-7.2.tar.gz (in case its needed
> in the future) ...
The 7.2.5 tarball is considerably bigger than 7.2.4; this seems to be
becaus
Nope, and I even checked jdbc to make sure nothing go screwed up with the
moves post-7.3, and its there also ... and 7.2 *appears* to be okay size
wise ...
On Thu, 19 Aug 2004, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
I never got any feedback on v7.3.7's packaging, so I'm g
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I never got any feedback on v7.3.7's packaging, so I'm guessing that it
> looked okay to everyone, even though it was substantially smaller?
Devrim pointed out yesterday that it seemed to be missing
contrib/earthdistance; that's not enough to expla
At 12:21 AM 20/08/2004, Tom Lane wrote:
You can give it a new paint job in 8.1, if you like.
To side-step the issue, is there a tablespace equivalent of a default schema?
Could we 'set default tablespace xxx', then have pg_dump/restore use a
'create table' that does not refer to the tablespace?
-
I never got any feedback on v7.3.7's packaging, so I'm guessing that it
looked okay to everyone, even though it was substantially smaller? The
only two things that I can think of that might have failed appear to be in
there:
%tar tvzpf postgresql-7.3.7.tar.gz | grep man.tar
-rw-r--r-- pgsql/wh
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Just call that a kludge as it means that the admin is expected to create
> as many dummy and unknown (if you have a custom dump file)
> tablespaces
There are any number of ways to find it out --- read the output of
"pg_restore -s", or just try the restor
Hi Every one.
At least I made PITR working however I still have 2 questions:
1) It seems there is a slight bug in this case:
select pg_backup_start('test);
... make backup
select pg_backup_end();
psql database
drp table note the time in logs
pg_ctl stop
rm -rf $PGDATA
restore backup
put the
Magnus Hagander said:
How about an environment variable that points to a .pgpass type file.
>>
>>So let's go woth PGPASSFILE
>
> How about --pwfile on the commandline, the same way initdb does it?
>
Then you can't make it part of libpq - you would have to build it into every
program that need
On Wed, 2004-08-18 at 02:48, Greg Stark wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>
> > This behaviour allows much closer mimicking of Oracle and other RDBMS's
> > transactional behaviour
>
> This is my single biggest pet peeve with Postgres. When I was first
> starting it was the single
Gavin Sherry wrote:
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 instead of a syste
> In point of fact I think this discussion is much ado about nothing, as
> there is already a workaround
Just call that a kludge as it means that the admin is expected to create
as many dummy and unknown (if you have a custom dump file) tablespaces as
necessary to please pg_restore.
These usele
Christopher Kings-Lynne 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 a
Dear Bruce,
> > Bruce - pg_dump TODO for --no-tablespace or something?
>
> Uh, TODO already has:
>
> * 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 m
hi all,
I am porting all my data from oracle to postgres :) . I want
to know where can I put the tables which existed in nulltablespace in
oracle. How is the nullTablespace different from default table space
and how is this done in postgres .
--
"Stand for something, or you will fall for
> > 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.
>
> Yea, I assume if you can't create the tablespace you put everything for
> that tablespace in the d
93 matches
Mail list logo
