[BUGS] BUG #3699: Fails to compile DTrace Support
The following bug has been logged online: Bug reference: 3699 Logged by: Lee Packham Email address: [EMAIL PROTECTED] PostgreSQL version: 8.2.5 Operating system: OSX Leopard Description:Fails to compile DTrace Support Details: I have built a patch to enable a working DTrace on OSX with Postgres 8.2.5. Basically the problem is that the dtrace command on OSX doesn't have the -G parameter - so you have to use the newer -h method to produce a header file. I have put the patch on my blog. http://leenux.org.uk/dtrace-patches/dtrace-with-postgres-on-osx Hope this is of use to you guys. Cheers, Lee Packham ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #3700: initdb could not find suitable encoding for locale "Polish_Poland.1250"
The following bug has been logged online: Bug reference: 3700 Logged by: Marek Romanowski Email address: [EMAIL PROTECTED] PostgreSQL version: 8.3-beta1 Operating system: Windows XP Professional Description:initdb could not find suitable encoding for locale "Polish_Poland.1250" Details: I've installed 8.2 yesterday and everything was ok, so I think it's some kind of regression bug. Second run was with -E LATIN2 option, so encoding was given clearly, database was initialized, but some warnings about encoding showed up too. $ ./initdb -D "c:\java\pgdata-8.3" The files belonging to this database system will be owned by user "efigence". This user must also own the server process. The database cluster will be initialized with locale Polish_Poland.1250. could not determine encoding for locale "Polish_Poland.1250": codeset is "CP1250" initdb: could not find suitable encoding for locale "Polish_Poland.1250" Rerun initdb with the -E option. Try "initdb --help" for more information. $ ./initdb -D "c:\java\pgdata-8.3" -E LATIN2 The files belonging to this database system will be owned by user "efigence". This user must also own the server process. The database cluster will be initialized with locale Polish_Poland.1250. could not determine encoding for locale "Polish_Poland.1250": codeset is "CP1250" initdb: could not find suitable text search configuration for locale "Polish_Poland.1250" The default text search configuration will be set to "simple". creating directory c:/java/pgdata-8.3 ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers/max_fsm_pages ... 32MB/204800 creating configuration files ... ok creating template1 database in c:/java/pgdata-8.3/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok vacuuming database template1 ... ok copying template1 to template0 ... WARNING: could not determine encoding for locale "Polish_Poland.1250": codeset is "CP1250" DETAIL: Please report this to . ok copying template1 to postgres ... WARNING: could not determine encoding for locale "Polish_Poland.1250": codeset is "CP1250" DETAIL: Please report this to . ok WARNING: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the -A option the next time you run initdb. Success. You can now start the database server using: "c:\Program Files\PostgreSQL\8.3-beta1\bin\postgres" -D "c:/java/pgdata-8.3" or "c:\Program Files\PostgreSQL\8.3-beta1\bin\pg_ctl" -D "c:/java/pgdata-8.3" -l logfile start ---(end of broadcast)--- TIP 1: 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] BUG #3700: initdb could not find suitable encoding for locale "Polish_Poland.1250"
On Fri, Oct 26, 2007 at 08:39:21AM +, Marek Romanowski wrote: > > The following bug has been logged online: > > Bug reference: 3700 > Logged by: Marek Romanowski > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3-beta1 > Operating system: Windows XP Professional > Description:initdb could not find suitable encoding for locale > "Polish_Poland.1250" > Details: > > I've installed 8.2 yesterday and everything was ok, > so I think it's some kind of regression bug. This is a known issue in beta1 which was missing WIN1250. It has been fixed and will be in beta2. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3700: initdb could not find suitable encoding for locale "Polish_Poland.1250"
Marek Romanowski wrote: > The following bug has been logged online: > > Bug reference: 3700 > Logged by: Marek Romanowski > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.3-beta1 > Operating system: Windows XP Professional > Description:initdb could not find suitable encoding for locale > "Polish_Poland.1250" > Details: > > I've installed 8.2 yesterday and everything was ok, > so I think it's some kind of regression bug. > > Second run was with -E LATIN2 option, so encoding was > given clearly, database was initialized, but some > warnings about encoding showed up too. > > > > $ ./initdb -D "c:\java\pgdata-8.3" > The files belonging to this database system will be owned by user > "efigence". > This user must also own the server process. > > The database cluster will be initialized with locale Polish_Poland.1250. > could not determine encoding for locale "Polish_Poland.1250": codeset is > "CP1250" > initdb: could not find suitable encoding for locale "Polish_Poland.1250" > Rerun initdb with the -E option. This should be OK in beta2. WIN1250 accidentally got left out of a table in beta 1. Regards, Dave. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] connection problem
Help me ,please. I have installed pgsql-8.2.5 on redhat-Linux server and pdAdmin3 on windows-xp, When i try to connect to installed PGSQL on win-xp with Linux-server i get the message : Connection refused (0x274D/10061) All changes in pg_hba.conf and in postgresql.conf have done.Maybe i must to open some extra parameters in postgresql.conf file or do something else ? I have attached the pg_hba.conf and postgresql.conf files. please help me solving this problem. -- Annaiah H. contact number -- 948645 # PostgreSQL Client Authentication Configuration File # === # # Refer to the "Client Authentication" section in the # PostgreSQL documentation for a complete description # of this file. A short synopsis follows. # # This file controls: which hosts are allowed to connect, how clients # are authenticated, which PostgreSQL user names they can use, which # databases they can access. Records take one of these forms: # # local DATABASE USER METHOD [OPTION] # host DATABASE USER CIDR-ADDRESS METHOD [OPTION] # hostsslDATABASE USER CIDR-ADDRESS METHOD [OPTION] # hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTION] # # (The uppercase items must be replaced by actual values.) # # The first field is the connection type: "local" is a Unix-domain socket, # "host" is either a plain or SSL-encrypted TCP/IP socket, "hostssl" is an # SSL-encrypted TCP/IP socket, and "hostnossl" is a plain TCP/IP socket. # # DATABASE can be "all", "sameuser", "samerole", a database name, or # a comma-separated list thereof. # # USER can be "all", a user name, a group name prefixed with "+", or # a comma-separated list thereof. In both the DATABASE and USER fields # you can also write a file name prefixed with "@" to include names from # a separate file. # # CIDR-ADDRESS specifies the set of hosts the record matches. # It is made up of an IP address and a CIDR mask that is an integer # (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that specifies # the number of significant bits in the mask. Alternatively, you can write # an IP address and netmask in separate columns to specify the set of hosts. # # METHOD can be "trust", "reject", "md5", "crypt", "password", # "krb5", "ident", "pam" or "ldap". Note that "password" sends passwords # in clear text; "md5" is preferred since it sends encrypted passwords. # # OPTION is the ident map or the name of the PAM service, depending on METHOD. # # Database and user names containing spaces, commas, quotes and other special # characters must be quoted. Quoting one of the keywords "all", "sameuser" or # "samerole" makes the name lose its special character, and just match a # database or username with that name. # # This file is read on server startup and when the postmaster receives # a SIGHUP signal. If you edit the file on a running system, you have # to SIGHUP the postmaster for the changes to take effect. You can use # "pg_ctl reload" to do that. # Put your actual configuration here # -- # # If you want to allow non-local connections, you need to add more # "host" records. In that case you will also need to make PostgreSQL listen # on a non-local interface via the listen_addresses configuration parameter, # or via the -i or -h command line switches. # # TYPE DATABASEUSERCIDR-ADDRESS METHOD # IPv4 local connections: hostall all 127.0.0.1/32 md5 # IPv6 local connections: #hostall all ::1/128 md5 hostall 1.0.0.1 255.255.255.255 trust # - # PostgreSQL configuration file # - # # This file consists of lines of the form: # # name = value # # (The '=' is optional.) White space may be used. Comments are introduced # with '#' anywhere on a line. The complete list of option names and # allowed values can be found in the PostgreSQL documentation. The # commented-out settings shown in this file represent the default values. # # Please note that re-commenting a setting is NOT sufficient to revert it # to the default value, unless you restart the server. # # Any option can also be given as a command line switch to the server, # e.g., 'postgres -c log_connections=on'. Some options can be changed at # run-time with the 'SET' SQL command. # # This file is read on server startup and when the server receives a # SIGHUP. If you edit the file on a running system, you have to SIGHUP the # server for the changes to take effect, or use "pg_ctl reload". Some # settings, which are marked below, require a server shutdown and restart # to take effect. # # Memory units: kB = kilobytes MB = megabytes GB = gigabytes # Time units:ms = milliseconds s = seconds min = minutes h = hours d = days #--- # FILE LOCATIONS #-
Re: [BUGS] connection problem
"annaiah h" <[EMAIL PROTECTED]> writes: > When i try to connect to installed PGSQL on win-xp with Linux-server i get > the message : > Connection refused (0x274D/10061) Either you didn't start the postmaster, or there's a firewall filter blocking your access to port 5432 ... regards, tom lane ---(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] BUG #3699: Fails to compile DTrace Support
"Lee Packham" <[EMAIL PROTECTED]> writes: > I have built a patch to enable a working DTrace on OSX with Postgres 8.2.5. You can't seriously expect us to accept a patch that rips out Solaris dtrace support to put in OSX dtrace support :-(. Can't you fix it so that it still uses the PG_TRACEn macros? BTW, where did you get dtrace for OSX, anyway? I don't see it on my machines here... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3699: Fails to compile DTrace Support
From: Lee Packham <[EMAIL PROTECTED]> > I have built a patch to enable a working DTrace on OSX with Postgres 8.2.5. > Basically the problem is that the dtrace command on OSX doesn't have > the -G > parameter - so you have to use the newer -h method to produce a header > file. > It bothers me that the Apple's Dtrace port doesn't have the -G flag. We chose the current approach for simplicity and at the same time allowing us to easily introduce a generic framework so other OSes can plug in a similar tool if needed. I have yet to review your patch in detail, but I hope it doesn't break this generic framework. More later... -Robert ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #3699: Fails to compile DTrace Support
The only thing I couldn't do was sort out the makefile to auto generate the header file. So the patch has a pre-built header file. I don't know Make well, enough. Sorry. But yeah - I was pretty annoyed they broke the -G parameter (i.e. didn't include it at all. Cheers, Lee. On 10/26/07, Robert Lor <[EMAIL PROTECTED]> wrote: > From: Lee Packham <[EMAIL PROTECTED]> > > > I have built a patch to enable a working DTrace on OSX with Postgres 8.2.5. > > Basically the problem is that the dtrace command on OSX doesn't have > > the -G > > parameter - so you have to use the newer -h method to produce a header > > file. > > > > It bothers me that the Apple's Dtrace port doesn't have the -G flag. We chose > the current approach for simplicity and at the same time allowing us to > easily introduce a generic framework so other OSes can plug in a similar tool > if needed. I have yet to review your patch in detail, but I hope it doesn't > break this generic framework. More later... > > -Robert > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] Yet another problem with ILIKE and UTF-8
Hello Gregory, hello all, I've tested the DB created with hu_HU.UTF8 lc_* settings and it works like a charm! We'll re-create the database and move the contents. It's a nice improvement of 8.3 to detect and disallow such misconfiguration. -- Summing up the issue & fix (for googling): - Version: postgresql 8.2.x (and possibly older ones as well) - Symptom: UTF-8 values are stored correctly but some ILIKE queries don't return results as expected, even when searching for ASCII substrings. - Reason: database misconfiguration -> UPPER()/LOWER() cannot handle UTF-8 chars -> ILIKE cannot handle UTF-8 chars. The error above occurs if the DB is created with UTF-8 internal encoding, but lc_* settings are not referring UTF-8 locales. (Eg. bad locale reference: "hu_HU", good locale reference: "hu_HU.UTF8".) - Fix: a new database (or DB cluster?) should be created with the corrected lc_* settings. If there's data already, it should be dumped and restored (see steps below). - Additional info: lc_* settings (and a whole lot of others) can be displayed with the psql command "SHOW ALL". - Additional info: in case the DB is configured incorrectly, psql 8.2 just fails to match rows correctly (without any errors), but 8.3+ will reject this bad configuration in time. -- Thanks a lot, guys! Best regards, Gergely BOR On 10/25/07, Gregory Stark <[EMAIL PROTECTED]> wrote: > > "Gergely Bor" <[EMAIL PROTECTED]> writes: > > > We'll google the initdb stuff and try it ASAP. > > > > What I've tried is LOWER and UPPER, and they seem to return trash for > > Hungarian UTF-8 characters, but they handle ASCII well. (H... > > maybe ILIKE requires LOWER and UPPER to work? Would not be > > illogical...) > > It does. I think it works by just downcasing both strings. It's possible to do > better but tricky. I think 8.3 has an optimization for that for single-byte > encodings but it had to be disabled for utf-8 in the end. > > If it's returning trash for those characters then it's not prepared to handle > UTF-8 data. You have to use an encoding compatible with your locale and > vice-versa. > > If you want to store UTF-8 data I suggest you > > . add hu_HU.UTF-8 to /etc/locale.gen, > . rerun /usr/sbin/locale-gen > . pg_dump your database > . re-initdb with the locale set to hu_HU.UTF-8 > . pg_restore your data. > > Unfortunately that'll take quite a while and involve down-time. > > You should probably do this in a second directory aside from your existing > database just in case you've created any invalidly encoded utf-8 strings. > You'll have to fix them before restoring. (Actually I don't recall which > version got strict about that.) > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > ---(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] Possible planner bug/regression introduced in 8.2.5
Hi Tom, Hmm. I think there are two different bugs involved here. One is fixed by the attached patch, and it masks the performance problem on your test case, but I wonder whether it will be enough for your real application. Can you try this and see if it fixes 8.2.5 for you? many thanks for the quick patch! PostreSQL support is truly unbeatable... We did some test today with patched 8.2.5. For some cases it is ok but for large ones it is still taking quite a big time (e.g. for 23 joins is the planning time 107s). Maybe there's no regression from 8.2.4 - we'll do the tests against 8.2.4 on Monday - it's not usual for us to run with geqo switched off and we don't monitor the planning time - the total runtime for these queries is in minutes so we don't know were the time is spent. I'll keep you updated. Kuba ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] The PostgreSQL Data directory Must be on an NTFS formatted Volume
Hello I have a problem with the installation: Data directory error: The PostgreSQL Data directory Must be on an NTFS formatted Volume Regards Toke ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] Possible planner bug/regression introduced in 8.2.5
Jakub Ouhrabka <[EMAIL PROTECTED]> writes: > We did some test today with patched 8.2.5. For some cases it is ok but > for large ones it is still taking quite a big time (e.g. for 23 joins is > the planning time 107s). Maybe there's no regression from 8.2.4 - we'll > do the tests against 8.2.4 on Monday - it's not usual for us to run with > geqo switched off and we don't monitor the planning time - the total > runtime for these queries is in minutes so we don't know were the time > is spent. Yeah, I was afraid that might happen. In the test case you sent, if the first LEFT JOIN is changed to RIGHT JOIN then the runtime goes right back up, because then it actually is the case make_outerjoininfo is looking for where the two outer joins can't be reordered. So you probably have some cases like that in your real application. But I'd expect 8.2.4 to be equally slow because it also contains the code that is slow in that scenario. I'm hoping to get some time today to think about how that could be fixed. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #3699: Fails to compile DTrace Support
"Lee Packham" <[EMAIL PROTECTED]> writes: > Dtrace is in Leopard. Just so you know :) Hmph ... that might be enough of a reason to upgrade right there ... regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] The PostgreSQL Data directory Must be on an NTFS formatted Volume
On Fri, Oct 26, 2007 at 03:49:09PM +0200, [EMAIL PROTECTED] wrote: > Hello > > I have a problem with the installation: Data directory error: > > The PostgreSQL Data directory Must be on an NTFS formatted Volume That's not a bug. It's a pretty obvious instruction on what you need to do. Cheers, David. -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: [EMAIL PROTECTED] Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #3699: Fails to compile DTrace Support
Tom Lane-2 wrote: > > "Lee Packham" <[EMAIL PROTECTED]> writes: >> Dtrace is in Leopard. Just so you know :) > > Hmph ... that might be enough of a reason to upgrade right there ... > > I believe ZFS is also in Leopard. Even more reason to upgrade! -Robert -- View this message in context: http://www.nabble.com/BUG--3699%3A-Fails-to-compile-DTrace-Support-tf4695658.html#a13428697 Sent from the PostgreSQL - bugs mailing list archive at Nabble.com. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] Possible planner bug/regression introduced in 8.2.5
I wrote: > ...probably have some cases like that in your real application. But I'd > expect 8.2.4 to be equally slow because it also contains the code that > is slow in that scenario. I'm hoping to get some time today to think > about how that could be fixed. Please try the attached patch (in addition to the one I sent earlier). regards, tom lane binVPuFKEAvKv.bin Description: join-order-2.patch ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[BUGS] BUG #3701: Don't work intarray GIN indexes
The following bug has been logged online:
Bug reference: 3701
Logged by: girla
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3beta1
Operating system: Windows XP Proffesional SP2
Description:Don't work intarray GIN indexes
Details:
8.3beta1 never used intarray GIN indexes.
The same test case:
EXPLAIN
SELECT *
FROM intarr
WHERE (arr && ARRAY[132,20,78,45,457]);
on 8.2:
"Bitmap Heap Scan on intarr (cost=4.33..37.45 rows=10 width=64)"
" Recheck Cond: (arr && '{132,20,78,45,457}'::integer[])"
" -> Bitmap Index Scan on i_arr_gin (cost=0.00..4.33 rows=10 width=0)"
"Index Cond: (arr && '{132,20,78,45,457}'::integer[])"
and on 8.3beta1:
-
"Seq Scan on intarr (cost=0.00..238.00 rows=10 width=58)"
" Filter: (arr && '{132,20,78,45,457}'::integer[])"
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] The PostgreSQL Data directory Must be on an NTFS formatted Volume
[EMAIL PROTECTED] writes: > I have a problem with the installation: Data directory error: > > The PostgreSQL Data directory Must be on an NTFS formatted Volume In which way does this appear to be a bug? Is the volume you are trying to put the database on an NTFS-formatted one, and the system is not recognizing that? If that is so, then you should see about reporting what information you can so that we might be able to figure out why the volume is being misreported. If that is not the problem, and you are attempting to install a database on other than an NTFS volume, then this is not a bug, but rather some sort of refusal, elliptical or otherwise, on your part, to follow directions. -- let name="cbbrowne" and tld="linuxfinances.info" in name ^ "@" ^ tld;; http://linuxfinances.info/info/linux.html "The primary difference between computer salesmen and used car salesmen is that used car salesmen know when they're lying to you." ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #3701: Don't work intarray GIN indexes
"girla" <[EMAIL PROTECTED]> writes:
> 8.3beta1 never used intarray GIN indexes.
Works for me:
contrib_regression=# \d test__int
Table "public.test__int"
Column | Type| Modifiers
+---+---
a | integer[] |
Indexes:
"text_idx" gin (a gin__int_ops)
contrib_regression=# SELECT count(*) from test__int WHERE a && '{23,50}';
count
---
403
(1 row)
contrib_regression=# explain SELECT count(*) from test__int WHERE a &&
'{23,50}';
QUERY PLAN
-
Aggregate (cost=25.18..25.19 rows=1 width=0)
-> Bitmap Heap Scan on test__int (cost=4.31..25.16 rows=7 width=0)
Recheck Cond: (a && '{23,50}'::integer[])
-> Bitmap Index Scan on text_idx (cost=0.00..4.31 rows=7 width=0)
Index Cond: (a && '{23,50}'::integer[])
(5 rows)
contrib_regression=#
(This is using the database set up by contrib/intarray's regression
test.)
So if you want help you're going to need to provide much more detail,
like say your *whole* test case.
regards, tom lane
---(end of broadcast)---
TIP 6: explain analyze is your friend
