Re: [GENERAL] pg_dump throws too many command-line arguments in Postgres 10

On Wed, Oct 18, 2017 at 8:05 AM, Andrus wrote: > pg_dump.exe -b -f b.backup -Fc -h -U admin -p 5432 mydb > > causes error > > pg_dump: too many command-line arguments (first is "-p") Don't you need a hostname after -h? I think right now pg_dump thinks your hostname is "-U", your database is "adm

Re: [GENERAL] pg_dump not dropping event trigger

On Sun, Jul 23, 2017 at 5:48 PM, Tom Lane wrote: > Greg Atkins writes: >> would you like a bug report to track this? > > No, it's already dealt with. In any case, your original email was good > enough --- we track bugs these days more by message-ID than anything else. This has been fixed by the

Re: [GENERAL] pg_dump not dropping event trigger

Greg Atkins writes: > would you like a bug report to track this? No, it's already dealt with. In any case, your original email was good enough --- we track bugs these days more by message-ID than anything else. regards, tom lane -- Sent via pgsql-general mailing list

Re: [GENERAL] pg_dump not dropping event trigger

Tom, would you like a bug report to track this? On Sat, Jul 22, 2017 at 07:00:03PM -0400, Tom Lane wrote: > Greg Atkins writes: > > I have a DB with an event trigger, which I am dumping with > > pg_dump -Fc --no-acl --no-owner [db_name] > [dump_file] > > > In my dump file, I can't find any DROP

Re: [GENERAL] pg_dump not dropping event trigger

Greg Atkins writes: > I have a DB with an event trigger, which I am dumping with > pg_dump -Fc --no-acl --no-owner [db_name] > [dump_file] > In my dump file, I can't find any DROP EVENT TRIGGER statement. Well, you wouldn't, for lack of -c ... but yes, it seems you don't get a DROP EVENT TRIGGER

Re: [GENERAL] pg_dump and insert json with copy

basti writes: > some tables has json type and show the following error at restore time: > ERROR: syntax error at or near "a" > LINE 1: a:1:{i:0; > ^ Is that really the very first error reported by the restore run? It seems much more likely to be a failure cascading from something else.

Re: [GENERAL] pg_dump 8.3.3 ERROR: invalid page header in block 2264419 of relation "pg_largeobject"

On 5/25/17 6:30 AM, Tom Lane wrote: David Wall writes: They do have a slave DB running via WAL shipping. Would that likely help us in any way? Have you tried taking a backup from the slave? It's possible that the corruption exists only on the master. We will give this a try once the customer

Re: [GENERAL] pg_dump 8.3.3 ERROR: invalid page header in block 2264419 of relation "pg_largeobject"

David Wall writes: > They do have a slave DB running via WAL shipping. Would that likely > help us in any way? Have you tried taking a backup from the slave? It's possible that the corruption exists only on the master. regards, tom lane -- Sent via pgsql-general mai

Re: [GENERAL] pg_dump 8.3.3 ERROR: invalid page header in block 2264419 of relation "pg_largeobject"

On Wed, May 24, 2017 at 04:45:51PM -0700, David Wall wrote: > They do have a slave DB running via WAL shipping. Would that likely help us > in any way? If you can find out which blobs are afflicted you may be able to extract those from the slave and re-insert them into the new DB. > Because the

Re: [GENERAL] pg_dump 8.3.3 ERROR: invalid page header in block 2264419 of relation "pg_largeobject"

On Wed, May 24, 2017 at 07:18:14PM -0400, Tom Lane wrote: > If possible, I'd take a physical backup (e.g. with tar) of the entire $PGDATA > directory, Make sure the backup goes directly to a different physical volume in case the underlying hardware is bad. Karsten -- GPG key ID E4071346 @ eu.p

Re: [GENERAL] pg_dump 8.3.3 ERROR: invalid page header in block 2264419 of relation "pg_largeobject"

On 5/24/17 4:18 PM, Tom Lane wrote: David Wall writes: We have not noted any issues, but when I ran a pg_dump on an 8.3.3 database, it failed after an hour or so with the error: 8.3.3? Yes, it's old. cat /proc/version Linux version 2.6.18-92.1.10.el5.xs5.0.0.39xen (root@pondo-2) (gcc versio

Re: [GENERAL] pg_dump 8.3.3 ERROR: invalid page header in block 2264419 of relation "pg_largeobject"

David Wall writes: > We have not noted any issues, but when I ran a pg_dump on an 8.3.3 > database, it failed after an hour or so with the error: 8.3.3? > cat /proc/version > Linux version 2.6.18-92.1.10.el5.xs5.0.0.39xen (root@pondo-2) (gcc > version 4.1.2 20071124 (Red Hat 4.1.2-42)) #1 SMP

Re: [GENERAL] pg_dump: creates dumps that cannot be restored

On Tue, Apr 25, 2017 at 4:15 AM, Thorsten Glaser wrote: > > ③ hack pg_dump to invalidate constraints before and revalidate them > after the fact. > ​I suspect there are many people who'd rather take the dump at face value then expending considerably amounts of time re-validating everything tha

Re: [GENERAL] pg_dump: creates dumps that cannot be restored

Hi again, one, possibly, last, thing. I wrote: > I still find the CHECK constraint > to be a more natural way to express what I want, though. Now let me extend on this a bit. The CHECK constraint says nicely and natively, what constraints (no pun intended) I want the data to fulfil. With both t

Re: [GENERAL] pg_dump: creates dumps that cannot be restored

Hi *, I’ve tried both setting the constraints temporarily to invalid (works) and converting (painstakingly slow, as this is new for me) to triggers (also works). Both can be dumped and restored. I’ve also found out that I probably can ship the schema update that converts the CHECK constraint to a

Re: [GENERAL] pg_dump recording privileges on foreign data wrappers

Adam Mackler writes: > If I grant a privilege on a foreign data wrapper like this: > GRANT USAGE ON FOREIGN DATA WRAPPER postgres_fdw TO myuser; > from within psql, then a dump of the database produced using pg_dump > seems to lack an equivalent GRANT statement, even though it contains > the

Re: [GENERAL] pg_dump pg_restore hanging in CentOS for large data

Hi Tom, Please find my answers below. ->ulimit : Verified in file /etc/security/limits.conf - it has been configured as 2. Should I increase the limit and try again? please let me know. root - nofile 2 postgres - nofile 2 ->ssl_renegotiation_limit : Its been set as

Re: [GENERAL] pg_dump pg_restore hanging in CentOS for large data

On 03/17/2017 12:27 AM, Sridevi B wrote: Ccing list. Please reply to list also, it puts more eyes on the problem. Hi Adrian, Sorry for delay. Please find my answers inline. Thanks, Sridevi On Thu, Mar 16, 2017 at 2:28 AM, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: On 03

Re: [GENERAL] pg_dump pg_restore hanging in CentOS for large data

Sridevi B writes: >I am facing an issue with backup/Restore for data size more than *2GB*. I'm suspicious that you're running into some limit external to postgres itself. A couple of likely possibilities: * maybe you've got a ulimit active on the server or the pg_dump or pg_restore proces.

Re: [GENERAL] pg_dump pg_restore hanging in CentOS for large data

On 03/14/2017 09:48 AM, Sridevi B wrote: Hi , I am facing an issue with backup/Restore for data size more than *2GB*. Its working fine for *1GB*. Below are the details for issue: Description: The command pg_dump is hanging at saving large objects and process gets terminated after som

Re: [GENERAL] pg_dump Conflict with recovery

On Tue, Jan 24, 2017 at 5:45 AM, Israel Brewster wrote: > On Jan 23, 2017, at 10:06 AM, Jerry Sievers > wrote: > > > Israel Brewster writes: > > I have a backup strategy that in part consists of doing pg_dump s on my > various databases. In order to hopefully reduce/prevent operational > slow-d

Re: [GENERAL] pg_dump Conflict with recovery

On Jan 23, 2017, at 10:06 AM, Jerry Sievers wrote: > > Israel Brewster writes: > >> I have a backup strategy that in part consists of doing pg_dump s on my >> various databases. In order to hopefully reduce/prevent operational >> slow-down as a result of the >> backup, I do the dumps from my

Re: [GENERAL] pg_dump Conflict with recovery

Israel Brewster writes: > I have a backup strategy that in part consists of doing pg_dump s on my > various databases. In order to hopefully reduce/prevent operational slow-down > as a result of the > backup, I do the dumps from my secondary server, configured as a hot standby > with streaming

Re: [GENERAL] pg_dump and quoted identifiers

Von: pgsql-general-ow...@postgresql.org [pgsql-general-ow...@postgresql.org]" im Auftrag von "Thomas Kellerer [spam_ea...@gmx.net] Gesendet: Donnerstag, 15. Dezember 2016 17:15 An: pgsql-general@postgresql.org Betreff: Re: [GENERAL] pg_dump

Re: [GENERAL] pg_dump and quoted identifiers

Thomas Kellerer writes: > Tom Lane schrieb am 15.12.2016 um 16:20: >> Hmm. It might shed some light if you put "echo" in front of that >> to see what gets printed: >> $ echo pg_dump -d postgres -t "\"Statuses\"" >> pg_dump -d postgres -t "Statuses" > Same here: > -bash-4.1$ echo pg_dump -d pos

Re: [GENERAL] pg_dump and quoted identifiers

On Thursday, December 15, 2016 5:15:44 PM EST Thomas Kellerer wrote: > Tom Lane schrieb am 15.12.2016 um 16:20: > >> Still doesn't work: > >> -bash-4.1$ pg_dump -d postgres -t "\"Statuses\"" > >> pg_dump: no matching tables were found > > > > Hmm. It might shed some light if you put "echo" in

Re: [GENERAL] pg_dump and quoted identifiers

Tom Lane schrieb am 15.12.2016 um 16:20: >> Still doesn't work: >> -bash-4.1$ pg_dump -d postgres -t "\"Statuses\"" >> pg_dump: no matching tables were found > > Hmm. It might shed some light if you put "echo" in front of that > to see what gets printed: > > $ echo pg_dump -d postgres -t "\"

Re: [GENERAL] pg_dump and quoted identifiers

On Thu, Dec 15, 2016 at 4:20 PM, Tom Lane wrote: ... > Hmm. It might shed some light if you put "echo" in front of that > to see what gets printed: > > $ echo pg_dump -d postgres -t "\"Statuses\"" > pg_dump -d postgres -t "Statuses" Also, when having strange issues, I've found the combo echo |

Re: [GENERAL] pg_dump and quoted identifiers

Thomas Kellerer writes: > Adrian Klaver schrieb am 14.12.2016 um 15:32: >> So have you tried the answer from the SO question?: > Still doesn't work: > -bash-4.1$ pg_dump -d postgres -t "\"Statuses\"" > pg_dump: no matching tables were found Hmm. It might shed some light if you put "echo" in

Re: [GENERAL] pg_dump and quoted identifiers

On 12/14/2016 11:37 PM, Thomas Kellerer wrote: Adrian Klaver schrieb am 14.12.2016 um 15:32: I'm suspicious that you're not actually typing plain-ASCII single and double quotes, but some fancy curly quote character. Definitely not. I typed this manually on the command line using Putty So you

Re: [GENERAL] pg_dump and quoted identifiers

Adrian Klaver schrieb am 14.12.2016 um 15:32: >>> I'm suspicious that you're not actually typing plain-ASCII single and >>> double quotes, but some fancy curly quote character. >> >> Definitely not. I typed this manually on the command line using Putty > > So you are reaching the Bash shell via Pu

Re: [GENERAL] pg_dump and quoted identifiers

On 12/13/2016 11:18 PM, Thomas Kellerer wrote: Tom Lane schrieb am 13.12.2016 um 19:35: These cases work for me. Maybe your shell is doing something weird with the quotes? Hmm, that's the default bash from CentOS 6 (don't know the exact version) I'm using bash from current RHEL6, should be

Re: [GENERAL] pg_dump and quoted identifiers

Tom Lane schrieb am 13.12.2016 um 19:35: >>> These cases work for me. Maybe your shell is doing something weird >>> with the quotes? > >> Hmm, that's the default bash from CentOS 6 (don't know the exact version) > > I'm using bash from current RHEL6, should be the same. > > I'm suspicious that

Re: [GENERAL] pg_dump and quoted identifiers

Thomas Kellerer writes: > Tom Lane schrieb am 13.12.2016 um 18:02: >> These cases work for me. Maybe your shell is doing something weird >> with the quotes? > Hmm, that's the default bash from CentOS 6 (don't know the exact version) I'm using bash from current RHEL6, should be the same. I'm su

Re: [GENERAL] pg_dump and quoted identifiers

On Tue, Dec 13, 2016 at 11:24 AM, Thomas Kellerer wrote: > David G. Johnston schrieb am 13.12.2016 um 18:05: > >> On Tue, Dec 13, 2016 at 9:43 AM, Pavel Stehule > >wrote: >> >> >> pg_dump -t '"Statuses"' postgres >> >> >> ​To elaborate - your shell was removing

Re: [GENERAL] pg_dump and quoted identifiers

Tom Lane schrieb am 13.12.2016 um 18:02: -bash-4.1$ pg_dump -d postgres -t '"Statuses"' pg_dump: no matching tables were found -bash-4.1$ pg_dump -d postgres -t 'public."Statuses"' pg_dump: no matching tables were found These cases work for me. Maybe your shell is doing some

Re: [GENERAL] pg_dump and quoted identifiers

David G. Johnston schrieb am 13.12.2016 um 18:05: On Tue, Dec 13, 2016 at 9:43 AM, Pavel Stehule mailto:pavel.steh...@gmail.com>>wrote: pg_dump -t '"Statuses"' postgres ​To elaborate - your shell was removing the double-quotes. You need make it so after shell processing the double-quotes

Re: [GENERAL] pg_dump and quoted identifiers

On Tue, Dec 13, 2016 at 9:43 AM, Pavel Stehule wrote: > >> pg_dump -t '"Statuses"' postgres > > ​To elaborate - your shell was removing the double-quotes. You need make it so after shell processing the double-quotes remain. Wrapping the double-quote string in single-quotes should do it. David

Re: [GENERAL] pg_dump and quoted identifiers

Thomas Kellerer writes: > postgres=# create table "Statuses" (id integer); > CREATE TABLE > -bash-4.1$ pg_dump -d postgres -t "Statuses" > pg_dump: no matching tables were found This is expected since those quotes are eaten by the shell. > -bash-4.1$ pg_dump -d postgres -t '

Re: [GENERAL] pg_dump and quoted identifiers

2016-12-13 17:38 GMT+01:00 Thomas Kellerer : > Inspired by this question: > >http://dba.stackexchange.com/q/158044/1822 > > I tried that for myself, and it seems that pg_dump indeed can not parse > quoted identifiers: > > psql (9.6.1) > Type "help" for help. > > postgres=# create t

Re: [GENERAL] pg_dump system catalog

On 28/11/2016 19:21, Melvin Davidson wrote: On Mon, Nov 28, 2016 at 10:50 AM, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: On 11/28/2016 07:44 AM, Melvin Davidson wrote: *To clarify, you cannot dump the pg_catalog schema. It is the main control of how all othe

Re: [GENERAL] pg_dump system catalog

On Mon, Nov 28, 2016 at 10:50 AM, Adrian Klaver wrote: > On 11/28/2016 07:44 AM, Melvin Davidson wrote: > >> >> > >> >> *To clarify, you cannot dump the pg_catalog schema. It is the main >> control of how all other objects are >> > > Actually you can. I would not of thought so, but tried Achillea

Re: [GENERAL] pg_dump system catalog

On 11/28/2016 07:44 AM, Melvin Davidson wrote: *To clarify, you cannot dump the pg_catalog schema. It is the main control of how all other objects are Actually you can. I would not of thought so, but tried Achilleas's suggestion and it worked. Example: -- -- Name: pg_aggregate; Type: T

Re: [GENERAL] pg_dump system catalog

On Mon, Nov 28, 2016 at 9:33 AM, Adrian Klaver wrote: > On 11/28/2016 03:40 AM, Juliano wrote: > >> I'm not knew that system catalogs could be saved as schema, thanks >> Achilleas. >> >> So, I would like to get the data and the schema of the system catalogs. >> How can I include the data in a dum

Re: [GENERAL] pg_dump system catalog

On 11/28/2016 03:40 AM, Juliano wrote: I'm not knew that system catalogs could be saved as schema, thanks Achilleas. So, I would like to get the data and the schema of the system catalogs. How can I include the data in a dump file with system schemas? (The parameter -a makes sense together the p

Re: [GENERAL] pg_dump system catalog

I'm not knew that system catalogs could be saved as schema, thanks Achilleas. So, I would like to get the data and the schema of the system catalogs. How can I include the data in a dump file with system schemas? (The parameter -a makes sense together the parameter --schema?) Regards, Juliano

Re: [GENERAL] pg_dump system catalog

On 25/11/2016 13:11, Juliano wrote: Hi everyone, How can I *use pg_dump* to do a backup of *"system catalogs"* only? pg_dump --schema=pg_catalog Regards, Juliano -- Achilleas Mantzios IT DEV Lead IT DEPT Dynacom Tankers Mgmt

Re: [GENERAL] pg_dump without any SET command in header of output plain text sql file

Ok, thanks ! Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company On 22.07.2016 06:49, Sameer Kumar wrote: On Thu, Jul 21, 2016 at 7:14 PM Alex Ignatov > wrote: And what is the options you mentioned about? I stand

Re: [GENERAL] pg_dump without any SET command in header of output plain text sql file

On Thu, Jul 21, 2016 at 7:14 PM Alex Ignatov wrote: > And what is the options you mentioned about? > I stand corrected. I think the only ones you can avoid are OWNERSHIP and TABLESPACE commands. I think sed would be the best tool here. > Alex Ignatov > Postgres Professional: http://www.postgre

Re: [GENERAL] pg_dump without any SET command in header of output plain text sql file

And what is the options you mentioned about? Alex Ignatov Postgres Professional: http://www.postgrespro.com The Russian Postgres Company On 20.07.2016 21:02, Sameer Kumar wrote: On Thu, 21 Jul 2016, 1:17 a.m. Alex Ignatov, > wrote: Hello everyone! I

Re: [GENERAL] pg_dump without any SET command in header of output plain text sql file

On Thu, 21 Jul 2016, 1:17 a.m. Alex Ignatov, wrote: > Hello everyone! > > Is there any way to make pg_dump(9.5) to dump table (with data) without > any SET command in the header of output plain sql file? > Yeah you need to use specific switch/option to disable each set command > P.S. Yeah I kn

Re: [GENERAL] pg_dump without any SET command in header of output plain text sql file

Alex Ignatov writes: > Is there any way to make pg_dump(9.5) to dump table (with data) without > any SET command in the header of output plain sql file? No, but if all you want is the table data in a file, why not just use COPY? regards, tom lane -- Sent via pgsql-gen

Re: [GENERAL] pg_dump fundenental question

On Tue, Jul 5, 2016 at 7:39 PM, J. Cassidy wrote: > My input (source) DB is 1TB in size, using the options as stated in my > original email (i.e. no compression it would seem) the output file size is > "only" 324GB. > I presume all of the formatting/indices have been ommited. As I said before, >

Re: [GENERAL] pg_dump fundenental question

"less" is much better for opening huge text files in *nix for reading. On 07/05/16 15:13, Christofer C. Bell wrote: On Tue, Jul 5, 2016 at 3:17 PM, Paul Linehan mailto:lineh...@tcd.ie>> wrote: > a good point, but I would prefer NOT to open a 324GB backup file in a text > editor. I can h

Re: [GENERAL] pg_dump fundenental question

On Tue, Jul 5, 2016 at 3:17 PM, Paul Linehan wrote: > > a good point, but I would prefer NOT to open a 324GB backup file in a > text > > editor. I can however cat/less/head/tail the file in Linux. > > Use vi (or flavour thereof) - it doesn't load the entire file in order to > read the contents of

Re: [GENERAL] pg_dump fundenental question

> a good point, but I would prefer NOT to open a 324GB backup file in a text > editor. I can however cat/less/head/tail the file in Linux. Use vi (or flavour thereof) - it doesn't load the entire file in order to read the contents of lines 1 - 100 (say). Paul... -- Sent via pgsql-general mail

Re: [GENERAL] pg_dump fundenental question

On Wed, 6 Jul 2016, 1:39 a.m. J. Cassidy, wrote: > Francisco, > > appreciate the tips/hints. > > My input (source) DB is 1TB in size, using the options as stated in my > original email (i.e. no compression it would seem) the output file size is > "only" 324GB. > It would be because of indexes d

Re: [GENERAL] pg_dump fundenental question

Thank you all for the information. On 07/05/2016 10:10 AM, J. Cassidy wrote: > Hello Adrian, > > appreciate the prompt reply, thank you. > > As stated in the original email, I want to know whether compression > (whatever level) is on by default (or not) - if I supply NO extra > switches/options

Re: [GENERAL] pg_dump fundenental question

Francisco, appreciate the tips/hints. My input (source) DB is  1TB in size, using the options as stated in my original email (i.e. no compression it would seem) the output file size is "only" 324GB.  I presume all of the formatting/indices have been ommited. As I said before, I can browse the b

Re: [GENERAL] pg_dump fundenental question

On 07/05/2016 10:10 AM, J. Cassidy wrote: Hello Adrian, appreciate the prompt reply, thank you. As stated in the original email, I want to know whether compression (whatever level) is on by default (or not) - if I supply NO extra switches/options. There is no compression by default. -- Com

Re: [GENERAL] pg_dump fundenental question

On Tue, Jul 5, 2016 at 4:54 PM, J. Cassidy wrote: > I have hopefully an "easy" question. > If I issue the pg_dump command with no switches or options i.e. > /usr/local/pgsql/bin/pg_dump -v dbabcd > /data3TB/Backup/dbabcd > Is their any "default" compression involved or not? Does pg_dump talk to >

Re: [GENERAL] pg_dump fundenental question

J. Cassidy wrote: > As stated in the original email, I want to know whether compression > (whatever level) is on by default (or not) -  if I supply NO extra > switches/options. I have read the documentation and it is unclear in > this respect. I am a Mainframer and perhaps have a different world

Re: [GENERAL] pg_dump fundenental question

Rob, appreciate the reply but I have never used nor never will use "that" os (small capitals intentional. Regards, Henk

Re: [GENERAL] pg_dump fundenental question

Hello David, a good point, but I would prefer NOT to open a 324GB backup file in a text editor. I can however cat/less/head/tail the file in Linux. Regards, Henk  

Re: [GENERAL] pg_dump fundenental question

Hello Adrian, appreciate the prompt reply, thank you. As stated in the original email, I want to know whether compression (whatever level) is on by default (or not) -  if I supply NO extra switches/options. I have read the documentation and it is unclear in this respect. I am a Mainframer and

Re: [GENERAL] pg_dump fundenental question

On 07/05/2016 10:54 AM, David G. Johnston wrote: On Tue, Jul 5, 2016 at 10:54 AM, J. Cassidy >wrote: Hello all, I have hopefully an "easy" question. If I issue the pg_dump command with no switches or options i.e. /usr/local/pgsql/bin/pg_dump -v dbab

Re: [GENERAL] pg_dump fundenental question

On Tue, Jul 5, 2016 at 10:54 AM, J. Cassidy wrote: > Hello all, > > I have hopefully an "easy" question. > > If I issue the pg_dump command with no switches or options i.e. > > /usr/local/pgsql/bin/pg_dump -v dbabcd > /data3TB/Backup/dbabcd > > Is their any "default" compression involved or not?

Re: [GENERAL] pg_dump fundenental question

On 07/05/2016 07:54 AM, J. Cassidy wrote: Hello all, I have hopefully an "easy" question. If I issue the pg_dump command with no switches or options i.e. /usr/local/pgsql/bin/pg_dump -v dbabcd > /data3TB/Backup/dbabcd Is their any "default" compression involved or not? Does pg_dump talk to zl

Re: [GENERAL] pg_dump from a hot standby replication slave

On Tue, 21 Jun 2016, 4:03 a.m. Johan Thomsen, wrote: > Hi, > > In relation to this thread: > > https://www.postgresql.org/message-id/0B4197B9-5DB8-4475-A83C-38DA5965782A%40etasseo.com > > > I ran the pg_dump process again this morning, ensuring that the standby > > parameters were set, and it com

Re: [GENERAL] pg_dump crashing ... solved

Hello, thank you for your answers. > On 20 Mar 2016, at 16:56, Adrian Klaver wrote: > > So what happens if you either?: > > 1) In the root crontab, change the command to: > > /Users/…/bin/pg_dump -p 5433 mydatabase_1_0_0 -U mmpostgres > > /my_backup_path/mydatabase_1_0_0.dump This will make

Re: [GENERAL] pg_dump crashing

On Mon, Mar 21, 2016 at 4:18 AM, Matthias Schmitt wrote: > Hello, > > sorry for the late response. > >> On 15 Mar 2016, at 18:59, rob stone wrote: >> >> I'm running Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux. >> >> Backups are done via a shell script using double hyphen syntax, as in >> e.g.:-

Re: [GENERAL] pg_dump crashing

On 03/20/2016 08:24 AM, Matthias Schmitt wrote: > Hello, > >> On 16 Mar 2016, at 14:55, Adrian Klaver wrote: >> >> On 03/15/2016 08:10 AM, Matthias Schmitt wrote: >>> Hello, >>> >>> since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian 8.3. >>> Everything is fine except the daily

Re: [GENERAL] pg_dump crashing

Hello, > On 16 Mar 2016, at 14:55, Adrian Klaver wrote: > > On 03/15/2016 08:10 AM, Matthias Schmitt wrote: >> Hello, >> >> since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian 8.3. >> Everything is fine except the daily backup. When calling pg_dump as part of >> a cron job pg

Re: [GENERAL] pg_dump crashing

Hello, sorry for the late response. > On 15 Mar 2016, at 18:59, rob stone wrote: > > I'm running Debian 4.3.5-1 (2016-02-06) x86_64 GNU/Linux. > > Backups are done via a shell script using double hyphen syntax, as in > e.g.:- > > pg_dump --port=5433 --dbname=mydatabase_1_0_0 --username=mmppos

Re: [GENERAL] pg_dump crashing

On 03/15/2016 08:10 AM, Matthias Schmitt wrote: Hello, since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian 8.3. Everything is fine except the daily backup. When calling pg_dump as part of a cron job pg_dump crashes: 2016-03-15 01:00:02 CETFATAL: semctl(23232524, 3, SETVAL, 0

Re: [GENERAL] pg_dump crashing

On Tue, 2016-03-15 at 16:10 +0100, Matthias Schmitt wrote: > Hello, > > since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian > 8.3. Everything is fine except the daily backup. When calling pg_dump > as part of a cron job pg_dump crashes: > > 2016-03-15 01:00:02 CETFATAL:  semctl(2

Re: [GENERAL] pg_dump crashing

On Tue, Mar 15, 2016 at 4:10 PM, Matthias Schmitt wrote: > since two weeks I am trying to get PostgreSQL 9.5.1 to run on Debian 8.3. > Everything is fine except the daily backup. When calling pg_dump as part of a > cron job pg_dump crashes: > > 2016-03-15 01:00:02 CETFATAL: semctl(23232524, 3,

Re: [GENERAL] pg_dump - ERROR - PostgreSQL 9.2

[SOLVED] Just to let you guys know.. I've solved this issue changing the max_standby_streaming_delay on my slave to "-1". Cheers Lucas Possamai - kinghost.co.nz - DigitalOcean

Re: [GENERAL] pg_dump streaming fails - PostgreSQL 9.2

On 01/28/2016 05:23 PM, drum.lu...@gmail.com wrote: Hi there! I'm running this command: *(Trying to copy a full DB (2TB) from a hot-standby server to a master (test) server)* |ssh postgres@myslaveserver "/usr/pgsql-9.2/bin/pg_dump --exclude-table-data='junk.*' -—format=custom master_db"|/usr/pg

Re: [GENERAL] pg_dump problem with dropped NOT NULL on child table

On 01/14/2016 12:59 AM, Karsten Hilbert wrote: On Wed, Jan 13, 2016 at 12:10:15PM -0800, Adrian Klaver wrote: On 01/13/2016 11:38 AM, Karsten Hilbert wrote: create table parent ( not_null_in_parent integer not null ); create table child() inherits (pa

Re: [GENERAL] pg_dump problem with dropped NOT NULL on child table

On Wed, Jan 13, 2016 at 03:32:12PM -0500, Tom Lane wrote: > Karsten Hilbert writes: > > create table parent ( > > not_null_in_parent integer not null > > ); > > > create table child() inherits (parent); > > alter table child > > alter column not_null_in_p

Re: [GENERAL] pg_dump problem with dropped NOT NULL on child table

On Wed, Jan 13, 2016 at 12:10:15PM -0800, Adrian Klaver wrote: > On 01/13/2016 11:38 AM, Karsten Hilbert wrote: > > create table parent ( > > not_null_in_parent integer not null > > ); > > > > create table child() inherits (parent); > > alter table child > >

Re: [GENERAL] pg_dump problem with dropped NOT NULL on child table

Karsten Hilbert writes: > Please consider the following: > create table parent ( > not_null_in_parent integer not null > ); > create table child() inherits (parent); > alter table child > alter column not_null_in_parent >

Re: [GENERAL] pg_dump problem with dropped NOT NULL on child table

On 01/13/2016 11:38 AM, Karsten Hilbert wrote: Please consider the following: - Debian - server is PG 9.4.5 - client (psql/pg_dump/libpq5) is 9.5 create table parent ( not_null_in_parent integer not null ); create table child() inherits (parent);

Re: [GENERAL] pg_dump executed on a hosts against another host fails with pg_dump: [archiver (db)] query was: SET search_path = pg_catalog, sys, dbo

From: "John R Pierce" To: pgsql-general@postgresql.org Sent: Tuesday, December 15, 2015 10:55:01 AM Subject: Re: [GENERAL] pg_dump executed on a hosts against another host fails with pg_dump: [archiver (db)] query was: SET search_path = pg_catalog, sys, dbo On 12/15/2015 1:16

Re: [GENERAL] pg_dump executed on a hosts against another host fails with pg_dump: [archiver (db)] query was: SET search_path = pg_catalog, sys, dbo

On 12/15/2015 1:16 AM, John R Pierce wrote: sys and dbo are Oracle schemas, is this the Oracle compatible server eDB sells?contact their paid support, thats not really postgres anymore. let me correct that, its not the community version of postgres that this mail list supports. --

Re: [GENERAL] pg_dump executed on a hosts against another host fails with pg_dump: [archiver (db)] query was: SET search_path = pg_catalog, sys, dbo

On 12/15/2015 12:50 AM, Daniel Westermann wrote: we try to dump a PostgreSQL 8.2.4 instance with pg_dump from version 9.4.5 (enterprisedb version) over the network. This is the error we get: pg_dump: [archiver (db)] query failed: ERROR: schema "sys" does not exist pg_dump: [archiver (db)] que

Re: [GENERAL] pg_dump - postgre 9.2 and "server closed the connection unexpectedly"

Maycon Oliveira writes: > i´m using postgre for 2 years now and i started to have this *INTERMITENT* > error from pg_dump: > pg_dump: Dumping the contents of table "adm_log" failed: PQgetCopyData() > failed. > pg_dump: Error message from server: server closed the connection > unexpectedly > Look

Re: [GENERAL] pg_dump error

On 07/27/2015 10:58 AM, AI Rumman wrote: I am not using any comma here. With the same command I am able to take dump on other disks. I beg to differ, From your original post: -f dbname_tablename,sqlc ^^^ > But with ISOLON CIFS, I am getting the error. Thanks. On Mon

Re: [GENERAL] pg_dump error

I am not using any comma here. With the same command I am able to take dump on other disks. But with ISOLON CIFS, I am getting the error. Thanks. On Mon, Jul 27, 2015 at 10:56 AM, Adrian Klaver wrote: > On 07/27/2015 10:55 AM, AI Rumman wrote: > >> No it is "-s" for schema only backup. >> > > M

Re: [GENERAL] pg_dump error

On 07/27/2015 10:55 AM, AI Rumman wrote: No it is "-s" for schema only backup. My ^ got misplaced in sending. I was talking about the ',' in the file name at the end of the command. Thanks. On Mon, Jul 27, 2015 at 10:53 AM, Adrian Klaver mailto:adrian.kla...@aklaver.com>> wrote: On 0

Re: [GENERAL] pg_dump error

No it is "-s" for schema only backup. Thanks. On Mon, Jul 27, 2015 at 10:53 AM, Adrian Klaver wrote: > On 07/27/2015 10:48 AM, AI Rumman wrote: > >> Hi, >> >> I am getting the following error during pg_dump: >> >> pg_dump dbname -v -t tablename -s -Fc -f dbname_tablename,sqlc >> >

Re: [GENERAL] pg_dump error

On 07/27/2015 10:48 AM, AI Rumman wrote: Hi, I am getting the following error during pg_dump: pg_dump dbname -v -t tablename -s -Fc -f dbname_tablename,sqlc ^ Is that really a ','(comma)? pg_dump: [custom archiver] WARNING: ftell mi

Re: [GENERAL] pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists

On 07/09/2015 01:24 AM, pinker wrote: Tom Lane-2 wrote $ time pg_dump -f /z/q regression pg_dump: [archiver] could not open output file "/z/q": No such file or directory real0m1.164s user0m0.062s sys 0m0.034s However, I don't see that with any of the non-plain-text output formats:

Re: [GENERAL] pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists

Tom Lane-2 wrote > $ time pg_dump -f /z/q regression > pg_dump: [archiver] could not open output file "/z/q": No such file or > directory > > real0m1.164s > user0m0.062s > sys 0m0.034s > > However, I don't see that with any of the non-plain-text output formats: In my case this is: p

Re: [GENERAL] pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists

Adrian Klaver-4 wrote > That is sort of dangerous:) As an example, do you really want --inserts > or --column-inserts, they really slow down a restore. I know, but this time I need it more for versioning/demo version prepariation so performence isn't important at all, what I care about is only dd

Re: [GENERAL] pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists

On 07/07/2015 08:15 AM, pinker wrote: Adrian Klaver-4 wrote I was talking about when you ran the backup from pgAdmin. The backup dialog has a file selector button to select the path/file you want to back up to. So I was wondering how you got an incorrect path in the first place? Then it occurre

Re: [GENERAL] pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists

Adrian Klaver-4 wrote > I was talking about when you ran the backup from pgAdmin. The backup > dialog has a file selector button to select the path/file you want to > back up to. So I was wondering how you got an incorrect path in the > first place? Then it occurred to me you might not have hav

Re: [GENERAL] pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists

On 07/07/2015 07:12 AM, pinker wrote: Adrian Klaver-4 wrote So how did you get the wrong file name then, the pgAdmin backup dialog has a file selector? Or did you cut and paste into the file field? Anyway, shouldn't postgresql first check if dump can be saved? and then start doing it? Ignor

Re: [GENERAL] pg_dump (PostgreSQL) 9.4.1 - delay in checking if file exists

On 07/07/2015 07:12 AM, pinker wrote: Adrian Klaver-4 wrote So how did you get the wrong file name then, the pgAdmin backup dialog has a file selector? Or did you cut and paste into the file field? Anyway, shouldn't postgresql first check if dump can be saved? and then start doing it? pgAdm

  1   2   3   4   5   6   7   8   9   10   >