Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

thank you. it listens to the local network, which are my two other MacBooks. I reported the bug to DaVinci. Hopefully the have a fix then I can put it back on md5. thank you for your script. will try it. best Robert > On 13 Nov 2016, at 23:27, John R Pierce wrote: > >

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

Thank you, I understand. Nobody else can access the database. As the database backup button in DaVinci started to work I could understand that DaVinci is only making pg_dump of the database. The restore works fine from any DaVinci installation to another one. I tested this. I still can make a

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

On 11/13/2016 01:01 PM, aws backup wrote: Hi, thank you so much. With your help I could solve all my problems. DaVinci has a bug somewhere with the database configuration. I installed everything new and set all auth method to trust instead of md5 which was default from DaVinci. Just remember

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

On 11/13/2016 8:51 AM, aws backup wrote: I assume that the postgres database password is the one which is shown in the DaVinci connect database window. user: postgres password: DaVinci there are no database passwords, thats the password for the postgres database role/user. But if I work

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

Hi Adrian, thank you for the explanation. I will look into you links. I am doing this because I want to make backups from the database. Ideally automatic backups every night. The Blackmagic support says they can't help me with this. The Backup and Restore button in DaVinci does not work. Every

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

On 11/13/2016 05:51 AM, aws backup wrote: Hi, now I have another problem. Sorry I am an absolute beginner. When I restore the dumpall backup with "psql -f infile postgres" I get lot of errors > "already exists" and the database is not restored to the point of the backup. Yes, because it

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

Hi, now I have another problem. Sorry I am an absolute beginner. When I restore the dumpall backup with "psql -f infile postgres" I get lot of errors > "already exists" and the database is not restored to the point of the backup. I mean after I made the backup I changed something and I

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

Hi Adrian, thank you for the answer. There is one password for the postgres database and one for the postgres user. Both are not working somehow. Is there a way to look up the passwords? I saw in the documentation that there is a .pgpass file. But I can't find it. I changed the auth method to

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

On Sat, Nov 12, 2016 at 2:31 PM, Adrian Klaver wrote: > On 11/12/2016 01:20 PM, aws backup wrote: >> >> Hi, >> >> I try to make pg_dumpall backups from a PostgreSQL 9.5 server which is >> part of the DaVinci Resolve 12.5.3 App on a Mac OS X 10.11.6 system. >> >>

Re: [GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

On 11/12/2016 01:20 PM, aws backup wrote: Hi, I try to make pg_dumpall backups from a PostgreSQL 9.5 server which is part of the DaVinci Resolve 12.5.3 App on a Mac OS X 10.11.6 system. Unfortunately I get following failure message: pg_dumpall: could not connect to database "template1":

[GENERAL] pg_dumpall: could not connect to database "template1": FATAL:

Hi, I try to make pg_dumpall backups from a PostgreSQL 9.5 server which is part of the DaVinci Resolve 12.5.3 App on a Mac OS X 10.11.6 system. Unfortunately I get following failure message: pg_dumpall: could not connect to database "template1": FATAL: password authentication failed for user

Re: [GENERAL] pg_dumpall from a script

You could write a plperlul function that runs a shell script to back up your database, you can even pass it parameters and put a call to that in a trigger. BUT, this could result in multiple backups running at the same time and become a performance drag. -- Mike Nolan On Tue, Oct 22, 2013 at

Re: [GENERAL] pg_dumpall from a script

Hi James, i wanna share with you a script that i use, i scheduled it with crontab. It generates a backup for each database. After that, there is another script scheduled that copies the backups to another server. #! /bin/bash TIEMPO=$(date '+%d%m%Y_%H%M%S')

Re: [GENERAL] pg_dumpall from a script

On Tue, Oct 22, 2013 at 10:50 AM, James Sewell james.sew...@lisasoft.comwrote: That looks great, but it doesn't really help with my problem unless I'm missing something (very possible!) I need a way to backup either from SQL in PSQL (possibly \!) or from a PG/PLSQL function to a file with a

Re: [GENERAL] pg_dumpall from a script

On Tue, Oct 22, 2013 at 1:20 AM, James Sewell james.sew...@lisasoft.comwrote: That looks great, but it doesn't really help with my problem unless I'm missing something (very possible!) I need a way to backup either from SQL in PSQL (possibly \!) or from a PG/PLSQL function to a file with a

Re: [GENERAL] pg_dumpall from a script

On Tue, Oct 22, 2013 at 7:20 AM, James Sewell james.sew...@lisasoft.com wrote: I need a way to backup either from SQL in PSQL (possibly \!) or from a PG/PLSQL function to a file with a name set from a :variable. Could it be something like this: # \setenv myFile 'filename' # \! pg_dump

Re: [GENERAL] pg_dumpall from a script

On 10/21/2013 11:41 PM, Luca Ferrari wrote: On Tue, Oct 22, 2013 at 7:20 AM, James Sewell james.sew...@lisasoft.com wrote: I need a way to backup either from SQL in PSQL (possibly \!) or from a PG/PLSQL function to a file with a name set from a :variable. Could it be something like this: #

Re: [GENERAL] pg_dumpall from a script

On 10/21/2013 10:20 PM, James Sewell wrote: That looks great, but it doesn't really help with my problem unless I'm missing something (very possible!) I need a way to backup either from SQL in PSQL (possibly \!) or from a PG/PLSQL function to a file with a name set from a :variable. This

Re: [GENERAL] pg_dumpall from a script

Hello All, Thanks for the replies.Sorry I must have been a bit unclear, I realise I *could* do this from the shell level, but can I do it from a PSQL session somehow? I think the answer is no (I assume unless I write my own C function or similar). It seems there is no way of passing a :variable

Re: [GENERAL] pg_dumpall from a script

On 10/22/2013 03:41 PM, James Sewell wrote: Hello All, Thanks for the replies.Sorry I must have been a bit unclear, I realise I *could* do this from the shell level, but can I do it from a PSQL session somehow? Lucas' \setenv method won't work for you? Cheers, James Sewell, PostgreSQL

Re: [GENERAL] pg_dumpall from a script

Oh I missed that, I skimmed and thought it was the same as \set Turns out it's not and it's exactly what I want! Thanks! James Sewell, PostgreSQL Team Lead / Solutions Architect __ Level 2, 50 Queen St, Melbourne VIC 3000 *P *(+61) 3 8370 8000 * **W*

[GENERAL] pg_dumpall from a script

Hello, I need to trigger a database dump from a SQL script (or function, but I think that is even less likely). I know I can do: \! pg_dumpall /mydir/myfile Which is fine, but I need to use a variable to set the name. \set myfile 'filename' \! pg_dumpall /mydir/:myfile Doesn't seem to

Re: [GENERAL] pg_dumpall from a script

On Tue, Oct 22, 2013 at 8:07 AM, James Sewell james.sew...@lisasoft.comwrote: Hello, I need to trigger a database dump from a SQL script (or function, but I think that is even less likely). I know I can do: \! pg_dumpall /mydir/myfile Which is fine, but I need to use a variable to set

Re: [GENERAL] pg_dumpall from a script

That looks great, but it doesn't really help with my problem unless I'm missing something (very possible!) I need a way to backup either from SQL in PSQL (possibly \!) or from a PG/PLSQL function to a file with a name set from a :variable. This would be triggered by a certain action in the

Re: [GENERAL] pg_dumpall custom format?

On Wed, 2011-06-22 at 16:17 +0100, Thom Brown wrote: On 13 May 2010 18:28, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 19:24, Thom Brown a écrit : On 13 May 2010 17:49, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 14:12, Thom Brown a écrit : On 5 March

Re: [GENERAL] pg_dumpall custom format?

On 13 May 2010 18:28, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 19:24, Thom Brown a écrit : On 13 May 2010 17:49, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 14:12, Thom Brown a écrit : On 5 March 2009 12:08, Thom Brown thombr...@gmail.com wrote: [...]

Re: [GENERAL] pg_dumpall behavior in 9.1beta1

oops! sorry for the noise it was an innocuous 'NOTICE' not ERROR as claimed. thanks for your time. regds mallah. On Fri, May 13, 2011 at 7:59 PM, Tom Lane t...@sss.pgh.pa.us wrote: Rajesh Kumar Mallah mallah.raj...@gmail.com writes: We migrated to 9.1beta1 from 9.0.x in our development

[GENERAL] pg_dumpall behavior in 9.1beta1

Dear List , We migrated to 9.1beta1 from 9.0.x in our development environment. we shall report if any significant problems or issue arises out of this. one small thing that we observed rite now regarding pg_dumpall output is that the ALTER USER is referring to some db objects which are not

Re: [GENERAL] pg_dumpall behavior in 9.1beta1

Rajesh Kumar Mallah mallah.raj...@gmail.com writes: We migrated to 9.1beta1 from 9.0.x in our development environment. we shall report if any significant problems or issue arises out of this. one small thing that we observed rite now regarding pg_dumpall output is that the ALTER USER is

[GENERAL] pg_dumpall backup script w. ftp ; pgpass file ; after upgrade to Ubuntu 10.4 (lucid) and Postgresql 9.0.2

After a year I have restarted work on a project using Postgresql. The database I created was in Postgresql 8.2.5. I updated my database server from Ubuntu 7.10 to 10.4 (lucid) and installed Postgresql 9.0.2 The Postgresql install went fine and the restore from my previous pg_dumpall went fine but

Re: [GENERAL] pg_dumpall backup script w. ftp ; pgpass file ; after upgrade to Ubuntu 10.4 (lucid) and Postgresql 9.0.2

On 01/21/11 11:07 AM, margaretgil...@chromalloy.com wrote: After a year I have restarted work on a project using Postgresql. The database I created was in Postgresql 8.2.5. I updated my database server from Ubuntu 7.10 to 10.4 (lucid) and installed Postgresql 9.0.2 The Postgresql install went

Re: [GENERAL] pg_dumpall backup script w. ftp ; pgpass file ; after upgrade to Ubuntu 10.4 (lucid) and Postgresql 9.0.2

FATAL:Identauthenticationfailedforuser"engineering"thatsaysitrightthere.yourLOCALauthenticationtypeissettoIDENTinyourpg_hba.conffile.That was it. I have updated my install documentation. Thank you, MargaretThis e-mail message and any attachment(s) are for the sole use of the intended recipient(s)

Re: [GENERAL] pg_dumpall custom format?

On 13 May 2010 18:28, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 19:24, Thom Brown a écrit : On 13 May 2010 17:49, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 14:12, Thom Brown a écrit : On 5 March 2009 12:08, Thom Brown thombr...@gmail.com wrote:

Re: [GENERAL] pg_dumpall custom format?

Le 17/05/2010 14:28, Thom Brown a écrit : On 13 May 2010 18:28, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 19:24, Thom Brown a écrit : On 13 May 2010 17:49, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 14:12, Thom Brown a écrit : On 5 March 2009 12:08,

Re: [GENERAL] pg_dumpall for Postgres Database Daily Backup

On Thursday 13 May 2010 17.50:31 Wang, Mary Y wrote: http://www.postgresql.org/docs/8.3/static/backup-dump.html#BACKUP-DUMP-A LL (I only found the documentation for 8.3.10), and it looks like pg_dumpall outfile is the best choice. pg_dumpall or by-database pg_dump ha the advantage that it is

Re: [GENERAL] pg_dumpall for Postgres Database Daily Backup

On 16/05/2010 16:59, Adrian von Bidder wrote: * pint in time recovery This is what happens *after* work - this side of the pond, anyway :-) Ray. -- Raymond O'Donnell :: Galway :: Ireland r...@iol.ie -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes

Re: [GENERAL] pg_dumpall for Postgres Database Daily Backup?

On Thu, 2010-05-13 at 09:15 -0700, Wang, Mary Y wrote: By reading the documentation over here: http://www.postgresql.org/docs/8.3/static/backup-dump.html#BACKUP-DUMP-ALL (I only found the documentation for 8.3.10), If you replace 8.3 with current, you will get the current docs. and it

Re: [GENERAL] pg_dumpall for Postgres Database Daily Backup

On Thu, May 13, 2010 at 8:16 PM, Scott Marlowe scott.marl...@gmail.comwrote: On Thu, May 13, 2010 at 9:50 AM, Wang, Mary Y mary.y.w...@boeing.com wrote: Hi, I'm running on Postgres 8.3.8. My system admin is ready to set up a cron job for a daily database backup. By reading the

Re: [GENERAL] pg_dumpall custom format?

...@postgresql.org [mailto: pgsql-general-ow...@postgresql.org] *On Behalf Of *Thom Brown *Sent:* Thursday, March 05, 2009 11:53 AM *To:* pgsql general *Subject:* [GENERAL] pg_dumpall custom format? Hi, I noticed that while pg_dump can output a custom format, effectively compressing the output

[GENERAL] pg_dumpall for Postgres Database Daily Backup

Hi, I'm running on Postgres 8.3.8. My system admin is ready to set up a cron job for a daily database backup. By reading the documentation over here: http://www.postgresql.org/docs/8.3/static/backup-dump.html#BACKUP-DUMP-ALL (I only found the documentation for 8.3.10), and it looks like

[GENERAL] pg_dumpall for Postgres Database Daily Backup?

Hi, I'm running on Postgres 8.3.8. My system admin is ready to set up a cron job for a daily database backup. By reading the documentation over here: http://www.postgresql.org/docs/8.3/static/backup-dump.html#BACKUP-DUMP-ALL (I only found the documentation for 8.3.10), and it looks like

Re: [GENERAL] pg_dumpall custom format?

Le 13/05/2010 14:12, Thom Brown a écrit : On 5 March 2009 12:08, Thom Brown thombr...@gmail.com wrote: [...] I'm bringing this thread back to life to see if there are any further thoughts on this. It would be nice to have a complete backup of a database cluster in custom format, and use

Re: [GENERAL] pg_dumpall for Postgres Database Daily Backup?

On Thu, 2010-05-13 at 09:15 -0700, Wang, Mary Y wrote: Hi, I'm running on Postgres 8.3.8. My system admin is ready to set up a cron job for a daily database backup. By reading the documentation over here: http://www.postgresql.org/docs/8.3/static/backup-dump.html#BACKUP-DUMP-ALL (I

Re: [GENERAL] pg_dumpall custom format?

On 13 May 2010 17:49, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 14:12, Thom Brown a écrit : On 5 March 2009 12:08, Thom Brown thombr...@gmail.com wrote: [...] I'm bringing this thread back to life to see if there are any further thoughts on this. It would be nice to

Re: [GENERAL] pg_dumpall custom format?

Le 13/05/2010 19:24, Thom Brown a écrit : On 13 May 2010 17:49, Guillaume Lelarge guilla...@lelarge.info wrote: Le 13/05/2010 14:12, Thom Brown a écrit : On 5 March 2009 12:08, Thom Brown thombr...@gmail.com wrote: [...] I'm bringing this thread back to life to see if there are any further

Re: [GENERAL] pg_dumpall for Postgres Database Daily Backup

On Thu, May 13, 2010 at 11:50 AM, Wang, Mary Y mary.y.w...@boeing.com wrote: it looks like pg_dumpall outfile is the best choice.  I'd like to ask the community to reconfirm. We do an individual pg_dump on each DB separately, using the '-Fc' format. The only thing we miss from pg_dumpall we

Re: [GENERAL] pg_dumpall for Postgres Database Daily Backup

On Thu, May 13, 2010 at 9:50 AM, Wang, Mary Y mary.y.w...@boeing.com wrote: Hi, I'm running on Postgres 8.3.8.  My system admin is ready to set up a cron job for a daily database backup. By reading the documentation over here:

Re: [GENERAL] pg_dumpall asking for password for each database

What version are you running? IIRC it should remember the password between databases. 8.4.0 on Linux/x86_64. It does not, and man page clearly says: pg_dumpall needs to connect several times to the PostgreSQL server (once per database). If you use password authentication it will

[GENERAL] pg_dumpall asking for password for each database

Hi, is it possible to force pg_dumpall to ask for password only once (connecting as superuser 'postgres') ? Entering it for every database is a bit annoying. Thanks, Krzysztof -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription:

Re: [GENERAL] pg_dumpall asking for password for each database

2009/10/6 Krzysztof Barlik kbar...@wp.pl Hi, is it possible to force pg_dumpall to ask for password only once (connecting as superuser 'postgres') ? Entering it for every database is a bit annoying. Kind of, you'll either use an environment variable:

Re: [GENERAL] pg_dumpall asking for password for each database

On Tue, 2009-10-06 at 22:59 +0200, Krzysztof Barlik wrote: Hi, is it possible to force pg_dumpall to ask for password only once (connecting as superuser 'postgres') ? Entering it for every database is a bit annoying. take a look at .pgpass documentation Thanks, Krzysztof --

Re: [GENERAL] pg_dumpall asking for password for each database

Krzysztof Barlik wrote: Hi, is it possible to force pg_dumpall to ask for password only once (connecting as superuser 'postgres') ? Entering it for every database is a bit annoying. What version are you running? IIRC it should remember the password between databases. -- Alvaro Herrera

[GENERAL] pg_dumpall custom format?

Hi, I noticed that while pg_dump can output a custom format, effectively compressing the output, pg_dumpall doesn't. Is there a reason for this? And is there a way to get pg_dumpall to compress it's output? Thanks Thom

Re: [GENERAL] pg_dumpall custom format?

Of *Thom Brown *Sent:* Thursday, March 05, 2009 11:53 AM *To:* pgsql general *Subject:* [GENERAL] pg_dumpall custom format? Hi, I noticed that while pg_dump can output a custom format, effectively compressing the output, pg_dumpall doesn't. Is there a reason for this? And is there a way to get

Re: [GENERAL] pg_dumpall custom format?

-ow...@postgresql.org] On Behalf Of Thom Brown Sent: Thursday, March 05, 2009 11:53 AM To: pgsql general Subject: [GENERAL] pg_dumpall custom format? Hi, I noticed that while pg_dump can output a custom format, effectively compressing the output, pg_dumpall doesn't. Is there a reason

Re: [GENERAL] pg_dumpall problem when roles have default schemas

[EMAIL PROTECTED] wrote: I've run into a problem while migrating an existing 8.2.7 data base to a new server running 8.3.3 (although I think the version numbers may not matter -- I think I've seen this problem in the past and just lived with it since so much of Postgresql is so great!). The

[GENERAL] pg_dumpall problem when roles have default schemas

I've run into a problem while migrating an existing 8.2.7 data base to a new server running 8.3.3 (although I think the version numbers may not matter -- I think I've seen this problem in the past and just lived with it since so much of Postgresql is so great!). The problem stems from the fact

[GENERAL] pg_dumpall problem when roles have default schemas

I've run into a problem while migrating an existing 8.2.7 data base to a new server running 8.3.3 (although I think the version numbers may not matter -- I think I've seen this problem in the past and just lived with it since so much of Postgresql is so great!). The problem stems from the

Re: [GENERAL] pg_dumpall problem when roles have default schemas

Tom Lane wrote: [EMAIL PROTECTED] writes: Thus, when piping the output (from legacy host 192.168.2.2) to populate the newly initialized cluster, by way of running (on the new host 192.168.2.3) pg_dumpall -h 192.168.2.2|psql an error occurs in that first section when the script

Re: [GENERAL] pg_dumpall problem when roles have default schemas

Tom Lane wrote: [EMAIL PROTECTED] writes: Thus, when piping the output (from legacy host 192.168.2.2) to populate the newly initialized cluster, by way of running (on the new host 192.168.2.3) pg_dumpall -h 192.168.2.2|psql an error occurs in that first section when the

[GENERAL] pg_dumpall problem when roles have default schemas

I've run into a problem while migrating an existing 8.2.7 data base to a new server running 8.3.3 (although I think the version numbers may not matter -- I think I've seen this problem in the past and just lived with it since so much of Postgresql is so great!). The problem stems from the

Re: [GENERAL] pg_dumpall problem when roles have default schemas

[EMAIL PROTECTED] writes: Thus, when piping the output (from legacy host 192.168.2.2) to populate the newly initialized cluster, by way of running (on the new host 192.168.2.3) pg_dumpall -h 192.168.2.2|psql an error occurs in that first section when the script attempts to set a

Re: [GENERAL] pg_dumpall: pg_conversion table not saved

Tom Lane schrieb: Michael Enke [EMAIL PROTECTED] writes: I updated pg_converion to set the condefault=false where I need it. Why are you needing to replace an existing default conversion? Do we have a bug in it? No, not a bug. But I need CP852 encoding conversion. Maybe you can take a look

[GENERAL] pg_dumpall: pg_conversion table not saved

Hi list, I updated pg_converion to set the condefault=false where I need it. pg_dumpall does NOT write that table out and therefore it is not possible to restore, this update get lost. Anybody know if this is an error or has an explanation why it has to work this way? Background: I have

Re: [GENERAL] pg_dumpall: pg_conversion table not saved

Michael Enke [EMAIL PROTECTED] writes: I updated pg_converion to set the condefault=false where I need it. Why are you needing to replace an existing default conversion? Do we have a bug in it? pg_dumpall does NOT write that table out and therefore it is not possible to restore, this update

Re: [GENERAL] pg_dumpall: pg_conversion table not saved

On Wed, May 07, 2008 at 05:38:12PM -0400, Tom Lane wrote: Michael Enke [EMAIL PROTECTED] writes: I updated pg_converion to set the condefault=false where I need it. Why are you needing to replace an existing default conversion? Do we have a bug in it? He doesn't really. See his message two

Re: [GENERAL] pg_dumpall

On Friday 18 January 2008 14:38, Steve Clark wrote: Thanks for everyone that replied to my query about pg_dumpall. Now another question/issue - anytime I usr createdb the resulting db ends up with UTF-8 encoding unless I use the -E switch. Is there a way to make the default be sql_ascii?

Re: [GENERAL] pg_dumpall

Erik Jones wrote: On Jan 17, 2008, at 1:08 PM, Greg Smith wrote: On Thu, 17 Jan 2008, Tom Lane wrote: There isn't any good way to guarantee time coherence of dumps across two databases. Whether there's a good way depends on what you're already doing. If you're going to the trouble of

[GENERAL] pg_dumpall

Hello List, the man page for pg_dump say: pg_dump is a utility for backing up a PostgreSQL database. It makes consistent backups even if the database is being used concurrently. does pg_dumpall make consistent backups if the database is being used concurrently? Even though

Re: [GENERAL] pg_dumpall

On Thu, Jan 17, 2008 at 11:14:22AM -0800, Glyn Astill wrote: begin; set transaction isolation level serializable; --- begin dumping stuff; Wouldn't that just lock everything so nothing could be updated? Or just the table it is outputting? PostgreSQL uses MVCC, which means the

Re: [GENERAL] pg_dumpall

Alvaro Herrera [EMAIL PROTECTED] wrote: Glyn Astill wrote: Out of interest, how does pg_dump manage to do a snapshot of a database at an instant in time? My mental picture of pg_dump was just a series of queries dumping out the tables... begin; set transaction isolation level

Re: [GENERAL] pg_dumpall

On Thu, 17 Jan 2008, Tom Lane wrote: There isn't any good way to guarantee time coherence of dumps across two databases. Whether there's a good way depends on what you're already doing. If you're going to the trouble of making a backup using PITR anyway, it's not hard to stop applying new

Re: [GENERAL] pg_dumpall

Out of interest, how does pg_dump manage to do a snapshot of a database at an instant in time? My mental picture of pg_dump was just a series of queries dumping out the tables... --- Tom Lane [EMAIL PROTECTED] wrote: Steve Clark [EMAIL PROTECTED] writes: does pg_dumpall make consistent

Re: [GENERAL] pg_dumpall

Tom Lane wrote: Steve Clark [EMAIL PROTECTED] writes: does pg_dumpall make consistent backups if the database is being used concurrently? Even though the man page doesn't say it does. That's intentional, because it doesn't. What you get is a pg_dump snapshot of each database in

Re: [GENERAL] pg_dumpall

Steve Clark [EMAIL PROTECTED] writes: does pg_dumpall make consistent backups if the database is being used concurrently? Even though the man page doesn't say it does. That's intentional, because it doesn't. What you get is a pg_dump snapshot of each database in sequence; those snapshots

Re: [GENERAL] pg_dumpall

On Jan 17, 2008, at 1:08 PM, Greg Smith wrote: On Thu, 17 Jan 2008, Tom Lane wrote: There isn't any good way to guarantee time coherence of dumps across two databases. Whether there's a good way depends on what you're already doing. If you're going to the trouble of making a backup

Re: [GENERAL] pg_dumpall

Glyn Astill wrote: Out of interest, how does pg_dump manage to do a snapshot of a database at an instant in time? My mental picture of pg_dump was just a series of queries dumping out the tables... begin; set transaction isolation level serializable; --- begin dumping stuff; -- Alvaro

Re: [GENERAL] pg_dumpall

Alvaro Herrera [EMAIL PROTECTED] writes: Tom Lane wrote: That's intentional, because it doesn't. What you get is a pg_dump snapshot of each database in sequence; those snapshots don't all correspond to the same time instant. There isn't any good way to guarantee time coherence of dumps

[GENERAL] pg_dumpall and authentication

I'm sure you guys have heard this about 100 times, and I've done some research on Google and found out some things, but I still have a couple questions. As I'm sure you may have guessed from the subject, I'm trying to schedule (under windows) pg_dumpall to run each night/morning/full

Re: [GENERAL] pg_dumpall and authentication

On Nov 9, 2007, at 8:52 AM, Tom Hart wrote: I'm sure you guys have heard this about 100 times, and I've done some research on Google and found out some things, but I still have a couple questions. As I'm sure you may have guessed from the subject, I'm trying to schedule (under windows)

Re: [GENERAL] pg_dumpall and authentication

Steve Atkins wrote: On Nov 9, 2007, at 8:52 AM, Tom Hart wrote: I'm sure you guys have heard this about 100 times, and I've done some research on Google and found out some things, but I still have a couple questions. As I'm sure you may have guessed from the subject, I'm trying to

[GENERAL] pg_dumpall to psql -f NOT working

Hello. I performed a pg_dumpall of my 8.1 db cluster and upgraded to 8.2.4. the dump went fine and the script file appears to be fine. I have a mixture of UTF8 and SQL_ASCII databases in the dump. However I am not able to restore my data after the upgrade. I performed from the command line

Re: [GENERAL] pg_dumpall to psql -f NOT working

2007/8/12, Ketema [EMAIL PROTECTED]: Hello. I performed a pg_dumpall of my 8.1 db cluster and upgraded to 8.2.4. the dump went fine and the script file appears to be fine. I have a mixture of UTF8 and SQL_ASCII databases in the dump. However I am not able to restore my data after the

Re: [GENERAL] pg_dumpall and version confusion

--- Original Message --- From: Joshua D. Drake [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 15/03/07, 23:51:18 Subject: Re: [GENERAL] pg_dumpall and version confusion If you want that, create a wrapper program that calls to different statically compiled versions

Re: [GENERAL] pg_dumpall and version confusion

Dave Page [EMAIL PROTECTED] writes: --- Original Message --- From: Joshua D. Drake [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 15/03/07, 23:51:18 Subject: Re: [GENERAL] pg_dumpall and version confusion If you want that, create a wrapper program that calls to different

Re: [GENERAL] pg_dumpall and version confusion

Jorge Godoy wrote: Dave Page [EMAIL PROTECTED] writes: --- Original Message --- From: Joshua D. Drake [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 15/03/07, 23:51:18 Subject: Re: [GENERAL] pg_dumpall and version confusion If you want that, create a wrapper program

Re: [GENERAL] pg_dumpall and version confusion

Dave Page wrote: --- Original Message --- From: Joshua D. Drake [EMAIL PROTECTED] To: Dave Page [EMAIL PROTECTED] Sent: 15/03/07, 23:51:18 Subject: Re: [GENERAL] pg_dumpall and version confusion If you want that, create a wrapper program that calls to different statically

Re: [GENERAL] pg_dumpall and version confusion

Joshua D. Drake wrote: other deficiencies let's not add to complexity by having an --output-version. If you want that, create a wrapper program that calls to different statically compiled versions of pg_dump. Joshua D. Drake I am afraid that I have to agree with Tom here. Pg_dump has

Re: [GENERAL] pg_dumpall and version confusion

Tony Caduto [EMAIL PROTECTED] writes: I don't think the whole --output-version thing would be a good idea either, but it would be a simple matter to add some logic for the GRANT ON SEQUENCE, which seems to be the only thing that is really causing problems at least between 8.1 and 8.2. You

[GENERAL] pg_dumpall and version confusion

I inherited an existing system with no documents on how it was originally configuerd, so I'll provide as much as I can. OS is CentOS 4.3 Linux Distribution. When I search my system for anything postgres I find a boatload of 8.0.4 source, and a boatload of 7.4.8 documentation. postgres --version

Re: [GENERAL] pg_dumpall and version confusion

Alan J Batsford [EMAIL PROTECTED] writes: When I search my system for anything postgres I find a boatload of 8.0.4 source, and a boatload of 7.4.8 documentation. rpm -qa | grep postgres would probably prove enlightening. It sounds like you have postgresql-server at 8.1.4 and the other

Re: [GENERAL] pg_dumpall and version confusion

Tom Lane wrote: We try to make pg_dump cope with prior server releases, but since we lack a time machine we can't go back and teach old versions about subsequent server changes... Tom, How come version 8.2 of pg_dump uses GRANT ON SEQUENCE when dumping a 8.1 or older database? Was it just a

Re: [GENERAL] pg_dumpall and version confusion

Tony Caduto wrote: Tom Lane wrote: We try to make pg_dump cope with prior server releases, but since we lack a time machine we can't go back and teach old versions about subsequent server changes... Tom, How come version 8.2 of pg_dump uses GRANT ON SEQUENCE when dumping a 8.1 or older

Re: [GENERAL] pg_dumpall and version confusion

Alvaro Herrera wrote: What's wrong with that? 8.2 will understand the GRANT ON SEQUENCE without a problem. Yes, but 8.1 and earlier wont! If you dump a 8.1 database (with 8.2 pg_dump) and then use that dump to restore to another 8.1 server, any permissions on sequences will fail to

Re: [GENERAL] pg_dumpall and version confusion

Tony Caduto wrote: Alvaro Herrera wrote: What's wrong with that? 8.2 will understand the GRANT ON SEQUENCE without a problem. Yes, but 8.1 and earlier wont! If you dump a 8.1 database (with 8.2 pg_dump) and then use that dump to restore to another 8.1 server, any permissions on

Re: [GENERAL] pg_dumpall and version confusion

Dave Page wrote: This is a problem I've been thinking about on and off recently - and I am starting to come to the conclusion that shipping each version of the utilities is the only way things are likely to work unless someone puts some really significant effort into adding backwards

Re: [GENERAL] pg_dumpall and version confusion

On Thu, 2007-03-15 at 11:53, Tony Caduto wrote: Dave Page wrote: This is a problem I've been thinking about on and off recently - and I am starting to come to the conclusion that shipping each version of the utilities is the only way things are likely to work unless someone puts some

Re: [GENERAL] pg_dumpall and version confusion

Tony Caduto [EMAIL PROTECTED] writes: Alvaro Herrera wrote: What's wrong with that? 8.2 will understand the GRANT ON SEQUENCE without a problem. Yes, but 8.1 and earlier wont! You're missing the point entirely. The versioning contract for pg_dump is that version M.N can dump from servers

Re: [GENERAL] pg_dumpall and version confusion

Tom Lane wrote: I have *no* interest in trying to get it to support an --output-version switch... There speaks a man who has the luxury of not having to worry about multi-version admin tools :-( /D ---(end of broadcast)--- TIP 4: Have you

Re: [GENERAL] pg_dumpall and version confusion

Dave Page wrote: Tom Lane wrote: I have *no* interest in trying to get it to support an --output-version switch... There speaks a man who has the luxury of not having to worry about multi-version admin tools :-( Is it more difficult for you to ship a pg_dump-8.0, pg_dump-8.1, etc along

  1   2   >