Re: [HACKERS] Open items for 8.2
--On Montag, September 04, 2006 23:58:35 -0400 Tom Lane [EMAIL PROTECTED] wrote: Updatable views are likewise dead --- we don't have a credible patch or any short-term path to get one. I hope to see both of these items land early in the 8.3 devel cycle, but for 8.2, nyet. Yeah, i don't had the time to get to it the last days and to fix all outstanding issues, sorry for that. Regarding to the complexity of all required work that needs to be done, 8.3 is the better choice, indeed. -- Thanks Bernd ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] BUG #2600: dblink compile with SSL missing libraries
Chris Browne wrote: I also seem to recall, in past discussions about library matters, that AIX is more sticky about requiring that libraries be named expressly. ecpglib has SHLIB_LINK = -L../pgtypeslib -lpgtypes $(libpq) \ $(filter -lintl -lssl -lcrypto -lkrb5 -lcrypt -lm, $(LIBS)) $(PTHREAD_LIBS) ifeq ($(PORTNAME), win32) # Link to shfolder.dll instead of shell32.dll SHLIB_LINK += -lshfolder endif Presumably the same would be necessary everywhere else libpq is used. I replaced: SHLIB_LINK = $(libpq) with SHLIB_LINK = $(libpq) $(LIBS) which allowed the compile to get through this. Do you build static or dynamic? What is the output of 'ldd psql'? I am wondering because I had similar problems building on AIX (5.3) before I told the linker to look for libpq.so BEFORE libpq.a by giving it LDFLAGS=-Wl,-bdynamic,-brtl (using gcc). This is just a thought - triggered by your remark that 'AIX is more sticky about requiring that libraries be named expressly'. Because in a static build you'd have to specify all the libraries whenever you link. Yours, Laurenz Albe ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 hard crash problem
Yes they are using a connection pool. A java based one. Since java has it's own protocol implementation, this is totally unrelated to any libpq error messages. Another important point that we've not been given information on: when pgAdmin/libpq starts failing like this, exactly what is happening with the connection pool? Is it still able to issue queries, and if not what happens exactly? No, when this happens everything stops. The only thing they get back is that message until they reboot the server. The web app (via java/connection pool), pgAdmin both give the same error. Which now that I think about it, seems odd if the message is coming from libpq yes? Yes, this is very odd, AFICS, this message does not exist in the java driver. So it would be interesting to get the actual logs from the client. Definitly - that error msg showing up in the web app really doesn't make sense. However, are we sure that the error message is *exactly* the same, word for word, or is it possible that it's just the same in what it says but with different words? I assume there are screendumps to verify this ;-) Another point that at least I don't know - what kind of connection pool is it? Is it an external one (like pgpool) to which the java app connects (using FE/BE protocol, emulating a proper postmaster but pooling access to the database), or is it running inside the app server (like for example .net connection pooling does, which simply means that when you run the Open() method on the connection object it will pick something off an *internal* pool)? //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 hard crash problem
Magnus Hagander wrote: Another point that at least I don't know - what kind of connection pool is it? Is it an external one (like pgpool) to which the java app connects (using FE/BE protocol, emulating a proper postmaster but pooling access to the database), or is it running inside the app server (like for example .net connection pooling does, which simply means that when you run the Open() method on the connection object it will pick something off an *internal* pool)? Googling for 3CPO [1] shows that it is a Java-based connection pool that implements connection pooling using the JDBC API, i.e. it is an *internal* pool running inside the app servers JVM. PG Admin cannot in any case connect through this pool. Best Regards Michael Paesold [1] http://sourceforge.net/projects/c3p0 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] @ versus ~, redux
The existing geometric containment tests seem to be nonstrict, so if we wanted to leave room to add strict ones later, it might be best to settle on x @= yx contains or equals y x =@ yx is contained in or equals y reserving @ and @ for future strict comparison operators. At first glace, it seems more intuitive to me to do: x @= y x contains or equals y x =@ y y is contained in or equals y Hm, I've never seen anyone spell less than or equal to as =, so I'm not sure where you derive =@ from? Not saying no, but the other seems clearer to me. Yes, but to me too =@ seems more natural since we started with @ and @. Tom, your argument would more match your original @ and @, but then it would imply @= and @=, imho. Andreas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] @ versus ~, redux
Tom Lane wrote: The existing geometric containment tests seem to be nonstrict, so if we wanted to leave room to add strict ones later, it might be best to settle on x @= y x contains or equals y x =@ y x is contained in or equals y reserving @ and @ for future strict comparison operators. Since the choice of @ and @ comes from current ltree operators I'd like to point out that they are non-strict for ltree, and this could add a little bit of inconsistence. Best regards -- Matteo Beccati http://phpadsnew.com http://phppgads.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Open items for 8.2
Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane: A couple of recently discussed FE/BE protocol issues are: not storing a plan at all for unnamed-statement cases, and thus allowing bind parameters to be treated as constants; allowing parameter types to go unresolved rather than throwing an error. Perhaps it's too late to consider these for 8.2, but they seem no more invasive than some other items on the open-issues list. Do we have a patch for that today? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Open items for 8.2
Am Dienstag, 5. September 2006 03:07 schrieb Bruce Momjian: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. What about using the wiki? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open items for 8.2
Hello, On Wed, 2006-09-06 at 13:04 +0200, Peter Eisentraut wrote: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. It is suffering from a DNS problem. What about using the wiki? Wiki has the same problem, too. Regards, -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ signature.asc Description: This is a digitally signed message part
[HACKERS] wartho failing
Hi, Warthog has been failing for the last 12 hours or so on contrib/sslinfo It seems that readline and termcap should not be linked with. What can I do to help? Also, now that beta is approaching, warthog runs his HEAD buikd every 8 hours. Do we need it more often? Regards, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] patching question
Sorry to ask this question here... How do I include newly created files in a patch with difforig or patch Thank you. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] ECPG regression failures on OpenBSD
Michael, if you want shell access to guppy, just contact me privately. Warning: guppy too, is somewhat dated (1:10 hours for the make step) :/ Michael, did you receive my private mail yesterday? (just want to make sure it wasn't blocked by an overzealous spam filter) Bye, Chris. -- Chris Mair http://www.1006.org ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] wartho failing
On Wed, Sep 06, 2006 at 01:32:53PM +0200, ohp@pyrenet.fr wrote: Hi, Warthog has been failing for the last 12 hours or so on contrib/sslinfo It seems that readline and termcap should not be linked with. What can I do to help? Classic putting-non-PIC-code-in-a-shared-library error. You can't do that; for some reason it's picked up the static version of termcap. In any case, it shouldn't be using termcap at all. Something in the makefile is including it obviously... Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] patching question
On Wed, Sep 06, 2006 at 01:37:51PM +0200, Gevik Babakhani wrote: Sorry to ask this question here... How do I include newly created files in a patch with difforig or patch Thank you. The -N option to diff treats non-existant files as empty. So diff -crN should do it. Have you read the developers FAQ? Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Open items for 8.2
Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. What about using the wiki? The problem is with the postgresql.org DNS servers. Something weird is afoot around the hub.org nameservers, from what I can tell. Servers seem to be dropping off one by one as TTLs expire. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Win32 hard crash problem
On 6-Sep-06, at 3:27 AM, Magnus Hagander wrote: Yes they are using a connection pool. A java based one. Since java has it's own protocol implementation, this is totally unrelated to any libpq error messages. Another important point that we've not been given information on: when pgAdmin/libpq starts failing like this, exactly what is happening with the connection pool? Is it still able to issue queries, and if not what happens exactly? No, when this happens everything stops. The only thing they get back is that message until they reboot the server. The web app (via java/connection pool), pgAdmin both give the same error. Which now that I think about it, seems odd if the message is coming from libpq yes? Yes, this is very odd, AFICS, this message does not exist in the java driver. So it would be interesting to get the actual logs from the client. Definitly - that error msg showing up in the web app really doesn't make sense. However, are we sure that the error message is *exactly* the same, word for word, or is it possible that it's just the same in what it says but with different words? I assume there are screendumps to verify this ;-) I looked at the code in the jdbc driver and it doesn't even do this check Another point that at least I don't know - what kind of connection pool is it? Is it an external one (like pgpool) to which the java app connects (using FE/BE protocol, emulating a proper postmaster but pooling access to the database), or is it running inside the app server (like for example .net connection pooling does, which simply means that when you run the Open() method on the connection object it will pick something off an *internal* pool)? It's an internal pool, and the client has told me off list they have removed it and are using the jdbc driver pool. At this point I'm confused as to what they really are using, but as they have contracted Command Prompt to fix this for them, I am no longer in the private loop. Dave //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] ECPG/OpenBSD buildfarm failures, take I
It seems ECPG regression tests trigger a bug in OpenBSD libc. Please try
the attached test case. I should give ERANGE as error, but on OpenBSD
errno is set to 0.
I tried this test case on Linux, where it works, and OpenBSD 3.8 and 4.0
(that is HEAD). On both these systems it doesn't. Now the question is
what do we do?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
#include stdio.h
#include stdlib.h
#include errno.h
main()
{
char *tmp=0.02;
double d;
d = strtod(tmp, NULL);
printf(error %d, double = %g\n, errno, d);
}
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Open items for 8.2
Martha Stewart called it a Good Thing when [EMAIL PROTECTED] (Magnus Hagander) wrote: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. What about using the wiki? The problem is with the postgresql.org DNS servers. Something weird is afoot around the hub.org nameservers, from what I can tell. Servers seem to be dropping off one by one as TTLs expire. Apparently Marc is back; he recently had a question about reordering IP addresses on pgsql.sql, which suggests some sort of DNS maintenance being up. Hopefully this is a matter of things getting a little worse before they get more comprehensively fixed. I hope... -- let name=cbbrowne and tld=gmail.com in name ^ @ ^ tld;; http://linuxdatabases.info/info/spreadsheets.html Look, would it save you all this bother if I just gave up and went mad now? -- Arthur Dent ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] @ versus ~, redux
Zeugswetter Andreas DCP SD [EMAIL PROTECTED] writes: Hm, I've never seen anyone spell less than or equal to as =, so I'm not sure where you derive =@ from? Not saying no, but the other seems clearer to me. Yes, but to me too =@ seems more natural since we started with @ and @. Tom, your argument would more match your original @ and @, but then it would imply @= and @=, imho. Well, I'm reading it as a comparison operator with @ plastered on the side of the larger object, not a mirror-image thing. But maybe we should just stick with @ and @ as per the ltree precedent, and not worry about leaving room for strict inclusion tests. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Open items for 8.2
Peter Eisentraut [EMAIL PROTECTED] writes: Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane: A couple of recently discussed FE/BE protocol issues are: not storing a plan at all for unnamed-statement cases, and thus allowing bind parameters to be treated as constants; allowing parameter types to go unresolved rather than throwing an error. Perhaps it's too late to consider these for 8.2, but they seem no more invasive than some other items on the open-issues list. Do we have a patch for that today? We could have a patch for the first one today --- I was thinking about it last night and intending to code it today. The second one is merely a matter of removing an error check that exists now; the question really is do people want that behavior. (I asked that on the jdbc list and got zero response, so actually I was thinking that it was a dead issue; but as long as it's on the open-items list we ought to discuss it.) regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.2
Peter Eisentraut wrote: Am Dienstag, 5. September 2006 03:07 schrieb Bruce Momjian: Here are the open items for 8.2: http://momjian.postgresql.org/cgi-bin/pgopenitems This host seems to be offline. What about using the wiki? The host is fine. postgresql.org DNS is broken. Reference the host directly: http://momjian.us/cgi-bin/pgopenitems -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Simplifying standby mode
Simon Riggs wrote: On Sat, 2006-09-02 at 09:14 -0400, Bruce Momjian wrote: Simon Riggs wrote: OK, I'll submit a C program called pg_standby so that we have an approved and portable version of the script, allowing it to be documented more easily. I think we are still waiting for this. I am also waiting for more PITR documentation to go with the recent patches. Yup. Likely to be completed by end of next week now, submitted in chunks: 1. Notes on restartable recovery 2. Notes on standby functionality 3. discussion on rolling your own record-level polling using pg_xlogfile_name_offset() 4. pg_standby.c sample code I need #4 long before the end of _this_ week, or it is going to be rejected for 8.2. The documentation can be added even during beta, though the earlier the better so it can be tested. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] @ versus ~, redux
Zeugswetter Andreas DCP SD wrote: The existing geometric containment tests seem to be nonstrict, so if we wanted to leave room to add strict ones later, it might be best to settle on x @= y x contains or equals y x =@ y x is contained in or equals y reserving @ and @ for future strict comparison operators. At first glace, it seems more intuitive to me to do: x @= y x contains or equals y x =@ y y is contained in or equals y Hm, I've never seen anyone spell less than or equal to as =, so I'm not sure where you derive =@ from? Not saying no, but the other seems clearer to me. Yes, but to me too =@ seems more natural since we started with @ and @. Tom, your argument would more match your original @ and @, but then it would imply @= and @=, imho. Doesn't =@ represent the ship from the BASIC version of the Star Trek game from the 70's? :-) -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Open items for 8.2
Bruce Momjian wrote: Tom Lane wrote: Had a bitmap-index patch arrived in my inbox this morning, as had been promised to me for three weekends running, I might have been willing to drop all else and review it. But, no patch. This item is dead for 8.2. Do not even think of suggesting otherwise. Well, we have to use some objective criteria, rather than one person's decision. I would say we are one month past feature freeze, and have not received a patch to review, and you have asked repeatedly. That is enough of a basis to reject this feature for 8.2. Removed from open items list. This may be too little too late, but I have time to work on the bitmap index patch and fix the API issues. I'm familiar with the index am API and I can see the issues with the patch as it stands. If it's definitely too late for 8.2, I'd like to get it into CVS as soon as possible after the 8.2 release. Jie and/or Gavin, could you send the latest version of the patch to the list in any case? Do you want help with the patch, or would I be stepping on your toes? -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Second try committing the path changes.
On Wed, Aug 30, 2006 at 12:48:55PM -0400, Chris Browne wrote: This looks like you're using an old version of the parser. preproc.y was changed to handle empty database names and the the error you report is due to an empty db name. I think the problem is that the latest version of preproc.c isn't based on that version of preproc.y (or perhaps similarly with pgc.l/pgc.c). ... It seems to me you need to rebuild the C files and commit them. AFAIRC the C files have never been part of the archive. The question is why the new preproc.y didn't trigger a rebuild of preproc.c. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] DNS fixed
Magnus Hagander wrote: Yes, there are DNS issues. They are partly solved, but expect further hiccups for a while. Seems the PostgreSQL master DNS servers became unavailable sometime in the past few hours, and Larry's secondary DNS was not responding because it had stale data. I told Larry to make his servers the master and that has fixed the problem for the present. Once the masters are up, Larry needs to be told to revert to a slave. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Multi-valued user-defined types
Greetings, * Tom Lane ([EMAIL PROTECTED]) wrote: Does anyone have examples of real user-defined types that would need two fields? If not it may not be worth spending time on. Guess I'm jumping in a little late on this, but when reading the threads linked to from the TODO items on user-defined types and typmod parameters I immediately thought of PostGIS and the current 'geometry' type. I've discussed this some with the PostGIS folks and I think they have a definite real-world use-case for multi-valued user-defined types. They achieve this at the moment by using a table in the public sceham to keep the extra information regarding the column since they can't put it in pg_attribute (which is certainly where it belongs). The information for each attribute is: Number of dimensions Spatial Referencing System (identified by the SRID) Type (ie: Point, Polygon, etc) This is pretty standard among GIS databases (indeed, the table they keep this information in is actually defined by the OpenGIS specification and includes these attributes). Ideally, this would be a view rather than a table and the actual information would be stored in pg_attribute (attypmod). It would also mean that the input/output functions could ensure only valid information is put into the columns instead of having to rely on constraints put on the table. The options for how to handle this, in order of what I believe the preference is: POINT(dims, srid) - eg: POINT(2,4269) geometry(dims, srid, type) - eg: geometry(2,4269,'POINT') POINT_2D(srid) - eg: POINT_2D(4269) geometry- eg: geometry (constraints, side-table) SRID is pretty uniformly defined to be an int4 itself, though the PostGIS folks seemed to think it could be cut to 30-bits (2 bits for dimension is enough for them) if necessary. I'd really like to see custom types able to support mutli-values (and to have numeric changed to whatever the new mechanism is). As for how this might be handled in the backend, my thinking was to have a function for parsing the parameters which is passed in a cstring/varchar/etc and then returns a complex type of some kind. My original thought was to return a bytea but an anyarray may also work. Another thought which was mentioned was to add more 'attypmod' columns, ala pg_statistic's stanumbersN columns. I did read through the threads linked from the TODO item but wasn't very clear from those where things stand now. My intention (and understanding based on the threads) is that the goal would be to have this in 8.3. I'm interested in helping to realize this goal as I've become very annoyed at having to deal with this side-table or use functions to add geometry columns. :) Thanks, Stephen - Forwarded message from Markus Schaber [EMAIL PROTECTED] - Date: Wed, 06 Sep 2006 11:48:36 +0200 From: Markus Schaber [EMAIL PROTECTED] To: PostGIS Users Discussion [EMAIL PROTECTED] Organization: Logical Tracking and Tracing International AG, Switzerland User-Agent: Thunderbird 1.5.0.5 (X11/20060812) Reply-To: PostGIS Users Discussion [EMAIL PROTECTED] X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.3 Subject: Re: [postgis-users] What's the Purpose of the Geometry_Columns Table? Hi, Strk, [EMAIL PROTECTED] wrote: Agreement with Markus. CREATE TABLE thetable ( thegeom GEOMETRY(4326,2,'POLYGON') ); Also: CREATE TABLE thetable ( thegeom ST_POLYGON2D(4326) ) (this won't need *multi_valued* typmod) That's right. Due to the small number of geometry and dimension combinations, we could possibly implement them using domains over GEOMETRY, but that's not feasible for the SRIDs. I don't know yet how DOMAINs affect the type names transmitted in the client protocol, so it's possible that the jdbc / j2ee / python geotypes have to be updated, but that might be the case for multi-valued typemods, too. And, finally, shielding the applications via abstraction over such changes is the whole point of those projects. Happy Committing, Markus -- Markus Schaber | Logical TrackingTracing International AG Dipl. Inf. | Software Development GIS Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org ___ postgis-users mailing list [EMAIL PROTECTED] http://postgis.refractions.net/mailman/listinfo/postgis-users - End forwarded message - signature.asc Description: Digital signature
Re: [HACKERS] ECPG/OpenBSD buildfarm failures, take I
Michael Meskes wrote: It seems ECPG regression tests trigger a bug in OpenBSD libc. Please try the attached test case. I should give ERANGE as error, but on OpenBSD errno is set to 0. I tried this test case on Linux, where it works, and OpenBSD 3.8 and 4.0 (that is HEAD). On both these systems it doesn't. Now the question is what do we do? well it's even more interesting that it gives the correct answer on spoonbill (the OpenBSD/Sparc64 box on the buildfarm) - I have forwarded that testcase to the openbsd-tech list maybe we get an answer there ... Stefan ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Getting a move on for 8.2 beta
On Sun, Sep 03, 2006 at 07:42:02PM -0400, Tom Lane wrote: The hard part of this problem is finding a convenient way to capture status data out of the community's conversations. I think when you find a solution to that, you'll notice that email is not the problem. In private groups (like companies) that do this well, that sort of convenient way turns out to be someone who is willing to do the summarisation and post it. Perhaps what is needed is a small group of people who would like to contribute, who can't contribute code, but who can spend some time doing summaries, documents, and that sort of thing? (Yes, I'll put my money where my mouth is.) A -- Andrew Sullivan | [EMAIL PROTECTED] Users never remark, Wow, this software may be buggy and hard to use, but at least there is a lot of code underneath. --Damien Katz ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] @ versus ~, redux
On Tue, 2006-09-05 at 23:00 -0400, Tom Lane wrote: Jeff Davis [EMAIL PROTECTED] writes: On Mon, 2006-09-04 at 10:45 -0400, Tom Lane wrote: The existing geometric containment tests seem to be nonstrict, so if we wanted to leave room to add strict ones later, it might be best to settle on x @= yx contains or equals y x =@ yx is contained in or equals y reserving @ and @ for future strict comparison operators. At first glace, it seems more intuitive to me to do: x @= y x contains or equals y x =@ y y is contained in or equals y Hm, I've never seen anyone spell less than or equal to as =, so I'm not sure where you derive =@ from? Not saying no, but the other seems clearer to me. Initially it seemed strange to me because the @ switches sides but the operator is not symmetrical. I see what you mean. Standard = and = syntax, with an @ on the side of the container. Now I'll be able to remember it at least, so I'm really fine with anything. Regards, Jeff Davis ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] wartho failing
Removing #include $(top_srcdir)/contrib/contrib-global.mk in sslinfo Makefile makes the problem go away... Hope it helps On Wed, 6 Sep 2006, Martijn van Oosterhout wrote: Date: Wed, 6 Sep 2006 13:49:21 +0200 From: Martijn van Oosterhout kleptog@svana.org To: ohp@pyrenet.fr Cc: pgsql-hackers list pgsql-hackers@postgresql.org Subject: Re: [HACKERS] wartho failing On Wed, Sep 06, 2006 at 01:32:53PM +0200, ohp@pyrenet.fr wrote: Hi, Warthog has been failing for the last 12 hours or so on contrib/sslinfo It seems that readline and termcap should not be linked with. What can I do to help? Classic putting-non-PIC-code-in-a-shared-library error. You can't do that; for some reason it's picked up the static version of termcap. In any case, it shouldn't be using termcap at all. Something in the makefile is including it obviously... Have a nice day, -- Olivier PRENANT Tel: +33-5-61-50-97-00 (Work) 15, Chemin des Monges+33-5-61-50-97-01 (Fax) 31190 AUTERIVE +33-6-07-63-80-64 (GSM) FRANCE Email: ohp@pyrenet.fr -- Make your life a dream, make your dream a reality. (St Exupery) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New Linux Filesystem: NILFS
On Tue, 2006-09-05 at 23:28 -0400, [EMAIL PROTECTED] wrote: On Tue, Sep 05, 2006 at 05:54:50PM -0700, Jeff Davis wrote: On Tue, 2006-09-05 at 18:24 -0400, Chris Browne wrote: Recently seen in ACM Operating Systems Review (this is the first time I've found as many as 1 interesting article in it in a while, and there were 3 things I found worthwhile...): ... NILFS is a log-structured file system developed for Linux. As I understand LFSs, they are not ideal for a database system. An LFS is optimized so that it writes sequentially. However, PostgreSQL already ... Do you see an advantage in using LFS for PostgreSQL? Hey guys - I think the original poster only meant to suggest that it was *interesting*... :-) I see, my mistake. Applying any database on top of another database seems inefficient to me. That's one reason why I argue the opposite - PostgreSQL *should* have its own on disk layout, and not being laid out on top of another generic system designed for purposes other than database storage. The reason it isn't pursued at present, and perhaps should not be pursued at present, is that PostgreSQL has other more important priorities in the short term. I think that it would be a higher priority if someone showed a substantial performance improvement. Some filesystems don't really cause much overhead that isn't needed by PostgreSQL. If someone did show a substantial improvement, I would be interested to see it. And if there is an improvement, shouldn't that be a project for something like Linux, where other databases could also benefit? It could just be implemented as a database-specific filesystem. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Simplifying standby mode
On Sat, 2006-09-02 at 09:14 -0400, Bruce Momjian wrote: Simon Riggs wrote: OK, I'll submit a C program called pg_standby so that we have an approved and portable version of the script, allowing it to be documented more easily. I think we are still waiting for this. I am also waiting for more PITR documentation to go with the recent patches. Yup. Likely to be completed by end of next week now, submitted in chunks: 1. Notes on restartable recovery 2. Notes on standby functionality 3. discussion on rolling your own record-level polling using pg_xlogfile_name_offset() 4. pg_standby.c sample code 5. Reworking Marko Kreen's test harness as a example for contrib Any other requests? Timescale acceptable? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Getting a move on for 8.2 beta
Andrew Sullivan wrote: On Sun, Sep 03, 2006 at 07:42:02PM -0400, Tom Lane wrote: The hard part of this problem is finding a convenient way to capture status data out of the community's conversations. I think when you find a solution to that, you'll notice that email is not the problem. In private groups (like companies) that do this well, that sort of convenient way turns out to be someone who is willing to do the summarisation and post it. Perhaps what is needed is a small group of people who would like to contribute, who can't contribute code, but who can spend some time doing summaries, documents, and that sort of thing? (Yes, I'll put my money where my mouth is.) Excellent! You are just the sort of person for this task, I think. cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] TODO: GUID datatype
I would like to know if anyone is working on the GUID datatype. If not, I am going to work on it. Please let me know. Regards, Gevik. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Multi-valued user-defined types
On Wed, Sep 06, 2006 at 12:50:20PM -0400, Stephen Frost wrote:
The information for each attribute is:
Number of dimensions
Spatial Referencing System (identified by the SRID)
Type (ie: Point, Polygon, etc)
snip
POINT(dims, srid) - eg: POINT(2,4269)
geometry(dims, srid, type)- eg: geometry(2,4269,'POINT')
POINT_2D(srid)- eg: POINT_2D(4269)
geometry - eg: geometry (constraints,
side-table)
SRID is pretty uniformly defined to be an int4 itself, though the
PostGIS folks seemed to think it could be cut to 30-bits (2 bits for
dimension is enough for them) if necessary.
User-defined typmod would be cool. As long as you don't want to rely on
the typmod to decode the Datums, it's really just a grammer change. I
proposed a while ago that users be allowed to provide a function that
converts the extra params into an int32 which is the actual typmod.
So the point type would be declared as having a typmod function
point_typmod. So you could have point_typmod(int4) and
point_typmod(int4,int4) to handle both cases. I don't think we should
be tied to only integers as parameters, I'd like to be able to do:
CREATE TABLE ... ( string_field text('latin1'), ...
Whether that's a good way to do that particular feature, I don't know,
but if it's possible I think that would indicate our system is flexable
enough.
Someone posted a patch to the grammer which seemed to work, I don't
think in and of itself it is very difficult. As long as you don't want
to have the typmod to avoid storing data in the datum (which the
raw(64) example is) it should be fairly straightforward...
Hope this helps,
--
Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/
From each according to his ability. To each according to his ability to
litigate.
signature.asc
Description: Digital signature
[HACKERS] Timezone List
Any chance for a DB Client accessible list of allowable time zones? I've been told that the only way to get at this list is by looking through the source and lifting the list from zone.tab. While I'm at it, how about an accessible list of country codes? I know that it's not core db functionality, but these lists are so universally useful that making users parse the files and store them in tables seems silly. What are other people's thoughts on this? Good idea or not? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Timezone List
On Thu, Sep 07, 2006 at 04:07:58AM +1000, Naz Gassiep wrote: Any chance for a DB Client accessible list of allowable time zones? I've been told that the only way to get at this list is by looking through the source and lifting the list from zone.tab. In the CVS version there is a table with this information: http://developer.postgresql.org/pgdocs/postgres/view-pg-timezonenames.html While I'm at it, how about an accessible list of country codes? I know that it's not core db functionality, but these lists are so universally useful that making users parse the files and store them in tables seems silly. Err, where does postgres use this information? I beleive there is a project on pgfoundary that has some standard datasets. Hope this helps, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] Timezone List
Martijn van Oosterhout wrote: In the CVS version there is a table with this information: http://developer.postgresql.org/pgdocs/postgres/view-pg-timezonenames.html Great, thanks for that Err, where does postgres use this information? I beleive there is a project on pgfoundary that has some standard datasets. Currently, it is stored in /src/timezone/data/iso3166.tab and I propose to have it available in a system view or something similar. This data is as useful as the available timezones, although I concede that it is not part of PG functionality and this may be more appropriate as a simple file that can be psql -f'd into the database if users need it as part of an app. It's more developer helper data than database functionlity and hence it could be more appropriate to distribute through the support community rather than as part of the postgresql core. Comments? ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Open items for 8.2
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Am Dienstag, 5. September 2006 05:58 schrieb Tom Lane: A couple of recently discussed FE/BE protocol issues are: not storing a plan at all for unnamed-statement cases, and thus allowing bind parameters to be treated as constants; allowing parameter types to go unresolved rather than throwing an error. Perhaps it's too late to consider these for 8.2, but they seem no more invasive than some other items on the open-issues list. Do we have a patch for that today? We could have a patch for the first one today --- I was thinking about it last night and intending to code it today. The second one is merely a matter of removing an error check that exists now; the question really is do people want that behavior. (I asked that on the jdbc list and got zero response, so actually I was thinking that it was a dead issue; but as long as it's on the open-items list we ought to discuss it.) I personally think it's a good idea to do it, as it should improve the plans for one-shot queries. Unfortunately I don't certainly know how the JDBC driver issues queries when called through a PreparedStatement but without a prepare-threshold[*] set. If it uses the unnamed-statement, then I guess the proposed change would be a win. Best Regards Michael Paesold [*] This option determines, after how many executes of a prepared statement, the driver will switch to server-side prepares. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Timezone List
Naz Gassiep [EMAIL PROTECTED] writes: Martijn van Oosterhout wrote: Err, where does postgres use this information? I beleive there is a project on pgfoundary that has some standard datasets. Currently, it is stored in /src/timezone/data/iso3166.tab and I propose to have it available in a system view or something similar. Hm. I wasn't aware that that was present in the zic database; it's not something used by or even exposed to the rest of the system. I would not support adding code that depends on it being there. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Timezone List
Martijn van Oosterhout kleptog@svana.org writes: In the CVS version there is a table with this information: http://developer.postgresql.org/pgdocs/postgres/view-pg-timezonenames.html Actually, what that view gives you is timezone offset abbreviations, not the full zone names that you could use with SET TIME ZONE. It strikes me that we should have a view for that as well. We could use code similar to scan_available_timezones() to generate the view output. It's somewhat urgent to address this now, because pg_timezonenames is sitting on the obvious name for such a view, and once we release 8.2 we won't be able to change it. On reflection I think the existing view is wrongly named --- perhaps it should be pg_timezoneabbrevs? Or more readably, perhaps pg_timezone_abbrevs, with pg_timezone_names for the other view. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] ECPG/OpenBSD buildfarm failures, take I
Michael Meskes wrote: It seems ECPG regression tests trigger a bug in OpenBSD libc. Please try the attached test case. I should give ERANGE as error, but on OpenBSD errno is set to 0. I tried this test case on Linux, where it works, and OpenBSD 3.8 and 4.0 (that is HEAD). On both these systems it doesn't. Now the question is what do we do? a bit of testing shows that at least FreeBSD 4.10 behaves similiar to OpenBSD/i386 and I found the following discussion too: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=3759+0+archive/2003/freebsd-standards/20030511.freebsd-standards that hints that setting ERANGE on an underflow (vs an overflow) is implementation specific though I ws unable to verify that this is indeed the case ... Stefan ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Timezone List
Actually, what that view gives you is timezone offset abbreviations, not the full zone names that you could use with SET TIME ZONE. It strikes me that we should have a view for that as well. We could use code similar to scan_available_timezones() to generate the view output. It's somewhat urgent to address this now, because pg_timezonenames is sitting on the obvious name for such a view, and once we release 8.2 we won't be able to change it. On reflection I think the existing view is wrongly named --- perhaps it should be pg_timezoneabbrevs? Or more readably, perhaps pg_timezone_abbrevs, with pg_timezone_names for the other view. regards, tom lane I agree with having two views, and I also think that the name as it is, is not right. I agree with pg_timezone_abbrevs and pg_timezone_names or similar. On a related note, there is not a one:one relationship between abbreviations and zone names, some abbreviations are used by two zones (forex EST, CST and others are used in Australia and the Americas) and currently it is a server configuration directive (australian_timezones) to assume Australian or American zones in the case of ambiguity. I don't know about anyone else, but the whole australian_timezones thing seems like an ugly hackaround to me. I do not have a proposed solution to this, but I see a non-trivial risk of an application being re-deployed on a server where the admin forgets to change this directive resulting in all kinds of fun and games. Forgive me if this is an already-discussed issue. I am also rather baffled at the way SAT is changed from being interpreted as a day of the week in one mode, and a timezone in another. This seems an awful incongruity of behavior, and SAT should be interpreted as a timezone in both modes. If it must be done, switching of this behavior doesn't fit in with the purpose of the australian_timezones directive and should be made the subject of a different directive (e.g., sat_is_timezone(boolean) or something similar). SAT should, IMHO, always be considered a timezone and use of the SAT string by DB programmers should be just another case for care as with any other SQL keyword. ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Timezone List
Naz Gassiep [EMAIL PROTECTED] writes: I don't know about anyone else, but the whole australian_timezones thing seems like an ugly hackaround to me. You really shouldn't be pontificating about this if you haven't been paying attention to recent development work ;-) regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] BUG #2600: dblink compile with SSL missing libraries
Chris Browne [EMAIL PROTECTED] writes: I still need the following, on AIX: -SHLIB_LINK = $(libpq) +SHLIB_LINK = $(libpq) $(LIBS) No you don't --- see recent warthog complaint. We have to filter LIBS down to just the minimum. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 hard crash problem
Joshua D. Drake [EMAIL PROTECTED] writes: O.k. to recap: This message will present itself, if connection attempts are made from the Web Application (Java/JDBC), or locally via PgAdmin. Once the error message is received, all subsequent connection attempts will also result in that same message. We do not know if the error occurs before or after authentication. I think other people have claimed that this message is in libpq and not in JDBC source code which is inconsistent with this description. The only known resolution is to reboot Windows. Using the service control panel to shutdown postgresql will fail once the message is received. It is unknown if using the task master to individually kill processes will work. This contradicts your previous email about restarting the postmaster working. I think you have to sit down and write down *exactly* what sequence of actions cause what results. Describing them in shorthand like if connection attempts are made is leading to a lot of speculation instead of systematic deductions. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] FE/BE protocol vs. parameterized queries
I wrote: Andrew - Supernews [EMAIL PROTECTED] writes: I believe this could usefully (and transparently to clients) be changed so that Bind on the unnamed statement does _not_ store the plan back in the unnamed statement's context, but instead produces a plan which is only used _for that specific portal_. That seems OK to me, since we document the unnamed statement/portal as being optimized for one-shot execution. Unfortunately it's probably less than a trivial change, because the planner never assumes that Params are constants; that would have to be changed somehow. I've applied a patch to do this --- the planner change turned out to be pretty trivial after all. The infrastructure for the former planning method (using the first Bind's parameters as sample values for estimation, but not as constants) is still there, but it's not being used now. Does anyone want to argue for changing things to plan named statements that way? I'm of two minds about it myself; you can make a good case that it'd usually be a win, but it's also not hard to envision scenarios where it'd be a loss. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Timezone List
In the CVS version there is a table with this information: http://developer.postgresql.org/pgdocs/postgres/view-pg-timezonenames. html Actually, what that view gives you is timezone offset abbreviations, not the full zone names that you could use with SET TIME ZONE. It strikes me that we should have a view for that as well. We could use code similar to scan_available_timezones() to generate the view output. You know, I think I suggested that back in the days when I worked on the replacement timezone code, and you didn't want it back then ;-) If you think it's good now then yes, I still think it is. I may even have the code for it around somewhere if I go look a bit... Assuming we can sneak this in even though it's feature-freeze, want me to look for it? It's somewhat urgent to address this now, because pg_timezonenames is sitting on the obvious name for such a view, and once we release 8.2 we won't be able to change it. On reflection I think the existing view is wrongly named --- perhaps it should be pg_timezoneabbrevs? Or more readably, perhaps pg_timezone_abbrevs, with pg_timezone_names for the other view. Seems reasonable - my vote is for the more readable version. //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Timezone List
On Thu, Sep 07, 2006 at 05:29:04AM +1000, Naz Gassiep wrote: I am also rather baffled at the way SAT is changed from being interpreted as a day of the week in one mode, and a timezone in another. Ugh. It'd be an argument if people actually used SAT as a timezone. They don't, it's ACST. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
Re: [HACKERS] ECPG/OpenBSD buildfarm failures, take I
On Wed, Sep 06, 2006 at 09:13:34PM +0200, Stefan Kaltenbrunner wrote: that hints that setting ERANGE on an underflow (vs an overflow) is implementation specific though I ws unable to verify that this is indeed the case ... Odd, according to these references: http://www.csse.uwa.edu.au/programming/ansic-library.html#stdlib http://cplus.kompf.de/cliblist.html http://docs.hp.com/en/B9106-90010/strtod.3C.html returning ERANGE on underflow was in the ANSI C standard. Can't find the text itself though, Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate. signature.asc Description: Digital signature
UUID/GUID discussion leading to request for hexstring bytea? (was: Re: [HACKERS] TODO: GUID datatype)
On Wed, Sep 06, 2006 at 07:49:09PM +0200, Gevik Babakhani wrote: I would like to know if anyone is working on the GUID datatype. If not, I am going to work on it. Please let me know. Assuming you mean GUID in the same sense as UUID, there are many non-core developers who would like to see it, or who have worked on one. There are at least three floating around that I am aware of, one of which I contributed to, that works well, and one that I imagine works well (the OSSP UUID library includes a PostgreSQL binding) both of which include support for a UUID type, including the desired index support and plpgsql function calls for generating, and manipulating the UUID values. I'm a little stuck at the moment, as I have time sapped away from me by things like real work, and I'm trying to prepare a submission that would be acceptable for core. I've read the thoughts of some of the core developers on this subject, and agree with many of them. The UUID type itself has value, however, the value it provides is limited. Generation of a UUID doesn't have to occur with the database. The application inserting the row can generate the UUID. The UUID type itself has limited value, in that the difference between a 36 bytes + 4 bytes = 40 bytes as a fully expanded char(40), or the packed value using the hexstring encode/decode SQL functions of a bytea type at 16 + 4 bytes = 20 bytes compared to a tightly packed UUID type of 16 bytes, are very close. The argument can easily be made that if space (disk space, index size, I/O bandwidth) is your first priority, than a UUID is the wrong type to use. A 64-bit integer may suffice. I'm also having trouble with the idea that a UUID deserves special treatment. I currently have a desire to store both UUID and MD5 checksum in my rows. They are both 128 bits = 16 bytes, and fit all of the same requirements above. I would really like to have an MD5 checksum type now for the same reason. It has a reasonable use that few could deny. Perhaps an MD5 checksum type would be more frequently used than a UUID type? More systems these days are using the MD5 checksum as a unique identifier for content. It has a few clever advantages. Assuming it really is well distributed, and extremely unlikely for overlap to occur within a system, the MD5 checksum has the advantage of automatically dealing with duplicate values. In my case, I have chosen to identify uploaded jpeg images by their MD5 checksum. This makes it seem as if a generic 128-bit data type would be desirable. They both have a compatible representation of a hexadecimal string. The extra '-' characters in the UUID can be easily added when necessary by a HEXSTRING2UUID() sort of function in plpgsql or in the claling application. But - MD5 isn't the only checksum that is frequently used. Some argue that the MD5 can be shown to be weak in some regards, and that perhaps other checksum algorithms such as SHA-1 provide a better guarantee of uniqueness. SHA-1 isn't 128-bits. It's 160-bits. This is where I start to buy Tom Lane's argument that the 4-byte prefix is no big deal. I find it more desirable to have a binary data type with a hexadecimal string input and output function. The flexibility of being able to use 128-bits or 160-bits is worth this 4-byte header to me. What I don't want to do is store double size fields, stored as hexadecimal. This leads to a few options: 1) Create specific types as necessary, with associated functions. No overhead. - uuid, md5sum, sha1sum, ... 2) Create semi-generic types with common bitlengths. Associated functions work on these semi-generic types. No overhead. - hexstring128, hexstring160, ... 3) Create a new bytea type that has ascii input and output formats, probably based around hexstrings. Overhead of 4 bytes. 4) Use varchar to store these types, and provide associated functions that return character strings in the right format. This follows the existing md5sum() PostgreSQL function. Overhead is double the size of the data. 5) Use bytea to store these types, and the encode/decode functions are passed character strings in the right format. Possibly complicated for the application to deal with, as well as a user typing SQL commands. Overhead of 4 bytes. As I said - I'm stuck. Not sure which way to go. I currently use a uuid type that I and another person on this list wrote against the OSSP UUID library. For the MD5 checksum, I use char(32). Cheers, mark -- [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] __ . . _ ._ . . .__. . ._. .__ . . . .__ | Neighbourhood Coder |\/| |_| |_| |/|_ |\/| | |_ | |/ |_ | | | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness bind them...
[HACKERS] Problems with extended-Query logging code
I happened to notice that the recently added code to log Bind-message parameters was printing garbage into my log. On investigation it turned out to be trying to print an already-pfree'd string. That's fixable, but having looked at the code closely, I see a bunch of other stuff I'm not happy about either: * It's overly verbose: printing the same parameters twice seems excessive. * It's inefficient: it's spending effort on formatting and copying parameter information around, whether or not there's any chance of that information ever being wanted. * It doesn't log the values of parameters sent in binary mode, which is something that at least JDBC needs. Another issue, which isn't the fault of the recent patches but has been there right along, is that execution of Parse or Bind could take awhile (due to planning of a complex query) but there's no log_duration or log_min_duration_statement coverage for these message types. Here are some thoughts about fixing it: * For extended-Query mode I propose that we treat log_duration and log_min_duration_statement as being effectively per-message not per-statement. That is, we'd log a Parse or Bind operation if it individually exceeded the duration threshold, and not otherwise. * I'm inclined to think that Parse and Bind shouldn't be logged at all, or maybe only at DEBUG2 or higher, unless logged by duration logging. If we've got support for logging the statement text and the parameter values at Execute time, isn't logging the preliminary steps just bloating the log? * I think that the best way to log bind-parameter values is to run the datatype output functions on the saved parameter values. This works whether they were sent in text or binary mode, and avoids any extra overhead at Bind time that might not be repaid. Comments? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Timezone List
Magnus Hagander [EMAIL PROTECTED] writes: Assuming we can sneak this in even though it's feature-freeze, want me to look for it? Yeah, please take a look --- seeing the size of the code will probably help us decide if it's too late for 8.2 or not. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Problems with extended-Query logging code
On 6-Sep-06, at 6:01 PM, Tom Lane wrote: I happened to notice that the recently added code to log Bind-message parameters was printing garbage into my log. On investigation it turned out to be trying to print an already-pfree'd string. That's fixable, but having looked at the code closely, I see a bunch of other stuff I'm not happy about either: * It's overly verbose: printing the same parameters twice seems excessive. * It's inefficient: it's spending effort on formatting and copying parameter information around, whether or not there's any chance of that information ever being wanted. * It doesn't log the values of parameters sent in binary mode, which is something that at least JDBC needs. AFAIK, we don't need binary mode right away, currently we only send bytea parameters in binary mode If we could get the text parameters it would be a big win. Another issue, which isn't the fault of the recent patches but has been there right along, is that execution of Parse or Bind could take awhile (due to planning of a complex query) but there's no log_duration or log_min_duration_statement coverage for these message types. Here are some thoughts about fixing it: * For extended-Query mode I propose that we treat log_duration and log_min_duration_statement as being effectively per-message not per-statement. That is, we'd log a Parse or Bind operation if it individually exceeded the duration threshold, and not otherwise. * I'm inclined to think that Parse and Bind shouldn't be logged at all, or maybe only at DEBUG2 or higher, unless logged by duration logging. If we've got support for logging the statement text and the parameter values at Execute time, isn't logging the preliminary steps just bloating the log? * I think that the best way to log bind-parameter values is to run the datatype output functions on the saved parameter values. This works whether they were sent in text or binary mode, and avoids any extra overhead at Bind time that might not be repaid. Comments? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ECPG/OpenBSD buildfarm failures, take I
On Wed, Sep 06, 2006 at 11:20:12PM +0200, Martijn van Oosterhout wrote: Odd, according to these references: http://www.csse.uwa.edu.au/programming/ansic-library.html#stdlib http://cplus.kompf.de/cliblist.html http://docs.hp.com/en/B9106-90010/strtod.3C.html returning ERANGE on underflow was in the ANSI C standard. Can't find the text itself though, In Plauger's _The Standard C Library_ (1992) on p 335 is an excerpt from the standard (I think). At the end of a section entitled 7.10.1.4 The strtod function is the following: If the correct value would cause underflow, zero is returned and the value of the macro ERANGE is stored in errno. I don't know how much weight a reference that old still has, but it does show that ERANGE on underflow has been defined for a long time. The Open Group Base Specifications Issue 6 (2004) also documents ERANGE on underflow: If the correct value would cause an underflow, a value whose magnitude is no greater than the smallest normalized positive number in the return type shall be returned and errno set to [ERANGE]. I'd post the link but they want people to register to read the specification; you can get there from here: http://www.opengroup.org/online-pubs-short?DOC=9699959299FORM=HTML -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Problems with extended-Query logging code
On 6-Sep-06, at 6:17 PM, Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
On 6-Sep-06, at 6:01 PM, Tom Lane wrote:
* It doesn't log the values of parameters sent in binary mode, which
is something that at least JDBC needs.
AFAIK, we don't need binary mode right away, currently we only send
bytea parameters in binary mode
I thought somebody had mentioned that integers were also sent in
binary
in the latest driver code? Can't find the archive entry right now
though.
regards, tom lane
Checking the source code
boolean isBinary(int index) {
// Currently, only StreamWrapper uses the binary parameter
form.
return (paramValues[index -1] instanceof StreamWrapper);
}
So for now if we concentrate on text parameters, binary parameters
would be superfluous for the moment.
Dave
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] Problems with extended-Query logging code
Tom Lane wrote: I happened to notice that the recently added code to log Bind-message parameters was printing garbage into my log. On investigation it turned out to be trying to print an already-pfree'd string. That's fixable, Uh, can you show me where? but having looked at the code closely, I see a bunch of other stuff I'm not happy about either: * It's overly verbose: printing the same parameters twice seems excessive. You mean printing the bind parameters on execute? I thought we wanted lines to be self-contained, and they can suppress the hints. * It's inefficient: it's spending effort on formatting and copying parameter information around, whether or not there's any chance of that information ever being wanted. The problem there was there was no way to know what the GUC setting was going to be by the time you did the execute, so I always stored it. It is possible that is excessive. * It doesn't log the values of parameters sent in binary mode, which is something that at least JDBC needs. Right. Another issue, which isn't the fault of the recent patches but has been there right along, is that execution of Parse or Bind could take awhile (due to planning of a complex query) but there's no log_duration or log_min_duration_statement coverage for these message types. Yea, I figured that the odds that a bind or execute would take greater than a certain duration was very unlikely, and the overhead of computing the timing is might be pretty large compared to the actual prepare/bind. Here are some thoughts about fixing it: * For extended-Query mode I propose that we treat log_duration and log_min_duration_statement as being effectively per-message not per-statement. That is, we'd log a Parse or Bind operation if it individually exceeded the duration threshold, and not otherwise. If you think the overhead it worth it, go ahead. * I'm inclined to think that Parse and Bind shouldn't be logged at all, or maybe only at DEBUG2 or higher, unless logged by duration logging. If we've got support for logging the statement text and the parameter values at Execute time, isn't logging the preliminary steps just bloating the log? Good point. I had not thought of that. * I think that the best way to log bind-parameter values is to run the datatype output functions on the saved parameter values. This works whether they were sent in text or binary mode, and avoids any extra overhead at Bind time that might not be repaid. Yes, I didn't get into something that complicated, but it would be a more complete solution. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Problems with extended-Query logging code
Dave Cramer [EMAIL PROTECTED] writes: On 6-Sep-06, at 6:01 PM, Tom Lane wrote: * It doesn't log the values of parameters sent in binary mode, which is something that at least JDBC needs. AFAIK, we don't need binary mode right away, currently we only send bytea parameters in binary mode I thought somebody had mentioned that integers were also sent in binary in the latest driver code? Can't find the archive entry right now though. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Problems with extended-Query logging code
On Wed, 6 Sep 2006, Tom Lane wrote: I thought somebody had mentioned that integers were also sent in binary in the latest driver code? Can't find the archive entry right now though. Using the fastpath protocol integers and oids are sent as binary. I don't know if that is related to this or logged at all. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] New Linux Filesystem: NILFS
[EMAIL PROTECTED] (Jeff Davis) writes: On Tue, 2006-09-05 at 23:28 -0400, [EMAIL PROTECTED] wrote: On Tue, Sep 05, 2006 at 05:54:50PM -0700, Jeff Davis wrote: On Tue, 2006-09-05 at 18:24 -0400, Chris Browne wrote: Recently seen in ACM Operating Systems Review (this is the first time I've found as many as 1 interesting article in it in a while, and there were 3 things I found worthwhile...): ... NILFS is a log-structured file system developed for Linux. As I understand LFSs, they are not ideal for a database system. An LFS is optimized so that it writes sequentially. However, PostgreSQL already ... Do you see an advantage in using LFS for PostgreSQL? Hey guys - I think the original poster only meant to suggest that it was *interesting*... :-) I see, my mistake. From a reliability perspective, I can see some value to it... I have seen far too many databases corrupted by journalling gone bad in the past year... :-( Applying any database on top of another database seems inefficient to me. That's one reason why I argue the opposite - PostgreSQL *should* have its own on disk layout, and not being laid out on top of another generic system designed for purposes other than database storage. The reason it isn't pursued at present, and perhaps should not be pursued at present, is that PostgreSQL has other more important priorities in the short term. I think that it would be a higher priority if someone showed a substantial performance improvement. Some filesystems don't really cause much overhead that isn't needed by PostgreSQL. If someone did show a substantial improvement, I would be interested to see it. And if there is an improvement, shouldn't that be a project for something like Linux, where other databases could also benefit? It could just be implemented as a database-specific filesystem. The classic problem with log structured filesystems is that sequential reads tend to be less efficient than in overwriting systems; perhaps if they can get vacuuming to be done frequently enough, that might change the shape of things. That would be a relevant lesson that _we_ have discovered that is potentially applicable to filesystem implementors. And I don't consider this purely of academic interest; the ability to: a) Avoid the double writing of journalling, and b) Avoid the risks of failures due to misordered writes are both genuinely valuable. -- output = reverse(ofni.sesabatadxunil @ enworbbc) http://cbbrowne.com/info/lisp.html All ITS machines now have hardware for a new machine instruction -- PFLTProve Fermat's Last Theorem. Please update your programs. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Sequences were not being shown due to the use of lowercase `s`
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tom Lane asked: Superusers can access anything they want to. What's your point? The spec says accessible ... disclaimer Not trying to lecture you Tom :), just posting my argument here for others. /disclaimer Temp tables are special because the user does not know (and, more importantly, should not usually have to know) which pg_temp_ schema the table is created in. For example, if I am in session #1 and create a table, I simply issue CREATE TABLE foobar(a int); If I want to test for the table's existence, I simply do: SELECT 1 FROM information_schema.tables WHERE table_name ='foobar'; If I want to be more specific with regards to a schema: CREATE TABLE zoo.foobar(a int); SELECT 1 FROM information_schema.tables WHERE table_name ='foobar' AND table_schema = 'zoo'; However, if I create a temp table, a problem occurs: CREATE TEMP TABLE foobar(a int); SELECT 1 FROM information_schema.tables WHERE table_name ='foobar'; -- which schema? The above might give a false positive if another session has created a temporary table of that name. Since the whole point of temp tables is temporary per-session relations, it seems silly for information_schema to tell me that another session already has a temporary table by that name, since that information has no use to me whatsoever. I cannot read from the other temp table (which could be a strong non-accessible argument), and its existence won't stop me from creating a same-named temporary table in my own session. The only thing it can do is cause errors for people who think that there is already a temporary table by that name and try to drop it (which is what prompted this patch in the first place). I can't think of a use case where a user would not want to append a is_visible clause to the query above. That or start tracking which pg_temp_ schema belongs to whom. - -- Greg Sabino Mullane [EMAIL PROTECTED] End Point Corporation PGP Key: 0x14964AC8 200609061927 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFE/1unvJuQZxSWSsgRAgC3AJ4kNmy2DMdGcZmsnbfAkODahKIgTACg9q2I +5q4E6BDmU87o28DnG5QZ1s= =4GFl -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New XML section for documentation
I have added a modified version of this to the SGML documentation, under data types. --- bruce wrote: Here is an new XML section for our SGML documentation. It explains the various XML capabilities, if we support them, and how to use them. Comments? --- XML Document Support XML support is not one capability, but a variety of features supported by a database. These capabilities include storage, import/export, validation, indexing, efficiency of modification, searching, transformating, and XML to SQL mapping. PostgreSQL supports some but not all of these XML capabilities. Future releases of PostgreSQL will continue to improve XML support. Storage --- PostgreSQL stores XML documents as ordinary text documents. It does not split apart XML documents into its component parts and store each element separately. You can use middle-ware solutions to do that, but once done, the data becomes relational and has to be processed accordingly. Import/Export - Because XML documents are stored as normal text documents, they can be imported/exported with little complexity. A simple TEXT field can hold up to 1 gigabyte of text, and large objects are available for larger documents. Validation -- /contrib/xml2 has a function called xml_valid() that can be used in a CHECK constraint to enforce that a field contains valid XML. It does not support validation against a specific XML schema. A server-side language with XML capabilities could be used to do schema-specific XML checks. Indexing Because XML documents are stored as text, full-text indexing tool /contrib/tsearch2 can be used to index XML documents. Of course, the searches are text searches, with no XML awareness, but tsearch2 can be used with other XML capabilities to dramatically reduce the amount of data processed at the XML level. Modification If an UPDATE does not modify an XML field, the XML data is shared between the old and new rows. However, if the UPDATE modifies a XML field, a full modified copy of the XML field must be created internally. Searching - XPath searches are implemented using /contrib/xml2. It processes XML text documents and returns results based on the requested query. Transforming /contrib/xml2 supports XSL transformations. XML to SQL Mapping --- This involves converting XML data to and from relational structures. PostgreSQL has no internal support for such mapping, and relies on external tools to do such conversions. Missing Features o XQuery o SQL/XML syntax (ISO/IEC 9075-14) o XML data type optimized for XML storage See also http://www.rpbourret.com/xml/XMLAndDatabases.htm -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Postgres tracking - the pgtrack project
Bruce Momjian wrote: Robert Treat wrote: FWIW I have never understood why we don't require patch submitters/committers to update the release notes when they do the patch. I've suggested this more than once in the past -- I think it would be a clear improvement over the status quo. Updating the release notes incrementally would lead to more accurate and complete release notes: more accurate because the description for a feature would be written at the same time as the feature itself, and more complete because it would be harder to unintentionally omit discussion of a new feature. It would also help communicate to users what features will be in the next release of Postgres, which is certainly good from a PR point of view (a certain Swedish software company is very fond of talking about the features it will be adding in future releases, for example...) Finally, it would remove the need for a sequential scan of the CVS history, which I'm sure is pretty time-consuming, and delays the beta process. I can't even get documentation for many patches. I am hesitant to add even more burden. I would prefer they concentrate on documentation. The first revision of a patch often doesn't include documentation updates, but in that case the submitter should be promptly told what they need to fix; I think the same would apply here. In practice, if you're committing a patch, you *should* understand it well enough to write a release note entry for it, so the burden might end up falling on committers, anyway. -Neil ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New Linux Filesystem: NILFS
On Wed, 2006-09-06 at 18:55 -0400, Chris Browne wrote: [EMAIL PROTECTED] (Jeff Davis) writes: Do you see an advantage in using LFS for PostgreSQL? Hey guys - I think the original poster only meant to suggest that it was *interesting*... :-) I see, my mistake. From a reliability perspective, I can see some value to it... I have seen far too many databases corrupted by journalling gone bad in the past year... :-( Can you elaborate a little? Which filesystems have been problematic? Which filesystems are you more confident in? And if there is an improvement, shouldn't that be a project for something like Linux, where other databases could also benefit? It could just be implemented as a database-specific filesystem. The classic problem with log structured filesystems is that sequential reads tend to be less efficient than in overwriting systems; perhaps if they can get vacuuming to be done frequently enough, that might change the shape of things. That would be a relevant lesson that _we_ have discovered that is potentially applicable to filesystem implementors. And I don't consider this purely of academic interest; the ability to: a) Avoid the double writing of journalling, and b) Avoid the risks of failures due to misordered writes are both genuinely valuable. Right, LFS is promising in a number of ways. I've read about it in the past, and it would be nice if this NILFS implementation sparks some new research in the area. Regards, Jeff Davis ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Timezone List
On 2006-09-06, Tom Lane [EMAIL PROTECTED] wrote: Martijn van Oosterhout kleptog@svana.org writes: In the CVS version there is a table with this information: http://developer.postgresql.org/pgdocs/postgres/view-pg-timezonenames.html Actually, what that view gives you is timezone offset abbreviations, not the full zone names that you could use with SET TIME ZONE. It strikes me that we should have a view for that as well. We could use code similar to scan_available_timezones() to generate the view output. Any view over the full timezone names should also include the corresponding data from zone.tab in the timezone library source. It's somewhat urgent to address this now, because pg_timezonenames is sitting on the obvious name for such a view, and once we release 8.2 we won't be able to change it. On reflection I think the existing view is wrongly named --- perhaps it should be pg_timezoneabbrevs? Or more readably, perhaps pg_timezone_abbrevs, with pg_timezone_names for the other view. Yes, the abbreviations table is definitely misnamed. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Timezone List
On Wed, 6 Sep 2006, Tom Lane wrote: Martijn van Oosterhout kleptog@svana.org writes: In the CVS version there is a table with this information: http://developer.postgresql.org/pgdocs/postgres/view-pg-timezonenames.html Actually, what that view gives you is timezone offset abbreviations, not the full zone names that you could use with SET TIME ZONE. It strikes me that we should have a view for that as well. We could use code similar to scan_available_timezones() to generate the view output. It's somewhat urgent to address this now, because pg_timezonenames is sitting on the obvious name for such a view, and once we release 8.2 we won't be able to change it. On reflection I think the existing view is wrongly named --- perhaps it should be pg_timezoneabbrevs? Or more readably, perhaps pg_timezone_abbrevs, with pg_timezone_names for the other view. I think 'abbrev' is a like unintuitive. How about 'short_names'? Gavin ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Problems with extended-Query logging code
At 2006-09-06 18:01:38 -0400, [EMAIL PROTECTED] wrote: That is, we'd log a Parse or Bind operation if it individually exceeded the duration threshold, and not otherwise. Ok. If we've got support for logging the statement text and the parameter values at Execute time, isn't logging the preliminary steps just bloating the log? Agreed. Logging Parse/Bind only if they're particularly interesting sounds good to me. * I think that the best way to log bind-parameter values is to run the datatype output functions on the saved parameter values. This works whether they were sent in text or binary mode, and avoids any extra overhead at Bind time that might not be repaid. Great. (The logging of binary parameters is something I also... not exactly _need_, but would be happy about.) -- ams ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] gBorg status?
On Mon, 4 Sep 2006, Dave Page wrote: My understanding is that Gborg is being recovered from backup as I type. I also understand that the delay was not caused by lack of backups or anything similarly scary, but simply by other priorities. Yes, I have the backup uploaded right now, and doing 'recover procedures' as I type this ... it will be up before I go to bed tonight ... As for the 'other priorities' ... the delay was due to an insufficient Internet connection to upload the backup ... we were waiting for our Internet to be installed in our new location, and were using an underpowered temporary connection in the interim ... that one was going to tie up the connection for 40 hours ... once we were able to get the backup server onto its 'permanent connection', the upload took ~5hrs ... As I mentioned, am working on it right now ... will post a follow up once she's back up live and needing to be tested ... she's also moving to one of our 64bit servers, so should be a wee bit better performance wise ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Build date for snapshots?
Folks, I'm not getting bug reports for 8.2 from inside Sun. However, I'm not sure how I can determine from the source what build day a particular snapshot instance is from -- sometimes these files get copied around a bit before being built. Is there a file somewhere that would carry a timestamp inside it? Thanks. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Win32 hard crash problem
Gregory Stark wrote: Joshua D. Drake [EMAIL PROTECTED] writes: O.k. to recap: This message will present itself, if connection attempts are made from the Web Application (Java/JDBC), or locally via PgAdmin. Once the error message is received, all subsequent connection attempts will also result in that same message. We do not know if the error occurs before or after authentication. I think other people have claimed that this message is in libpq and not in JDBC source code which is inconsistent with this description. Yes I am fully aware of that. I am only relaying what the customer said. The only known resolution is to reboot Windows. Using the service control panel to shutdown postgresql will fail once the message is received. It is unknown if using the task master to individually kill processes will work. This contradicts your previous email about restarting the postmaster working. No, it doesn't. I never said restarting the postmaster would work. I said rebooting windows, allows postgresql to come back up. Those are entirely different things. Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Win32 hard crash problem
Joshua D. Drake wrote: Gregory Stark wrote: Joshua D. Drake [EMAIL PROTECTED] writes: The only known resolution is to reboot Windows. Using the service control panel to shutdown postgresql will fail once the message is received. It is unknown if using the task master to individually kill processes will work. This contradicts your previous email about restarting the postmaster working. No, it doesn't. I never said restarting the postmaster would work. I said rebooting windows, allows postgresql to come back up. Those are entirely different things. Yup. It was me who said that restarting the postmaster solved the problem. That's what Dave Cramer told me. But maybe Dave was not certain about that -- he did use the word reboot and I asked for confirmation about whether this was an actual reboot of the machine or just a postmaster reboot, and he said it was the latter. But this may have been a suposition. Sorry for the confusion. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] New Linux Filesystem: NILFS
[EMAIL PROTECTED] (Jeff Davis) wrote: On Wed, 2006-09-06 at 18:55 -0400, Chris Browne wrote: [EMAIL PROTECTED] (Jeff Davis) writes: Do you see an advantage in using LFS for PostgreSQL? Hey guys - I think the original poster only meant to suggest that it was *interesting*... :-) I see, my mistake. From a reliability perspective, I can see some value to it... I have seen far too many databases corrupted by journalling gone bad in the past year... :-( Can you elaborate a little? Which filesystems have been problematic? Which filesystems are you more confident in? Well, more or less *all* of them, on AMD-64/Linux. The pulling the fibrechannel cable test blew them all. XFS, ext3, JFS. ReiserFS was, if I recall correctly, marginally better, but only marginally. On AIX, we have seen JFS2 falling over when there were enough levels of buffering in the way on disk arrays. And if there is an improvement, shouldn't that be a project for something like Linux, where other databases could also benefit? It could just be implemented as a database-specific filesystem. The classic problem with log structured filesystems is that sequential reads tend to be less efficient than in overwriting systems; perhaps if they can get vacuuming to be done frequently enough, that might change the shape of things. That would be a relevant lesson that _we_ have discovered that is potentially applicable to filesystem implementors. And I don't consider this purely of academic interest; the ability to: a) Avoid the double writing of journalling, and b) Avoid the risks of failures due to misordered writes are both genuinely valuable. Right, LFS is promising in a number of ways. I've read about it in the past, and it would be nice if this NILFS implementation sparks some new research in the area. Indeed. I don't see it being a production-ready answer yet, but yeah, I'd certainly like to see the research continue. A vital problem is in the area of vacuuming; there may be things to be learned in both directions. -- output = reverse(moc.liamg @ enworbbc) http://linuxdatabases.info/info/fs.html Health is merely the slowest possible rate at which one can die. ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ECPG/OpenBSD buildfarm failures, take I
Michael Fuhr [EMAIL PROTECTED] writes: In Plauger's _The Standard C Library_ (1992) on p 335 is an excerpt from the standard (I think). At the end of a section entitled 7.10.1.4 The strtod function is the following: If the correct value would cause underflow, zero is returned and the value of the macro ERANGE is stored in errno. The Single Unix Spec also makes it clear that ERANGE on underflow is not optional: http://www.opengroup.org/onlinepubs/007908799/xsh/strtod.html I think there is no question that OpenBSD is broken. The question for us is whether we should expend effort to work around that. We already have a small-is-zero workaround comparison file in the main regression tests, so my thought is that ecpg should probably do likewise ... regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Fix compiler warnings on 64-bit boxes:
Gavin Sherry [EMAIL PROTECTED] writes: It might seem a minor quibble, but it seems like a more reliable approach might be to cast to a 64 bit type and user a 64 bit int formatter. int64 is a real pain to use in error messages because of the machine-dependence of the format string --- the translation machinery doesn't work reliably if you try to do ereport(...errmsg(trouble at offset UINT64_FORMAT, bigintvar)); because any given translator will see only one of the several possible source strings. You can get around this if you have to (print the bigint into a char[n] local array and then use %s in the message), but it's not worth it when dealing with values that can't plausibly overflow an int. I think Teodor fixed it the right way. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Fix compiler warnings on 64-bit
ereport(...errmsg(trouble at offset UINT64_FORMAT, bigintvar)); One more solution: add format code %D to expand_fmt_string() which should be expanded to usual %d on 32-bit architecture and to UINT64_FORMAT on 64-bit. -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Fix compiler warnings on 64-bit boxes:
Teodor Sigaev [EMAIL PROTECTED] writes: ereport(...errmsg(trouble at offset UINT64_FORMAT, bigintvar)); One more solution: add format code %D to expand_fmt_string() which should be expanded to usual %d on 32-bit architecture and to UINT64_FORMAT on 64-bit. Not very workable unless you can figure out how to teach gcc what it means... else we lose compiler checking that the corresponding argument matches, which'd be even more important than usual with a machine-dependent format code. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Ding-dong, contrib is dead ...
On 9/5/06, Abhijit Menon-Sen [EMAIL PROTECTED] wrote: At 2006-09-05 16:35:49 -0400, [EMAIL PROTECTED] wrote: The biggest part of the work needed is to write the documentation --- but we'd have to do that for Abhijit's patch too, since the userlocks docs presumably fall under GPL along with the code. I'll write the documentation, either for the code as it is, or for any replacement we decide to use. I didn't submit documentation (or a Makefile, uninstall_otherlock.sql, etc.) only because I didn't know if anything was going to be done with otherlock now. I just wanted to mention the existence of the code. So basically I don't see the point of investing effort in a bug-compatible version of userlocks, when we can have something cleaner and suitable for the long run with not very much more effort. Fine with me. Two questions: - Where would the code live, if it were in core? - Shall I hack up the API you suggested in your earlier message? are we still moving forward with this? I would love to see this go in for 8.2. merlin ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Build date for snapshots?
Josh Berkus josh@agliodbs.com writes: I'm not getting bug reports for 8.2 from inside Sun. However, I'm not sure how I can determine from the source what build day a particular snapshot instance is from -- sometimes these files get copied around a bit before being built. Is there a file somewhere that would carry a timestamp inside it? Well, you could grep for the latest $PostgreSQL$ header line's commit date, but I kinda wonder why exactly you should need to do that. If you don't know when you pulled the snapshot you are testing, I submit you have a process problem you ought to fix. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Build date for snapshots?
Tom, Well, you could grep for the latest $PostgreSQL$ header line's commit date, but I kinda wonder why exactly you should need to do that. If you don't know when you pulled the snapshot you are testing, I submit you have a process problem you ought to fix. These aren't PostgreSQL test people, but folks from Java and the like testing other stuff. And they're pulling the build from ftp:/pub/dev/, not from CVS. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Ding-dong, contrib is dead ...
At 2006-09-07 00:16:38 -0400, [EMAIL PROTECTED] wrote: - Where would the code live, if it were in core? - Shall I hack up the API you suggested in your earlier message? are we still moving forward with this? I would love to see this go in for 8.2. I don't know about its going into 8.2 or not, but I'm writing the code, and I'll submit a patch tomorrow. -- ams ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Build date for snapshots?
Josh, Well, you could grep for the latest $PostgreSQL$ header line's commit date, but I kinda wonder why exactly you should need to do that. If you don't know when you pulled the snapshot you are testing, I submit you have a process problem you ought to fix. These aren't PostgreSQL test people, but folks from Java and the like testing other stuff. And they're pulling the build from ftp:/pub/dev/, not from CVS. O.k. but why aren't they submitting pgsql-bugs? Believe me, you don't want these people submitting bugs unfiltered by me. Especially since they can't remember when they grabbed the snapshot. Seriously, though, it would be an aid to testing if we could add a tag to the version or README file or something for the pgsql-snapshot that told us build date. If there is one, I can't find it. When Marc gets done putting out fires, I'll ask him how difficult that would be. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Build date for snapshots?
Josh Berkus wrote: Josh, Well, you could grep for the latest $PostgreSQL$ header line's commit date, but I kinda wonder why exactly you should need to do that. If you don't know when you pulled the snapshot you are testing, I submit you have a process problem you ought to fix. These aren't PostgreSQL test people, but folks from Java and the like testing other stuff. And they're pulling the build from ftp:/pub/dev/, not from CVS. O.k. but why aren't they submitting pgsql-bugs? Believe me, you don't want these people submitting bugs unfiltered by me. Especially since they can't remember when they grabbed the snapshot. Heh, o.k. I can definitely respect that :) Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Build date for snapshots?
Josh Berkus wrote: Tom, Well, you could grep for the latest $PostgreSQL$ header line's commit date, but I kinda wonder why exactly you should need to do that. If you don't know when you pulled the snapshot you are testing, I submit you have a process problem you ought to fix. These aren't PostgreSQL test people, but folks from Java and the like testing other stuff. And they're pulling the build from ftp:/pub/dev/, not from CVS. O.k. but why aren't they submitting pgsql-bugs? Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Build date for snapshots?
On Wed, 6 Sep 2006, Josh Berkus wrote: Josh, Well, you could grep for the latest $PostgreSQL$ header line's commit date, but I kinda wonder why exactly you should need to do that. If you don't know when you pulled the snapshot you are testing, I submit you have a process problem you ought to fix. These aren't PostgreSQL test people, but folks from Java and the like testing other stuff. And they're pulling the build from ftp:/pub/dev/, not from CVS. O.k. but why aren't they submitting pgsql-bugs? Believe me, you don't want these people submitting bugs unfiltered by me. Especially since they can't remember when they grabbed the snapshot. Seriously, though, it would be an aid to testing if we could add a tag to the version or README file or something for the pgsql-snapshot that told us build date. How about adding a simple: 'touch snapshotdate' .. in the root directory? Would that suffice? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
