Problem migrating dump to latest CVS snapshot.

Problem migrating dump to latest CVS snapshot.

Post by Gunnar R|nni » Sat, 24 Mar 2001 06:18:03

We have pgsql-7.0.2 running on a production platform doing nightly dumps. I
tried to import this dump using psql to a pgsql server running from a cvs
update of 7.1 I did today.

All the data was imported OK except for the data in one table where I got
the following message on import :

ERROR:  copy: line 154391, Bad timestamp external representation '2000-10-24 15:14:60.00+02'
PQendcopy: resetting connection

The result was that this table turned up with no rows at all after the
import when it should have contained more than 900000 rows.

I get exactly the same error trying to import into a 7.0.2 database on
my laptop as well, so I guess the problem might have been around for a

The production platform creating the dump file is Solaris 7 on an Ultra
Sparc, while the laptop I'm importing the file on is Redhat Linux 6.1 on an
x86 processor.

The actual table "access_log" got these columns :
a_accesstime                      timestamp           8            
a_locid                           int4                4            
a_catid                           int4                4            
a_searchterm                      varchar           256            
a_host                            varchar            64            
a_requesturl                      varchar           128            
a_action                          varchar            16            
a_uid                             int4                4            
a_pt_id                           int4                4            

Do anybody have suggestions to where I should look for the error or what
other data I need to supply to help somebody look into it ?

If you look at the seconds part of the time above you notice 60, which make
me wonder how that could get in there in the first place.

So to me there seems to bugs, it is possible to get invalid times into the
database and dump/restore breaks if you manage this.



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command


Problem migrating dump to latest CVS snapshot.

Post by Thomas Lockha » Tue, 27 Mar 2001 04:09:30

Quote:> Seems Mandrake Linux is not the only platform where roundoff behavior is
> less IEEE-perfect than Thomas would like it to be.  Perhaps we need a
> slightly more robust approach to controlling roundoff error.

Go ahead. istm that asking modulo, trunc, etc to Do The Right Thing is
not a big deal, and it would be better to understand how to build
executables that can do math.

Certainly better than writing a bunch of extra checking code to work
around the inability of a compiler (or compiler options) to do IEEE
math. It *is* a standard, ya know ;)

                     - Thomas

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


1. cvs snapshot compile problems

On OBSD from cvs source,  clean checkout:

gcc -O2 -pipe -Wall -Wmissing-prototypes -Wmissing-declarations
-I../../../../src/include  -DLIBDIR=\"/usr/local/pgsql/lib\
" -DDLSUFFIX=\".so\"  -c -o dfmgr.o dfmgr.c
dfmgr.c: In function `load_external_function':
dfmgr.c:118: `RTLD_GLOBAL' undeclared (first use in this function)
dfmgr.c:118: (Each undeclared identifier is reported only once
dfmgr.c:118: for each function it appears in.)
gmake[4]: *** [dfmgr.o] Error 1
gmake[4]: Leaving directory

??  RTLD_GLOBAL problems?

- b


---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

2. DB-LIBRARY and bcp_xxxxxx

3. [ CVS: src]

4. inserting data

5. HeapTuple header changes cause core dumps in CVS tip

6. ADO Clones

7. Database Export : Dump Tables and Stored Procedures for Later Import

8. SQL Embedded: Handling NULLS

9. too late for dumping syslog ?

10. Migrating a datbase with snapshots using EXP/IMP

11. Problem: rerun snapshot because current snapshot files are obsolete

12. Problem: Transaction log dump bigger than entire database dump

13. Query - how to find later dates that latest in detail table