Re: [HACKERS] Win32 port - current status?
On Mon, 2003-07-14 at 01:58, Claudio Natoli wrote: I'm just (one of the many?) hanging out for this, to justify continued use of Postgres to the powers that be. Seems like there has been no word on this for a couple weeks, and I'm not even sure whether or not it has made/will make it into 7.4? Perhaps I've missed a crucial message somewhere... I certainly can't comment on it's current status, but it most certainly will not be in 7.4. I too am very excited by the port, but it just didn't get done in time for 7.4, I hope it makes it into 7.5 devel early on in the cycle. ---(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 port - current status?
Claudio Natoli wrote: just wondering if the guys involved in the Win32 port could give a quick update? I'm just (one of the many?) hanging out for this, to justify continued use of Postgres to the powers that be. Seems like there has been no word on this for a couple weeks, and I'm not even sure whether or not it has made/will make it into 7.4? Perhaps I've missed a crucial message somewhere... Well, I was going to post a link to the message in the archives, but it appears the archives aren't getting updated -- last good message is from Philip Yarra at about 1400 on 10 July. Here's a copy of what Bruce posted to HACKERS on July 10 later in the day: As some of you may already have realized, the Win32 port and point-in-time recovery (PITR) will not be in the 7.4 release. I was working on Win32, but ran out of time. Jan did not help. Patrick was working on PITR, but ran out of time too, and J.R might be helping him. My new plan is for us to work on Win32 and PITR during the 7.4 beta. If they can be completed in time for 7.4 final, we will add those features and push out a 7.5 release soon afterwards. This give us a nice short-term deadline to shoot for again. Joe ---(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] NLS: czech
Hi, I start translate rest of all non-translated PostgreSQL's LC_MESSAGES from http://developer.postgresql.org/~petere/nls.php. Please, if someone other will do this work connect me first. I want to prevent duplicated work... Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] ERROR: MemoryContextAlloc: invalid request size (maybe bug ingist index)
hi, i use _int contrib module and gist index here sample t1.sql.gz Description: GNU Zip compressed data ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS notification (Path algorithms)
Hi Andreas, Just noticed this commit - thanks, I've been trying to work on it all day but keep getting sidetracked before I can get into it properly! One problem though - none of the helpfiles work for me still (none giving errors now), in my dev environment, or in a test 'real' installation - in fact Bugreport does nothing at all - the rest at least open the help window. Any ideas? I'm stumped as it seems to be loading the correct filenames (albeit with mixed slashes in some cases). Regards, Dave -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 14 July 2003 13:37 To: Dave Page Subject: CVS notification pgadmin3/src/utils misc.cpp --- Triggered commit watch on /disk1/cvsroot/pgadmin3/src/utils By andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ERROR: MemoryContextAlloc: invalid request size (maybe
Try create index data_idx on testkw using gist(data gist__intbig_ops); Default class gist__int_ops is usable for small arrays (with small number of unique elements of all arrays) Nikolay Kim wrote: hi, i use _int contrib module and gist index here sample ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Teodor Sigaev E-mail: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] NLS: czech
Karel Zak [EMAIL PROTECTED] writes: I start translate rest of all non-translated PostgreSQL's LC_MESSAGES from http://developer.postgresql.org/~petere/nls.php. Please, if someone other will do this work connect me first. The backend messages will be getting edited over the course of the next week, so don't waste your time by doing anything with them until that dust settles. You could make progress on the frontend and client messages though. 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] NLS: czech
On Mon, Jul 14, 2003 at 10:37:24AM -0400, Tom Lane wrote: Karel Zak [EMAIL PROTECTED] writes: I start translate rest of all non-translated PostgreSQL's LC_MESSAGES from http://developer.postgresql.org/~petere/nls.php. Please, if someone other will do this work connect me first. The backend messages will be getting edited over the course of the next week, so don't waste your time by doing anything with them until that dust settles. You could make progress on the frontend and client messages though. Yes. I don't want to translate something for BE until beta version will release. I have done pg_controldata, libpq, pg_resetxlog and I work on pgscripts now. Maybe I will work on pgadmin too. Karel -- Karel Zak [EMAIL PROTECTED] http://home.zf.jcu.cz/~zakkr/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] NLS: czech
-Original Message- From: Karel Zak [mailto:[EMAIL PROTECTED] Sent: 14 July 2003 15:49 To: Tom Lane Cc: pgsql-hackers Subject: Re: [HACKERS] NLS: czech Yes. I don't want to translate something for BE until beta version will release. I have done pg_controldata, libpq, pg_resetxlog and I work on pgscripts now. Maybe I will work on pgadmin too. You'd be more than welcome :-) Regards, Dave. ---(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] [GENERAL] Backwards index scan
[ reply redirected to a more appropriate list ] Dmitry Tkach [EMAIL PROTECTED] writes: I am not sure if this is really a bug, but it certainly looks like one to me... It's not a bug, but I agree that _bt_first can be inefficient if there are lots of matching keys. This is because there are *lots* (a few million) of matches for x=10, and _bt_first () scans through them *all* sequentually to get to the last one. I understand that with the generic approach to operators in postgres it is, probably, not very feasible to try and teach _bt_first () to handle this situation automatically (it would need to know how to get next/previous value for every indexable type)... I think what we'd want is variant versions of _bt_search and _bt_binsrch that locate the first entry greater than the specified target key, rather than the first entry greater than or equal to it. Given such positioning, all the _bt_first cases that involve stepping over more than one entry could be improved to require no more than one step. Not sure whether it'd be better to make clone versions of these functions, or to add a parameter to tell them which behavior is wanted. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] cvs version compile error on AIX 4.3.3 using xlc (long)
Weiping He [EMAIL PROTECTED] writes: just try to compile newly updated 7.4-devl version on a AIX 4.4.3 box, [ lots of problems ] make[3]: Entering directory `/home/postgres/pgsql-7.4/pgsql/src/backend/port' xlc -O2 -qmaxmem=16384 -qsrcmsg -qlonglong -I../../../src/include -c -o pg_shmem.o pg_shmem.c 310 | if ((hdr = (PGShmemHeader *) memAddress = PGSharedMemoryAttach( ...a a - 1506-025 (S) Operand must be a modifiable lvalue. I've fixed this one, since I was in process of modifying that file anyway. I think that there are proposed patches already to address the AI_NUMERICHOST issue (Kurt?). The ecpg problems are Michael Meskes' responsibility. Not sure whether we should remove #include ldfcn.h from the AIX dynloader file as you suggest --- why was it put in there to begin with? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bad permissions bug in 7.3 dump (and 7.4)?
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Has anyone looked at this problem? I have delved into the source code, but I can't for the life of me see where to make the change. I think there are actually a few possible solutions: * Dump all foreign key constraints as a superuser I don't like that solution --- pg_dump should not operate on the assumption that it has access to a superuser account, at least not when dumping single-owner databases. * Prevent changing ownership of tables that have foreign keys where the new owner does not have REFERENCE privs for all referenced tables. * Grant REFERENCE to new owner when changing ownership of table. Neither of these would really prevent the problem AFAICS, since you could easily create the same situation by revoking the REFERENCE priv afterwards. The generic problem is that you can get into states where references exist that should not be allowed under the current privilege setup. It doesn't only affect foreign keys, either --- consider for example a view that references a table in another schema, and suppose USAGE rights on that other schema are revoked from the view owner. Probably the only real solution is to implement DROP-CASCADE-like checking when a privilege is revoked. Seems like rather a lot of work :-( regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Possible psql bug
Christopher Kings-Lynne [EMAIL PROTECTED] writes: When I run psql on freebsd/alpha with latest CVS and no postmaster running, I get this: bash-2.03$ psql test psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket ùÿÿÿØ`? What's with the bizarre socket name? I suspect the recent IPv6 code changes have broken the SockAddr struct definition for you, probably by making unportable assumptions about field size or layout. Do you have time to look at it, or can you grant access to your machine for someone else? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Fwd: Re: [HACKERS] Possible psql bug
This mail didn't make it to the list, it seems. Kurt ---BeginMessage--- On Thu, Jul 10, 2003 at 10:35:04AM +0800, Christopher Kings-Lynne wrote: When I run psql on freebsd/alpha with latest CVS and no postmaster running, I get this: bash-2.03$ psql test psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket ùÿÿÿØ`? This is probably getnameinfo() not supporting AF_UNIX, which I already was afraid of. And the return value of getnameinfo() isn't checked either. My suggestion was to make our own getnameinfo_unix() like we have a getaddrinfo_unix() for exactly the same reason. It should be rather easy to write since we already have a getnameinfo() in it that supports it. Kurt ---End Message--- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] duplicate define in elog.h
I was looking through elog.h and noticed this at about line 36: #define ERROR 20 /* user error - abort transaction; return * to known state */ #define ERROR 20 /* user error - abort transaction; return * to known state */ Joe ---(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] duplicate define in elog.h
Joe Conway [EMAIL PROTECTED] writes: I was looking through elog.h and noticed this at about line 36: #define ERROR 20 /* user error - abort transaction; return * to known state */ #define ERROR 20 /* user error - abort transaction; return * to known state */ Good catch. Looks like it snuck in here: http://developer.postgresql.org/cvsweb.cgi/pgsql-server/src/include/utils/elog.h.diff?r1=1.41r2=1.42 regards, tom lane ---(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] Transaction handling in extended query mode and Sync message issues
Carlos Guzman Alvarez [EMAIL PROTECTED] writes: In the extended query mode documentation i see this: Note: Sync does not cause a transaction block opened with BEGIN to be closed. It is possible to detect this situation since the ReadyForQuery message includes transaction status information. I have tested the same cycle with a BEGIN WORK but having the same problem, any idea on what i'm doing wrong ??? Did you figure this out? I can't see any way that a Sync message would close a transaction started with BEGIN (or START TRANSACTION). It runs the same code we run at the end of a simple-Query message, and we'd definitely have noticed if that were causing premature commit ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ERROR: MemoryContextAlloc: invalid request size
thanks! error is gone. On , 2003-07-14 at 20:36, Teodor Sigaev wrote: Try create index data_idx on testkw using gist(data gist__intbig_ops); Default class gist__int_ops is usable for small arrays (with small number of unique elements of all arrays) Nikolay Kim wrote: hi, i use _int contrib module and gist index here sample ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [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
