Re: [BUGS] BUG #6086: Segmentation fault
On Thu, Jun 30, 2011 at 3:32 AM, Dennis wrote:
> For some reason a 9.0.4 server which has always run completely stable, and
> without any recent changes, crashed ("WARNING: terminating connection
> because of crash of another server process" ..)
>
> Since it is not a debug build the backtrace is not that useful, but
> hopefully may give some idea of where to look, or ring a bell with someone.
>
> #0 0x000806a0d5dc in pthread_mutex_lock () from /lib/libthr.so.3
> #1 0x000800c1d965 in xmlRMutexLock () from /usr/local/lib/libxml2.so.5
> #2 0x000800c6c67d in xmlDictFree () from /usr/local/lib/libxml2.so.5
> #3 0x000800bb1ac5 in xmlFreeParserCtxt () from
> /usr/local/lib/libxml2.so.5
> #4 0x000800bc3f19 in xmlParseBalancedChunkMemoryRecover () from
> /usr/local/lib/libxml2.so.5
> #5 0x000800bc4090 in xmlParseBalancedChunkMemory () from
> /usr/local/lib/libxml2.so.
Any idea what query triggered this?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6126: CC parameter in to_char() behaves incorrectly
The following bug has been logged online:
Bug reference: 6126
Logged by: Artem Andreev
Email address: ar...@oktetlabs.ru
PostgreSQL version: 9.0.4
Operating system: Debian 6.0
Description:CC parameter in to_char() behaves incorrectly
Details:
CC parameter in to_char() behaves incorrectly with BC dates:
1st century BC:
select to_char('0002-01-01 00:00:00 BC' :: timestamp, 'CC');
>
to_char
-
01
2nd century BC:
select to_char('0101-01-01 00:00:00 BC' :: timestamp, 'CC');
=>
to_char
-
00
3rd century BC:
iliran=> select to_char('0301-01-01 00:00:00 BC' :: timestamp, 'CC');
to_char
-
-2
In all these cases EXTRACT(CENTURY FROM ...) yields the expected result
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6127: pg_restore failing: unexpected message type 0x58 during COPY from stdin
The following bug has been logged online: Bug reference: 6127 Logged by: Greg Johnson Email address: greg.john...@interprose.com PostgreSQL version: pg_dump (Postgr Operating system: CentOS release 5.6 (Final) Description:pg_restore failing: unexpected message type 0x58 during COPY from stdin Details: I am running into an error loading a backup of the production database.. never had a problem before. These are dump /restore commands I am using: pg_dump -Fc -h ackbar -U webar_admin webar -f /var/portal/backup/db/webar-20110719180003.gz pg_restore -d webar_dev -U webar_admin -Fc webar-20110719180003.gz Both machines have same version of postgres : [root@awing ~]# pg_dump --version pg_dump (PostgreSQL) 8.4.8 [root@dev ~]# pg_restore --version pg_restore (PostgreSQL) 8.4.8 MD5s are the same: [root@awing db]# md5sum webar-20110719180003.gz f4ec991e4635cd70a1f85864e04e6214 webar-20110719180003.gz [root@dev ~]# md5sum webar-20110719180003.gz f4ec991e4635cd70a1f85864e04e6214 webar-20110719180003.gz This is the error from dev while trying to restore: pg_restore: [custom archiver] could not read from input file: end of file Here is what I found in the pg_log file: LOG: checkpoint starting: xlog LOG: checkpoint complete: wrote 8147 buffers (3.1%); 0 transaction log file(s) added, 0 removed, 128 recycled; write=192.644 s, sync=1.613 s, total=194.269 s ERROR: unexpected message type 0x58 during COPY from stdin CONTEXT: COPY form_big, line 9195632 Here is another log entry: TRUNCATE TABLE ONLY form_field_config; LOG: statement: COPY form_field_config (form_field_config_id, form_config_id, identifier, label, field_type, field_group, required, display_on_summary, new_line, col_span, field_order, searchable, fk_form_config_id, fk_label, fk_on_delete_action, primary_key, form_big_column) FROM stdin; LOG: checkpoint starting: time LOG: checkpoint complete: wrote 160 buffers (0.1%); 0 transaction log file(s) added, 0 removed, 0 recycled; write=31.811 s, sync=0.066 s, total=33.898 s ERROR: unexpected message type 0x58 during COPY from stdin CONTEXT: COPY form_config, line 1 STATEMENT: COPY form_config (form_config_id, customer_id, identifier, form_config_type, label, description, icon, location, allow_multiple, created_by, create_date, last_updated_by, last_updated, view_on_update, view_on_insert, "position", record_label, converted, text_count, bigint_count, timestamp_count, real_count, boolean_count) FROM stdin; LOG: could not send data to client: Broken pipe STATEMENT: COPY form_config (form_config_id, customer_id, identifier, form_config_type, label, description, icon, location, allow_multiple, created_by, create_date, last_updated_by, last_updated, view_on_update, view_on_insert, "position", record_label, converted, text_count, bigint_count, timestamp_count, real_count, boolean_count) FROM stdin; LOG: unexpected EOF on client connection ERROR: unexpected message type 0x58 during COPY from stdin Looks like they are happening at different spots.. I have tried 5 different dump/restores and all error out. There is nothing in /var/log/messages -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6127: pg_restore failing: unexpected message type 0x58 during COPY from stdin
"Greg Johnson" writes: > I am running into an error loading a backup of the production database.. > ERROR: unexpected message type 0x58 during COPY from stdin > CONTEXT: COPY form_big, line 9195632 This looks like pg_restore is terminating unexpectedly. What do you see on the client end of it? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6127: pg_restore failing: unexpected message type 0x58 during COPY from stdin
Greg Johnson writes: > On Thu, Jul 21, 2011 at 11:44 AM, Tom Lane wrote: >> This looks like pg_restore is terminating unexpectedly. What do you see >> on the client end of it? > pg_restore: [custom archiver] could not read from input file: end of file Well, that suggests you have a truncated or otherwise corrupted pg_dump archive file. Do you get a similar failure if you just do "pg_restore -l" on the archive file? Is the pg_dump run reporting any signs of distress? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6127: pg_restore failing: unexpected message type 0x58 during COPY from stdin
Greg Johnson writes: > Interesting.. I was able to pg_restore -f to a file... and then psql -f the > resulting file. and it loaded just fine.. the down side to this method is I > cannot use the parallel load function (and the extra time). but I am glad > that I got the data loaded. Let me know if there is any other info I get > you. Parallel restore? You didn't mention using parallel restore before. Were the failed pg_restore runs using parallelism? regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] BUG #6128: A boolean variable doesn't evaluate properly in an IF conditional...
The following bug has been logged online: Bug reference: 6128 Logged by: Email address: dani...@megasystems.us PostgreSQL version: 8.3 Operating system: Windows XP Description:A boolean variable doesn't evaluate properly in an IF conditional... Details: I wrote some code in a PLPGSQL function to generate a printout string of some information. Basically, I create a string of printed characters, which my calling program will then print out... I wrote an IF conditional to generate different printing based on what input data I got... I declared the variable "put_the_in_city_online boolean := false" in my declaration section. I then had the following IF conditional inside a FOR LOOP structure with a record variable called "rec"... -- If the applicant has electric services, -- then we display a line indicating such... IF (rec.has_electric = 'Y') THEN IF (put_the_in_city_online = FALSE) THEN application_page_01 := application_page_01 || ' SERVICES: ELECTRIC ' || rec.electric_rate_category || ' ' || rec.in_or_out_of_city || end_of_line; put_the_in_city_online := true; ELSE application_page_01 := application_page_01 || 'ELECTRIC ' || rec.electric_rate_category || end_of_line; END IF; END IF; The bug occurs in the execution of these statements. I enter inside the first IF statement no problem, but the 2nd IF statement executes the opposite of what it should. The ELSE code is executing when the IF code should be executing! For some reason, POSTGRESQL does not evaluate ((put_the_in_city_online = FALSE) = true) correctly. This statement is true, but corresponding statements are not executed; the statements for ((put_the_in_city_online = FALSE) = false) end up being executed! I don't see any flaw in my logic. Postgresql doesn't seem to work correctly based on logic! -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #6127: pg_restore failing: unexpected message type 0x58 during COPY from stdin
pg_restore: [custom archiver] could not read from input file: end of file Thanks for your help! On Thu, Jul 21, 2011 at 11:44 AM, Tom Lane wrote: > "Greg Johnson" writes: > > I am running into an error loading a backup of the production database.. > > > ERROR: unexpected message type 0x58 during COPY from stdin > > CONTEXT: COPY form_big, line 9195632 > > This looks like pg_restore is terminating unexpectedly. What do you see > on the client end of it? > >regards, tom lane > -- Greg Johnson The InterProse Corporation Software Developer Phone: (360) 604-3531 x225 Fax: (360) 604-3579
Re: [BUGS] BUG #6128: A boolean variable doesn't evaluate properly in an IF conditional...
"" writes: > For some reason, POSTGRESQL does not evaluate ((put_the_in_city_online = > FALSE) = true) correctly. This is pretty hard to believe, and you're not going to get anyone to think it's anything except pilot error unless you provide a complete, reproducible example. Selectively quoting from your function does not provide anything anyone could investigate. Please see http://wiki.postgresql.org/wiki/Guide_to_reporting_problems regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
