Hi Adrian,
so finally I have a workaround which is ok for me. When I seperate the
tables and the data (using the -a and -s switch from pg_dump) into 2 sql
backup files, everything works ok on the problem-VM.
I try to investigate further in the coming weeks, I´m on holiday next week.
Regards and
> The restore left you with two empty tables. What happens if you log into
Postgres > via psql and then INSERT one set of values containing floats
into say, >dev_my_settings?
SUCCESS! This works OK!
INSERT INTO dev_my_settings(123, 'test', 'test', 'test', 123, 123.345);
Value 123.345 can be read
So, one more success...
I have taken a part of the backup SQL file which fills the table
COPY dev_my_settings (.) from stdin;
12345 text text 0 123.345345
This file ALONE works! (without changing ANYTHING!)
So if I run the first (huge) SQL file and then the second, which fills the
de
On 12/10/2014 01:32 AM, Eric Svenson wrote:
So, one more success...
I have taken a part of the backup SQL file which fills the table
COPY dev_my_settings (.) from stdin;
12345 text text 0 123.345345
This file ALONE works! (without changing ANYTHING!)
Hmm, almost like the encoding/
Hi Adrian,
here are the results of today:
> How where the Postgres instances installed?
> From a package?
Yes. It is Version 9.2 for Windows, comment of the package is
"The PostgreSQL RDBMS, version 9.2, packaged by EnterpriseDB"
> Compiled and if so with what compiler and what settings?
No
Hi Adrian,
I try to get access to the non-VM machine, at the moment access is not
possible for me unfortunately.
You are right, there are more tables in the database which are restored
correctly but these tables do NOT contain float values. These two tables
are the only tables in the database whi
On 12/08/2014 06:53 AM, Eric Svenson wrote:
Hi Adrian,
I try to get access to the non-VM machine, at the moment access is not
possible for me unfortunately.
You are right, there are more tables in the database which are restored
correctly but these tables do NOT contain float values. These two
On 12/08/2014 06:53 AM, Eric Svenson wrote:
Hi Adrian,
I try to get access to the non-VM machine, at the moment access is not
possible for me unfortunately.
You are right, there are more tables in the database which are restored
correctly but these tables do NOT contain float values. These two
On 12/08/2014 12:21 AM, Eric Svenson wrote:
Hi Adrian,
here are the results of today:
> How where the Postgres instances installed?
> From a package?
Yes. It is Version 9.2 for Windows, comment of the package is
"The PostgreSQL RDBMS, version 9.2, packaged by EnterpriseDB"
> Compiled a
On 12/05/2014 01:13 AM, Eric Svenson wrote:
Hi Adrian,
Is the above how the message was actually presented or has a partialtranslation
taken >place? Just asking because it would seem to indicate
further confusion about the locale.
This is an exact copy of the screen contents, no translatio
Hi Adrian,
>Is the above how the message was actually presented or has a partial
translation taken >place? Just asking because it would seem to indicate
further confusion about the locale.
This is an exact copy of the screen contents, no translation by me has
taken place. Indeed strange, "ERROR"
On 12/04/2014 02:01 AM, Eric Svenson wrote:
So what if you load to the VM Postgres using the psql from the host?
I tried that: On the host I started psql with
psql -h 192.168.2.55 -U postgres -p 5432 my_Database < myFile.sql
I get the same error
ERROR: invalid input syntax for type double pre
> So what if you load to the VM Postgres using the psql from the host?
I tried that: On the host I started psql with
psql -h 192.168.2.55 -U postgres -p 5432 my_Database < myFile.sql
I get the same error
ERROR: invalid input syntax for type double precision "0.2"
KONTEXT: COPY dev_my_settings, l
On 12/03/2014 12:23 AM, Eric Svenson wrote:
Hi Adrian,
thank you for your support. Here are the informations you requested
I have already done that and found something strange:
On the PC where the backup was done with pg_dump, all locale settings of
Postgres were English/United S
Hi Adrian,
thank you for your support. Here are the informations you requested
> I have already done that and found something strange:
>
> On the PC where the backup was done with pg_dump, all locale settings of
> Postgres were English/United States. (LC_COLLATE, LC_CTYPE, LC_MONETARY,
> LC_NUME
On 11/29/2014 12:25 AM, Eric Svenson wrote:
Seems you have a locale mismatch issue. The dump is coming
from a locale
where a '.' is the decimal mark and is being restored to a
locale where
',' is the mark. Look at what the locales are
Seems you have a locale mismatch issue. The dump is coming from a locale
>>> where a '.' is the decimal mark and is being restored to a locale where
>>> ',' is the mark. Look at what the locales are the machines that work and
>>> the one that does not.
>>>
>>
>>
I have already done that and found s
On 11/28/2014 02:08 PM, Tom Lane wrote:
Adrian Klaver writes:
On 11/28/2014 05:35 AM, Eric Svenson wrote:
I have done a backup of a postgres database on a virtual machine
(Windows 8.1) using pg_dump.
On another (non-virtual) machine the restore (with psql) worked without
problems.
On the thi
Adrian Klaver writes:
> On 11/28/2014 05:35 AM, Eric Svenson wrote:
>> I have done a backup of a postgres database on a virtual machine
>> (Windows 8.1) using pg_dump.
>>
>> On another (non-virtual) machine the restore (with psql) worked without
>> problems.
>>
>> On the third virtual machine, h
On 11/28/2014 05:35 AM, Eric Svenson wrote:
Hello,
I have done a backup of a postgres database on a virtual machine
(Windows 8.1) using pg_dump.
On another (non-virtual) machine the restore (with psql) worked without
problems.
On the third virtual machine, however, the restore fails.
(ERROR:
Hello,
I have done a backup of a postgres database on a virtual machine (Windows
8.1) using pg_dump.
On another (non-virtual) machine the restore (with psql) worked without
problems.
On the third virtual machine, however, the restore fails.
(ERROR: invalid input syntax for type double precision
nal Message-
> From: [EMAIL PROTECTED] [mailto:pgsql-general-
> [EMAIL PROTECTED] On Behalf Of Tom Lane
> Sent: Friday, January 04, 2008 3:35 PM
> To: Ken Winter
> Cc: PostgreSQL pg-general List
> Subject: Re: [GENERAL] Problem with pg_dump?
>
> "Ken Winter" <[E
"Ken Winter" <[EMAIL PROTECTED]> writes:
> When I do a pg_dump from an 8.1 database (with options schema-only,
> no-owner, and plain format), the dump file includes the following:
> ALTER SEQUENCE transaction_transaction_id_seq OWNED BY
> "transaction".transaction_id;
Don't use 8.2 pg_dump if you
When I do a pg_dump from an 8.1 database (with options schema-only,
no-owner, and plain format), the dump file includes the following:
"
--
-- TOC entry 1623 (class 1259 OID 17618)
-- Dependencies: 5 1624
-- Name: transaction_transaction_id_seq; Type: SEQUENCE; Schema: public;
-- Owner: -
--
CRE
Hi!
I've got problem with dumping the database on the slave server.
Situation:
Master:
Running CentOS release 4.4 (Final) with PostgreSQL 8.2.4.
Slave:
Running CentOS release 4.3 (Final) with PostgreSQL 8.2.4 and slon
version 1.2.9
pg_dump on master works fine. On slave i've got error on st
Andrew Sullivan wrote:
On Tue, May 22, 2007 at 04:36:49PM +0200, [EMAIL PROTECTED] wrote:
pg_dump on master works fine. On slave i've got error on start of
dumping:
-bash-3.00$ pg_dump -d -D my_database
pg_dump: failed sanity check, parent table OID 225893092 of
pg_rewrite entry OID 225893271
Andrew Sullivan wrote:
On Tue, May 22, 2007 at 04:36:49PM +0200, [EMAIL PROTECTED] wrote:
pg_dump on master works fine. On slave i've got error on start of
dumping:
-bash-3.00$ pg_dump -d -D my_database
pg_dump: failed sanity check, parent table OID 225893092 of
pg_rewrite entry OID 225893271
On Tue, May 22, 2007 at 04:36:49PM +0200, [EMAIL PROTECTED] wrote:
> pg_dump on master works fine. On slave i've got error on start of
> dumping:
>
> -bash-3.00$ pg_dump -d -D my_database
> pg_dump: failed sanity check, parent table OID 225893092 of
> pg_rewrite entry OID 225893271 not found
Yo
[EMAIL PROTECTED] wrote:
Hi!
I've got problem with dumping the database on the slave server.
Situation:
Master:
Running CentOS release 4.4 (Final) with PostgreSQL 8.2.4.
Slave:
Running CentOS release 4.3 (Final) with PostgreSQL 8.2.4 and slon
version 1.2.9
pg_dump on master works fine. On
Hi!
I've got problem with dumping the database on the slave server.
Situation:
Master:
Running CentOS release 4.4 (Final) with PostgreSQL 8.2.4.
Slave:
Running CentOS release 4.3 (Final) with PostgreSQL 8.2.4 and slon
version 1.2.9
pg_dump on master works fine. On slave i've got error on st
Ok - it is user error, my bad. It looks like something bad happened during the restore, and indexes didn't get created. I forgot that pg_dump creates indexes as upper case CREATE INDEX, and I was grepping for 'index', not 'INDEX'.
sorry for the confusion, to be honest I panicked when the thought
On Friday 10 November 2006 08:37, "Alex Turner" <[EMAIL PROTECTED]> wrote:
> Sure thing, I hope it's as simple as user error!
>
> #!/bin/sh
> export DATE=`date +%Y%m%d`
>
> /usr/local/pgsql/bin/pg_dump -Upostgres -hlocalhost trend >
> /backup/trend.dump.$DATE
>
> Thats pretty much it repeated for e
Alex Turner <[EMAIL PROTECTED]> schrieb:
> Sure thing, I hope it's as simple as user error!
>
> #!/bin/sh
> export DATE=`date +%Y%m%d`
>
> /usr/local/pgsql/bin/pg_dump -Upostgres -hlocalhost trend > /backup/
> trend.dump.$DATE
>
> Thats pretty much it repeated for each database. I just upgrade
I would be happy to point someone to the dump file, it's about 500Meg thoughAlexOn 11/10/06, Alex Turner <
[EMAIL PROTECTED]> wrote:Sure thing, I hope it's as simple as user error!
#!/bin/shexport DATE=`date +%Y%m%d`/usr/local/pgsql/bin/pg_dump -Upostgres -hlocalhost trend > /backup/trend.dump.$DAT
Sure thing, I hope it's as simple as user error!#!/bin/shexport DATE=`date +%Y%m%d`/usr/local/pgsql/bin/pg_dump -Upostgres -hlocalhost trend > /backup/trend.dump.$DATEThats pretty much it repeated for each database. I just upgraded to
8.1.5 to see if that would fix the problem, but it didn'tAlexO
On Fri, 2006-11-10 at 11:23 -0500, Tom Lane wrote:
> "Alex Turner" <[EMAIL PROTECTED]> writes:
> > Well yes - thats what I mean, the definition for the index. It's not
> > dumping the index defs. It also looks like it's not dumping roles fully
> > either. I was missing grants from the dump too.
"Alex Turner" <[EMAIL PROTECTED]> writes:
> Well yes - thats what I mean, the definition for the index. It's not
> dumping the index defs. It also looks like it's not dumping roles fully
> either. I was missing grants from the dump too.
[ raised eyebrow... ] Let's see a test case.
Well yes - thats what I mean, the definition for the index. It's not dumping the index defs. It also looks like it's not dumping roles fully either. I was missing grants from the dump too.Alex
On 11/9/06, Brent Wood <[EMAIL PROTECTED]> wrote:
A. Kretschmer wrote:> am Thu, dem 09.11.2006, um 13:
A. Kretschmer wrote:
am Thu, dem 09.11.2006, um 13:04:31 -0500 mailte Alex Turner folgendes:
I seem to be having a problem with pg_dump in 8.1.2, it's not dumping indexes
at all. Is this a known problem, should I just do an upgrade?
I can't see a necessity to dump a index. But, i hop
am Thu, dem 09.11.2006, um 13:04:31 -0500 mailte Alex Turner folgendes:
> I seem to be having a problem with pg_dump in 8.1.2, it's not dumping indexes
> at all. Is this a known problem, should I just do an upgrade?
I can't see a necessity to dump a index. But, i hope, and i'm sure,
pg_dump dump
I seem to be having a problem with pg_dump in 8.1.2, it's not dumping indexes at all. Is this a known problem, should I just do an upgrade?Thanks,Alex TurnerMint Pixels
Shanmugasundaram Doraisamy <[EMAIL PROTECTED]> writes:
> Thanks for all your support to my previous
> postings. I am currently using Postgresql 7.3.4-2PGDG. The problem I
> am facing is that when I take a dump of the DB using pg_dump and restore
> it using the cat pg_dump_
Dear Group,
Thanks for all your support to my previous
postings. I am currently using Postgresql 7.3.4-2PGDG. The problem I
am facing is that when I take a dump of the DB using pg_dump and restore
it using the cat pg_dump_file |psql dbname, I find that some views and
funct
43 matches
Mail list logo
