On 20.02.2013 16:19, Heikki Linnakangas wrote:
~/pgsql.92stable$ bin/createdb "foo=bar"
~/pgsql.92stable$ bin/pg_dumpall > /dev/null
pg_dump: [archiver (db)] connection to database "(null)" failed: invalid
connection option "foo"
pg_dumpall: pg_dump failed on database "foo=bar", exiting
There ar
Please try to change you cuttent working directory to a place you have
Write-Access before pg_upgrade
As in cd \temp or cd %Home%
Harald
Am 12.10.2010 um 01:09 schrieb Chris English :
> In my attempts I changed all pg_hba.conf (8.4 & 9.0) to trusted, turned off
> firewall,
> followed instruc
On Mon, Oct 11, 2010 at 7:09 PM, Chris English wrote:
> In my attempts I changed all pg_hba.conf (8.4 & 9.0) to trusted, turned off
> firewall,
> followed instructions to shut down db(s) and ran cmd.exe as postgres:
>
> C:\WINDOWS\system32>pg_upgrade.exe -p 5432 -P 5433 -d "c:/program
> files/post
> Date: Mon, 11 Oct 2010 16:15:52 -0700> From: pie...@hogranch.com> To:
> sgl...@hotmail.com> CC: pgsql-bugs@postgresql.org> Subject: Re: [BUGS]
> pg_dumpall -> by hand without --binary-upgrade or BUG #5690: pg_upgrade
> fails> > On 10/11/10 4:09 PM, Chris E
On 10/11/10 4:09 PM, Chris English wrote:
C:\WINDOWS\system32>pg_dumpall.exe --port 5433 username--"postgres"
--schema-onl
y >"c:/windows/system32/pg_upgrade_dump_all.sql"
Access is denied.
why are you writing the .sql output to the windows system32 directory?!?!?
thats a TERRIBLE place t
Thanks Tom.
I've now successfully restored my database. I manually modified the SQL to
include the missing statements. What prompted me to email the list was that
I expected the dump tool to handle the incompatibilities between the
versions automatically. I thought it was a bug that it didn't.
"Shaun Crampton" <[EMAIL PROTECTED]> writes:
> I tried to dump the 7.4.13 database using pg_dumpall from 8.3.1 and restore
> into 8.3.5 on my local test machine. I get the following errors at restore
> time:
> ERROR: missing FROM-clause entry for table "icc_countries"
> LINE 2: ...de, icc_member
Ivan wrote:
Hi,
> Thursday, November 3, 2005, 3:28:41 PM, you wrote:
> >> Perhaps you missed my previous message.
> >> pg_dumpall has not -f command line option
> >> to specify output file - it always send output
> >> to standart output. But there is an issue with
> >> it in Windows (I described
Hello Alvaro,
Thursday, November 3, 2005, 3:28:41 PM, you wrote:
AH> Ivan wrote:
AH> Hi,
>> Perhaps you missed my previous message.
>> pg_dumpall has not -f command line option
>> to specify output file - it always send output
>> to standart output. But there is an issue with
>> it in Windows (
Ivan wrote:
Hi,
> Perhaps you missed my previous message.
> pg_dumpall has not -f command line option
> to specify output file - it always send output
> to standart output. But there is an issue with
> it in Windows (I described it earlier) - function's
> line endings are changed from 0D 0A to 0D
On 2004.11.16 16:25 Tom Lane wrote:
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> I deleted the 'public' schema from my databases
> in 7.3, now in 7.4 they are back.
IMHO this is not a bug. It is not pg_dump's charter to remove
system-created objects...
I can live with this, but I find the implicat
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> It appears as though pg_dumpall is setting the search_path
> runtime variable in the databases before it creates the
> schemas. Further, it appears as though the ALTER
> DATABASE command used to set the search path does
> not have the quotes correct.
T
"Karl O. Pinc" <[EMAIL PROTECTED]> writes:
> I deleted the 'public' schema from my databases
> in 7.3, now in 7.4 they are back.
IMHO this is not a bug. It is not pg_dump's charter to remove
system-created objects...
regards, tom lane
---(end of b
Tom Lane <[EMAIL PROTECTED]> writes:
> Neil Conway <[EMAIL PROTECTED]> writes:
>> If not, we needn't worry about it, IMHO. But if there are, I can
>> take a look at producing a low-risk version of this changed for
>> application to REL7_3_STABLE.
>
> Go for it.
Just FYI, I'm really busy with vario
Neil Conway <[EMAIL PROTECTED]> writes:
> Are there plans for a 7.3.5 release?
Yes, I think there will be a 7.3.5 fairly soon.
> If not, we needn't worry about
> it, IMHO. But if there are, I can take a look at producing a low-risk
> version of this changed for application to REL7_3_STABLE.
Go f
Tom Lane <[EMAIL PROTECTED]> writes:
> Well, it was done as part of a significant set of changes to
> pg_dumpall:
Are there plans for a 7.3.5 release? If not, we needn't worry about
it, IMHO. But if there are, I can take a look at producing a low-risk
version of this changed for application to REL
Neil Conway <[EMAIL PROTECTED]> writes:
> Is this a candidate for being back-patched to 7_3_STABLE? IMHO it
> would be useful and low-risk.
Well, it was done as part of a significant set of changes to pg_dumpall:
2003-05-30 18:55 tgl
* src/bin/pg_dump/: dumputils.c, dumputils.h, pg_dump
Tom Lane <[EMAIL PROTECTED]> writes:
> Paul Tillotson <[EMAIL PROTECTED]> writes:
>> pg_dumpall does not save all access control permissions on a database.
>> (This is true for at least the CREATE permission.)
>
> This is fixed as of 7.4.
Is this a candidate for being back-patched to 7_3_STABLE? I
Paul Tillotson <[EMAIL PROTECTED]> writes:
> pg_dumpall does not save all access control permissions on a database.
> (This is true for at least the CREATE permission.)
This is fixed as of 7.4.
regards, tom lane
---(end of broadcast)---
This is fixed in 7.4.X and in fact 7.4 pg_dumpall will work on a 7.3.X
database.
---
Paul Tillotson wrote:
>
> POSTGRESQL
ozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130
>X-Accept-Language: en-us, en
>MIME-Version: 1.0
>To: Serge Obeuf <[EMAIL PROTECTED]>
>Cc: [EMAIL PROTECTED]
>Subject: Re: [BUGS] pg_dumpall not working in batch
>Content-Transfer-Encoding: 7bit
>
You must have some environment setting (like LD_LIBRARY_PATH?) in your
.login or .bashrc (or whatever shell you are using), that tells psql
where to find that library. When you run it via cron, that environment
isn't being set and causes it to fail.
I hope, it helps...
Dima
Serge Obeuf wrot
On Thu, 12 Jun 2003, Serge Obeuf wrote:
> Hi all.
>
> I recently posted here some questions about pg_dumpall (7.2) on solaris8.
> Investigating, I reduce my problem cases.
>
> When I plan by crontab 'pg_dumpall > dball.sql', I receive this error
> connected to template1...
> ld.so.1: /usr/local/
Ahh... as a matter of fact I do. Adding someone to this empty group
corrects the problem.
Thanks!
Nick
On Fri, Mar 14, 2003 at 05:32:42PM -0500, Tom Lane wrote:
> Nick Eskelinen <[EMAIL PROTECTED]> writes:
> > pg_dumpall segfaults when trying to dump group information.
>
> Hmm, you have any empt
Nick Eskelinen <[EMAIL PROTECTED]> writes:
> Ahh... as a matter of fact I do. Adding someone to this empty group
> corrects the problem.
Thought so. I've committed a fix if you need it:
*** src/bin/pg_dump/pg_dumpall.c.orig Thu Mar 6 16:45:52 2003
--- src/bin/pg_dump/pg_dumpall.cFri M
Nick Eskelinen <[EMAIL PROTECTED]> writes:
> pg_dumpall segfaults when trying to dump group information.
Hmm, you have any empty (member-less) groups? Looks like this loop
needs a test at the top not the bottom ...
regards, tom lane
---(end of bro
On Thu, 6 Mar 2003, Tom Lane wrote:
> "Dan Langille" <[EMAIL PROTECTED]> writes:
> > $ pg_dumpall --globals_only
> > pg_dumpall: unrecognized option `--globals_only'
>
> There seems to be a bit of a disconnect between the code, the usage
> message, and the long_options table in pg_dumpall :-(. I'
On Thu, 2003-03-06 at 19:25, Dan Langille wrote:
> Hi folks...
>
> Can anyone else confirm this on 7.3.2?
>
> $ pg_dumpall --globals_only
In fact it should be "globals-only" (hyphen, not underscore), but even
when spelt correctly it doesn't work.
> pg_dumpall: unrecognized option `--globals_onl
"Dan Langille" <[EMAIL PROTECTED]> writes:
> $ pg_dumpall --globals_only
> pg_dumpall: unrecognized option `--globals_only'
Looks like it's just a one-liner oversight. I'm not sure whether -g
will work on your platform; if not, use the attached patch.
regards, tom lane
*
"Dan Langille" <[EMAIL PROTECTED]> writes:
> $ pg_dumpall --globals_only
> pg_dumpall: unrecognized option `--globals_only'
There seems to be a bit of a disconnect between the code, the usage
message, and the long_options table in pg_dumpall :-(. I'll see
about cleaning it up, but in the meantime
Andrew Kohlsmith wrote:
> > > Is there a particular reason why plain text is forced?
> > Because pg_dumpall is producing a script file.
> > This is obviously not optimal, but it's not very clear how to do better.
>
> Agreed. :-)
>
> I notice that pg_dumpall just uses a query to grab a list of d
> > Or is that on the TODO for whenever foreign keys can be across databases?
> I very seriously doubt that PG will *ever* support foreign keys across
> databases.
No problem. I'm not that advanced of a user or admin to want it, I was just
trying to peer into the crystal ball and try to anticip
> > Is there a particular reason why plain text is forced?
> Because pg_dumpall is producing a script file.
> This is obviously not optimal, but it's not very clear how to do better.
Agreed. :-)
I notice that pg_dumpall just uses a query to grab a list of databases and
some information about t
grant wrote:
> You could fake some of this (select only) by using the dblink stuff in
> contrib. You could link back to yourself and make it work. Maybe if
> you REALLY need it, you could modify dblink to allow updates as well as
> selects. If you really need it that bad, you have the sourc
You could fake some of this (select only) by using the dblink stuff in
contrib. You could link back to yourself and make it work. Maybe if
you REALLY need it, you could modify dblink to allow updates as well as
selects. If you really need it that bad, you have the source, write it.
--
Andrew Kohlsmith <[EMAIL PROTECTED]> writes:
> Is there a way to start a transaction at the start of
> the dump and hold it throughout successive connections, finally releasing it
> at the end?
No, and since one backend can only talk to one database, I don't foresee
that changing.
> Or is that
Andrew Kohlsmith <[EMAIL PROTECTED]> writes:
> Is there a particular reason why plain text is forced?
Because pg_dumpall is producing a script file.
This is obviously not optimal, but it's not very clear how to do better.
regards, tom lane
---(en
Without showing the database being dumped, the entire output of
pg_dumpall seems pretty useless so you may as well pipe the whole output
to /dev/null. I don't think a quiet feature for pg_dumpall has enough
use for ordinary users. Sorry.
-
"karthikeyan V" <[EMAIL PROTECTED]> writes:
> "failed sanity check, table user_details was not found
> pg_dump failed on users, exiting"
Probably, you deleted the pg_shadow entry for the user that owned this
table. 7.1's pg_dump is somewhat smarter about this sort of situation,
but in older vers
> pg_dumpall -h looks up database names locally.
True. You will find this fixed in 7.1.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Applied. I should have realized I was using the username to look up the
username.
-- Start of PGP signed section.
> it seems in the beta2 release DBUSERID in pg_dumpall is the _name_ of the
> user, so it doesn't need to be translated from the number to the name.
>
> also ``create database ...''
lt;[EMAIL PROTECTED]>
> Gesendet: Donnerstag, 9. März 2000 20:17
> Betreff: Re: [BUGS] pg_dumpall
>
>
> Kardos, Dr. Andreas writes:
>
> > I have tested the pg_dumpall (with PATHNAME stuff) which Peter E. has
> mailed
> > to this list.
> >
> > It wo
Eisentraut <[EMAIL PROTECTED]>
An: Kardos, Dr. Andreas <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Gesendet: Donnerstag, 9. März 2000 20:17
Betreff: Re: [BUGS] pg_dumpall
Kardos, Dr. Andreas writes:
> I have tested the pg_dumpall (with PATHNAME stuff) which Peter E. has
Kardos, Dr. Andreas writes:
> I have tested the pg_dumpall (with PATHNAME stuff) which Peter E. has mailed
> to this list.
>
> It works fine on QNX4 but definitly not on Digital Unix.
>
> The version in CVS works in general, but not on QNX4. On QNX4 I have to
> remove the escape backslashes.
O
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
> Bruce Momjian writes:
>
> > > > 3. QNX4 only: The double quotes in
> > > >
> > > > POSTGRES_USER="`echo \" \
> > > >
> > > > etc. must not be escaped with a backslash.
> > >
> > > Technically, it should just work without them (the back
Nachricht-
Von: Peter Eisentraut <[EMAIL PROTECTED]>
An: Kardos, Dr. Andreas <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Gesendet: Donnerstag, 9. März 2000 01:38
Betreff: Re: [BUGS] pg_dumpall
Kardos, Dr. Andreas writes:
> 2. FOO="`echo "$BAR"`"
>
&
46 matches
Mail list logo
