Re: [HACKERS] Bug 1500
This has my vote Lorne In <[EMAIL PROTECTED]>, on 03/26/05 at 02:04 PM, Josh Berkus said: >Karel, >> > Yeah. áKarel Zak, who wrote that code, is convinced we should remove it, >> > but I don't think anyone else is ... >> >> áI think I was Peter and Josh Berkus who convinced me that the code is >> bed. "we should remove..." is opinion only... >I certainly didn't recommend removing it before we have a replacement >ready. >The complaint, btw, was that the current to_char formats intervals as if >they were dates. This results in some rather confusing output. I >wanted to improve to_char to support proper interval formatting, but >apparently it's difficult to do that without breaking other aspects of >to_char (at least, I was told that). >What we need is a function or functions which do the following: >SELECT to_char( INTERVAL '43 hours 20 minutes', 'MI' ) || ' min'; 2600 >min >SELECT to_char( INTERVAL '43 hours 20 minutes', 'WK:DD:HR:MI' ); >0:1:19:20 >SELECT to_char( INTERVAL '3 years 5 months','MM' ) || ' mons'; 41 mons >etc. This would be more sophisticated than the logic employed for the >current to_char, as the interval would be re-calculated in the units >supplied, limited by the month/year|day/hour/minute boundary. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] psql: recall previous command?
In <[EMAIL PROTECTED]>, on 02/22/05 at 03:26 PM, Neil Conway <[EMAIL PROTECTED]> said: >Is there a way to recall the previous command in psql? Obviously, "up >arrow" or Ctrl-P using readline and the default readline bindings is >close, but it recalls the previous _line_ of input. That is not at all >the same thing in the case of a multiple line command, for example. >If there is no way at present, I think there should be. Using "up arrow" >is quite annoying when dealing with multiple line SQL statements. >Two issues: >- how to handle slash commands? Slash commands and SQL statements can be >intermixed: >neilc=# select 1 \timing >Timing is off. >neilc-# ; > ?column? >-- > 1 >(1 row) >So I'm not quite sure what the right behavior here is. We could always >just ignore slash commands (the command would "recall the previous SQL >statement") -- since few slash commands are multi-line, I don't think >that would be too bad. >- when a multiple-line command is recalled, how should it be presented >in the psql input buffer? Perhaps we could strip newlines from recalled >command text, so that the recalled command would fit on a single line. >That would mean the recalled command would look somewhat different than >how the user typed it, although of course the semantics of the query >should be the same. Any better ideas? >-Neil How about a multi-line buffer that picks up everything from the last \g or ; to the next \g or ; That would pick up everything, That could then be pushed into the input buffer except for the last line containing the ; or \g The last line would have to pushed in when the user pressed the return key. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] SMP buffer management test question
Thanks Well I tried it out and on OS/2 using 8.0 it has the same problems as on Linux, with two clients running on a dual PIII 750 both CPUs go to 100% and the system is madly switching between the two processes. With a single client, about 35% CPU is used. Should the new buffer manager patch eliminate this behaviour? That is what I gathered from the discussions. Lorne In <[EMAIL PROTECTED]>, on 02/20/05 at 02:01 PM, Tom Lane <[EMAIL PROTECTED]> said: >[EMAIL PROTECTED] writes: >> There was a mention of a "context-swap-storm" test in the posts on the ARC >> patent. Where might I obtain a copy of this test procedure? >http://archives.postgresql.org/pgsql-performance/2004-04/msg00280.php >(The archiver seems to have lost the message's separation into parts, but >the "setup" script is the part down through the checkpoint command.) >Read the whole thread for context. > regards, tom lane >---(end of broadcast)--- >TIP 7: don't forget to increase your free space map settings -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] SMP buffer management test question
There was a mention of a "context-swap-storm" test in the posts on the ARC patent. Where might I obtain a copy of this test procedure? Thanks -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: 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: [HACKERS] Data loss, vacuum, transaction wrap-around
In <[EMAIL PROTECTED]>, on 02/19/05 at 02:23 PM, Jaime Casanova <[EMAIL PROTECTED]> said: >On Fri, 18 Feb 2005 22:35:31 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: > >[EMAIL PROTECTED] writes: >> > I think there should be a 100% no data loss fail safe. >> >> Possibly we need to recalibrate our expectations here. The current >> situation is that PostgreSQL will not lose data if: >> >>1. Your disk drive doesn't screw up (eg, lie about write complete, >> or just plain die on you). >>2. Your kernel and filesystem don't screw up. >>3. You follow the instructions about routine vacuuming. >>4. You don't hit any bugs that we don't know about. >> >I'm not an expert but a happy user. My opinion is: >1) there is nothing to do with #1 and #2. >2) #4 is not a big problem because of the velocity developers fix those >when a bug is found. >3) All databases has some type of maintenance routine, in informix for >example we have (update statistics, and there are others for oracle) of >course they are for performance reasons, but vacuum is too for that and >additionally give us the XID wraparound. >So, to have a maintenance routine in PostgreSQL is not bad. *Bad* is to >have a DBA(1) with no clue about the tool is using. Tools that do to much >are an incentive in hire *no clue* people. >(1) DBA: DataBase Administrator or DataBase Aniquilator??? >regards, >Jaime Casanova Bad mouthing the people who use your software is a good way to make sure no one uses the software. The catastrophic failure of the database because a maintenence function is not performed is a problem with the software, not with the people using it. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: 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: [HACKERS] Data loss, vacuum, transaction wrap-around
In <[EMAIL PROTECTED]>, on 02/18/05 at 09:48 PM, Andrew Dunstan <[EMAIL PROTECTED]> said: >Russell Smith wrote: >>On Sat, 19 Feb 2005 04:10 am, Tom Lane wrote: >> >> >>>[EMAIL PROTECTED] writes: >>> >>> In fact, I think it is so bad, that I think we need to back-port a fix to previous versions and issue a notice of some kind. >>>They already do issue notices --- see VACUUM. >>> >>>A real fix (eg the forcible stop we were talking about earlier) will not >>>be reasonable to back-port. >>> >>> >>> >>Not to be rude, but if backporting is not an option, why do we not just >>focus on the job of getting autovacuum into 8.1, and not have to think >>about how a patch that will warn users will work? >> >> >> >> >What if autovacuum is turned off for some reason? Or fails? A more >graceful failure along the lines suggested would be a good thing, ISTM. >I agree with Tom about not backpatching, though. The situation seems >analogous with a car owner who neglects the clear instructions in the >manual to perform regular oil changes and then finds to his great >surprise that the car stops running. It's hardly the manufacturer's >fault. >cheers >andrew I never did like car analogies... At least a car comes with an IDIOT light or maybe even an oil pressure gauge. Something like that (the idiot light) is missing from postgreSQL. The oil pressure gauge would be good to have, kind of like a gauge that lets you when you are about to run out of fuel. Of course the best thing is the auto-fill gas tank. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: 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: [HACKERS] win32 performance - fsync question
In <[EMAIL PROTECTED]>, on 02/17/05 at 10:21 AM, Andrew Dunstan <[EMAIL PROTECTED]> said: >E.Rodichev wrote: >> >> This problem is addressed by file system (fsck, journalling etc.). >> Is it reasonable to handle it directly within application? >> >> >In the words of the Duke of Wellington, "If you believe that you'll >believe anything." >Please review past discussions on the mailing lists on this point. >BTW, most journalling file systems do not guarantee file integrity, only >file metadata integrity. In particular, I believe this is tru of NTFS >(and whether it even does that has been debated). >So by all means turn off fsync if you want the performance gain *and* >you accept the risk. But if you do, don't come crying later that your >data has been lost or corrupted. >(the results are interesting, though - with fsync off Windows and Linux >are in the same performance ballpark.) >cheers >andrew In anything I've done, Windows is very slow when you use fsync or the Windows API equivalent. If you need the performance, you had better have the machine hooked up to a UPS (probably a good idea in any case) and set up something that is triggered by the UPS running down to signal postgreSQL to do an immediate shutdown. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Extending System Views: proposal for 8.1/8.2
In <[EMAIL PROTECTED]>, on 01/22/05 at 05:21 PM, "Jim C. Nasby" <[EMAIL PROTECTED]> said: >On Sat, Jan 22, 2005 at 01:36:54PM -0800, Josh Berkus wrote: > Jim, >> >> > Just to be clear, I'm not suggesting renaming anything in any of the >> > existing pg_catalog objects. I'm suggesting creating a new, easier to >> > use set of views that would sit on top of pg_catalog. >> >> I have no objection to using easier to read names for the system views. >> (This is the user-friendly views, folks, not the actual system >> objects!). The reason I suggested the names I did was to be >> consistent. >Out of curiosity, what's the relation between the tables in pg_catalog >and the 'actual system objects'? I ass-u-me'd that these tables were the >backing store for the real information, but maybe that's not the case. >> Thing is, at least for the next version, if we are changing the naming >> conventions, we need to leave the old views alone, at least for one >> version (pg_tables, pg_views, etc.). This means a new view name scheme >> for the new views. Suggestions? >If we're dropping the pg_, maybe call the new schema just 'catalog'? That will break all of the older ODBC drivers. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: 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
[HACKERS] OS/2 port
I submitted the patches and additional files for the OS/2 port on the patches ML. I might as well claim responsibility for that port and put myself down as the maintainer... Lorne Sunley Winnipeg MB Canada -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: 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: [HACKERS] OS/2 port regression tests
Hi, Never mind about the "permission denied errors" I tracked it down to a bug in the LIBC port's handling of doing an unlink... So it would appear the port mostly works barring the problems with the LIBC implementation. Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Libtool?
In <[EMAIL PROTECTED]>, on 01/07/05 at 10:00 PM, "Marc G. Fournier" <[EMAIL PROTECTED]> said: >On Fri, 7 Jan 2005, Peter Eisentraut wrote: >> Various recent and not so recent problem reports got me thinking again >> that it might be worth switching our shared library build system to >> libtool. Among those are: >> >> - Guesswork about which spellings of -rpath, -export-dynamic, -fpic etc. >> work on a particular platform or compiler. >> >> - Lack of information about which libraries libpq depends on. >> >> - Makefile.shlib can only build one library per directory. >> >> - pgxs is pretty ugly and inflexible because of the above. >> >> - Static libraries built with -fpic, which is sometimes considered a >> bug. >> >> - Misbehavior with rpaths pointing the wrong way during the regression >> tests and similar problems could maybe be tackled. >> >> Considering that pretty much everyone uses libtool these days, I'm not >> too worried about portability. >> >> (And before anyone asks: No, libtool does not require automake.) >> >> I think it may be worth trying out. Comments? >Does it work with Windows, or with that be a 'special case'? It is supposed to... Mind you, it is supposed to support OS/2 as well and I have had problems with several projects that use it. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Is there a psql function equivalent to a session log
One of my testers asked me if there is a function in psql that is equivalent to a session log - something that will write out commands sent to the server and the results written to a file while still displaying the results on screen. I can't find anything like this, but I think I can put it together quite quickly. Has anyone else done something like this? Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] sysv_shmem potential problem
I see, The shmem.c implementation I am using returns the OS/2 memory ID which also happens to be the base address of the allocated memory. Bug in shmem.c code then Thanks Lorne In <[EMAIL PROTECTED]>, on 12/31/04 at 03:53 PM, Tom Lane <[EMAIL PROTECTED]> said: >[EMAIL PROTECTED] writes: >> I am using the sysv_shmem.c shared memory allocation api for os/2 and I >> ran into a problem when OS/2 allocates shared memory over the 2 gigabyte >> address boundary. >> The existing sysv_shmem.c tests for the return address of the segment as >> less than 0 and determines that a negative indicates an error. >shmget returns an ID, not an address. I quote from the Single Unix Spec: > Upon successful completion, shmget() returns a non-negative integer, > > namely a shared memory identifier; otherwise, it returns -1 and errno > will be set to indicate the error. >While your change might be harmless, it should not be necessary, and it >certainly shouldn't have anything to do with 2gig address boundaries. > regards, tom lane -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] sysv_shmem potential problem
Hi I am using the sysv_shmem.c shared memory allocation api for os/2 and I ran into a problem when OS/2 allocates shared memory over the 2 gigabyte address boundary. The existing sysv_shmem.c tests for the return address of the segment as less than 0 and determines that a negative indicates an error. I have this patch (below) ifdef'd for OS/2 but I thought that there may be a problem on other platforms that can allocate shared memory over the 2 gig boundary The existing code is if (shmid < 0) Index: sysv_shmem.c === RCS file: /projects/cvsroot/pgsql/src/backend/port/sysv_shmem.c,v retrieving revision 1.41 diff -r1.41 sysv_shmem.c 80a81,85 > #ifdef __OS2__ > /* shared memory address may be allocated over 2 gig and will negative > */ > /* so test for the explicit -1 return */ > if (shmid == -1) > #else 81a87 > #endif -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] RC3 in ... ~12 hours ...
Yay I assume that any changes will be in CVS at that point? I have a bunch of patches and some new files for the OS/2 port that I plan on submitting as a diff to the 8.0 GA when that comes about. Is that the appropriate time? BTW - I did get all the NLS stuff working as well. Lorne In <[EMAIL PROTECTED]>, on 12/30/04 at 09:38 PM, "Marc G. Fournier" <[EMAIL PROTECTED]> said: >Baring any cries of *STOP* ... I'm going to try and get it packaged first > thing in the morning ... > >Marc G. Fournier Hub.Org Networking Services >(http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy > >ICQ: 7615664 >---(end of broadcast)--- >TIP 5: Have you checked our extensive FAQ? > http://www.postgresql.org/docs/faqs/FAQ.html -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: 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
[HACKERS] Multiple language support
Are there any plans for modifying the message outputs from the programs to support multiple languages? Most of the messages (at least in things like the database engine and utilities like initdb etc) have messages hard coded in English. This does not affect me very much, but I have at least 6 beta testers for the postgreSQL OS/2 port that are based in Germany and one in Italy, and another in the Netherlands. Or am I missing something somewhere? Lorne Sunley -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] order by problems FIXED
Hi all It was a setlocale problem Thanks Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 3: 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
[HACKERS] more on character fields
Hi all, It would appear that none of the comparision functions work on my OS/2 port for columns defined as char or varchar. With a table "smalvar" of two columns, one varchar and the other name acol nn -- AA AA CC a "select * from smalvar where acol = '' " will return all three rows a "select * from smalvar where nn = 'AA' " will return two rows. a "select * from smalvar where nn = 'CC' " will return two rows. I realize I have a problem with comparisons as any thing that does a comparison using a char or varchar field fails, whereas doing the same operation with a "name" column succeeds and with an integer column succeeds. What I would like help with is locating where in the code the comparisons take place for these functions. Please help? Thank you Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] More on Order by
OK I believe that.. But why does order by work on a "name" column but not a "char(10)" column. See my earlier (posted later because of problems) e-mail. Lorne In <[EMAIL PROTECTED]>, on 12/26/04 at 02:16 PM, Michael Fuhr <[EMAIL PROTECTED]> said: >On Sun, Dec 26, 2004 at 02:57:08PM -0500, [EMAIL PROTECTED] wrote: >> So what is difference between a "name" and a char(10)??? >See the "Character Types" section in the "Data Types" chapter of the >documentation. >"The name type exists _only_ for storage of identifiers in the internal >system catalogs and is not intended for use by the general user." -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Problem with ORDER BY
The previous one of these seems to being blocked because of the big
attachments.
Short stuff is embedded in this e-mail.
Hi all,
I have a problem in my os/2 port of postgreSQL v8.0 and I am hoping
someone can help me with it.
When I create a database and use the commands shown below the select ...
order by works for the pg_tables view column "tablename" but fails for
the addresslist column "city". The output from my test database is in
out.log
I ran a complete createdb processed the addresslist.sql with -d3 output
and the results are in debug.log and psql output in out2.log. There was a
failure when I typoed the createdb statement.
select ... order by will work for the columns defined as integer but not
for character
Where is the best place to start looking???
Does this work properly on other platforms (I hope so).
Thanks for any help.
Lorne Sunley
SQL to execute --
create table addresslist (name char(40), address char(40), city char(40),
telephone char(20), postalcode char(10), numfield integer); insert into
addresslist values ('Aardvark', '101 Street', 'Sometown', '999-000', 'H0H
0H0', 1); insert into addresslist values ('Beebop', '901 Street',
'Sometown', '888-000', 'T0T 0H0', 2); insert into addresslist values
('Xerox', '801 Street', 'Sometown', '777-000', 'K0H 0H0', 3); insert into
addresslist values ('Middling', '1101 Street', 'Sometown', '333-000', 'R0R
0H0', 4); insert into addresslist values ('Lost', '1 Avenue', 'Sometown',
'456-000', 'X0X 0H0', 5); insert into addresslist values ('Timeout', '202
Street', 'Sometown', '789-000', 'T0H 0H0' ,5); insert into addresslist
values ('What Where Who', '555 Street', 'Where', '911-000', 'T0H 0H0', 6);
insert into addresslist values ('Catalog', '989 Street', 'LittleBurg',
'911-001', 'T0H 0H0', 7); insert into addresslist values ('Premium', '21
Street', 'Bigcity', '222-', 'W0W 0H0', 8); insert into addresslist
values ('ToastMaster', '13 Street', 'Waytown', '444-000', 'W0R 0H0', 9);
insert into addresslist values ('Dumbthing', '888 Street', 'Thistown',
'555-000', 'W0T 0H0', 9); select city from addresslist order by city desc;
select tablename from pg_tables order by tablename desc;
select city from addresslist order by city asc;
select tablename from pg_tables order by tablename asc;
select city, numfield from addresslist order by numfield asc; select city,
numfield from addresslist order by numfield desc;
--- end of SQL -
- results ---
CREATE TABLE
INSERT 17325 1
INSERT 17326 1
INSERT 17327 1
INSERT 17328 1
INSERT 17329 1
INSERT 17330 1
INSERT 17331 1
INSERT 17332 1
INSERT 17333 1
INSERT 17334 1
INSERT 17335 1
city
--
Thistown
Sometown
Sometown
Sometown
Sometown
Sometown
Where
LittleBurg
Bigcity
Waytown
Sometown
(11 rows)
tablename
-
sql_sizing_profiles
sql_sizing
sql_packages
sql_languages
sql_implementation_info
sql_features
pg_type
pg_trigger
pg_tablespace
pg_statistic
pg_shadow
pg_rewrite
pg_proc
pg_operator
pg_opclass
pg_namespace
pg_listener
pg_largeobject
pg_language
pg_inherits
pg_index
pg_group
pg_description
pg_depend
pg_database
pg_conversion
pg_constraint
pg_class
pg_cast
pg_attribute
pg_attrdef
pg_amproc
pg_amop
pg_am
pg_aggregate
addresslist
(36 rows)
city
--
Thistown
Sometown
Sometown
Sometown
Sometown
Sometown
Where
LittleBurg
Bigcity
Waytown
Sometown
(11 rows)
tablename
-
addresslist
pg_aggregate
pg_am
pg_amop
pg_amproc
pg_attrdef
pg_attribute
pg_cast
pg_class
pg_constraint
pg_conversion
pg_database
pg_depend
pg_description
pg_group
pg_index
pg_inherits
pg_language
pg_largeobject
pg_listener
pg_namespace
pg_opclass
pg_operator
pg_proc
pg_rewrite
pg_shadow
pg_statistic
pg_tablespace
pg_trigger
pg_type
sql_features
sql_implementation_info
sql_languages
sql_packages
sql_sizing
sql_sizing_profiles
(36 rows)
city | numfield
--+
[HACKERS] More on Order by
Hi All I have discovered that when I use a table like this create table whois (acol name); and insert a few rows, the order by clause works correctly. I dug into the database init stuff to find that the table pg_class column relname is where the pg_tables column tablename comes from. That column is defined as a 'name' datatype. So what is difference between a "name" and a char(10)??? Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] rc2 bundled
Will do... thanks Lorne In <[EMAIL PROTECTED]>, on 12/21/04 at 01:56 AM, "Marc G. Fournier" <[EMAIL PROTECTED]> said: >check her over .. > >Marc G. Fournier Hub.Org Networking Services >(http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy > >ICQ: 7615664 >---(end of broadcast)--- >TIP 9: the planner will ignore your desire to choose an index scan if >your > joining column's datatypes do not match -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Locale question
Hi I have a few people in Europe trying out the rc1 port for OS/2 and they have run into a problem with the locale settings They have a locale set as de_DE_EURO and the initdb program really does not like this because the setlocale(LC_MESSAGES, NULL) call returns a zero length string. When the postgres code finds that the lc_messages does not = the return from LC_CTYPE it appears to attempt to see if it is a known language setup and something goes wrong. When the local is de_DE everything works fine. Can someone point me to where the locale string is tested to be a known type, or explain how to track down the problem? If I patch initdb to just use the return from LC_CTYPE as the value for lc_messages the init conpletes and the database will start up OK Should I be doing something else to fix this problem? This apparently also happened with the 7.4.x postgres code as well. Thanks Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] So is there a 8.0RC1 tomorrow
CONGRATULATIONS BTW - I have the OS/2 port running through to creating the template0 and template1 databases with initdb. I have a glitch with the fork() processing that seems to be in the OS/2 GCC 3.3.5 runtime, but I expect to have that resolved shortly. I am going to apply the patches from os/2 beta5 to RC 1 and see how it works. Lorne In <[EMAIL PROTECTED]>, on 12/03/04 at 11:29 PM, Bruce Momjian <[EMAIL PROTECTED]> said: >[EMAIL PROTECTED] wrote: >> Out of all of the messages on this thread, I am still not sure... >> >> Is there an RC1 coming out RSN? >Yes, it has been packaged and is now propogating to the mirrors. It is >on the main ftp site now under /pub/beta/*rc1*. -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] So is there a 8.0RC1 tomorrow
Out of all of the messages on this thread, I am still not sure... Is there an RC1 coming out RSN? Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] New member says hello
In <[EMAIL PROTECTED]>, on 11/27/04 at 01:05 PM, Tom Lane <[EMAIL PROTECTED]> said: >[EMAIL PROTECTED] writes: >>at 09:50 PM, Tom Lane <[EMAIL PROTECTED]> said: >>> If you're hoping to get this into 8.0, it had better arrive soon and be a >>> very small patch ... >> It may have to be for 8.0.1 there are a lot of changes to the makefiles to >> accomodate the if(($portname), ibmos2) stuff and the src/port/ibmos2 code >More like 8.1, then. A not-previously-supported port is going to be seen >as a new feature, not a bug fix, especially if the changes are less than >trivial. Sounds good to me... The makefile changes are more than trivial (18 new and/or changed files) and the build environment would have to be tested on supported platforms to make sure nothing got broken. There are a few changes to the C code (28 new and/or changed files) and H files (9 new and/or changed files). So far :-) >> BTW - has anyone else noticed that there are a number of places where >> there is a test for HAVE_OPTRESET instead of HAVE_INT_OPTRESET? >Good catch ... that's definitely broken. Sometimes doing a new port finds problems that are not noticed otherwise. I'll just forge ahead with the OS/2 stuff and get patches ready for a post 8.0.0 GA Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] New member says hello
In <[EMAIL PROTECTED]>, on 11/26/04 at 09:50 PM, Tom Lane <[EMAIL PROTECTED]> said: >[EMAIL PROTECTED] writes: >> How do I go about getting OS/2 specific changes for source code and >> makefiles merged with the regular release code? >Send a proposed patch to pgsql-patches for discussion. >If you're hoping to get this into 8.0, it had better arrive soon and be a >very small patch ... > regards, tom lane Thanks... It may have to be for 8.0.1 there are a lot of changes to the makefiles to accomodate the if(($portname), ibmos2) stuff and the src/port/ibmos2 code BTW - has anyone else noticed that there are a number of places where there is a test for HAVE_OPTRESET instead of HAVE_INT_OPTRESET? Lorne -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] New member says hello
Hi All, I am doing a port of postgreSQL v8 to OS/2. I have successfully built a port (using the beta 4 code), and am starting testing. I will be updating my port with the beta 5 code in the next couple of days. How do I go about getting OS/2 specific changes for source code and makefiles merged with the regular release code? Lorne Sunley Winnipeg, Manitoba Canada -- --- [EMAIL PROTECTED] --- ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
