[BUGS] COPY problem with bad dates
It looks like when a bad date is entered using COPY the backend connection gets killed. I noticed this when having a problem loading a database with several copies in one transaction. The backend died consistantly at the same point, but not near where the bad dates were. I eventually found the bad dates and corrected the problem with the load. However I noticed that the error message I got indicated the backend died, so I thought I should try to get a simpler case that shows the same problem. Below is a short psql example run against a 7.3 database that also gets the backend to crash, though not in the middle of a large transaction. bruno=> create table test (col1 timestamp); CREATE TABLE bruno=> copy test from stdin; Enter data to be copied followed by a newline. End with a backslash and a period on a line by itself. >> 11/31/02 >> \. ERROR: copy: line 1, Bad timestamp external representation '11/31/02' lost synchronization with server, resetting connection ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] strange problem
Title: strange problem Hi, I don't know what is going on here. Maybe somebody can help. Iam using postgresql 7.3. ici=# select id,pseudonym from user_all where pseudonym = 'autologin_funkey'; id | pseudonym +--- (0 rows) ici=# select id,pseudonym from user_all where pseudonym ~ '^autologin_funkey$'; id | pseudonym --+-- 6881 | autologin_funkey (1 row) ici=# update user_all set pseudonym = (select pseudonym from user_all where pseudonym ~ '^autologin_funkey$') where pseudonym ~ '^autologin_funkey$'; UPDATE 1 ici=# select id,pseudonym from user_all where pseudonym = 'autologin_funkey'; id | pseudonym --+-- 6881 | autologin_funkey (1 row) Sebastian Böhm Friendscout24.de
Re: [BUGS] COPY problem with bad dates
On Wed, Dec 18, 2002 at 09:14:18 -0600, Bruno Wolff III <[EMAIL PROTECTED]> wrote: > It looks like when a bad date is entered using COPY the backend connection > gets killed. I just tried it with 7.3.1 and get the same error. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] COPY problem with bad dates
Bruno Wolff III <[EMAIL PROTECTED]> writes: > ERROR: copy: line 1, Bad timestamp external representation '11/31/02' > lost synchronization with server, resetting connection This is not a backend crash, this is libpq's standard operating procedure for recovering from an error during COPY. If we had a less brain-dead COPY protocol (ie, one that actually had provisions for error abort), we'd not have to do this. See plans for 7.4 protocol revisions ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] strange problem
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?= <[EMAIL PROTECTED]> writes: > ici=3D# select id,pseudonym from user_all where pseudonym =3D > 'autologin_funkey'; > id | pseudonym > +--- > (0 rows) > ici=3D# select id,pseudonym from user_all where pseudonym ~ > '^autologin_funkey$'; > id |pseudonym > --+-- > 6881 | autologin_funkey > (1 row) That's pretty bizarre. Can you give a procedure for reproducing this from a standing start? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] strange problem
Title: AW: [BUGS] strange problem Hi, I did reindex, vacuum , dump/import, ... I also tried 7.3.1 -->> It happens only with btree index on that column, without index it works, with hash index also no problem. This happend to 0.3% of all rows in this table, after dump/import exactly the same rows were affected. Can somebody tell me how to import a 7.3(.1) dump into 7.2.3 ? It gives errors on import, so I cannot try it on 7.2.3. Hope that helps. Sebastian Böhm Friendscout24 -Ursprüngliche Nachricht- Von: Tom Lane [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 18. Dezember 2002 17:42 An: "Böhm, Sebastian (Vendor)" Cc: '[EMAIL PROTECTED]' Betreff: Re: [BUGS] strange problem =?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?= <[EMAIL PROTECTED]> writes: > ici=3D# select id,pseudonym from user_all where pseudonym =3D > 'autologin_funkey'; > id | pseudonym > +--- > (0 rows) > ici=3D# select id,pseudonym from user_all where pseudonym ~ > '^autologin_funkey$'; > id | pseudonym > --+-- > 6881 | autologin_funkey > (1 row) That's pretty bizarre. Can you give a procedure for reproducing this from a standing start? regards, tom lane
Re: [BUGS] strange problem
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?= <[EMAIL PROTECTED]> writes: > This happend to 0.3% of all rows in this table, after dump/import exactly > the same rows were affected. So you can reproduce the problem after dumping/reloading? If you could send me the dump file (off-list!) I'd be willing to investigate here ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] strange problem
Title: AW: AW: [BUGS] strange problem Hi, I installed an newer rpm of the glibc (2.2.2-8.1 / 2.2.2-4 before) und reinitialized the database with locale=C. Just after installing the rpm, the problem was still there (reindex I did), but after dump/initdb --locale=C/import the problem was gone. Dont know wheater it is the reinit with new glibc or the reinit with locale=C, dont have the time to figure it out. (have to sleep now) Thank you for your help ! Sebastian Böhm -Ursprüngliche Nachricht- Von: Tom Lane [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 19. Dezember 2002 00:18 An: "Böhm, Sebastian (Vendor)" Betreff: Re: AW: [BUGS] strange problem Thanks for sending the test data. Unsurprisingly, I don't see any failure here: regression=# select id,pseudonym from test4 where pseudonym = 'autologin_funkey'; id | pseudonym --+-- 6881 | autologin_funkey (1 row) but I was already suspecting a platform-dependent or locale-dependent problem. Please update to glibc 2.2.3 or later, then rebuild (or at least reindex) your tables, and let me know if you can still see a problem. regards, tom lane
Re: [BUGS] strange problem
=?iso-8859-1?Q?=22B=F6hm=2C_Sebastian_=28Vendor=29=22?= <[EMAIL PROTECTED]> writes: > I installed an newer rpm of the glibc (2.2.2-8.1 / 2.2.2-4 before) und > reinitialized the database with locale=3DC. > Just after installing the rpm, the problem was still there (reindex I = > did), > but after dump/initdb --locale=3DC/import the problem was gone. > Dont know wheater it is the reinit with new glibc or the reinit with > locale=3DC, dont have the time to figure it out. If I am correct in guessing that strcoll is to blame, then setting the locale to C would have made the problem go away. I am dubious that glibc 2.2.2-8 fixes the strcoll bug --- the notes I have say that that fix appeared in glibc 2.2.3. However, if you're happy running in C locale then it doesn't really matter whether strcoll works or not ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Bug #851: cast() no longer works in array inserts
Malcolm Tredinnick ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
cast() no longer works in array inserts
Long Description
If I have a table containing an array (e.g. a bigint[] field), then it does not appear
to be possible to insert values using the cast() function. This used to work in
PostgreSQL 7.1, but no longer works in 7.2 or 7.3. I cannot see anything in the
release notes saying the previous behaviour was considered incorrect and the
documentation seems to indicate it should be possible.
If this is not meant to work, then this is a documentation bug, because it is unclear
how to insert a constant like 0 into a bigint field in an array.
The example code below works in 7.1, but not in later versions. The error message
given is
ERROR: Bad int8 external representation "{0::bigint, 0::bigint}"
for the first example and similarly for the second (with the appropriate cast
statements substituted).
Sample Code
create table foo (bar bigint[]);
insert into foo values ('{"0"::bigint, "0"::bigint}');
insert into foo values ('{cast("0" as decimal(12)), cast("0" as decimal(12))}');
No file was uploaded with this report
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] Bug #851: cast() no longer works in array inserts
[EMAIL PROTECTED] writes: > cast() no longer works in array inserts It never has. You are confusing a rather lame failure of error checking in 7.1 with a feature. 7.1 and before will in fact take quite a lot of random garbage in array input strings :=( regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bug #851: cast() no longer works in array inserts
Malcolm Tredinnick <[EMAIL PROTECTED]> writes:
> So given that one cannot just insert 0 into a bigint field (even an
> array of bigints), since postgres complains it is not of the correct
> type, how is one supposed to fille a field of bigint[] with {0, 0}?
I must be missing something ... what is wrong with
regression=# create table foo (bar bigint[]);
CREATE TABLE
regression=# insert into foo values ('{0, 0}');
INSERT 1101788 1
regression=# select * from foo;
bar
---
{0,0}
(1 row)
regards, tom lane
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
