[HACKERS] Where are the ERROR: Messages
[HACKERS] Where are the ERROR: Messages I'm converting from a C based program to PostgreSQL. There are some DBMS specific errors caught, i.e. deadlocks. Not only for this reason, but also from general curiosity I'd like to know what kinds of ERRORS PostgreSQL is dealing with. Which source code/header file is hiding this infromation? Regards, Christoph ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Large object help requierd
Hi, I am trying to store some large object in database. I print the number of bytes returned by lo_write. It's greater than zero. However sometime later, I start getting errors for lo_closelike invalid object descriptor fd=0 where df is variable I used for large object fd. Actually after lo_write is done lo_close is called. I wonder why it takes time between these two. I also found that the error values for many functions are not properly documented. e.g. lo_open. One more thing I am not sure of. Am I suppose to commit after I call lo_creat but before I can call lo_open? I am experimenting. I will let you know the results. Shridhar __ Terrorist Attacks on U.S. - How can you help? Donate cash, emergency relief information http://dailynews.yahoo.com/fc/US/Emergency_Information/ ---(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] Major change to CVS effective immediately ...
:pserver:[EMAIL PROTECTED]:/projects/cvsroot On 18 Sep 2001, Gunnar [iso-8859-1] Rønning wrote: * Marc G. Fournier [EMAIL PROTECTED] wrote: | | anoncvs.postgresql.org is going to be out of sync until, most likely, | tomorrow, for anyone trying to use that ... anoncvs is *no longer* | available through the main cvs repository either ... Is anoncvs.postgresql.org working yet ? I just tried : # cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/pgsql/cvsroot login and # cvs -d :pserver:[EMAIL PROTECTED]:/cvsroot login with postgresql as password. In both cases the response was this : cvs [login aborted]: authorization failed: server anoncvs.postgresql.org rejected access regards, Gunnar -- Gunnar Rønning - [EMAIL PROTECTED] Senior Consultant, Polygnosis AS, http://www.polygnosis.com/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Major change to CVS effective immediately ...
On Wed, Sep 19, 2001 at 10:14:44AM -0400, Marc G. Fournier wrote: :pserver:[EMAIL PROTECTED]:/projects/cvsroot While trying a cvs update, I get ? ChangeLogs/libecpg.so.3.1.1 ? ChangeLogs/HTML ? ChangeLogs/GTAGS ? ChangeLogs/GPATH ? ChangeLogs/GRTAGS ? ChangeLogs/GSYMS ? ChangeLogs/libpqpp.h cannot create_adm_p /tmp/cvs-serv27285/ChangeLogs Cheers, Patrick ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Case sensitive file names
While checking out TOT pgsql today onto an HFS+ file system (case-preserving, case-insensitive), I hit the following CVS conflict: pgsql/src/backend/utils/mb/Unicode/utf8_to_alt.map pgsql/src/backend/utils/mb/Unicode/utf8_to_ALT.map HFS+ can not store two differerent files in a path that differs only by case. Mac OS X users will be grateful if you can find a way to rename one of these files. -pmb ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Case sensitive file names
- Original Message - From: Peter Bierman [EMAIL PROTECTED] Sent: Wednesday, September 19, 2001 3:41 PM While checking out TOT pgsql today onto an HFS+ file system (case-preserving, case-insensitive), I hit the following CVS conflict: pgsql/src/backend/utils/mb/Unicode/utf8_to_alt.map pgsql/src/backend/utils/mb/Unicode/utf8_to_ALT.map I thought the latter was supposed to go (it was supposed to be renamed to the former, wasn't it?) S. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: CVS vs anoncvs (was Re: [HACKERS] Case sensitive file names)
should be four hours, but I haven't had a chance, with the newest worm/virus going around right now having killed our core router yesterday, to redirect the sync'ag with the new server ... will do that first thing tomorrow ... On Wed, 19 Sep 2001, Tom Lane wrote: Peter Bierman [EMAIL PROTECTED] writes: If it's already been fixed (yay!), the fix isn't at anoncvs yet. I think there is some lag between the master CVS and anoncvs now. Marc, is that correct? How much lag? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
CVS vs anoncvs (was Re: [HACKERS] Case sensitive file names)
Peter Bierman [EMAIL PROTECTED] writes: If it's already been fixed (yay!), the fix isn't at anoncvs yet. I think there is some lag between the master CVS and anoncvs now. Marc, is that correct? How much lag? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] FOREIGN KEY taking write locks on parent.
I sent a message a while back on this list on why an insert onto a table A which has a foreign key constraint to table B obtains a write (exclusive) lock on that row on table B (basically does a select for update). The answer was there is no SQL construct to obtain read (shared) locks on a particular row, therefore it took a write lock. I was just wondering, isn't the fact that FOREIGN KEY takes a write lock on its parent a bug? I was just wondering whether this is being worked on, and if anyone has any ideas where to start in case I want to work on it, or can I create my own function / constraint which will just emulate a shared lock behavior for a FOREIGN KEY constrant. This is making it tough to sanely handle concurrent long-running transactions, even if I use the INITIALLY DEFERRED for the foreign key constrant. Thanx a lot, and thanx for this wonderful DB. -rchit ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] FOREIGN KEY taking write locks on parent.
Rachit Siamwalla [EMAIL PROTECTED] writes: I was just wondering, isn't the fact that FOREIGN KEY takes a write lock on its parent a bug? Yes, I think so. Fixing it is not trivial (else we'd have done it right to start with) ... but if you want to step up to the plate to fix it, we're all ears ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Beta time
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Attached is the CONSTR_PRIMARY switch block from command.c. I've marked the problem test with '@@'. Hmmm this code has got a number of problems, but I don't see why *that* would fail. Anyone? What I do see: 1. Should not break out of loop over indexes after detecting a matching non-primary-key index. This allows detection of the NOTICE condition to distract you from detecting the ERROR condition on a later index. I'd suggest issuing the NOTICE inside the loop, actually, and not breaking at all. (See also #4) 2. What's with the if (keyno 0)? That breaks detection of everything on indexes on system columns, eg OID. (Of course, the rel_attrs[keyno - 1] reference doesn't work for system columns, but sticking your head in the sand is no answer.) 3. pfree'ing iname at the bottom doesn't strike me as a good idea; isn't that possibly part of your input querytree? 4. If you're going to be so pedantic as to issue a warning notice about a duplicate non-primary index, it'd be polite to give the name of that index. Else how shall I know which index you think I should drop? regards, tom lane ---(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] Beta time
1. Should not break out of loop over indexes after detecting a matching non-primary-key index. This allows detection of the NOTICE condition to distract you from detecting the ERROR condition on a later index. I'd suggest issuing the NOTICE inside the loop, actually, and not breaking at all. (See also #4) OK. 2. What's with the if (keyno 0)? That breaks detection of everything on indexes on system columns, eg OID. (Of course, the rel_attrs[keyno - 1] reference doesn't work for system columns, but sticking your head in the sand is no answer.) This is code that I've borrowed from elsewhere. I'll have a good look at it tho. 3. pfree'ing iname at the bottom doesn't strike me as a good idea; isn't that possibly part of your input querytree? Hmmm. OK. What about in the case where iname is null and I give it a makeObjectName? 4. If you're going to be so pedantic as to issue a warning notice about a duplicate non-primary index, it'd be polite to give the name of that index. Else how shall I know which index you think I should drop? I'll improve the messages. As for me being pedantic - that's a result of what you specified as the best behaviour should be when I posted on the list! You may also want to look at the CONSTR_UNIQUE block that's already been committed, as it may also have similar issues. Any fixes I make to PRIMARY, I will also fix in UNIQUE... Cheers, Chris ---(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] Putting timestamps in PostgreSQL log
On Lun 17 Sep 2001 23:28, Christopher Kings-Lynne wrote: Would it be an idea to add timestamps to the PostgreSQL error/debug/notice log? Sometimes I would really like to know when an event has occurred! Use syslog and you'll get timestamps in your log. Saludos... :-) -- Porqué usar una base de datos relacional cualquiera, si podés usar PostgreSQL? - Martín Marqués |[EMAIL PROTECTED] Programador, Administrador, DBA | Centro de Telematica Universidad Nacional del Litoral - ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] slow UNIONing
I experienced that UNIONs in 7.1.1 are rather slow: tir=# explain (select nev from cikk) union (select tevekenyseg from log); NOTICE: QUERY PLAN: Unique (cost=667.63..687.18 rows=782 width=12) - Sort (cost=667.63..667.63 rows=7817 width=12) - Append (cost=0.00..162.17 rows=7817 width=12) - Subquery Scan *SELECT* 1 (cost=0.00..28.16 rows=1316 width=12) - Seq Scan on cikk (cost=0.00..28.16 rows=1316 width=12) - Subquery Scan *SELECT* 2 (cost=0.00..134.01 rows=6501 width=12) - Seq Scan on log (cost=0.00..134.01 rows=6501 width=12) Of course a simple SELECT is fast: tir=# explain select nev from cikk; NOTICE: QUERY PLAN: Seq Scan on cikk (cost=0.00..28.16 rows=1316 width=12) For me it seems to be slow due to the sorting. Is this right? Is this normal at all? Is it possible to make it faster? If you know, that your result does not produce duplicates (which are filtered away with union) you can use a union all which should be substantially faster, since it does not need to sort. Andreas ---(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] Large objects and ecpg
On Wed, Sep 19, 2001 at 12:46:03AM +0530, Chamanya wrote: Can I use ecpg with large objects? All examples in documentation are for libpq. Yes and no. Since ECPG uses libpq it should not be too difficult to use the lo functions too. But there is no way to use them via some EXEC SQL statements. Any idea how these statements should look like? Would be a good idea to implement. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] slow UNIONing
Kovacs Zoltan writes: I experienced that UNIONs in 7.1.1 are rather slow: tir=# explain (select nev from cikk) union (select tevekenyseg from log); Try UNION ALL. Plain UNION will eliminate duplicates, so it becomes slower. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Beta time
Christopher Kings-Lynne [EMAIL PROTECTED] writes: 3. pfree'ing iname at the bottom doesn't strike me as a good idea; isn't that possibly part of your input querytree? Hmmm. OK. What about in the case where iname is null and I give it a makeObjectName? Don't worry about it. palloc'd space will be recovered anyway at end of statement. It's really not worth the code space to pfree every little bit of space you might use, except in routines that could be executed many times in a single query. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Major change to CVS effective immediately ...
can you ssh into cvs.postgresql.org?
On Tue, 18 Sep 2001, D'Arcy J.M. Cain wrote:
Thus spake Marc G. Fournier
This will most likely screw some ppl up, and fix others ...
CVSROOT has now moved to the new machine, finally ... and I've cleaned up
pathing ... and CVS_RSH=ssh now works again too ...
So, now CVSROOT is accessible as:
:pserver:userid@cvs.postgresql.org:/cvsroot
-or-
:ext:userid@cvs.postgresql.org:/cvsroot
- where CVS_RSH is set to ssh
None of this helps me. I still can't get into that system. Can you
please check this and get me back in. If I can't get in I will have
to move PyGreSQL back to my own CVS repository and I think it is good
for both projects to leave it where it is. Will you be in today? I
can call you later to discuss this and hopefully resolve it.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] CVSup Server has the time bug, needs to be upgraded
Please note that as of 07:24PST, 09-19 the cvsup server is old and needs to be upgraded, the following is what I now get when trying to sync: Parsing supfile cvsup_config Connecting to postgresql.org Connected to postgresql.org Server software version: REL_16_1 Server postgresql.org has the S1G bug See http://www.polstra.com/projects/freeware/CVSup/s1g/ for details Please notify the maintainer of postgresql.org Refusing update from server with S1G bug When might the server be upgraded? The above page gives a good reason: Outdated clients create a heavy load on the servers, so upgrading to SNAP_16_1e is strongly recommended. Best regards, .. Otto Otto Hirr OLAB Inc 503.617.6595 [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] [Fwd: [Fwd: [tao-users] FW: HEADS UP: CVSup timestamp bug]]
Right now, we have: OK, these are three *physically distinct* machines with some aliases attached to them? Or are virtual hosts involved too?? I need a site map from someone since nothing but my home directory is in the place they used to be (actually, even that moved but I *do* know how to find my home directory ;). I've found some stuff, but no doc areas and no ftp areas. Help!! (At your convenience, of course; I *know* you are doing a lot of work on this ;) - Thomas golem host cvsup.postgresql.org cvsup.postgresql.org is a nickname for rs.PostgreSQL.org rs.PostgreSQL.org has address 64.39.15.238 rs.PostgreSQL.org has address 64.39.15.238 golem host anoncvs.postgresql.org anoncvs.postgresql.org is a nickname for rs.PostgreSQL.org rs.PostgreSQL.org has address 64.39.15.238 rs.PostgreSQL.org has address 64.39.15.238 golem host cvs.postgresql.org cvs.postgresql.org is a nickname for mail.postgresql.org mail.postgresql.org has address 216.126.85.28 mail.postgresql.org has address 216.126.85.28 golem host mail.postgresql.org mail.postgresql.org has address 216.126.85.28 golem host www.postgresql.org www.postgresql.org is a nickname for rs.postgresql.org rs.postgresql.org has address 64.39.15.238 rs.postgresql.org has address 64.39.15.238 golem host ftp.postgresql.org ftp.postgresql.org is a nickname for postgresql.org postgresql.org has address 216.126.84.28 postgresql.org has address 216.126.84.28 golem host rsync.postgresql.org rsync.postgresql.org is a nickname for rs.postgresql.org rs.postgresql.org has address 64.39.15.238 rs.postgresql.org has address 64.39.15.238 anoncvs.postgresql.org == cvsup.postgresql.org - same machine, brand new cvs.postgresql.org == www.postgresql.org == mail.postgresql.org == ssh/login server - same machine rsync.postgresql.org == ftp.postgresql.org == primary www server - old server, slowly being migrated between the above two machines (rsync - anoncvs, ftp/primary - cvs) ---(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] Status of greatbridge.org
I am advised by the (few remaining) Great Bridge folk that they will be shutting down their webservers very shortly, like tomorrow. This will take the project pages at greatbridge.org offline. All the data at greatbridge.org has been transferred to a hub.org server at http://gborg.postgresql.org/. Project URLs will be the same except for the change of site name. Please note that while the data is there, not all of the site functionality is up yet. Chris Ryan is working hard to make the necessary adjustments, and the glitches should be smoothed out over the next few days. On behalf of the PG core committee, I'd like to thank the Great Bridge people and particularly Chris Ryan for their efforts to continue support for the projects that were hosted at greatbridge.org. Also, of course, thanks to Marc and hub.org for picking up the service. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Returning NULL from functions
I am working on date/time stuff, and in the spirit of cleaning up
interesting but marginally useful features I've dropped support for
invalid for the timestamp and timestamptz types.
To help with upgrading, I thought that I'd map it to a NULL value, and
see the following in the regression tests:
-- Obsolete special values
INSERT INTO TIMESTAMP_TBL VALUES ('invalid');
ERROR: OidFunctionCall3: function 1150 returned NULL
Is this error message a feature of all returns of NULL, particular to
input routines, or can I somehow mark routines as being allowed to
return NULL values?
Comments?
- Thomas
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] type casting troubles
I have split the timestamp data type into two types to better match SQL9x specs. I've implemented them as timestamp and timestamptz (the latter corresponding to the implementation in recent releases), and have implemented conversion routines between the two types. However, I expect to be able to cast one to the other, but am crashing the server deep down in the executor when phrasing a query using the CAST() syntax, whereas an explicit call to the conversion routine seems to work fine. I thought that I understood the mechanisms for this casting (I'd done the original implementation, after all ;) but the code has evolved since then, presumably for the better. Any hints on what could be happening? - Thomas thomas=# select timestamp without time zone 'now', timestamptz(timestamp without time zone 'now'); +--- 2001-09-19 19:05:07.81 | 2001-09-19 19:05:07.81-07 (1 row) thomas=# select cast(timestamp without time zone 'now' as timestamptz); server closed the connection unexpectedly backend select cast(timestamp without time zone 'now' as timestamptz); Program received signal SIGSEGV, Segmentation fault. 0x401286f6 in strncpy () from /lib/libc.so.6 (gdb) where #0 0x401286f6 in strncpy () from /lib/libc.so.6 #1 0x819fc77 in namestrcpy (name=0x82d6340, str=0x1f8 Address 0x1f8 out of bounds) at name.c:175 #2 0x806cb34 in TupleDescInitEntry (desc=0x82d6304, attributeNumber=1, attributeName=0x1f8 Address 0x1f8 out of bounds, oidtypeid=1184, typmod=-1, attdim=0, attisset=0 '\000') at tupdesc.c:365 #3 0x810d309 in ExecTypeFromTL (targetList=0x82d60a8) at execTuples.c:594 #4 0x810d63d in ExecAssignResultTypeFromTL (node=0x82d60c4, commonstate=0x82d628c) at execUtils.c:288 #5 0x8115072 in ExecInitResult (node=0x82d60c4, estate=0x82d616c, parent=0x0) at nodeResult.c:227 #6 0x8109334 in ExecInitNode (node=0x82d60c4, estate=0x82d616c, parent=0x0) at execProcnode.c:140 #7 0x8107570 in InitPlan (operation=CMD_SELECT, parseTree=0x82d23cc, plan=0x82d60c4, estate=0x82d616c) at execMain.c:628 #8 0x8106c5e in ExecutorStart (queryDesc=0x82d6150, estate=0x82d616c) at execMain.c:135 #9 0x817e719 in ProcessQuery (parsetree=0x82d23cc, plan=0x82d60c4, dest=Debug) at pquery.c:257 #10 0x817cbf2 in pg_exec_query_string ( query_string=0x82d2008 select cast(timestamp without time zone 'now' as timestamptz);\n, dest=Debug, parse_context=0x82a5e94) at postgres.c:812 #11 0x817e0c1 in PostgresMain (argc=2, argv=0xb6f4, real_argc=2, real_argv=0xb6f4, username=0x828f6d8 thomas) at postgres.c:1963 #12 0x81236e5 in main (argc=2, argv=0xb6f4) at main.c:203 #13 0x400e9cbe in __libc_start_main () from /lib/libc.so.6 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Returning NULL from functions
Thomas Lockhart [EMAIL PROTECTED] writes: ERROR: OidFunctionCall3: function 1150 returned NULL Is this error message a feature of all returns of NULL, particular to input routines, or can I somehow mark routines as being allowed to return NULL values? It's a feature for all places that invoke SQL functions via the FooFunctionCallN routines. The API for those routines offers no way to handle passing or returning NULL, so they have little choice but to raise elog(ERROR) if they see the called function return NULL. Those routines are intended for use in places where a NULL result is nonsensical anyway, and so extending their API to allow NULL would just create useless notational clutter. If you want to cope with NULLs then you have to set up and inspect a FunctionCallInfoData structure for yourself. See the comments in backend/utils/fmgr/fmgr.c. Offhand I see no good reason why a datatype input routine should return NULL. Either return a valid value of the type, or elog(ERROR). IMHO, NULL is (and should be) an out-of-band value handled by datatype-independent logic. regards, tom lane ---(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] type casting troubles
Thomas Lockhart [EMAIL PROTECTED] writes: #2 0x806cb34 in TupleDescInitEntry (desc=0x82d6304, attributeNumber=1, attributeName=0x1f8 Address 0x1f8 out of bounds, oidtypeid=1184, typmod=-1, attdim=0, attisset=0 '\000') at tupdesc.c:365 This appears to indicate that you have a Resdom node with an invalid resname field. Seems like that wouldn't be a datatype-specific issue at all. Have you changed the handling of cast() nodes? regards, tom lane ---(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] Major change to CVS effective immediately ...
Thus spake Marc G. Fournier
can you ssh into cvs.postgresql.org?
Yes! I could not do that before. Did you fix something?
I will be sending some PyGreSQL changes over shortly. Thanks.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Case sensitive file names
Peter Bierman writes: While checking out TOT pgsql today onto an HFS+ file system (case-preserving, case-insensitive), I hit the following CVS conflict: pgsql/src/backend/utils/mb/Unicode/utf8_to_alt.map pgsql/src/backend/utils/mb/Unicode/utf8_to_ALT.map HFS+ can not store two differerent files in a path that differs only by case. Remove both of these files and update again. The files were recently renamed to have a consistent case-ness. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Case sensitive file names
Peter Bierman writes: At 10:47 PM +0200 9/19/01, Peter Eisentraut wrote: Peter Bierman writes: While checking out TOT pgsql today onto an HFS+ file system (case-preserving, case-insensitive), I hit the following CVS conflict: pgsql/src/backend/utils/mb/Unicode/utf8_to_alt.map pgsql/src/backend/utils/mb/Unicode/utf8_to_ALT.map HFS+ can not store two differerent files in a path that differs only by case. Remove both of these files and update again. The files were recently renamed to have a consistent case-ness. This was from an anoncvs HEAD/TOT checkout I did into an empty directory less than an hour ago. Indeed, someone forgot to remove the old file. I just removed it a second ago, so you should be fine now. -- Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
