Re: [BUGS] BUG #8124: How to uninstall and reinstall postgreSQL 9.2
Hi The OS is Windows or Linux (Ubuntu)? In any case, installation will also create Uninstaller. Running the uninstaller will remove everything from the installation except the 'data' directory. Why were r u unable to remove? On Sun, Apr 28, 2013 at 3:28 PM, wrote: > The following bug has been logged on the website: > > Bug reference: 8124 > Logged by: Eleasar V > Email address: eleasa...@gmail.com > PostgreSQL version: 9.2.0 > Operating system: Windows 7 > Description: > > Please provide me the information of how to install and reinstall > postgreSQL > 9.2 in ubuntu.. I installed it but unable to remove. > > > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- Sandeep Thakkar Senior Software Engineer EnterpriseDB Corporation The Enterprise Postgres Company Phone: +91.20.30589523 Website: www.enterprisedb.com EnterpriseDB Blog: http://blogs.enterprisedb.com/ Follow us on Twitter: http://www.twitter.com/enterprisedb This e-mail message (and any attachment) is intended for the use of the individual or entity to whom it is addressed. This message contains information from EnterpriseDB Corporation that may be privileged, confidential, or exempt from disclosure under applicable law. If you are not the intended recipient or authorized to receive this for the intended recipient, any use, dissemination, distribution, retention, archiving, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by reply e-mail and delete this message.
[BUGS] Optimizer problem with multi-column index
Hello, we have an issue concerning multi-column indexes not being used by the planner. version PostgreSQL 9.2.3 on x86_64-unknown-linux-gnu, compiled by gcc (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012], 64-bit (same has been tested on postgres 8.4 with exactly the same results) default_statistics_target is set to 1000. The following is a detailed description, completely sufficient to reproduce the problem. consider the following table: create sequence plannertest_seq; create table plannertest ( id bigint not null default nextval( 'plannertest_seq' ), xyz_id bigint not null default random() * 9 + 1, datum timestamp not null ); with these 2 indexes: create index plannertest_datum on plannertest( datum ); create index plannertest_xyz_id_datum on plannertest( xyz_id, datum ); we now insert data into the table using the following statement: insert into plannertest( datum ) select datum from generate_series( '2010-01-01 00:00', now(), interval '1 minute' ); INSERT 0 1748655 analyze plannertest; then we issue the following select: select datum from plannertest where xyz_id = 3 and datum >= '2012-10-25 06:00:00' and Datum < '2013-01-27 06:00:00'; which yields the following plan: Index Scan using plannertest_datum on plannertest (cost=0.00..5444.83 rows=15164 width=24) Index Cond: ((datum >= '2012-10-25 06:00:00'::timestamp without time zone) AND (datum < '2013-01-27 06:00:00'::timestamp without time zone)) Filter: (xyz_id = 3) so the optimizer here chooses the 1-column index on column "datum" even though the 2-column index would be 10 times as selective. we now drop the 1-column index. drop index plannertest_datum; and then issue the same statement again. now we get the following plan: QUERY PLAN -- Bitmap Heap Scan on plannertest (cost=630.09..12623.71 rows=15164 width=24) Recheck Cond: ((xyz_id = 3) AND (datum >= '2012-10-25 06:00:00'::timestamp without time zone) AND (datum < '2013-01-27 06:00:00'::timestamp without time zone)) -> Bitmap Index Scan on plannertest_xyz_id_datum (cost=0.00..626.30 rows=15164 width=0) Index Cond: ((xyz_id = 3) AND (datum >= '2012-10-25 06:00:00'::timestamp without time zone) AND (datum < '2013-01-27 06:00:00'::timestamp without time zone)) this is really funny. Apparently, in the first case, where the 1-column index (which does NOT contain the column to be filtered) is used, the planner forgets about the necessity to visit every tuple in order to do the filtering on the "xyz" column. In the second case, where everything needed is included in the index, however, the planner thinks it has to use an absolutely unnecessary bitmap heap scan. A simple forward index scan would do here. BTW, exactly the same plans are output when I do a "select *".
Re: [BUGS] Optimizer problem with multi-column index
Marc Schablewski writes: > we have an issue concerning multi-column indexes not being used by the > planner. I see no particular bug here, just a rational response to an artificial test case. The planner is being discouraged by the random character of the data in your first index column: that means that an indexscan on that index would jump all over the place while accessing the table. In contrast, the other index is *exactly* in heap order and so using it will result in nice sequential touches of the heap. So with default random_page_cost, the cost to use the two-column index comes out quite a bit higher than the cost to use the one-column index. A bitmap scan is less subject to the random-access problem, but it still loses out compared to following an index that's exactly in heap order. Whether this test case corresponds very well to your real use case is hard to say, but it seems a bit extreme from here. BTW, had you vacuumed the table, the planner would've preferred an index-only scan of the two-column index, since with the table marked all-visible the potential for lots of random fetches from the heap goes away. But you didn't. If these plan choices don't correspond to the actual runtimes you're seeing, that probably suggests that you need to lower random_page_cost for your environment. This test case is small enough to fit in RAM on most machines, so you'd have to set random_page_cost to 1 to expect to get accurate predictions for the test case as-is. I don't know how large your real table is ... 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 #8125: server connecting error
The following bug has been logged on the website: Bug reference: 8125 Logged by: Pradip Patel Email address: pradi...@gmail.com PostgreSQL version: 9.0.0 Operating system: Windows Description: i have a backup of only the "data" folder of postgres and my serer was crashed now i m trying to install thesame version of postgres and restore that file but after that i m unable to connect with postgres server that showing me the following error ""could not connect to server: Connection refused (0x274D/10061) Is the server running on host "localhost" and accepting TCP/IP connections on port 5432? "" -- 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 #8127: After failed insert a select to figure out what failed is rejected
The following bug has been logged on the website: Bug reference: 8127 Logged by: Matti Aarnio Email address: matti.aar...@methics.fi PostgreSQL version: 9.2.4 Operating system: Fedora 18 Description: With table: CREATE TABLE demo ( pkey INTEGER PRIMARY KEY, key2 VARCHAR UNIQUE, key3 VARCHAR UNIQUE ); An insert that fails secondary constraint key does return SQL State 23505, and maybe an explanation message telling that "Key (key3)=".. " is duplicate." With Oracle we ask a SELECT after such an error on that table for all possibly existing secondary keys values, and get them to report detailed conflict information. With PostgreSQL we get following error on those error analysis SELECTs: ERROR: current transaction is aborted, commands ignored until end of transaction block Could PostgreSQL be similarly permissive (with respect of Oracle) allowing SELECTs within same transaction context that was already rejected? -- 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 #8118: Wrong sorting text
Thank you, works fine. Bug reference: 8118 Logged by: whiplash Email address:whipl...@bss.org.ua PostgreSQL version: 9.2.2 Operating system: Linux (Fedora 11, Fedora 16 and Ubuntu 12.04) Description: I execute query (1): SELECT t.name FROM ( SELECT 'AAA AAA' AS name UNION ALL SELECT 'AAA_AAA' UNION ALL SELECT 'BBB_AAA' UNION ALL SELECT 'BBB AAB' ) t ORDER BY t.name and I getting a result: AAA AAA AAA_AAA BBB_AAA BBB AAB It's a matter of collate. If you want ascii ordering specify collate "C". ... ORDER BY t.name collate "C"; name - AAA AAA AAA_AAA BBB AAB BBB_AAA (4 rows) -- Daniele -- 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 #8126: error in translation dutch
The following bug has been logged on the website: Bug reference: 8126 Logged by: dennis coomans Email address: dennis.coom...@hva.nl PostgreSQL version: 8.4.17 Operating system: Win7 Description: in PgAdmin menu Tools is translated %Gereedschappen The '%' should not be there -- 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 #8125: server connecting error
go to services--- right click on postgresql service goto path to executable and change runservice to start -- View this message in context: http://postgresql.1045698.n5.nabble.com/BUG-8125-server-connecting-error-tp5753634p5753656.html Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. -- 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 #8125: server connecting error
On 4/29/2013 12:02 AM, pradi...@gmail.com wrote: The following bug has been logged on the website: Bug reference: 8125 Logged by: Pradip Patel Email address:pradi...@gmail.com PostgreSQL version: 9.0.0 Operating system: Windows Description: i have a backup of only the "data" folder of postgres and my serer was crashed now i m trying to install thesame version of postgres and restore that file but after that i m unable to connect with postgres server that showing me the following error ""could not connect to server: Connection refused (0x274D/10061) Is the server running on host "localhost" and accepting TCP/IP connections on port 5432? "" this is not a bug, and shouldn't be on the bug list. would best to bring this to the pgsql-general email list. at a minimum, after installing the new postgres software, you'd have to STOP postgres, THEN restore your data directory, then restart postgres. if it doesn't restart, then check the logfiles and/or event viewer to see why. if postgres was running when you made your data backup, odds are pretty good that backup is no good, unless you used backup software that used Windows Volume Snapshot Service (VSS). -- john r pierce 37N 122W somewhere on the middle of the left coast -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] RESET ROLE issue (Unreproduceable (so far) )
Debuggers,
Having an interesting issue with RESET ROLE. So far it's defied my
ability to come up with a simpler test case so that I can diagnose the
issue. Here's the situ:
1. plpgsql function create_data_tables() creates a bunch of tables.
2. as part of this, it uses SET ROLE to a role the calling user is a
member of ("dbowner").
3. create_data_tables then calls create_partitions() to partition the
newly created tables, in a loop.
4. create_partitions() also does SET ROLE dbowner, and RESET ROLE at the
end of the function.
5. If called, on the ~~ 8th iteration of create_partitions(), it has a
permissions problem: "must be owner of table new_master_table"
6. If I remove the SET/RESET from the create_partitions function, it
works fine.
Anyway, I can't imagine how you could diagnose this without a valid test
case, and my attempts to construct a very simple reproduceable one so
far have met with failure. So I'm filing this bug *in case* we see other
issues with repetitive RESET ROLE calls in the future.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
[BUGS] Fw: [pgadmin-support] (Bug) Numeric fault calculation
sent to pgsql-bugs list.
Best Regards,
Kanitchet Vaiassava
999 Nawamin Rd., Nuanjun, Buengkum, Bangkok 10230, Thailand
Mobile +66 89 515 9955; Office +66 2 944 2000 Ext.1204; Fax +66 2 944 2020
---
From: Kevin Grittner
Sent: Wednesday, April 24, 2013 8:34 PM
To: Kanitchet Vaiassava
Subject: Re: ***(Updated)*** Re: [BUGS] Fw: [pgadmin-support] (Bug) Numeric
fault calculation
Hi Kanitchet,
It is best to keep the list copied so that everyone is aware of these things.
Could you please resend with a copy to the list?
Thanks,
-Kevin
--
From: Kanitchet Vaiassava
To: kgri...@ymail.com
Sent: Tuesday, April 23, 2013 9:46 PM
Subject: ***(Updated)*** Re: [BUGS] Fw: [pgadmin-support] (Bug) Numeric fault
calculation
Dear Mr.Kevin Grittner
First, sorry for another send on this. I’ve tried this on
MySQL server
1# SELECT CAST((3.00 * (1.00/3.00)) AS DECIMAL(15,10))
2# SELECT CAST(3.00 AS DECIMAL) * (CAST(1.00 AS DECIMAL) / CAST(3.00 AS
DECIMAL))
Result is (same) : 1.00
http://dev.mysql.com/doc/refman/5.5/en/precision-math.html
> The MySQL library for fixed-point arithmetic.
These features have several implications for numeric operations and provide a
high degree of compliance with standard SQL:
PostgreSQL server
for postgrsql may treat as numeric to numeric calculation
1/3 = 0.33
0.3 * 3 = 0.
#1
PostgreSQL
SELECT (3.00::numeric * (1.00::numeric /3.00::numeric))
Result is : 0.00
#2
PostgreSQL (However, I don’t know if this should be 1.00 or maybe
postgres auto cast 3.00 to 3.00::numeric)
SELECT (3.00 * (1.00 /3.00))::numeric
Result is : 0.00
I knows the demand may not sufficient but if we’re using library fixed-point
arithmetic like MySQL and its not cause development time so much,
please consider this.
Thank you
Best Regards,
Kanitchet Vaiassava
ThaiAce Capital Co., Ltd
999 Nawamin Rd., Nuanjun, Buengkum, Bangkok 10230, Thailand
Mobile +66 89 515 9955; Office +66 2 944 2000 Ext.1204; Fax +66 2 944 2020
---
From: Kanitchet Vaiassava
Sent: Wednesday, April 24, 2013 8:50 AM
To: Kevin Grittner
Cc: Kanitchet Vaiassava ; Kanitchet Vaiassava
Subject: Re: [BUGS] Fw: [pgadmin-support] (Bug) Numeric fault calculation
Dear Mr.Kevin Grittner
Thank you very much for your quick reply with clearly explanation and
useful suggestion.
I hope this can be done someway in the future because I think it affected
when we use postgresql to do some calculation about monetary
by using SQL or Stored Procedure (that I affected and more when the money is
lage) and maybe affected some critical scientific calculation that needed to
use many multiply & division or others math function that may result to this
problem.
Sorry for bad English.
Best Regards,
Kanitchet Vaiassava
ThaiAce Capital Co., Ltd
999 Nawamin Rd., Nuanjun, Buengkum, Bangkok 10230, Thailand
Mobile +66 89 515 9955; Office +66 2 944 2000 Ext.1204; Fax +66 2 944 2020
---
From: Kevin Grittner
Sent: Wednesday, April 24, 2013 3:46 AM
To: Kanitchet Vaiassava ; pgsql-bugs@postgresql.org
Cc: Kanitchet Vaiassava
Subject: Re: [BUGS] Fw: [pgadmin-support] (Bug) Numeric fault calculation
Kanitchet Vaiassava wrote:
> [division and some math functions using the numeric type can
> sometimes have a result which the numeric type cannot represent
> exactly]
Yeah, you can use a simpler example:
test=# select '1'::numeric / '3'::numeric;
?column?
0.
(1 row)
test=# select '3'::numeric * ('1'::numeric / '3'::numeric);
?column?
0.
(1 row)
> So I think this problem should be solve? or at least, it should
> be note in document for other developer to be more careful.
Yeah, there should probably be something in the docs to indicate
that not all rational numbers (and certainly no irrational or
imaginary numbers) can be stored as a single numeric value without
loss of precision.
It might be interesting to create a "rational" type which would
internally hold two numeric values, and which would be capable of
doing what you want. I'm not sure that the demand is sufficient to
back the development of it, though. (Is there a convention for how
to indicate the repeating part of a decimal fraction when you can't
draw a line over those digits?)
In the absence of such a type, you might want to arr
