[BUGS] BUG #6425: Bus error in slot_deform_tuple
The following bug has been logged on the website: Bug reference: 6425 Logged by: orval Email address: postg...@dunquino.com PostgreSQL version: 9.0.6 Operating system: Solaris 10 u9 Description: This is intermittent and hard to reproduce but crashes consistently in the same place. That place is backend/access/common/heaptuple.c line 1104: values[attnum] = fetchatt(thisatt, tp + off); off is always 0, tp is an unaligned address (not divisible by 4 -- this is Sparc BTW.) I've seen tup->t_hoff set to 0x62 and 0x82 in different core files. This system is using streaming replication, and the problem always occurrs on the secondary. The system is under heavy load, both in terms of queries and DML on the primary. There are usually quite a lot of deadlocks going on. The query in question each time is a join between a table called preferences and one called preference_fields. The tuple is in preference_fields. I have not confirmed this is a cause, but the following statement does appear in one of the scripts in action: DELETE FROM preference_fields WHERE preference_field_id NOT IN (SELECT DISTINCT preference_field_id FROM preferences); There is also this kind of nasty stuff going on: ALTER TABLE preferences RENAME TO preferences_old; ALTER TABLE preferences_1326144465 RENAME TO preferences; Where preferences_1326144465 is a copy of preferences that is used during a data import process. At the moment I have asserts in the places where t_hoff is set, looking for (address % 4 != 0) but it's been going for a couple of days and it hasn't happened yet. Any advice on where better to put some debugging would be gratefully received. -- 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 #7750: pid file conflict in RedHat
The following bug has been logged on the website:
Bug reference: 7750
Logged by: Timothy J Bruce
Email address: postg...@tbruce.com
PostgreSQL version: 9.1.6
Operating system: RedHat v6.2
Description:
In line 238 of the rpm based init.d script, the pid file is called
specifically with a qualified path ("status -p
/var/run/postmaster-9.1.pid"), even though line 70 specifies a variable to
point to the pid file (pidfile="/var/run/postmaster-9.1.pid").
This is with rpm version of postgres 9.1.4 and 9.1.6 (we haven't tested
9.1.7 at this time).
--
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 #5055: Invalid page header error
> Was there any particular event that marked the onset of these issues? > Anything in the system logs (dmesg / syslog etc) around that time? Unfortunately, cannot recall anything abnormal. > Was Pg forcibly killed and restarted, or the machine hard-reset? (This > _shouldn't_ cause data corruption, but might give some starting point > for looking for a bug). It is a normal pg shutdown followed by a reboot. > *** DID YOU TAKE COPIES OF YOUR DATA FILES BEFORE "FIXING" THEM *** ? No. Should have taken a backup on hindsight. At that time, the primary motivation was to get over the hump and have the query result succssfully. Correct me if I am wrong, but I thought one of the, if not the most, primary tasks for relational databases is to ensure that no data loss ever occurs. Which is why I was initially surprised that the issue did not get enough importnace. But now it seems more like the community not knowing what triggered the issue i.e. not knowing which component to fix. But I do have one overriding question - since postgres is still running on the same hardware, wouldn't it rule out hardware as the primary suspect? _ Ready for Fall shows? Use Bing to find helpful ratings and reviews on digital tv's. http://www.bing.com/shopping/search?q=digital+tv's&form=MSHNCB&publ=WLHMTAG&crea=TEXT_MSHNCB_Vertical_Shopping_DigitalTVs_1x1
[BUGS] Inserts taking exponentially longer as table size grows
We have seen a strange situation with postgres 8.3.6 taking longer times for inserting a fixed amount of data. The insertion time is increasing as the data in the table is growing. We tried to use COPY command but to no avail. The increase is also not linear. Insert is one of the basic operations. I am surprised to run into it on a fairly well established platform. _ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/
[BUGS] win32 executables
Hello, I tried your 8.3beta3 and 8.2.5 zip-packaged (no installer) versions. The 8.2.5 does not react at all to the starting of any of the executables (on the command line, the prompt immediately returns, incidentially the return code is 53, but there are no visible signs of unhappiness; strace on cygwin says "Process 2504, exception C135 at 7C974ED1", which may or may not indicate evil), the 8.3beta3 shows the error "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem" (this is actually a lie since mine says this in german with a spelling mistake: "Diese Anwendung konnte nicht gestartet werden, weil die Anwenungskonfiguration nicht korrekt ist. Zur Problembehebung sollten Sie die Anwendung neu installieren."). Apparently this can be fixed by being careful in the use of Visual Studio, the details can be read up here: http://trolltech.com/developer/knowledgebase/faq.2006-12-05.8269192532/ Great thanks go to the Postgres team! You have really built an amazing piece of software. I use it as my preferred database (custom compiled on each box. On windows at work, however, I'm currently using Apache Derby, but as you can tell from my efforts, I'm in the process of switching to something more powerful). Best regards, Oliver Seidel ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [BUGS] Improper processing of random values in sub-queries
Tom Lane <[EMAIL PROTECTED]> wrote: > I assume though that this is a made-up example and is not the case > that's really troubling you. What is the actual problem you are looking > at? I was generating random test data and naively assumed that ()::integer truncated its value, therefore I was getting duplicate values. Once I I realised that random()::integer was rounded I had no further problem, but figured should report the bug that I had already noticed. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[BUGS] Slow views
I know this has been discussed many times before but I'm not entirely
satisfied with the answer, which I understand is "views are essentially
macros". Despite that Postgres is producing the correct output, I hope
you'll all agree that the performance issue is serious enough to call
this a "bug."
I'm running Postgres 7.4.3 installed on Fedora Core 1 (i386) from rpms
downloaded from ftp.postgres.org.
I've got a view defined as:
CREATE VIEW stock_exp_v AS
SELECT stock_code, barcode, title, supplier.description AS supplier,
format.description AS format, rating.description AS rating,
genre_list(stock_code) AS genre, release_date, price, srp
FROM stock
LEFT JOIN supplier USING (supplier_code)
LEFT JOIN format USING (format_code)
LEFT JOIN rating USING (rating_code);
When I use the view in a join the query takes 52 seconds, for example:
SELECT trim(stock_code), barcode, title, supplier, format, rating, genre,
release_date, o.price, o.srp, quantity
FROM order_lines o
LEFT JOIN stock_exp_v USING (stock_code);
btrim |barcode|title|supplier
| format | rating | genre | release_date | price | srp | quantity
-+---+-++++---+--+---+--+--
B00392S | 9397810039223 | GREATEST WILDLIFE SHOW ON EARTH THE | ROADSHOW
ENTERTAINMENT | VHS|| | 2000-06-05 | 1.23 | 1.10 | 15
B00392S | 9397810039223 | GREATEST WILDLIFE SHOW ON EARTH THE | ROADSHOW
ENTERTAINMENT | VHS|| | 2000-06-05 | 1.23 | 1.10 | 15
| | |
||| | | 1.23 | 1.10 |5
(3 rows)
Time: 52110.369 ms
When I expand the view by hand it takes only 27 milliseconds:
SELECT trim(stock_code), barcode, title, supplier.description,
format.description, rating.description, genre_list(o.stock_code),
release_date, o.price, o.srp, quantity
FROM order_lines o
LEFT JOIN stock USING (stock_code)
LEFT JOIN supplier USING (supplier_code)
LEFT JOIN format USING (format_code)
LEFT JOIN rating USING (rating_code);
btrim |barcode|title| description
| description | description | genre_list | release_date | price | srp | quantity
-+---+-++-+-++--+---+--+--
B00392S | 9397810039223 | GREATEST WILDLIFE SHOW ON EARTH THE | ROADSHOW
ENTERTAINMENT | VHS | || 2000-06-05 | 1.23 | 1.10 |
15
B00392S | 9397810039223 | GREATEST WILDLIFE SHOW ON EARTH THE | ROADSHOW
ENTERTAINMENT | VHS | || 2000-06-05 | 1.23 | 1.10 |
15
| | |
| | || | 1.23 | 1.10 |5
(3 rows)
Time: 26.820 ms
The plans are different; views are clearly not "essentially macros":
videos=> explain select trim(stock_code), barcode, title, supplier, format, rating,
genre, release_date, o.price, o.srp, quantity
videos-> from order_lines o left join stock_exp_v using (stock_code);
QUERY PLAN
Merge Left Join (cost=4344.01..4447.40 rows=202 width=217)
Merge Cond: ("outer"."?column5?" = "inner".stock_code)
-> Sort (cost=1.05..1.06 rows=3 width=45)
Sort Key: (o.stock_code)::bpchar
-> Seq Scan on order_lines o (cost=0.00..1.03 rows=3 width=45)
-> Sort (cost=4342.95..4393.38 rows=20171 width=188)
Sort Key: stock_exp_v.stock_code
-> Subquery Scan stock_exp_v (cost=3.85..1711.67 rows=20171 width=188)
-> Hash Left Join (cost=3.85..1509.96 rows=20171 width=125)
Hash Cond: ("outer".rating_code = "inner".rating_code)
-> Hash Left Join (cost=2.79..1233.63 rows=20171 width=135)
Hash Cond: ("outer".format_code = "inner".format_code)
-> Hash Left Join (cost=1.75..930.03 rows=20171 width=146)
Hash Cond: ("outer".supplier_code =
"inner".supplier_code)
-> Seq Scan on stock (cost=0.00..625.71 rows=20171
width=133)
-> Hash (cost=1.60..1.60 rows=60 width=33)
Re: [BUGS] Can't join on null values
People, Thanks for your help with my problem with NULL values. Also, particular thanks for a hint on where to find a copy of SQL-92 standard, something I didn't already have. It was annoying to discover that UNIQUE didn't have what I felt was the "obvious" meaning, but it doesn't and PostgreSQL does operate correctly. David ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] BUG #6668: hashjoin cost problem
Why is cost_hashjoin estimating 50 billion tuple comparisons for 10K rows of output though? From: Tom Lane To: postgresu...@yahoo.com Cc: pgsql-bugs@postgresql.org Sent: Wednesday, May 30, 2012 10:03 PM Subject: Re: [BUGS] BUG #6668: hashjoin cost problem postgresu...@yahoo.com writes: > create table small(i) as select (g/1000) * 1000 from > generate_series(1,1) g; > create table large(i) as select generate_series(1,1); > It doesn't matter how big the big table is... for this distribution large > table is hashed. I don't think that's wrong. If it hashes the small table, there cannot be less than 1000 entries on each populated hash chain; adding more work_mem doesn't help. The planner is designed to avoid hashing such unfriendly distributions as that. The fact that you can get a somewhat smaller runtime by forcing hashing in the other direction suggests that its cost factors are not quite right for your specific case --- but it's a long way from that observation to deciding that we should change the cost factors for everyone. In any case, the sizes of the tables are not the only determinant of which one should be hashed. regards, tom lane
[BUGS] BUG #7611: \copy (and COPY?) incorrectly parses nul character for windows-1252
The following bug has been logged on the website: Bug reference: 7611 Logged by: James Email address: sams.james+postg...@gmail.com PostgreSQL version: 9.1.6 Operating system: Ubuntu Linux 12.04 Description: I have a file with several nul characters in it. The file itself appears to be encoded as windows-1252, though I am not 100% certain of that. I do know that other software (e.g. Python) can decode the data as windows-1252 without issue. Postgres's \copy, however, chokes on the nul byte: ERROR: unterminated CSV quoted field CONTEXT: COPY promo_nonactive_load_fake, line 239900 Note that the error is wrong, the field is quoted but postgres seems to jump forward in the file when it encounters the nul bytes. Further, the line number is wrong. That is the length of the file (in lines), not the line on which the error occurs, which is several hundred lines before this. Deleting the nul byte characters allowed copy to proceed normally. I experienced similar issues with psycopg2 and copy_expert using COPY FROM STDIN and this file. -- 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 #6252: After drop the default database 'postgres', I can not create a database by 'createdb.exe'
The following bug has been logged online: Bug reference: 6252 Logged by: Can not create DB by 'createdb.exe' when DB 'postgres' is droped Email address: yanghui...@gmail.com PostgreSQL version: 9.0.5 Operating system: Windows XP SP2 Description:After drop the default database 'postgres', I can not create a database by 'createdb.exe' Details: 1.drop database 'postgres' 2.create a database by createdb.exe the follow error message will dispaly: Can not create DB by 'createdb.exe' when database 'postgres' is droped PS:file: '\postgresql-9.0.5\src\bin\scripts\createdb.c' Line: 195 Source: conn = connectDatabase(strcmp(dbname, "postgres") == 0 ? "template1" : "postgres", host, port, username, prompt_password, progname); *Sorry for my poor English -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
