Re: Fwd: Fwd: Problem with pg_dump and decimal mark - Mailing list pgsql-general

From Adrian Klaver
Subject Re: Fwd: Fwd: Problem with pg_dump and decimal mark
Date
Msg-id 54861EC9.1020909@aklaver.com
Whole thread Raw
In response to Problem with pg_dump and decimal mark  (Eric Svenson <esvenson74@googlemail.com>)
Responses Re: Fwd: Fwd: Problem with pg_dump and decimal mark  (Eric Svenson <esvenson74@googlemail.com>)
List pgsql-general
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 tables
> are the only tables in the database which contain floats.
>
> The errors occur with the first float in the table, the restore process
> seems to terminate with that table and seems to continue with the next
> table. The result are completely empty tables for dev_my_settings and
> file_item.
>
> There are float values in the table which can be viewed with pg_admin.
>
> The table definitions for dev_my_settings and file_item contain lots of
> BIGINTS, smallints and integers, and several double precision values.
> All other tables do not contain any double precision values.

Alright a chance to think some more.

So:

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?

While you are in psql, what does SHOW ALL display for the lc_* settings?

On the Windows server where the Postgres server is running what does SET
show from the command line?

>
> Regards,
> Eric
>
>


--
Adrian Klaver
adrian.klaver@aklaver.com


pgsql-general by date:

Previous
From: John R Pierce
Date:
Subject: Re: Streaming Replication - changing IP addresses
Next
From: Daniel Begin
Date:
Subject: Re: Removing duplicate records from a bulk upload (rationale behind selecting a method)