[HACKERS] citex regression fails with de.UTF8 locale
I setup more locale testing on gothic moth and citext regression test
fails.
See
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-04-22%2020:06:01
Problem is here:
---
SELECT citext_cmp('B'::citext, 'a'::citext) AS one;
one
-
!1
(1 row)
-- Do some tests using a table and index.
--- 216,222
SELECT citext_cmp('B'::citext, 'a'::citext) AS one;
one
-
! 28
(1 row)
-- Do some tests using a table and index.
---
It seems to me that citex_cmp can return any integer value. It depends
what wcscoll() returns. I think it should be changed to:
SELECT citext_cmp('B'::citext, 'a'::citext) 0 AS one;
Zdenek
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] citex regression fails with de.UTF8 locale
Zdenek Kotala wrote:
It seems to me that citex_cmp can return any integer value. It depends
what wcscoll() returns. I think it should be changed to:
SELECT citext_cmp('B'::citext, 'a'::citext) 0 AS one;
The comment in varstr_cmp() claims that it returns -1, 0 or 1. That's
not accurate then.
Comment and test case fixed. I considered changing varstr_cmp to really
return -1, 0 or 1, but I didn't because the behavior has been unchanged
for ages and all the callers are happy with it. That's a heavily called
function so any extra cycles there could make a difference.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New trigger option of pg_standby
Fujii Masao wrote: On Wed, Apr 22, 2009 at 4:27 AM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: Fujii Masao wrote: On Tue, Apr 14, 2009 at 2:41 PM, Fujii Masao masao.fu...@gmail.com wrote: I'd like to propose another simple idea; pg_standby deletes the trigger file *whenever* the nextWALfile is a timeline history file. A timeline history file is restored at the end of recovery, so it's guaranteed that the trigger file is deleted whether nextWALfile exists or not. A timeline history file is restored also at the beginning of recovery, so the accidentally remaining trigger file is deleted in early warm-standby as a side-effect of this idea. Here is the revised patch as above. If you notice something, please feel free to comment. Ok, looking at this in more detail now. A couple of small things: We mustn't remove the trigger file immediately even in fast mode. As noted elsewhere in this thread, we have the same bug in fast mode where pg_standby gets stuck if you copy WAL files directly into pg_xlog. Yes, there is the same problem also in fast mode. But, in fast mode, the trigger file has to be deleted immediately if it's found. Otherwise, recovery may fail as follows. 1. pg_standby finds the trigger file for fast mode, and returns non-zero without deleting the trigger file. 2. the startup process tries to read the WAL file from pg_xlog, but it's not found. 3. the startup process tries to restore the last applied WAL file using pg_standby. 4. (Again) pg_standby finds the trigger file for fast mode, and returns non-zero without deleting the trigger file. 5. the startup process tries to read the last applied WAL file, but it's not found. (though the last applied file was of course restored before, the restored one cannot be read here) 6. recovery fails because the last applied WAL file cannot be read. On the other hand, if pg_standby returns 0 also in fast mode when the requested file and trigger file exist, ISTM that there is not much difference between fast and smart mode; also in fast mode, all the available WAL files would be applied. Hmm, pg_standby could truncate the trigger file, so that it acts like a smart trigger in the subsequent pg_standby invocations. Assuming the postgres user has write access to it; it probably does because it can delete it, but conceivably it has only read access on the file but write access on the directory it's in. This is getting complicated, though. I guess it would be enough to document that you mustn't copy any extra files into pg_xlog if you use a fast trigger. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] citex regression fails with de.UTF8 locale
Heikki Linnakangas píše v čt 23. 04. 2009 v 10:22 +0300: Zdenek Kotala wrote: Comment and test case fixed. Thanks I considered changing varstr_cmp to really return -1, 0 or 1, but I didn't because the behavior has been unchanged for ages and all the callers are happy with it. That's a heavily called function so any extra cycles there could make a difference. I think keep it as it is good decision. strcmp() also does not guarantee -1, 0, 1. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] RFE: Transparent encryption on all fields
Dear pgsql hackers, The encryption options http://www.postgresql.org/docs/8.3/static/encryption-options.html fall short for my thread case. Consider the case where all users of a machine are trusted and the machine automatically locks itself down on a period of inactivity, and only local psql connections are allowed. If the machine is stolen, the only current protection is to use an encrypted drive. This is impractical because it requires a manual start of the psql server and essentially means each user has to use a separate instance and copy of the databases, each storing their data in their own encrypted drives. (e.g. consider Apple OS X FileVault, Windows TrueCrypt, or Linux/BSD equivalents) If it were feasible, a transparent crypto on all fields for a given database would be just the trick! Connections to such databases could require a key as well as the user login. Queries could then continue as if it was a normal connection and all fields would be unencrypted on the fly. This particular approach might be a little too naive, but it is a threat case I would urge you to consider. All security comes with a cost, the cost here should be only minimal performance hit and no changes to queries. -- Sam smime.p7s Description: S/MIME cryptographic signature
Re: [HACKERS] New trigger option of pg_standby
Hi, On Thu, Apr 23, 2009 at 4:49 PM, Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote: This is getting complicated, though. I guess it would be enough to document that you mustn't copy any extra files into pg_xlog if you use a fast trigger. Agreed. I added this note into document. Attached is the updated patch. I also fixed my bug which pg_standby returns 0 even if the requested file fails to be restored in smart mode. This patch is ready to commit, I think. Please review this. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center pgstandby_change_trigger_0423.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Re: Synch Replication: Synchronization of files between Primary Standby
Hi, On Wed, Apr 22, 2009 at 9:21 PM, K, Niranjan (NSN - IN/Bangalore) niranja...@nsn.com wrote: Starting a new thread related to synchronization of the data files, WAL etc.. between Primary and standby servers in Synchronous replication patch. Use case: Whenever the primary and standby are out of sync due to network problems. Existing handling is to prepare the standby by 1) Deleting the $PGDATA on standby 2) Make a fresh base backup of the primary and load this data to the standby 3) Setup the necessary configurations (ex. recovery) and start the standby server In the earlier discussions, please check the link (point 2 related to direct connection between primary and standby), i think we still need to work to conclude on what will be done. http://archives.postgresql.org/pgsql-hackers/2009-02/msg01160.php I'm now implementing the capability to transfer a file related to xlog (i.e. xlog segment file, backup history file and timeline history file). This is used when there are missing files in the standby, and they are automatically copied from the primary. As usability aspect, you don't need to configure warm-standby for Synch Rep any longer before starting the standby. I'll show the detailed design of it before very long. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] RFE: Transparent encryption on all fields
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Apr 23, 2009 at 12:43:30PM +0100, Sam Halliday wrote: Dear pgsql hackers, The encryption options http://www.postgresql.org/docs/8.3/static/encryption-options.html [...] If it were feasible, a transparent crypto on all fields for a given database would be just the trick! Connections to such databases could require a key as well as the user login [...] If I understand you correctly you are proposing to do the decryption server-side. This doesn't seem to make much sense (at least not beyond encrypting the partition where the data is). Either the machine is stolen when shut down, or the machine is stolen when running. In the first case you are fine, in the second you are lost. It's the same as with an encrypted partition. Providing the key/passphrase to unlock the partition is possible over the net. Keeping the (at least the decryption) key client-side makes much more sense (and you can provide different clients with different keys). The only drawback is when you need an index over an encrypted field :-( Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ8HzFBcgs9XrR2kYRAlcMAJ4irB6+J0/8KxSpDFKCidRyVkA6cgCeKSBi UqMNLQ1QLrYGsb0YZ+d1aNY= =RSOK -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Prepared transactions vs novice DBAs, again
Joshua D. Drake j...@commandprompt.com wrote: I am not opposed to making the default zero. +1 making zero the default for 8.4 I am also +1 on adding the warnings. +1, but less urgent, lower priority -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] RFE: Transparent encryption on all fields
In response to to...@tuxteam.de: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Apr 23, 2009 at 12:43:30PM +0100, Sam Halliday wrote: Dear pgsql hackers, The encryption options http://www.postgresql.org/docs/8.3/static/encryption-options.html [...] If it were feasible, a transparent crypto on all fields for a given database would be just the trick! Connections to such databases could require a key as well as the user login [...] If I understand you correctly you are proposing to do the decryption server-side. This doesn't seem to make much sense (at least not beyond encrypting the partition where the data is). Either the machine is stolen when shut down, or the machine is stolen when running. In the first case you are fine, in the second you are lost. It's the same as with an encrypted partition. Providing the key/passphrase to unlock the partition is possible over the net. Keeping the (at least the decryption) key client-side makes much more sense (and you can provide different clients with different keys). The only drawback is when you need an index over an encrypted field :-( It's possible that this could be accomplished by something like Veil, or the built-in implementation that's coming in some future version of PG (is it scheduled for 8.5 at this point?) Anyway, if a Veil rule required the user to enter a password that would decrypt their key then store it in the session, this could be used for subsequent queries to encrypted fields. Since each user has their own key, the data is protected from all sorts of priv escalations, theft, etc (really, just about every attack vector aside from password brute forcing and social engineering ... and those will require other methods of protection anyway.) -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PL compilations ignores LDFLAGS
I hit a problem with libtcl.so that LDFLAGS is not propagated. The same problem is with other PL languages as well. Is it intention or a bug? thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Zdenek Kotala zdenek.kot...@sun.com writes: I hit a problem with libtcl.so that LDFLAGS is not propagated. The same problem is with other PL languages as well. Is it intention or a bug? It's intentional; LDFLAGS is for linking executables and may not be suitable for shlibs. I see that Makefile.shlib makes exceptions for some platforms though. What *specific* problem are you having, on what platform? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
On Thursday 23 April 2009 17:50:47 Zdenek Kotala wrote: I hit a problem with libtcl.so that LDFLAGS is not propagated. The same problem is with other PL languages as well. Is it intention or a bug? For shared libraries, you need to use LDFLAGS_SL instead. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Zdenek Kotala píše v čt 23. 04. 2009 v 16:50 +0200: I hit a problem with libtcl.so that LDFLAGS is not propagated. The same problem is with other PL languages as well. Is it intention or a bug? I'm looking on Makefile.shlib and I see there strange line: # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) It seems to me that one of these line are not correct. But anyway I lost -R somewhere. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] RFE: Transparent encryption on all fields
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote: [...] It's possible that this could be accomplished by something like Veil, Veil? Care to share an URL? Sorry for my ignorance - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ8IeHBcgs9XrR2kYRAk/CAJ9d9vuth3gcEkmYSLOzHXkYDSaOXQCffEjE DTKysAGopIw6nUQIrAk7NRs= =TNgv -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] RFE: Transparent encryption on all fields
In response to to...@tuxteam.de: On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote: [...] It's possible that this could be accomplished by something like Veil, Veil? Care to share an URL? Google knows :) http://veil.projects.postgresql.org/curdocs/index.html -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Tom Lane píše v čt 23. 04. 2009 v 11:11 -0400: Zdenek Kotala zdenek.kot...@sun.com writes: I hit a problem with libtcl.so that LDFLAGS is not propagated. The same problem is with other PL languages as well. Is it intention or a bug? It's intentional; LDFLAGS is for linking executables and may not be suitable for shlibs. I see that Makefile.shlib makes exceptions for some platforms though. What *specific* problem are you having, on what platform? I have problem with setup builfarm member on Solaris 10. I need to pass -Rpath (rpath). I can do it by LD_OPTIONS as we do it for package building. I had only doubt if it is correct behavior. however it seems to me that $rpath should be set like --with-libs, but it look likes that it does not work. Thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Peter Eisentraut píše v čt 23. 04. 2009 v 18:11 +0300: On Thursday 23 April 2009 17:50:47 Zdenek Kotala wrote: I hit a problem with libtcl.so that LDFLAGS is not propagated. The same problem is with other PL languages as well. Is it intention or a bug? For shared libraries, you need to use LDFLAGS_SL instead. I see. Thanks I will try it. Could anybody fix ./configure to show correct help? Thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] RFE: Transparent encryption on all fields
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Apr 23, 2009 at 11:23:20AM -0400, Bill Moran wrote: [...] Veil? Care to share an URL? Google knows :) http://veil.projects.postgresql.org/curdocs/index.html Thanks! [yes, Google knew, but it had so many veils it got me completely furled] Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ8IvdBcgs9XrR2kYRAlT8AJ41IsOphvUE1dYh1vZAcf6OnJnSAACcDPpE OnCJlvNjaeAyzkCxeBK0xFY= =iEJC -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Copyright waiver from Helios (fix for non-BSD copyright)
I have received the attached email from HELIOS Software GmbH giving us permission to change the licensing of HELIOS-contributed software to our project to the official BSD license. (I am BCC'ing them.) I think we should re-add the AIX files we removed from CVS yesterday, and then remove the non-BSD HELIOS copyright from CVS HEAD and all back branches. --- Helmut Tschemernjak wrote: Dear Herr Seifert, Dear Bruce Momjian, I am the founder and president of HELIOS Software, Jens-Uwe Mager left in 2002 HELIOS. We agree to change to all contributions of HELIOS source codes for the PostgreSQL project into a BSD License. If you have further questions please contact me. best regards / mit freundlichen Gruessen, Helmut Tschemernjak HELIOS Software GmbH President -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Zdenek Kotala zdenek.kot...@sun.com writes: Tom Lane pÃÅ¡e v Ät 23. 04. 2009 v 11:11 -0400: What *specific* problem are you having, on what platform? I have problem with setup builfarm member on Solaris 10. I need to pass -Rpath (rpath). I can do it by LD_OPTIONS as we do it for package building. I had only doubt if it is correct behavior. Well, $(rpath) is included into SHLIB_LINK on every platform, so the question is why that's not getting set. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Copyright waiver from Helios (fix for non-BSD copyright)
Bruce Momjian br...@momjian.us writes: I think we should re-add the AIX files we removed from CVS yesterday, Why? That code is ten years obsolete. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Copyright waiver from Helios (fix for non-BSD copyright)
Bruce Momjian wrote: I have received the attached email from HELIOS Software GmbH giving us permission to change the licensing of HELIOS-contributed software to our project to the official BSD license. (I am BCC'ing them.) I think we should re-add the AIX files we removed from CVS yesterday, and then remove the non-BSD HELIOS copyright from CVS HEAD and all back branches. Maybe we could just re-copyright the files in the back branches, and leave HEAD alone ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Copyright waiver from Helios (fix for non-BSD copyright)
Alvaro Herrera wrote: Bruce Momjian wrote: I have received the attached email from HELIOS Software GmbH giving us permission to change the licensing of HELIOS-contributed software to our project to the official BSD license. (I am BCC'ing them.) I think we should re-add the AIX files we removed from CVS yesterday, and then remove the non-BSD HELIOS copyright from CVS HEAD and all back branches. Maybe we could just re-copyright the files in the back branches, and leave HEAD alone ... OK, I thought there was some uncertainty about whether people were using the AIX code. -- Bruce Momjian br...@momjian.ushttp://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Copyright waiver from Helios (fix for non-BSD copyright)
Bruce Momjian br...@momjian.us writes: OK, I thought there was some uncertainty about whether people were using the AIX code. Somebody suggested that the code might be needed on pre-5.3 AIX. But after I looked into the files and found out the code is only needed pre *4.3*, I think the odds of anyone still wanting it are nil. I concur with Alvaro: change the back branch copyrights and leave HEAD as it is. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] citex regression fails with de.UTF8 locale
On Apr 23, 2009, at 12:22 AM, Heikki Linnakangas wrote:
Zdenek Kotala wrote:
It seems to me that citex_cmp can return any integer value. It
depends
what wcscoll() returns. I think it should be changed to:
SELECT citext_cmp('B'::citext, 'a'::citext) 0 AS one;
The comment in varstr_cmp() claims that it returns -1, 0 or 1.
That's not accurate then.
Comment and test case fixed. I considered changing varstr_cmp to
really return -1, 0 or 1, but I didn't because the behavior has been
unchanged for ages and all the callers are happy with it. That's a
heavily called function so any extra cycles there could make a
difference.
Thanks, I also changed it in my version for 8.3.
https://svn.kineticode.com/citext/trunk/
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Why do we let CREATE DATABASE reassign encoding?
If I have locale set to C, I can do this: regression=# create database u8 encoding 'utf8'; CREATE DATABASE regression=# create database l1 encoding 'latin1' template u8; CREATE DATABASE Had I had any actual utf8 data in u8, l1 would now contain encoding-corrupt information. Given that we've tried to clamp down on encoding violations in recent releases, I wonder why this case is still allowed. (In non-C locales, this will typically fail because the two different encodings can't both match the locale. But I don't believe it's our policy to enforce encoding validity only for non-C locales.) We should presumably let the encoding be changed when cloning from template0, and probably it's reasonable to trust the user if either source or destination DB encoding is SQL_ASCII. In other cases I'm thinking it should fail. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Tom Lane wrote: If I have locale set to C, I can do this: regression=# create database u8 encoding 'utf8'; CREATE DATABASE regression=# create database l1 encoding 'latin1' template u8; CREATE DATABASE Had I had any actual utf8 data in u8, l1 would now contain encoding-corrupt information. Given that we've tried to clamp down on encoding violations in recent releases, I wonder why this case is still allowed. Wow, I'm surprised we allow that. Never occurred to me to try. We should presumably let the encoding be changed when cloning from template0, and probably it's reasonable to trust the user if either source or destination DB encoding is SQL_ASCII. In other cases I'm thinking it should fail. Agreed, that's exactly what we did with per-database collation. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Tom Lane píše v čt 23. 04. 2009 v 11:42 -0400: Zdenek Kotala zdenek.kot...@sun.com writes: Tom Lane píše v čt 23. 04. 2009 v 11:11 -0400: What *specific* problem are you having, on what platform? I have problem with setup builfarm member on Solaris 10. I need to pass -Rpath (rpath). I can do it by LD_OPTIONS as we do it for package building. I had only doubt if it is correct behavior. Well, $(rpath) is included into SHLIB_LINK on every platform, so the question is why that's not getting set. I went through the makefiles and it is set correctly. I expected that --with-libs automatically adds path into $(rpath), but it is --libdir what is used. If I run ldd -rU on any libs or pl*.so then I got: unused search path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/cube.so) unused search path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/libpgtypes.so) unused search path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/libpq.so) unused search path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/pgcrypto.so) unused search path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/pltcl.so) unused search path=/usr/postgres/8.3/lib (RUNPATH/RPATH from file /usr/postgres/8.3/lib/sslinfo.so) Which is wrong. I already discussed this issue with Peter a moth ago without any result. But I find now that plperl.so override rpathdir and it could be used in other libs too. I supposed to do something like this for libpq, libpgtypes and so on. *** pgsql.orig.d976d4abedca/src/interfaces/libpq/Makefile 2009-04-23 20:07:21.178749132 +0200 --- pgsql.orig/src/interfaces/libpq/Makefile2009-04-23 20:07:21.194173674 +0200 *** *** 65,70 --- 65,71 endif SHLIB_EXPORTS = exports.txt + rpath = all: all-lib For plctl.so I suggest to use path to libtcl.so which can be detect in configure. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
In response to Tom Lane t...@sss.pgh.pa.us: If I have locale set to C, I can do this: regression=# create database u8 encoding 'utf8'; CREATE DATABASE regression=# create database l1 encoding 'latin1' template u8; CREATE DATABASE Had I had any actual utf8 data in u8, l1 would now contain encoding-corrupt information. Given that we've tried to clamp down on encoding violations in recent releases, I wonder why this case is still allowed. (In non-C locales, this will typically fail because the two different encodings can't both match the locale. But I don't believe it's our policy to enforce encoding validity only for non-C locales.) We should presumably let the encoding be changed when cloning from template0, and probably it's reasonable to trust the user if either source or destination DB encoding is SQL_ASCII. In other cases I'm thinking it should fail. On a pedantic level, doesn't this remove the ability to have databases on a single cluster that are different encodings? I mean, if template1 is utf8, and I can't change that using CREATE DATABASE, then I'm stuck with utf8 for all databases on that cluster ... unless I'm missing something. Granted, there's the potential for special cases with databases used only for templates, but as I see it, this should be allowed, it should just fail if any data in the template can't be converted to the desired encoding. I mean, I can always alter template1 by inserting non-utf8 data, and then try to use it to create a utf8 encoded database ... -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Zdenek Kotala zdenek.kot...@sun.com writes: I supposed to do something like this for libpq, libpgtypes and so on. *** pgsql.orig.d976d4abedca/src/interfaces/libpq/Makefile 2009-04-23 20:07:21.178749132 +0200 --- pgsql.orig/src/interfaces/libpq/Makefile 2009-04-23 20:07:21.194173674 +0200 *** *** 65,70 --- 65,71 endif SHLIB_EXPORTS = exports.txt + rpath = all: all-lib That seems like a pretty awful idea. How do you know that the rpath isn't being used to pick up stuff like openssl? For plctl.so I suggest to use path to libtcl.so which can be detect in configure. I believe that we expect to get any required switches for that out of the TCL_LIB_SPEC and/or TCL_LIBS variables, which we get from tclconfig. I wonder if you are working with an improperly configured Tcl installation. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Tom Lane wrote: If I have locale set to C, I can do this: regression=# create database u8 encoding 'utf8'; CREATE DATABASE regression=# create database l1 encoding 'latin1' template u8; CREATE DATABASE Had I had any actual utf8 data in u8, l1 would now contain encoding-corrupt information. Given that we've tried to clamp down on encoding violations in recent releases, I wonder why this case is still allowed. (In non-C locales, this will typically fail because the two different encodings can't both match the locale. But I don't believe it's our policy to enforce encoding validity only for non-C locales.) We should presumably let the encoding be changed when cloning from template0, and probably it's reasonable to trust the user if either source or destination DB encoding is SQL_ASCII. In other cases I'm thinking it should fail. Really? You want to forbid selecting an encoding when the source is template1, which is the default, and template1 is not SQL_ASCII? So the following sequence woiuld be illegal: initdb -E latin1 createdb -E utf8 I think we have a bit more thinking to do on this - I don't have a reasonable solution immediately in my head. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Bill Moran wmo...@potentialtech.com writes: In response to Tom Lane t...@sss.pgh.pa.us: We should presumably let the encoding be changed when cloning from template0, and probably it's reasonable to trust the user if either source or destination DB encoding is SQL_ASCII. In other cases I'm thinking it should fail. On a pedantic level, doesn't this remove the ability to have databases on a single cluster that are different encodings? I mean, if template1 is utf8, and I can't change that using CREATE DATABASE, then I'm stuck with utf8 for all databases on that cluster ... unless I'm missing something. You're supposed to clone from template0, not template1, when creating DBs that are different in either encoding or locale from the installation default. We already enforce this except for having missed the special case of C locale. (There might be some corner cases involving UTF8 on Windows, too; not sure about that.) The reason is that template0 is expected to contain only ASCII data, but template1 might not. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Bill Moran wrote: In response to Tom Lane t...@sss.pgh.pa.us: We should presumably let the encoding be changed when cloning from template0, and probably it's reasonable to trust the user if either source or destination DB encoding is SQL_ASCII. In other cases I'm thinking it should fail. On a pedantic level, doesn't this remove the ability to have databases on a single cluster that are different encodings? I mean, if template1 is utf8, and I can't change that using CREATE DATABASE, then I'm stuck with utf8 for all databases on that cluster ... unless I'm missing something. You could still use template0 as template for a database with any encoding, like: CREATE DATABASE .. TEMPLATE = template0; We can special case template0 because we know its contents are pure 7-bit ascii which is compatible with any server encoding. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Andrew Dunstan and...@dunslane.net writes: So the following sequence woiuld be illegal: initdb -E latin1 createdb -E utf8 Yes, that's rather the point. Note that it already *is* illegal unless you happen to have selected C locale; AFAICS that is an oversight and not intentional. For instance, going in the other direction in en_US locale, I get $ createdb -E latin1 l1 createdb: database creation failed: ERROR: encoding LATIN1 does not match locale en_US.utf8 DETAIL: The chosen LC_CTYPE setting requires encoding UTF8. You can get around this by cloning template0 instead of template1 (we assume template0 contains nothing that's encoding-specific). Possibly the docs will need to be improved to emphasize that. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: So the following sequence woiuld be illegal: initdb -E latin1 createdb -E utf8 Yes, that's rather the point. Note that it already *is* illegal unless you happen to have selected C locale; AFAICS that is an oversight and not intentional. Ok, then I agree that we need a big warning on that in the docs. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
In response to Tom Lane t...@sss.pgh.pa.us: Bill Moran wmo...@potentialtech.com writes: In response to Tom Lane t...@sss.pgh.pa.us: We should presumably let the encoding be changed when cloning from template0, and probably it's reasonable to trust the user if either source or destination DB encoding is SQL_ASCII. In other cases I'm thinking it should fail. On a pedantic level, doesn't this remove the ability to have databases on a single cluster that are different encodings? I mean, if template1 is utf8, and I can't change that using CREATE DATABASE, then I'm stuck with utf8 for all databases on that cluster ... unless I'm missing something. You're supposed to clone from template0, not template1, when creating DBs that are different in either encoding or locale from the installation default. We already enforce this except for having missed the special case of C locale. Ah ... was not aware of that. It hasn't come up in my usage. (There might be some corner cases involving UTF8 on Windows, too; not sure about that.) The reason is that template0 is expected to contain only ASCII data, but template1 might not. Makes sense, with that explanation. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
So it would still be possible to byass this check by cloning a database into SQL_ASCII and then cloning it into the desired encoding? Doesn't sound like it really accomplishes much. I do seem to recall some discussion about this way back. I don't recall the conclusion but I remember some talk about detecting an empty template database and the ned to reindex. -- Greg On 23 Apr 2009, at 19:46, Bill Moran wmo...@potentialtech.com wrote: In response to Tom Lane t...@sss.pgh.pa.us: If I have locale set to C, I can do this: regression=# create database u8 encoding 'utf8'; CREATE DATABASE regression=# create database l1 encoding 'latin1' template u8; CREATE DATABASE Had I had any actual utf8 data in u8, l1 would now contain encoding-corrupt information. Given that we've tried to clamp down on encoding violations in recent releases, I wonder why this case is still allowed. (In non-C locales, this will typically fail because the two different encodings can't both match the locale. But I don't believe it's our policy to enforce encoding validity only for non-C locales.) We should presumably let the encoding be changed when cloning from template0, and probably it's reasonable to trust the user if either source or destination DB encoding is SQL_ASCII. In other cases I'm thinking it should fail. On a pedantic level, doesn't this remove the ability to have databases on a single cluster that are different encodings? I mean, if template1 is utf8, and I can't change that using CREATE DATABASE, then I'm stuck with utf8 for all databases on that cluster ... unless I'm missing something. Granted, there's the potential for special cases with databases used only for templates, but as I see it, this should be allowed, it should just fail if any data in the template can't be converted to the desired encoding. I mean, I can always alter template1 by inserting non-utf8 data, and then try to use it to create a utf8 encoded database ... -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Greg Stark greg.st...@enterprisedb.com writes: So it would still be possible to byass this check by cloning a database into SQL_ASCII and then cloning it into the desired encoding? Doesn't sound like it really accomplishes much. Well, it accomplishes preventing stupid encoding violations. The point came to mind when I saw a post a little bit ago on -general in which the poster seemed to imagine that CREATE DATABASE would convert encodings for him. Since that is not happening in the foreseeable future, I think we need to prevent the system from acting like it would work. If we wanted to be entirely anal about this, we could allow SQL_ASCII destination with a different source encoding, but not the reverse. However, we currently consider that you're on your own to ensure sanity when using SQL_ASCII as far as locale goes, so I'm not sure why the policy would be different for encoding. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Tom Lane wrote: If we wanted to be entirely anal about this, we could allow SQL_ASCII destination with a different source encoding, but not the reverse. However, we currently consider that you're on your own to ensure sanity when using SQL_ASCII as far as locale goes, so I'm not sure why the policy would be different for encoding. The trouble is that people won't know the provenance of their database. I think we should try to guarantee as far as possible that if a database has encoding X then all the data in it is valid in that encoding. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
On Apr 23, 2009, at 12:00 PM, Tom Lane wrote: You can get around this by cloning template0 instead of template1 (we assume template0 contains nothing that's encoding-specific). Possibly the docs will need to be improved to emphasize that. I was just about to suggest that. With this change, template0 is suddenly going to be a lot more important for people to know about and make use of. Best, David -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Tom Lane píše v čt 23. 04. 2009 v 14:47 -0400: Zdenek Kotala zdenek.kot...@sun.com writes: I supposed to do something like this for libpq, libpgtypes and so on. *** pgsql.orig.d976d4abedca/src/interfaces/libpq/Makefile 2009-04-23 20:07:21.178749132 +0200 --- pgsql.orig/src/interfaces/libpq/Makefile2009-04-23 20:07:21.194173674 +0200 *** *** 65,70 --- 65,71 endif SHLIB_EXPORTS = exports.txt + rpath = all: all-lib That seems like a pretty awful idea. How do you know that the rpath isn't being used to pick up stuff like openssl? Dynamic linker explicitly looks into /lib and /usr/lib directory. If openssl is placed e.g. in /usr/sfw/lib (Solaris 10) then you need specify -R (or -rpath) option, because postgresql libs are in /usr/postgres/8.3/lib. It make sense to set rpath=libdir for example when somebody install postgres into /usr/local/lib. But I don't like this idea when compilation auto setup it. What you can do in case, when you have more openssl version on the system? One in /usr/local/lib and one in /usr/lib and you prefer /usr/lib for openssl. I think if user want to opessl from same location as libpq he should specified it explicitly. For plctl.so I suggest to use path to libtcl.so which can be detect in configure. I believe that we expect to get any required switches for that out of the TCL_LIB_SPEC and/or TCL_LIBS variables, which we get from tclconfig. I wonder if you are working with an improperly configured Tcl installation. Problem is that TCL_LD_SEARCH_FLAGS is not use in pltcl Makefile to override rpath. See patch. Unfortunately it does not work on Solaris 11, because it is wrongly defined. On Solaris 10 and RHEL 4 it seems to be ok. diff -Nrc pgsql.orig.d976d4abedca/configure.in pgsql.orig/configure.in *** pgsql.orig.d976d4abedca/configure.in2009-04-23 22:08:39.205236380 +0200 --- pgsql.orig/configure.in 2009-04-23 22:08:39.212144346 +0200 *** *** 1709,1715 if test $with_tcl = yes; then PGAC_PATH_TCLCONFIGSH([$with_tclconfig]) PGAC_EVAL_TCLCONFIGSH([$TCL_CONFIG_SH], ! [TCL_INCLUDE_SPEC,TCL_LIB_FILE,TCL_LIBS,TCL_LIB_SPEC,TCL_SHARED_BUILD]) AC_SUBST(TCL_SHLIB_LD_LIBS)dnl don't want to double-evaluate that one # now that we have TCL_INCLUDE_SPEC, we can check for tcl.h ac_save_CPPFLAGS=$CPPFLAGS --- 1709,1715 if test $with_tcl = yes; then PGAC_PATH_TCLCONFIGSH([$with_tclconfig]) PGAC_EVAL_TCLCONFIGSH([$TCL_CONFIG_SH], ! [TCL_INCLUDE_SPEC,TCL_LIB_FILE,TCL_LIBS,TCL_LIB_SPEC,TCL_SHARED_BUILD,TCL_LD_SEARCH_FLAGS]) AC_SUBST(TCL_SHLIB_LD_LIBS)dnl don't want to double-evaluate that one # now that we have TCL_INCLUDE_SPEC, we can check for tcl.h ac_save_CPPFLAGS=$CPPFLAGS diff -Nrc pgsql.orig.d976d4abedca/src/Makefile.global.in pgsql.orig/src/Makefile.global.in *** pgsql.orig.d976d4abedca/src/Makefile.global.in 2009-04-23 22:08:39.208705241 +0200 --- pgsql.orig/src/Makefile.global.in 2009-04-23 22:08:39.212430882 +0200 *** *** 182,187 --- 182,188 TCL_LIB_SPEC = @TCL_LIB_SPEC@ TCL_INCLUDE_SPEC = @TCL_INCLUDE_SPEC@ TCL_SHARED_BUILD = @TCL_SHARED_BUILD@ + TCL_LD_SEARCH_FLAGS = @TCL_LD_SEARCH_FLAGS@ TCL_SHLIB_LD_LIBS = @TCL_SHLIB_LD_LIBS@ PTHREAD_CFLAGS= @PTHREAD_CFLAGS@ diff -Nrc pgsql.orig.d976d4abedca/src/pl/tcl/Makefile pgsql.orig/src/pl/tcl/Makefile *** pgsql.orig.d976d4abedca/src/pl/tcl/Makefile 2009-04-23 22:08:39.210435528 +0200 --- pgsql.orig/src/pl/tcl/Makefile 2009-04-23 22:08:39.213140838 +0200 *** *** 28,33 --- 32,38 endif endif + rpath=$(TCL_LD_SEARCH_FLAGS) SHLIB_LINK = $(TCL_LIB_SPEC) ifneq ($(PORTNAME), win32) Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] RFE: Transparent encryption on all fields
On Thu, 2009-04-23 at 16:08 -0300, pgsql-hackers-ow...@postgresql.org wrote: On Thu, Apr 23, 2009 at 10:38:55AM -0400, Bill Moran wrote: [...] It's possible that this could be accomplished by something like Veil, Veil? Care to share an URL? http://veil.projects.postgresql.org/curdocs/index.html Veil is intended to enable implementation of virtual private databases. It provides a bunch of primitives for managing bitmaps of privileges. These privileges can be used to control access to individual rows within a table. In principle it could be used in the way that Bill Moran suggests though I have never used it that way. I am somewhat suspicious of passing encryption keys to the database server as there is always the potential for them to be leaked. It is generally much safer to keep keys and the decryption process on a separate server. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] PL compilations ignores LDFLAGS
On Thursday 23 April 2009 18:14:59 Zdenek Kotala wrote: I'm looking on Makefile.shlib and I see there strange line: # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) It seems to me that one of these line are not correct. Why not? But anyway I lost -R somewhere. Use LDFLAGS_SL. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
On Thursday 23 April 2009 18:32:19 Zdenek Kotala wrote: however it seems to me that $rpath should be set like --with-libs, but it look likes that it does not work. The rpath stuff only sets the rpath where our libraries are going to be installed. It does not handle rpaths necessary to get other libraries. That is up to the local admin to figure out, I suppose. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
On Thursday 23 April 2009 22:00:25 Tom Lane wrote: Andrew Dunstan and...@dunslane.net writes: So the following sequence woiuld be illegal: initdb -E latin1 createdb -E utf8 Yes, that's rather the point. Note that it already is illegal unless you happen to have selected C locale; AFAIR, the only reason that we haven't disallowed this sort of stuff years and years ago is that people use it; the Japanese in particular. I don't see what is different now. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4b1 regression?
On Apr 22, 2009, at 10:47 PM, Tom Lane wrote: I think this is due to a change that was made in 8.2: Cool. Thanks for the followup! eric -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Why do we let CREATE DATABASE reassign encoding?
Peter Eisentraut pete...@gmx.net writes: AFAIR, the only reason that we haven't disallowed this sort of stuff years and years ago is that people use it; the Japanese in particular. I don't see what is different now. What's different now is that 8.4 has already established the principle that you have to clone template0 if you want to change the locale of a database. I think this is a good time to establish the same principle for encodings. (Or in other words, if we don't fix it now, when will be a better time?) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] PL compilations ignores LDFLAGS
Dne 23.04.09 23:31, Peter Eisentraut napsal(a): On Thursday 23 April 2009 18:14:59 Zdenek Kotala wrote: I'm looking on Makefile.shlib and I see there strange line: # Insert -L from LDFLAGS after any -L already present in SHLIB_LINK SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) It seems to me that one of these line are not correct. Why not? Yeah, It is correct I swapped meaning of filter and filter-out. Thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cs_CZ vs regression tests, part N+1
Please, can somebody look on this patch? I would like to have green lights on my buildfarms. thanks Zdenek Dne 24.03.09 12:23, Zdenek Kotala napsal(a): Dne 24.03.09 08:43, Peter Eisentraut napsal(a): Peter Eisentraut wrote: Andrew Dunstan wrote: Yes, dungbeetle is ... I took tcl out of its config until we had this sorted out. Are you going to commit a _1.out file? Done Can't catch a break: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-03-23%2021:06:01 This time it's the btree_gist and tsearch tests that are complaining, and this time it is because of the Czech locale rules. Patch attached. I hope last one. thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cs_CZ vs regression tests, part N+1
This diff in tsearch2.out surprised me: @@ -2390,7 +2390,7 @@ body bSea/b view wow ubfoo/b bar/u iqq/i a href=http://www.google.com/foo.bar.html; target=_blankYES nbsp;/a - ff-bg + ff-bg script document.write(15); /script Any idea what's causing that? Zdenek Kotala wrote: Please, can somebody look on this patch? I would like to have green lights on my buildfarms. thanks Zdenek Dne 24.03.09 12:23, Zdenek Kotala napsal(a): Dne 24.03.09 08:43, Peter Eisentraut napsal(a): Peter Eisentraut wrote: Andrew Dunstan wrote: Yes, dungbeetle is ... I took tcl out of its config until we had this sorted out. Are you going to commit a _1.out file? Done Can't catch a break: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-03-23%2021:06:01 This time it's the btree_gist and tsearch tests that are complaining, and this time it is because of the Czech locale rules. Patch attached. I hope last one. thanks Zdenek -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] cs_CZ vs regression tests, part N+1
Dne 24.04.09 07:17, Heikki Linnakangas napsal(a): This diff in tsearch2.out surprised me: @@ -2390,7 +2390,7 @@ body bSea/b view wow ubfoo/b bar/u iqq/i a href=http://www.google.com/foo.bar.html; target=_blankYES nbsp;/a - ff-bg + ff-bg script document.write(15); /script Any idea what's causing that? Good catch. I don't see it on http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=comet_mothdt=2009-04-24%2004:47:44 I'm playing with it now. Unfortunately I don't have my laptop with workspace now. Thanks Zdenek Zdenek Kotala wrote: Please, can somebody look on this patch? I would like to have green lights on my buildfarms. thanks Zdenek Dne 24.03.09 12:23, Zdenek Kotala napsal(a): Dne 24.03.09 08:43, Peter Eisentraut napsal(a): Peter Eisentraut wrote: Andrew Dunstan wrote: Yes, dungbeetle is ... I took tcl out of its config until we had this sorted out. Are you going to commit a _1.out file? Done Can't catch a break: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=gothic_mothdt=2009-03-23%2021:06:01 This time it's the btree_gist and tsearch tests that are complaining, and this time it is because of the Czech locale rules. Patch attached. I hope last one. thanks Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
