[HACKERS] Testing for a shared library
Hi,
Is there any way of checking to see if a particular shared library is
installed?
eg. select is_shared_library('$libdir/tsearch2');
If not, can we please have one :D
This will greatly help in GUI apps like phpPgAdmin...
Chris
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Testing for a shared library
Is there any way of checking to see if a particular shared library is
installed?
eg. select is_shared_library('$libdir/tsearch2');
How well do you know the library you are looking for? You could just try
creating a function from it and seeing if it fails.
I know it pretty well, but it seems kind of lame to have to create the
function and test for it, especialyl if you have a non-error tolerating
environment.
Plus, you have to know what exported functions it has and you have to
worry about creating any input and return types, etc.
Chris
---(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] Testing for a shared library
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Christopher Kings-Lynne
Sent: 07 September 2005 09:03
To: PostgreSQL-development
Subject: [HACKERS] Testing for a shared library
Hi,
Is there any way of checking to see if a particular shared library is
installed?
eg. select is_shared_library('$libdir/tsearch2');
How well do you know the library you are looking for? You could just try
creating a function from it and seeing if it fails.
Regards, Dave.
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] Testing for a shared library
-Original Message-
From: Christopher Kings-Lynne [mailto:[EMAIL PROTECTED]
Sent: 07 September 2005 09:16
To: Dave Page
Cc: PostgreSQL-development
Subject: Re: [HACKERS] Testing for a shared library
Is there any way of checking to see if a particular shared
library is
installed?
eg. select is_shared_library('$libdir/tsearch2');
How well do you know the library you are looking for? You
could just try
creating a function from it and seeing if it fails.
I know it pretty well, but it seems kind of lame to have to
create the
function and test for it, especialyl if you have a non-error
tolerating
environment.
Yeah, but if you need a quick hack...
Plus, you have to know what exported functions it has and you have to
worry about creating any input and return types, etc.
That's why I asked how well you know the library :-)
/D
---(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] Testing for a shared library
As you know, presence of shared library doesn't mean precense of module in db
:).
You can try selecting:
# select count(*) from pg_opclass where opcname = 'tsvector_ops';
or, more general,
# select count(*) from pg_proc where probin = '$libdir/tsearch2';
But not all modules adds new function...
Christopher Kings-Lynne wrote:
Hi,
Is there any way of checking to see if a particular shared library is
installed?
eg. select is_shared_library('$libdir/tsearch2');
If not, can we please have one :D
This will greatly help in GUI apps like phpPgAdmin...
Chris
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
--
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] Testing for a shared library
No, I want to check that the shared library exists (eg. the slony
libraries) BEFORE executing the slony sql script that creates all the
objects.
Chris
Teodor Sigaev wrote:
As you know, presence of shared library doesn't mean precense of module
in db :).
You can try selecting:
# select count(*) from pg_opclass where opcname = 'tsvector_ops';
or, more general,
# select count(*) from pg_proc where probin = '$libdir/tsearch2';
But not all modules adds new function...
Christopher Kings-Lynne wrote:
Hi,
Is there any way of checking to see if a particular shared library is
installed?
eg. select is_shared_library('$libdir/tsearch2');
If not, can we please have one :D
This will greatly help in GUI apps like phpPgAdmin...
Chris
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] PL/PGSQL and drop/create table
# create table foo ( bar int ); CREATE TABLE # create or replace function func (int) returns int as $$ DECLARE IID alias for $1; CNT int; BEGIN select into CNT count(*) from foo where bar = IID; RETURN CNT; END; $$ language plpgsql; CREATE FUNCTION # select func(1); func -- 0 (1 row) # drop table foo; DROP TABLE # create table foo ( bar int ); CREATE TABLE # select func(1); ERROR: relation with OID 16628 does not exist CONTEXT: SQL statement SELECT count(*) from foo where bar = $1 PL/pgSQL function func line 5 at select into variables After reconnecting to database all is ok. Is it supposed behaviour? -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(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] inet increment with int
On Wed, Sep 07, 2005 at 02:48:00AM -, Andrew - Supernews wrote: On 2005-09-06, Patrick Welche [EMAIL PROTECTED] wrote: Now with: test=# select '192.168.0.0/24'::inet + 1; ERROR: Trying to increment a network (192.168.0.0/24) rather than a host What possible justification is there for this behaviour? test=# select '192.168.0.1/24'::inet + -1; ERROR: Increment returns a network (192.168.0.0/24) rather than a host While I suspect I know where this idea came from, it is equally boneheaded since it is making completely unwarranted assumptions about how inet values are being used. So, back to original version? Comments anyone? Patrick ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS]
After reconnecting to database all is ok. Is it supposed behaviour? Yes. The plpgsql interpreter in the backend directs the backend to prepare and cache every sql statement in the function. The planned statements reference oids of the tables referenced. Dropping the connection gets rid of the (now invalid) cached plan. People have proposed some sort of reparse / replan command, but I don't know if they could gain consensus. It'd be really fancy if plpgsql could sniff into the plan structure of each planned query, looking for table oids, and then registering itself as being a dependent object of that table, so that upon table drop the planned function body could be abandoned, and upon next call to the function, hopefully the table might have been recreated, and then the function gets planned successfully again. Or, if the table does not exist yet, then it just fails as normal. James Robinson Socialserve.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PL/PGSQL and drop/create table
On Wed, Sep 07, 2005 at 03:51:05PM +0400, Teodor Sigaev wrote: ERROR: relation with OID 16628 does not exist CONTEXT: SQL statement SELECT count(*) from foo where bar = $1 http://www.postgresql.org/docs/faqs.FAQ.html#4.19 -- Michael Fuhr ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] inet increment with int
Patrick Welche wrote: Comments anyone? Is incrementing an inet address a valid thing to do, or is its meaning too open to interpretation? How about either a pair of functions, one for incrementing the network and another for the host, or a combined function that allows you to work with both parts in one go? Sam ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Thomas Hallgren [EMAIL PROTECTED] writes: I assume that the path of the shared library will be somehow relative to the GUC dynamic_library_path? Well, whatever you put in the template is what will be in the probin field of the support functions. I suppose it does not *have* to use $libdir, but I would definitely recommend using $libdir rather than depending on dynamic_library_path. I also assume that the handler name can be prefixed with a schema name? All PL/Java support functions reside in the sqlj schema. Not if you use the template facility, they won't. The handler and validator are hard-wired to live in pg_catalog under this scheme. The validator for PL/Java will have to wait until 8.2. Do you want to drop in a stub? It's only a one-line function. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Testing for a shared library
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Is there any way of checking to see if a particular shared library is installed? Try to LOAD it, perhaps. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Tom Lane wrote: Thomas Hallgren [EMAIL PROTECTED] writes: I assume that the path of the shared library will be somehow relative to the GUC dynamic_library_path? Well, whatever you put in the template is what will be in the probin field of the support functions. I suppose it does not *have* to use $libdir, but I would definitely recommend using $libdir rather than depending on dynamic_library_path. I'm not I understand this. The default setting for the dynamic_library_path is $libdir, isn't it? So why have another hardwired setting here? Wouldn't it be better if all PL's used the dynamic_library_path setting at all times? I also assume that the handler name can be prefixed with a schema name? All PL/Java support functions reside in the sqlj schema. Not if you use the template facility, they won't. The handler and validator are hard-wired to live in pg_catalog under this scheme. Ok. That's fine. They're not covered by the SQL standard anyway. I have a lot of other support functions for managing jar files, classpath, etc. in the database. They all live in the sqlj schema but they will not be affected by this. The validator for PL/Java will have to wait until 8.2. Do you want to drop in a stub? It's only a one-line function. Yes, that's a good idea. I'll call them java_validator and javau_validator respectively. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] uuid type for postgres
# [EMAIL PROTECTED] / 2005-09-06 17:54:34 -0400: There's a fair amount of nearly unmaintained cruft in the core distro already (eg, the never-finished line datatype ... or the entire rtree index module ...) and a datatype that might be used by only a few people is a likely candidate to become an unmaintained backwater. And yet it's hard to get rid of stuff that's been there awhile. So one of the questions that's going to be asked is how useful/popular it's really going to be. We'd have use for uuid in tables of N*10^6 rows (N10 in most cases). I'm far from claiming to be an experienced C programmer, but count me in for whatever I'll be able to do. I think that coming up with code that meets the general criteria for inclusion in PostgreSQL first, before it's considered for inclusion, is a reasonable thing to do. One thing that is raising my own level of concern quite a bit is the apparent portability issues. That's understood. -- How many Vietnam vets does it take to screw in a light bulb? You don't know, man. You don't KNOW. Cause you weren't THERE. http://bash.org/?255991 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Thomas Hallgren [EMAIL PROTECTED] writes: Wouldn't it be better if all PL's used the dynamic_library_path setting at all times? I wouldn't think so at all. That's just another way to shoot yourself in the foot; $libdir is the correct place by definition, and any other directory is not the correct place, by definition. This is certainly true for the PLs that are part of the distribution, but I don't see that it would be any less true for add-on PLs. As an example of how to shoot yourself in the foot, consider someone setting dynamic_library_path to point to a version-specific directory: /home/postgres/version74/lib and then updating to a newer release without changing that. If there were some upside to letting people load alternate versions of PLs by changing dynamic_library_path then you might have a point ... but I really don't see any value there, just risk of breakage. Do you want to drop in a stub? It's only a one-line function. Yes, that's a good idea. I'll call them java_validator and javau_validator respectively. OK, I'll add that to the template info. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] uuid type for postgres
Nathan, Take a look at the version 3 or version 5 UUIDs. They essentially do this. The hash isn't reversable, but rather recreatable. Seems that if it were reversable, it would be compression, not a hash. Anyway. Hmmm, yes, true. You're assuming though that you want to leak this information. If you do, or you don't care, go ahead with the v3 or v5 uuid creator. Or use v1 if you want mac/time based uuids, or v4 for random uuids. The convenient thing about using the uuid library is that all of these mechanisms result in the same type, and are thus compatible. That's good, it gives users options. And I can see why you don't want to re-create the functionality in PG code, it's probably pretty large. I've never understood the complex measures which application developers take to create universal IDs. Different applications have different goals. Unguessability might be important in some contexts. Well, IMHO, if the unguessability of UUIDs is an important part of your spec, you have some design problems. But it's not my job to lock up the foot-guns, just to make sure they come with warnings ... -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] uuid type for postgres
Nathan, - linking against libuuid is fine for a contrib/ extension, but no good for a built-in type. A real uuid would have to do a proper independent implementation of uuid creation within pgsql. Why? I think the issue is portability. Remember that this type needs to work on Windows as well as all POSIX platforms and AIX. I'm not sure what the default build instructions are, but i've got the following on my linux box... Quite a list. I wonder what readline is doing there. Readline is for PSQL command completion and history. As for the rest, they are *optional* modules that apparently your RPM builder chose to include; I build from source and my only dependencies are bison, flex, gcc and perl. It would appear that linking against libraries is just fine, I don't see that uuid is any different. Is it portable to all platforms we support? How does it generate its machine identifier? One of the differences between an add-in and core code is support for all PostgreSQL platforms. -- Josh Berkus Aglio Database Solutions 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] Remove xmin and cmin from frozen tuples
On Wed, Sep 07, 2005 at 12:31:01AM -0500, Jim C. Nasby wrote: On Tue, Sep 06, 2005 at 07:02:20PM -0400, Tom Lane wrote: Jim C. Nasby [EMAIL PROTECTED] writes: If the 4 header fields in question were just normalized out, wouldn't all the semantics continue to work the same? All I'm envisioning is replacing them in each tuple with a pointer (vis_id) to another datastore that would be roughly equivalent to: CREATE TABLE visibility ( vis_id SERIAL, xminint, xmaxint, cminint, cmax_xmax int ) Of course you wouldn't use an actual table to do this, but hopefully this clarifies my idea. Well, like I said, I'm not envisioning using a table to store that info. Since we'd be storing 4 fixed-length fields, you wouldn't need to actually store vis_id per entry, just use the offset into the page. Assuming you use one 'slot' to store the id of the first set, you could store 511 tuples per page, which doesn't sound very bad. I think this could be done with our SLRU mechanism, just like pg_clog, pg_subtrans and pg_multixact do. Whether it's really a good idea or not, it's another story. The problem is that you would be creating new ones all the time, it would become a huge source of contention, and it would use a lot of memory. Anyway you are just moving the storage somewhere else -- instead of having 4 fields in the tuple itself, you have one field which points the same 4 fields elsewhere. I don't see how is that a win; it's actually worse because you have to do two lookups. (And actually you have just enlarged the storage requirements because you need to store the vis_id twice.) -- Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com La realidad se compone de muchos sueños, todos ellos diferentes, pero en cierto aspecto, parecidos... (Yo, hablando de sueños eróticos) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] uuid type for postgres
On Wed, Sep 07, 2005 at 09:45:17AM -0700, josh@agliodbs.com wrote: I think the issue is portability. Remember that this type needs to work on Windows as well as all POSIX platforms and AIX. I had forgotten about windows. I'll see to what extent the library i'm using is portable to windows. It would appear that linking against libraries is just fine, I don't see that uuid is any different. Is it portable to all platforms we support? I don't know yet. It could be made to be so though. I don't have any way to compile on windows, so someone would have to be willing to try that. Same with AIX. If someone with an AIX box could download and test it out I would appreciate a compatibility report. How does it generate its machine identifier? No idea. Does it matter? Not having to fret this kind of detail is the advantage of using someone else's library. One of the differences between an add-in and core code is support for all PostgreSQL platforms. So would including my type in contrib be possible then? To me, that is perhaps more important than making it a core type, though i think there should be a core UUID type as well. I'm testing out elog(). I'll post a new version later today. There really won't be any new functionality, it's just code clean up. -- Nathan Wagner ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Remove xmin and cmin from frozen tuples
On Wed, Sep 07, 2005 at 01:05:52PM -0400, Alvaro Herrera wrote: Anyway you are just moving the storage somewhere else -- instead of having 4 fields in the tuple itself, you have one field which points the same 4 fields elsewhere. I don't see how is that a win; it's actually worse because you have to do two lookups. (And actually you have just enlarged the storage requirements because you need to store the vis_id twice.) It would only be of use if the table had few transactions in it; in other words, if it was mostly read-only. For a true read-only table there are other options people have suggested that are probably better. BTW, this becomes even more attractive if vis_id is int2; in that case you can keep the entire mapping in memory in ~1MB. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Remove xmin and cmin from frozen tuples
On Wed, Sep 07, 2005 at 01:20:27PM -0400, Tom Lane wrote: Anyway the fundamental insight has been completely lost here. The original point was that cmin and cmax are only interesting within the originating transaction, and not to anyone else, and thus perhaps don't need to be kept in permanent storage; while xmin/xmax are different animals because they *are* of interest to other transactions. I'm curious to know how can you store the cmin/cmax pair completely out of the tuple. It's easy to see how to store a single identifier in each tuple that would be an index to a structure in local memory. However, to eliminate both you'd have to keep a list of all tuples you have created or obsoleted, with the cmin and cmax of each. This seems like an awful amount of memory. -- Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com I can't go to a restaurant and order food because I keep looking at the fonts on the menu. Five minutes later I realize that it's also talking about food (Donald Knuth) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] uuid type for postgres
On Wed, Sep 07, 2005 at 09:45:17AM -0700, Josh Berkus wrote: Nathan wrote: Quite a list. I wonder what readline is doing there. Readline is for PSQL command completion and history. As for the rest, they are *optional* modules that apparently your RPM builder chose to include; I build from source and my only dependencies are bison, flex, gcc and perl. Still seems odd to me: I would expect psql to have readline, not postgres. Cheers, Patrick ---(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] Remove xmin and cmin from frozen tuples
Alvaro Herrera [EMAIL PROTECTED] writes: I'm curious to know how can you store the cmin/cmax pair completely out of the tuple. It's easy to see how to store a single identifier in each tuple that would be an index to a structure in local memory. However, to eliminate both you'd have to keep a list of all tuples you have created or obsoleted, with the cmin and cmax of each. This seems like an awful amount of memory. Yeah. I think a reasonable compromise scheme is to try to get down to three fields per tuple: xminsame as now xmaxsame as now cid/xvac xvac can share storage with the command ID info as long as VACUUM FULL never tries to move a tuple whose originating or deleting transaction is still running ... which is pretty much the same restriction we had before. For the command IDs, I am imagining: if created in current transaction: use cid to store cmin if deleted in current transaction: use cid to store cmax if both created and deleted in current transaction: cid is an index into an in-memory data structure that contains cmin and cmax. current transaction would have to have the loose definition that includes any subxact of the current top xact, but still, I think that the case where you need both fields is relatively uncommon. The in-memory data structure would only need to contain an entry for each distinct combination of cmin and cmax used in the current xact, so I think we could assume that it would never get unreasonably large. The entries would be created on demand much like we do for multixact ids (I guess you'd want a hash table to map requested cmin/cmax to an existing entry ID quickly). regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Remove xmin and cmin from frozen tuples
Alvaro Herrera [EMAIL PROTECTED] writes: I think this could be done with our SLRU mechanism, just like pg_clog, pg_subtrans and pg_multixact do. Whether it's really a good idea or not, it's another story. The problem is that you would be creating new ones all the time, it would become a huge source of contention, and it would use a lot of memory. ... and you couldn't expire the data in a reasonable period of time. pg_subtrans and pg_multixact have only very short active ranges. pg_clog is longer-lived, but at only 2 bits per transaction, we can stand it. 16 bytes per tuple is a whole lot more data. Anyway the fundamental insight has been completely lost here. The original point was that cmin and cmax are only interesting within the originating transaction, and not to anyone else, and thus perhaps don't need to be kept in permanent storage; while xmin/xmax are different animals because they *are* of interest to other transactions. The storage scheme Jim proposes takes no advantage of that whatever. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] uuid type for postgres
On Wed, Sep 07, 2005 at 09:48:08AM -0700, josh@agliodbs.com wrote: That's good, it gives users options. And I can see why you don't want to re-create the functionality in PG code, it's probably pretty large. It would also be something else that would have to be maintained and debugged. Which i would be starting from scratch. The OSSP UUID library is at version 1.3. From this I infer that he has spent some time maintaining and debugging it. The less duplication of code and effort the better. There may be a problem with using the library as a core type though, due to windows portability concerns. That said, it would probably be easier to port the underlying library than to start from scratch. Well, IMHO, if the unguessability of UUIDs is an important part of your spec, you have some design problems. I was thinking of cryptographic applications. Then, to use an example from another domain, initial TCP sequence numbers should be random (i.e. unguessable). A problem with TCP perhaps. It's been a while since i've read over my copy of _Applied Cryptography_, but I seem to recall that unguessable numbers were sometimes useful. -- Nathan Wagner ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] statement logging / extended query protocol issues
On Tue, 2005-09-06 at 07:47 +, Oliver Jowett wrote: Simon Riggs wrote: Looking more closely, I don't think either is correct. Both can be reset according to rewind operations - see DoPortalRewind(). We'd need to add another bool onto the Portal status data structure. AFAIK this is only an issue with SCROLLABLE cursors, which v3 portals aren't. OK, that may be so, but the internals don't know that. If I use atEnd or atStart then messages would differ from v3 to v2. It would then be easy to confuse v2 cursor actions with multiple re-executions in v3. I want to be able to look at the log and work out what happened, not to start asking questions like do you use v2, v3 or a mix of both?. If queries are short and yet there is much fetching, we may see a program whose main delay is because of program-to-server delay because of fetching. So, I'd like to see that in the log, but I agree with your earlier comments that it should be a shorter log line. I'm coming from the point of view of a user who wants to just turn on query logging. The mechanics of the portals aren't of interest to them. Currently, log_statement = all produces markedly different output depending on whether the extended query protocol is used or not, which is very much an implementation detail.. ...and I hope it would, since the impact on the server differs. I want the log to reflect what has happened on the server. How about log_statement = verbose or something similar to enable logging of all the details, and have all just log Parse and the first Execute? I think I like that suggestion. IMHO the client/server interaction is often worth reviewing as part of a performance analysis, so I do want to include all of that detail, but it sounds like a good idea to be able to turn off the noise once that aspect has been examined. How would that suggestion work when we use log_min_duration_statement? Oliver, would it be possible to show a simplified call sequence and what you would like to see logged for each call? That would simplify the process of gaining agreement and would give a simple spec for me to code. We're into beta now, so I don't want to stretch people's patience too much further by changes in this area. I ask you since I think you have a better grasp on the various protocols than I do. I'll work on a further recoding of what we have been discussing. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] uuid type for postgres
Nathan, I was thinking of cryptographic applications. Then, to use an example from another domain, initial TCP sequence numbers should be random (i.e. unguessable). A problem with TCP perhaps. It's been a while since i've read over my copy of _Applied Cryptography_, but I seem to recall that unguessable numbers were sometimes useful. Yeah, the problem is what it does to your data. If there's no analyzable correspondence between the key and the server/table/row it attaches to, then you have no way to detect if the key and the data have become disassociated. This is, btw, a problem with conventional SERIALs as well. unguessable UUIDs just compound the problem by adding additional variables (the server and the table), as well as generally leading to applications which depend *entirely* on UUID-based integrity and thus can't cope with any failures in UUID generation or transmission. I'm also a little baffled to come up with any real application where making an id number for most tables unguessable would provide any kind of real protection not far better provided by other means. For your users table, sure, but that's a very special case. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] PostgreSQL from source using MinGW
Hi, All. Has anyone successfully built PostgreSQL from source using MinGW? Anyone have step-by-step instructions on how to do this? I am willing to write the documentation on this if I can just get it to work. :-) I have done the following: 1. Install MinGW a. Go to URL: http://www.mingw.org/download.shtml b. Download: MinGW-4.1.1.exe i. Install full set of packages c. Download: MSYS-1.0.10.exe i. Answer y/n questions (installed MinGW on c:/mingw. Make sure this is entered because you will not be able to mount the directory otherwise.) 2. Then, I ran ./configure However, I cannot get the make to work. Do I still need to install the GNU Make utility? Any suggestions? LEEP ~/sources/PostgreSQL/postgresql-8.0.3 $ configure --prefix=/c/PostgreSQL/8.0.3 checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking which template to use... win32 checking whether to build with 64-bit integer date/time support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking if gcc supports -Wdeclaration-after-statement... yes checking if gcc supports -Wold-style-definition... yes checking if gcc supports -Wendif-labels... yes checking if gcc supports -fno-strict-aliasing... yes configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wold-style-definition -Wendif-labels -fno-strict-aliasing checking whether the C compiler still works... yes checking how to run the C preprocessor... gcc -E checking allow thread-safe client libraries... no checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... no checking whether to build with Kerberos 4 support... no checking whether to build with Kerberos 5 support... no checking whether to build with PAM support... no checking whether to build with Rendezvous support... no checking whether to build with OpenSSL support... no configure: WARNING: *** Readline does not work on MinGW --- disabling configure: using CPPFLAGS= -I./src/include/port/win32 -DEXEC_BACKEND configure: using LDFLAGS=-Wl,--allow-multiple-definition checking for gawk... gawk checking for flex... no configure: WARNING: *** Without Flex you will not be able to build PostgreSQL from CVS or *** change any of the scanner definition files. You can obtain Flex from *** a GNU mirror site. (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Flex *** output is pre-generated.) checking whether ln -s works... yes checking for ld used by GCC... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for ranlib... ranlib checking for lorder... no checking for tar... /bin/tar checking for strip... strip checking whether it is possible to strip libraries... yes checking for bison... no configure: WARNING: *** Without Bison you will not be able to build PostgreSQL from CVS or *** change any of the parser definition files. You can obtain Bison from *** a GNU mirror site. (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Bison *** output is pre-generated.) To use a different yacc program (possible, *** but not recommended), set the environment variable YACC before running *** 'configure'. checking for perl... no checking for main in -lbsd... no checking for setproctitle in -lutil... no checking for main in -lm... yes checking for main in -ldl... no checking for main in -lnsl... no checking for main in -lsocket... no checking for main in -lipc... no checking for main in -lIPC... no checking for main in -llc... no checking for main in -ldld... no checking for main in -lld... no checking for main in -lcompat... no checking for main in -lBSD... no checking for main in -lgen... no checking for main in -lPW... no checking for main in -lresolv... no checking for library containing getopt_long... none required checking for main in -lunix... no checking for library containing crypt... no checking for library containing fdatasync... no checking for shmget in -lcygipc... no checking for main in -lwsock32... yes checking for inflate in -lz... no configure: error: zlib library not found If you have zlib already installed, see config.log for details on the failure. It is possible the compiler isn't looking in the proper directory. Use --without-zlib to disable zlib support. LEEP ~/sources/PostgreSQL/postgresql-8.0.3 $ make You need to run the 'configure' program first. See the file 'INSTALL' for installation
Re: [HACKERS] uuid type for postgres
I have made a new version, and made a web page for it. http://granicus.if.org/~nw/uuid/ Given the statement that it won't be accepted for contrib or core unless it compiles on windows, I guess I won't really have anything further to say on the topic. I don't have any way to compile on windows, so it's not an obstacle I can readily address. Comments for improvements are welcome. Other sorts of comments on the code are welcome as well. I hope someone else will find it useful. I won't post any further update/release notices to the list, they're not really on topic, I posted these two so that folks could look at the code i was proposing if they wished. -- Nathan Wagner ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL from source using MinGW
Have you read doc/FAQ_MINGW? --- Lee, Patricia S. wrote: Hi, All. ? Has anyone successfully built PostgreSQL from source using MinGW?? Anyone have step-by-step instructions on how to do this? I am willing to write the documentation on this if I can just get it to work. :-) I have done the following: 1. Install MinGW a. Go to URL:? http://www.mingw.org/download.shtml b. Download:? MinGW-4.1.1.exe i. Install full set of packages c. Download:? MSYS-1.0.10.exe i. Answer y/n questions (installed MinGW on c:/mingw.? Make sure this is entered because you will not be able to mount the directory otherwise.) 2.? Then, I ran ./configure However, I cannot get the make to work. Do I still need to install the GNU Make utility? Any suggestions? LEEP ~/sources/PostgreSQL/postgresql-8.0.3 $ configure --prefix=/c/PostgreSQL/8.0.3 checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking which template to use... win32 checking whether to build with 64-bit integer date/time support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking if gcc supports -Wdeclaration-after-statement... yes checking if gcc supports -Wold-style-definition... yes checking if gcc supports -Wendif-labels... yes checking if gcc supports -fno-strict-aliasing... yes configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wold-style-definition -Wendif-labels -fno-strict-aliasing checking whether the C compiler still works... yes checking how to run the C preprocessor... gcc -E checking allow thread-safe client libraries... no checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... no checking whether to build with Kerberos 4 support... no checking whether to build with Kerberos 5 support... no checking whether to build with PAM support... no checking whether to build with Rendezvous support... no checking whether to build with OpenSSL support... no configure: WARNING: *** Readline does not work on MinGW --- disabling configure: using CPPFLAGS= -I./src/include/port/win32 -DEXEC_BACKEND configure: using LDFLAGS=-Wl,--allow-multiple-definition checking for gawk... gawk checking for flex... no configure: WARNING: *** Without Flex you will not be able to build PostgreSQL from CVS or *** change any of the scanner definition files.? You can obtain Flex from *** a GNU mirror site.? (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Flex *** output is pre-generated.) checking whether ln -s works... yes checking for ld used by GCC... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for ranlib... ranlib checking for lorder... no checking for tar... /bin/tar checking for strip... strip checking whether it is possible to strip libraries... yes checking for bison... no configure: WARNING: *** Without Bison you will not be able to build PostgreSQL from CVS or *** change any of the parser definition files.? You can obtain Bison from *** a GNU mirror site.? (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Bison *** output is pre-generated.)? To use a different yacc program (possible, *** but not recommended), set the environment variable YACC before running *** 'configure'. checking for perl... no checking for main in -lbsd... no checking for setproctitle in -lutil... no checking for main in -lm... yes checking for main in -ldl... no checking for main in -lnsl... no checking for main in -lsocket... no checking for main in -lipc... no checking for main in -lIPC... no checking for main in -llc... no checking for main in -ldld... no checking for main in -lld... no checking for main in -lcompat... no checking for main in -lBSD... no checking for main in -lgen... no checking for main in -lPW... no checking for main in -lresolv... no checking for library containing getopt_long... none required checking for main in -lunix... no checking for library containing crypt... no checking for library containing fdatasync... no checking for shmget in -lcygipc... no checking for main in -lwsock32... yes checking for inflate in -lz... no configure: error: zlib library not found If you have zlib already installed, see config.log for details on the failure.? It is possible
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Thomas Hallgren wrote:
If my assumptions are correct, then please add:
{ java, true, sqlj.java_call_handler, NULL,
libpljava },
{ javaU, false, sqlj.javau_call_handler, NULL,
libpljava },
In the interest of uniformity, please rename your libraries to omit the
lib prefix.
The other problem I see emerging here is that in certain environments,
the java language may not be trusted, such as when it is compiled
with GCJ. Then, this built-in template will override the CREATE
LANGUAGE specification and introduce a security hole.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(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] PostgreSQL from source using MinGW
please direct to -win32-hackers, -general, or -novice. take your pick. Also please don't cc unless you have a reason to speak directly to that person. anyways, install bison. Merlin -Original Message- From: [EMAIL PROTECTED] [mailto:pgsql-hackers- [EMAIL PROTECTED] On Behalf Of Lee, Patricia S. Sent: Wednesday, September 07, 2005 2:32 PM To: Jim C. Nasby; Tom Lane; Bruce Momjian; ITAGAKI Takahiro; pgsql- [EMAIL PROTECTED] Subject: [HACKERS] PostgreSQL from source using MinGW Hi, All. Has anyone successfully built PostgreSQL from source using MinGW? Anyone have step-by-step instructions on how to do this? I am willing to write the documentation on this if I can just get it to work. :-) I have done the following: 1. Install MinGW a. Go to URL: http://www.mingw.org/download.shtml b. Download: MinGW-4.1.1.exe i. Install full set of packages c. Download: MSYS-1.0.10.exe i. Answer y/n questions (installed MinGW on c:/mingw. Make sure this is entered because you will not be able to mount the directory otherwise.) 2. Then, I ran ./configure However, I cannot get the make to work. Do I still need to install the GNU Make utility? Any suggestions? LEEP ~/sources/PostgreSQL/postgresql-8.0.3 $ configure --prefix=/c/PostgreSQL/8.0.3 checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking which template to use... win32 checking whether to build with 64-bit integer date/time support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking if gcc supports -Wdeclaration-after-statement... yes checking if gcc supports -Wold-style-definition... yes checking if gcc supports -Wendif-labels... yes checking if gcc supports -fno-strict-aliasing... yes configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith - Wdeclaration-after-statement -Wold-style-definition -Wendif-labels -fno- strict-aliasing checking whether the C compiler still works... yes checking how to run the C preprocessor... gcc -E checking allow thread-safe client libraries... no checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... no checking whether to build with Kerberos 4 support... no checking whether to build with Kerberos 5 support... no checking whether to build with PAM support... no checking whether to build with Rendezvous support... no checking whether to build with OpenSSL support... no configure: WARNING: *** Readline does not work on MinGW --- disabling configure: using CPPFLAGS= -I./src/include/port/win32 -DEXEC_BACKEND configure: using LDFLAGS=-Wl,--allow-multiple-definition checking for gawk... gawk checking for flex... no configure: WARNING: *** Without Flex you will not be able to build PostgreSQL from CVS or *** change any of the scanner definition files. You can obtain Flex from *** a GNU mirror site. (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Flex *** output is pre-generated.) checking whether ln -s works... yes checking for ld used by GCC... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for ranlib... ranlib checking for lorder... no checking for tar... /bin/tar checking for strip... strip checking whether it is possible to strip libraries... yes checking for bison... no configure: WARNING: *** Without Bison you will not be able to build PostgreSQL from CVS or *** change any of the parser definition files. You can obtain Bison from *** a GNU mirror site. (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Bison *** output is pre-generated.) To use a different yacc program (possible, *** but not recommended), set the environment variable YACC before running *** 'configure'. checking for perl... no checking for main in -lbsd... no checking for setproctitle in -lutil... no checking for main in -lm... yes checking for main in -ldl... no checking for main in -lnsl... no checking for main in -lsocket... no checking for main in -lipc... no checking for main in -lIPC... no checking for main in -llc... no checking for main in -ldld... no checking for main in -lld... no checking for main in -lcompat... no checking for main in -lBSD... no checking for main in -lgen... no checking for main in -lPW... no checking for main in -lresolv... no checking for library containing getopt_long... none required checking for main in
Re: [HACKERS] uuid type for postgres
Josh Berkus josh@agliodbs.com writes: One of the differences between an add-in and core code is support for all PostgreSQL platforms. These days, things won't get into contrib either if they don't work on all the buildfarm machines. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Peter Eisentraut [EMAIL PROTECTED] writes: What I'm trying to say here is that it might be OK to hardcode the properties of core languages in the server, because considering that the only officially supported way to activate those is createlang (rather than using SQL), the properties of them are in effect already hardcoded, and from the point of view of a user who is using createlang, nothing changes. Please note that one of the benefits of a template catalog is that createlang will work for everything in the catalog, not only the core languages. For languages that are not shipped in the core, we gain pretty much nothing by this approach as currently implemented and potentially introduce more problems than we solve (e.g., language is compiled in an untrusted way, but template says it's trusted; template says language has validator, but user uses old version that has none; template points to $libdir, user has it installed elsewhere). These are straw men. We know we have a problem with hard-coded paths in old dumps. We know we have a problem with missing validators in old dumps (which will get worse as more languages acquire validators). And I think that a template is much more likely to prevent than introduce the sorts of mis-definition problems you suggest --- all of them can easily happen now from simple user errors, whereas with a template it would be right every time. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] uuid type for postgres
nathan wagner [EMAIL PROTECTED] writes: On Wed, Sep 07, 2005 at 09:45:17AM -0700, josh@agliodbs.com wrote: How does it generate its machine identifier? No idea. Does it matter? Not having to fret this kind of detail is the advantage of using someone else's library. It absolutely matters, because without knowing that we can have no idea what sort of portability issues we might face with it. I don't buy the not having to fret line in the least. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Peter Eisentraut [EMAIL PROTECTED] writes: The other problem I see emerging here is that in certain environments, the java language may not be trusted, such as when it is compiled with GCJ. Hmm, is that really the case? I thought Java is Java. Then, this built-in template will override the CREATE LANGUAGE specification and introduce a security hole. But it's exactly the same hole the user would create by manually saying CREATE TRUSTED LANGUAGE in error. I don't think that's a reasonable argument against the template idea --- it just says that you have to be aware of what you're doing. (An appropriate solution, in my mind, would be to drop the trusted call handler from the shared library if it's built with gcj --- then there's really no possibility of doing the wrong thing.) regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] uuid type for postgres
On Wed, Sep 07, 2005 at 06:35:51PM +, nathan wagner wrote: I have made a new version, and made a web page for it. http://granicus.if.org/~nw/uuid/ Given the statement that it won't be accepted for contrib or core unless it compiles on windows, I guess I won't really have anything further to say on the topic. I don't have any way to compile on windows, so it's not an obstacle I can readily address. Comments for improvements are welcome. Other sorts of comments on the code are welcome as well. I hope someone else will find it useful. I won't post any further update/release notices to the list, they're not really on topic, I posted these two so that folks could look at the code i was proposing if they wished. Rather than just give up on it, why not create a project in pgFoundry? I don't really see why this *has* to be in core (or contrib) anyway. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [ADMIN] How to determine date / time of last postmaster restart
On Wed, Sep 07, 2005 at 12:38:44AM -0500, Jim C. Nasby wrote: On Tue, Sep 06, 2005 at 08:22:34PM -0400, Tom Lane wrote: PG 8.1 will have a function to return postmaster start time, but not database reset time. I wonder if this is misdefined --- if you are trying to measure database uptime, the last reset would be more appropriate to track. Is it too late to add a function that returns last reset time as well? That would cover all bases and force some less confusing naming. This would be one more vote in favour of initdb before next beta. (pltemplate being the other one.) We should set a threshold in order to be able to decide ... -- Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com Use it up, wear it out, make it do, or do without ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] uuid type for postgres
Patrick Welche [EMAIL PROTECTED] writes: Still seems odd to me: I would expect psql to have readline, not postgres. That's because we generate just one LIBS list and use it for all the executables we build. Autoconf makes it a bit difficult to do otherwise. There is an option in the linux linker to suppress ldd references to shared libraries that aren't actually used by the program, but when we tried to use it we found out it was pretty buggy (see archives). 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] Attention PL authors: want to be listed in template table?
I wrote: Another note: PLs that are not in the core distribution are not created with createlang in the first place, so the issues that led up to this proposal don't apply AFAICT, What I'm trying to say here is that it might be OK to hardcode the properties of core languages in the server, because considering that the only officially supported way to activate those is createlang (rather than using SQL), the properties of them are in effect already hardcoded, and from the point of view of a user who is using createlang, nothing changes. For languages that are not shipped in the core, we gain pretty much nothing by this approach as currently implemented and potentially introduce more problems than we solve (e.g., language is compiled in an untrusted way, but template says it's trusted; template says language has validator, but user uses old version that has none; template points to $libdir, user has it installed elsewhere). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Peter Eisentraut [EMAIL PROTECTED] writes: We are only talking about well-known procedural languages. The issue of completely new languages added by the user is addressed by neither proposal. Sure it is: in my proposal, you can add new languages to the template catalog. (Which admittedly we don't have today. We could have it tomorrow, though, if an initdb for beta2 is OK.) Also, ISTM your proposal is to cause CREATE LANGUAGE foo on an already-existing language to execute GRANT USAGE ON LANGUAGE foo TO PUBLIC instead, rather than erroring out. That doesn't seem to pass the least-surprise test at all. Clearly, there's going to be some surprise element. The surprise element proposed by you is that the command does something completely different than specified (which possibly introduces security holes, see other mail). Haven't seen this other mail yet... My proposal is that the command does only a subset of what it would normally do, which amounts to some sort of implicit OR REPLACE, which people are familiar with. No, because what the command would normally do in that situation (the language already exists) is error out. Silently granting rights is a security risk. What if the DBA already created the language, adjusted its permissions the way he wants, and then accidentally did another CREATE LANGUAGE (or more likely, loaded a dump file containing same)? Now he's got language usage granted to PUBLIC, and he doesn't even know it. The CREATE OR REPLACE variants that we have don't muck with the object's permissions, so I don't see them as good precedent. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL from source using MinGW
Bruce Momjian wrote: Have you read doc/FAQ_MINGW? --- Lee, Patricia S. wrote: To be a little more helpful. Patricia everything you need is here: http://www.postgresql.org/docs/faqs.FAQ_MINGW.html Sincerely, Joshua D. Drake -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(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] Attention PL authors: want to be listed in template table?
Tom Lane wrote: Barring further changes, we'll have a hard-wired template list for 8.1 and a real system catalog in 8.2. So there's a choice now for PLs that are not part of the core distribution: do you want to be listed in the hard-wired template? Another note: PLs that are not in the core distribution are not created with createlang in the first place, so the issues that led up to this proposal don't apply AFAICT, that is: - pg_dump dumps them at a pretty low semantic level -- pg_dump dumps them at exactly the level they were created at. - problem with adding a validator -- An update of PostgreSQL does not change the properties of external modules - issues with hardwired paths to the shared libraries -- This is an issue with all loadable modules and needs a more general solution. Basically, on a major version upgrade, we need to make the user recompile all shared libraries. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL from source using MinGW
Thjis is done all the time - see for example http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=goosebr=HEAD At a minumum you will need to install the DTK and from recollection also bison (must be 1.875) and flex (must be 2.5.4) from the gnuwin32 project You don't need an extra make - the make that comes with Mingw is Gnu make and works just fine. cheers andrew Lee, Patricia S. wrote: Hi, All. Has anyone successfully built PostgreSQL from source using MinGW? Anyone have step-by-step instructions on how to do this? I am willing to write the documentation on this if I can just get it to work. :-) I have done the following: 1. Install MinGW a. Go to URL: http://www.mingw.org/download.shtml b. Download: MinGW-4.1.1.exe i. Install full set of packages c. Download: MSYS-1.0.10.exe i. Answer y/n questions (installed MinGW on c:/mingw. Make sure this is entered because you will not be able to mount the directory otherwise.) 2. Then, I ran ./configure However, I cannot get the make to work. Do I still need to install the GNU Make utility? Any suggestions? LEEP ~/sources/PostgreSQL/postgresql-8.0.3 $ configure --prefix=/c/PostgreSQL/8.0.3 checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 checking which template to use... win32 checking whether to build with 64-bit integer date/time support... no checking whether NLS is wanted... no checking for default port number... 5432 checking for gcc... gcc checking for C compiler default output... a.exe checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... .exe checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking if gcc supports -Wdeclaration-after-statement... yes checking if gcc supports -Wold-style-definition... yes checking if gcc supports -Wendif-labels... yes checking if gcc supports -fno-strict-aliasing... yes configure: using CFLAGS=-O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wold-style-definition -Wendif-labels -fno-strict-aliasing checking whether the C compiler still works... yes checking how to run the C preprocessor... gcc -E checking allow thread-safe client libraries... no checking whether to build with Tcl... no checking whether to build Perl modules... no checking whether to build Python modules... no checking whether to build with Kerberos 4 support... no checking whether to build with Kerberos 5 support... no checking whether to build with PAM support... no checking whether to build with Rendezvous support... no checking whether to build with OpenSSL support... no configure: WARNING: *** Readline does not work on MinGW --- disabling configure: using CPPFLAGS= -I./src/include/port/win32 -DEXEC_BACKEND configure: using LDFLAGS=-Wl,--allow-multiple-definition checking for gawk... gawk checking for flex... no configure: WARNING: *** Without Flex you will not be able to build PostgreSQL from CVS or *** change any of the scanner definition files. You can obtain Flex from *** a GNU mirror site. (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Flex *** output is pre-generated.) checking whether ln -s works... yes checking for ld used by GCC... c:/mingw/mingw32/bin/ld.exe checking if the linker (c:/mingw/mingw32/bin/ld.exe) is GNU ld... yes checking for ranlib... ranlib checking for lorder... no checking for tar... /bin/tar checking for strip... strip checking whether it is possible to strip libraries... yes checking for bison... no configure: WARNING: *** Without Bison you will not be able to build PostgreSQL from CVS or *** change any of the parser definition files. You can obtain Bison from *** a GNU mirror site. (If you are using the official distribution of *** PostgreSQL then you do not need to worry about this because the Bison *** output is pre-generated.) To use a different yacc program (possible, *** but not recommended), set the environment variable YACC before running *** 'configure'. checking for perl... no checking for main in -lbsd... no checking for setproctitle in -lutil... no checking for main in -lm... yes checking for main in -ldl... no checking for main in -lnsl... no checking for main in -lsocket... no checking for main in -lipc... no checking for main in -lIPC... no checking for main in -llc... no checking for main in -ldld... no checking for main in -lld... no checking for main in -lcompat... no checking for main in -lBSD... no checking for main in -lgen... no checking for main in -lPW... no checking for main in -lresolv... no checking for library containing getopt_long... none required checking for main in -lunix... no checking for library containing crypt... no checking for library containing fdatasync... no checking for shmget in -lcygipc... no checking for main in -lwsock32... yes
Re: [HACKERS] uuid type for postgres
Nathan, http://granicus.if.org/~nw/uuid/ Given the statement that it won't be accepted for contrib or core unless it compiles on windows, I guess I won't really have anything further to say on the topic. I don't have any way to compile on windows, so it's not an obstacle I can readily address. Wanna start a pgFoundry project so that someone *else* can do the Windows version, if they want? -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] uuid type for postgres
On Wed, Sep 07, 2005 at 06:48:41PM +0100, Patrick Welche wrote: On Wed, Sep 07, 2005 at 09:45:17AM -0700, Josh Berkus wrote: Nathan wrote: Quite a list. I wonder what readline is doing there. Readline is for PSQL command completion and history. As for the rest, they are *optional* modules that apparently your RPM builder chose to include; I build from source and my only dependencies are bison, flex, gcc and perl. Still seems odd to me: I would expect psql to have readline, not postgres. It's an issue with the linker. I seem to remember that 8.1 uses the --as-needed flag to ld, which means it will only link the libraries that each executable actually uses. Hmm, poking my build, this doesn't seem to be the case: $ ldd `which postgres` linux-gate.so.1 = (0xe000) libz.so.1 = /usr/lib/libz.so.1 (0x41c54000) libreadline.so.5 = /lib/libreadline.so.5 (0xb7f51000) libcrypt.so.1 = /lib/tls/libcrypt.so.1 (0xb7f23000) libresolv.so.2 = /lib/tls/libresolv.so.2 (0x41c6a000) libnsl.so.1 = /lib/tls/libnsl.so.1 (0x41c25000) libdl.so.2 = /lib/tls/libdl.so.2 (0x4118f000) libm.so.6 = /lib/tls/libm.so.6 (0x41153000) libc.so.6 = /lib/tls/libc.so.6 (0x41019000) libncurses.so.5 = /lib/libncurses.so.5 (0xb7ee) /lib/ld-linux.so.2 (0x4100) This is a fairly recent 8.1, maybe post-beta1. Not sure what happened. I certainly don't see the --as-needed in LDFLAGS: $ pg_config | grep LDFLA LDFLAGS = -Wl,-rpath,/pg/install/00orig/lib LDFLAGS_SL = -- Alvaro Herrera -- Valdivia, Chile Architect, www.EnterpriseDB.com ¿Que diferencia tiene para los muertos, los huérfanos, y aquellos que han perdido su hogar, si la loca destrucción ha sido realizada bajo el nombre del totalitarismo o del santo nombre de la libertad y la democracia? (Gandhi) ---(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] PostgreSQL from source using MinGW
On Sep 7, 2005, at 2:31 PM, Lee, Patricia S. wrote: However, I cannot get the make to work. Do I still need to install the GNU Make utility? Any suggestions? LEEP ~/sources/PostgreSQL/postgresql-8.0.3 $ configure --prefix=/c/PostgreSQL/8.0.3 Try adding --without-zlib to your configure. Sorry I don't recall what, if any, limitations that involves. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Tom Lane wrote: How is this different from 1. register language in pg_language without privileges 2. activate language by granting privileges Because you can't create a language without first creating the support procedures, which ordinarily requires having the shared library present. We are only talking about well-known procedural languages. The issue of completely new languages added by the user is addressed by neither proposal. Also, ISTM your proposal is to cause CREATE LANGUAGE foo on an already-existing language to execute GRANT USAGE ON LANGUAGE foo TO PUBLIC instead, rather than erroring out. That doesn't seem to pass the least-surprise test at all. Clearly, there's going to be some surprise element. The surprise element proposed by you is that the command does something completely different than specified (which possibly introduces security holes, see other mail). My proposal is that the command does only a subset of what it would normally do, which amounts to some sort of implicit OR REPLACE, which people are familiar with. -- 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] uuid type for postgres
On Sep 7, 2005, at 10:04 AM, nathan wagner wrote: On Wed, Sep 07, 2005 at 09:45:17AM -0700, josh@agliodbs.com wrote: I think the issue is portability. Remember that this type needs to work on Windows as well as all POSIX platforms and AIX. I had forgotten about windows. I'll see to what extent the library i'm using is portable to windows. You don't need to use a non-standard library for a lot of platforms, you're pretty much guaranteed UUID support for (at least): Linux/Darwin/Mac OS X: uuid_generate uuid/uuid.h (part of libc, at least on Darwin) FreeBSD: uuid_create uuid.h (again, libc) Windows: UuidCreate Rpc.h (link to Rpcrt4.dll, IIRC) Where a native UUID generate is not available, you can include some implementation, but surely other platforms also include UUID implementations. I think Windows portability is a non-issue here. -bob ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL from source using MinGW
Joshua D. Drake wrote: Bruce Momjian wrote: Have you read doc/FAQ_MINGW? --- Lee, Patricia S. wrote: To be a little more helpful. Patricia everything you need is here: http://www.postgresql.org/docs/faqs.FAQ_MINGW.html That information is not adequate in my experience, and needs to be expanded. See my previous email for more details. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] uuid type for postgres
Alvaro Herrera wrote: This is a fairly recent 8.1, maybe post-beta1. Not sure what happened. I certainly don't see the --as-needed in LDFLAGS: $ pg_config | grep LDFLA LDFLAGS = -Wl,-rpath,/pg/install/00orig/lib LDFLAGS_SL = It was removed because it was very badly broken. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] uuid type for postgres
On Wed, Sep 07, 2005 at 11:31:16AM -0700, Josh Berkus wrote: I'm also a little baffled to come up with any real application where making an id number for most tables unguessable would provide any kind of real protection not far better provided by other means. For your users table, sure, but that's a very special case. It should never be the sole means of defense, however, it can be quite effective at prevention. For a rather simple example, consider a site that associates a picture with each member. If the pictures are named 1.jpg, 2.jpg, 3.jpg, etc. it makes it ridiculously easy to write a script to pull all of the pictures off the site. This can be bothersome, as the only type of person who would do this, is the type of person with an illegitimate motivation. I want the data to be easily and freely accessible as specific objects, but I do not wish to provide an easy way of dumping all of the data as a unit. By making the picture identifier unguessable, it discourages the most common sort of abuse of the system. If the number is unguessable, and they can't access the directory as a listing, it will be sufficiently difficult as to discourage the common abuser of the system. On the other hand, an obviously guessable identifier may *encourage* the common person to consider abuse. In my case, it isn't only pictures. I don't want people pulling all the data off the site as a dump, and using it how they wish, but I do wish to make the data freely available, and easily accessible from a web browser. I'm not under the impression that it is impossible for a competent person to dump my database. I am under the impression that the people who would do such a thing, tend not to be intelligent, and will be stopped by this simple tactic. I could use any identifier at all. It could be a random sequence of characters. The UUID appeals to me, as I don't have to re-invent the concept. This use of UUID falls outside the scope of using it to join tables. It's a handle that is associated with the data, for external identification of the object. I happen to also use it as an internal primary key for the objects that fit this category, as I wish to benefit from the built-in merge capabilities of UUID over SERIAL, and I don't currently see the point of keeping a SERIAL and a UUID for each object. On the last point, I did start to do this, but every single one of my queries become more complicated as a result. Using the SERIAL for joining, and the UUID for identifying a set of rows was becoming a little ridiculous for my purposes. Using only the UUID to provide for all my purposes is suiting my requirements for the cost of 1.5X the size of a primary key index, 2X the size of a index for a n to n relation mapping UUID to UUID, and an far less significant increase in table space (much less than 1.5X, although I haven't finished calculating it yet). Not that everybody should rip out SERIAL and replace it with UUID, but it really isn't that bad, and in some cases, such as mine, I don't see the point of using both, and choose to instead allow UUID to solve many of my concerns at the same time, with an acceptable for me cost in database pages. 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... http://mark.mielke.cc/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL from source using MinGW
Andrew Dunstan wrote: http://www.postgresql.org/docs/faqs.FAQ_MINGW.html That information is not adequate in my experience, and needs to be expanded. See my previous email for more details. It is adequate for building sources downloaded from ftp (you don't need bison, flex, DTK for this), but it's not adequate for building sources from cvs. -- Regards Petr Jelinek (PJMODOS) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] uuid type for postgres
Alvaro Herrera [EMAIL PROTECTED] writes: This is a fairly recent 8.1, maybe post-beta1. Not sure what happened. This: 2005-05-07 01:48 neilc * configure, configure.in: Revert the ld --as-needed patch. This breaks Fedora Core 3, due to a strange interaction between ld, readline, termcap, and psql. The symptom is psql failing with this error on startup: symbol lookup error: /usr/lib64/libreadline.so.4: undefined symbol: BC I'm still trying to find the best way to solve this, but in the mean time I'm reverting the patch in order to unbreak FC3. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] pg_config/share_dir
pg_config doesn't currently seem to have an option to report the share_dir. Should it? cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL from source using MinGW
Petr Jelinek wrote: Andrew Dunstan wrote: http://www.postgresql.org/docs/faqs.FAQ_MINGW.html That information is not adequate in my experience, and needs to be expanded. See my previous email for more details. It is adequate for building sources downloaded from ftp (you don't need bison, flex, DTK for this), but it's not adequate for building sources from cvs. Ah. OK. Arguably we should cover both ;-) I think we should also tell people how about --without-readline and about installing zlib or using --without-zlib cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Tom Lane wrote:
These are straw men.
No, these are real problems that exist today.
We know we have a problem with hard-coded paths
in old dumps.
This is irrelevant for non-core languages. If I have PL/foo 1.0
installed and upgrade from PostgreSQL 8.0 to 8.1, then I have to
manually recompile PL/foo and install the shared library. So manual
intervention is required in any case and no template system of any kind
will help.
Moreover, the hard-coded paths will not be solved by your proposal. I
don't suppose that in a release or three will start hard coding postgis
parameters to work around hard coded paths in general plug-in modules?
We know we have a problem with missing validators in
old dumps
This is irrelevant for non-core languages. If I have PL/foo 1.0
installed and upgrade from PostgreSQL 8.0 to 8.1, the validator in
PL/foo 1.0 will not magically appear or disappear. The information in
the dump is the only accurate information that exists about the
existence of a validator. The information in the template is
completely unrelated to reality. You are assuming that during the
update from PostgreSQL 8.0 to PostgreSQL 8.1 there will also be an
upgrade from PL/foo 1.0 to PL/foo ${latest-at-time-of-8.1-release}, but
there is simply no basis for assuming that.
And I think that a template is much more likely to
prevent than introduce the sorts of mis-definition problems you
suggest
No, the template system introduces misdefinitions that would otherwise
not exist.
--- all of them can easily happen now from simple user
errors, whereas with a template it would be right every time.
As you can see above, that is not true.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Tom Lane wrote: But it's exactly the same hole the user would create by manually saying CREATE TRUSTED LANGUAGE in error. I don't think that's a reasonable argument against the template idea --- it just says that you have to be aware of what you're doing. (An appropriate solution, in my mind, would be to drop the trusted call handler from the shared library if it's built with gcj --- then there's really no possibility of doing the wrong thing.) The case in reality is this: First of all, the language name java is fixed by the SQL standard, so we ought to allow alternative implementations to use that name. I'm not sure what kind of interface the PL/J people are working on, but if they also lay claim to the name java, then we have a problem. Second, Java is not, in fact, always Java, so different quality variants of the same implementations exist. The Debian package of pljava is compiled using gcj, but it is also planned to provide an alternative version that is compiled using the Sun JDK. That way, users can trade off quality/features vs. licensing freedom. This is the kind of freedom of choice that the current situation allows. Now the template solution will buy nothing here, because there has never been a release of PL/Java that (a) used a hard-coded shared library path, or (b) was ambiguous about its installation schema in the first place. And the validator upgrade issue will also not be solved unless there is a major synchronization effort between the PostgreSQL upstream, the PL/Java upstream, the PostgreSQL packager, and the PL/Java packager (4 different parties) (and in worse cases: the GCC packagers, etc.). In other words, it is not possible and could only be solved effectively by putting PL/Java in the core both upstream and downstream. I think you are assuming all the way through this discussion that a PostgreSQL upgrade will also entail an upgrade of all procedural languages. People are putting dummy validator functions into their code right now, but (1) will they also release that new version at the same time as PostgreSQL 8.1 comes out?, and (2) will users be willing to upgrade at the same time? Point 1 is questionable at best, and point 2 is completely out of the question, not only because I've seen too many PL releases just plain break, but simply because people may want to upgrade one thing at a time. Again, we could work around both of these points by putting the PL in question into the core, in which case I am willing to support the template idea, but for languages out of the core I don't think the implicitly required synchronization efforts have been taking into account. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Peter Eisentraut [EMAIL PROTECTED] writes:
Tom Lane wrote:
We know we have a problem with hard-coded paths
in old dumps.
This is irrelevant for non-core languages. If I have PL/foo 1.0
installed and upgrade from PostgreSQL 8.0 to 8.1, then I have to
manually recompile PL/foo and install the shared library. So manual
intervention is required in any case and no template system of any kind
will help.
Certainly you have to install new software, but that is a task exactly
equivalent to installing the new version of Postgres itself. The
problem being addressed here is fixing wrong information in your pg_dump
scripts, and that is just as real for non-core as core PLs. The
proposal *will* fix the need for manual intervention while reloading
dump data.
Moreover, the hard-coded paths will not be solved by your proposal.
On what basis do you assert that? The proposal will replace those paths
by $libdir/plfoo (or whatever is in the template), which is something
we should be able to go forward with indefinitely ... and if we can't,
a template update will fix it in some future release.
Now this certainly discriminates against installing PLs outside $libdir,
but I haven't heard any good reason why people would need to do that.
We know we have a problem with missing validators in
old dumps
This is irrelevant for non-core languages.
Again, I see no basis for that assertion. It is only true to the extent
that non-core languages haven't created validators yet.
If I have PL/foo 1.0
installed and upgrade from PostgreSQL 8.0 to 8.1, the validator in
PL/foo 1.0 will not magically appear or disappear.
As a general rule, PLs have to at least be recompiled to move to a new
release of the backend, and usually need some source code tweaking as
well. So I think your premise is faulty. You'll need to install the
8.1 version of that PL, and that very possibly will have a validator
where none existed before.
... The information in
the dump is the only accurate information that exists about the
existence of a validator.
Except that the information in the dump is likely *not* to be accurate.
It tells you the way things were some number of releases ago, and as
we've already seen, people frequently propagate their dumps forward
across multiple releases --- indeed, one would hope that they'd be able
to do so. We need to fix things so that that Just Works in the face of
improvements to PLs.
You are assuming that during the
update from PostgreSQL 8.0 to PostgreSQL 8.1 there will also be an
upgrade from PL/foo 1.0 to PL/foo ${latest-at-time-of-8.1-release}, but
there is simply no basis for assuming that.
How many of the past major releases have allowed a previous PL to be
used without any changes? Hardly any AFAIR, and 8.1 is certainly not
far behind the previous ones when it comes to making internal API
changes that affect PLs.
In any case, not one of these arguments seems to me to favor the
alternative of preloading definitions into pg_language: that preloaded
definition is going to be just as wrong as the template information, if
either one is wrong. Now it's true that a hardwired template table is
harder to fix than a system catalog, but we can get rid of the hardwired
table at the same cost (viz, a forced initdb) as adding preloaded
definitions. I don't see any other advantage to doing it that way.
One other response to your point about surprise or lack of it: in my
proposal, in a release or so everyone will just be doing CREATE
LANGUAGE foo and there will be no surprise that the system knows how to
fill in the low-level details. The handler functions will be relegated
to what they should have been all along: an implementation detail. But
I think that having CREATE LANGUAGE alter the permissions of an existing
entry would be a permanent security risk; it will never not surprise
people, because other forms of CREATE don't do that.
regards, tom lane
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_config/share_dir
Andrew Dunstan wrote: pg_config doesn't currently seem to have an option to report the share_dir. Should it? Is there a case where a user would need anything from there? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pg_config/share_dir
Peter Eisentraut wrote: Andrew Dunstan wrote: pg_config doesn't currently seem to have an option to report the share_dir. Should it? Is there a case where a user would need anything from there? Why would they need pkglibdir either? I was asked about this by an author who wanted to use it to find where to put module config/setup scripts. cheers andrew ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: The other problem I see emerging here is that in certain environments, the java language may not be trusted, such as when it is compiled with GCJ. Well, yes. But use the word environment in singular please :-) To my knowledge the security is full-proof with all other VM's since they all use the standard runtime libraries. The GCJ support is as experimental as the GCJ in itself and cannot be trusted in production. Hmm, is that really the case? I thought Java is Java. GCJ is a clean house implementation of Java. They don't use the runtime libraries from Sun and they are not really there yet in their efforts to copy the functionality. One of the things that lag behind is security. They hope to have a better security implementation before the year end but there's no promise. Then, this built-in template will override the CREATE LANGUAGE specification and introduce a security hole. But it's exactly the same hole the user would create by manually saying CREATE TRUSTED LANGUAGE in error. I don't think that's a reasonable argument against the template idea --- it just says that you have to be aware of what you're doing. (An appropriate solution, in my mind, would be to drop the trusted call handler from the shared library if it's built with gcj --- then there's really no possibility of doing the wrong thing.) That's a though although I'm not sure we would gain anything. No PL/Java binaries are provided that run with GCJ. You have to compile from source using some specific settings. If you are skilled enough to experiment with that, then there's a good chance you are able to tweak the source to enable the trusted call handler also. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Peter Eisentraut [EMAIL PROTECTED] writes: The case in reality is this: First of all, the language name java is fixed by the SQL standard, so we ought to allow alternative implementations to use that name. I'm not sure what kind of interface the PL/J people are working on, but if they also lay claim to the name java, then we have a problem. Second, Java is not, in fact, always Java, so different quality variants of the same implementations exist. The Debian package of pljava is compiled using gcj, but it is also planned to provide an alternative version that is compiled using the Sun JDK. That way, users can trade off quality/features vs. licensing freedom. Are you seriously suggesting that it's a good idea for the single language name java to mean different things at different installations? I can't believe that that wouldn't lead to chaos. In any case, java has not been put forward as one of the template entries, and as long as we don't accept a template for it, we have not made the situation any worse. I think you are assuming all the way through this discussion that a PostgreSQL upgrade will also entail an upgrade of all procedural languages. Yes, I am assuming that, and I challenge you to supply examples of PLs that won't require at least a recompile before there's any hope of their working on 8.1. In a quick look through the CVS logs, I note that heap_openr/index_openr are gone, the representation of pg_proc entries is quite a bit different than it was in 8.0, and there are incompatible changes in the APIs of spi.c and dynahash.c. The pg_proc changes in particular practically guarantee a need for a source-code update. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] initdb profiles
One regular topic of conversation on IRC and elsewhere is that the settings initdb installs especially for memory use, connections, and so on, are often very conservative. Of course, we tell people how to tune them to some extent, although performance tuning seems to remain a black art. But I wondered if it might not be a good idea to allow an option to initdb which would provide a greater possible range of settings for max_connections, shared_buffers and so on. For example, we might offer a profile which is very conservative for memory bound machines, medium size for a development platform, large for a server running with other server processes, and huge for a decdicated box, and then provide some heuristics that initdb could apply. We'd have to let all of these degrade nicely, so that even if the user select the machine hog setting, if we find we can only do something like the tiny setting that's what s/he would get. Also, we might need to have some tolerably portable way of finding out about machine resources. And power users will still want to tube things more. But it might help to alleviate our undeserved reputation for poor performance if we provide some help to start off at least in the right ballpark. thoughts? cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Thomas Hallgren [EMAIL PROTECTED] writes: GCJ is a clean house implementation of Java. They don't use the runtime libraries from Sun and they are not really there yet in their efforts to copy the functionality. One of the things that lag behind is security. They hope to have a better security implementation before the year end but there's no promise. OK, so that is a transient limitation of the GCJ work, not something fundamental. Thanks for clarifying. In that case I agree that trying to restrict it mechanically isn't a good idea --- the code restriction would still be around after the problem was gone. I still think this is irrelevant to the PL template discussion, however, since neither our past approach nor either of the proposals will make it the least bit difficult for a user to mislabel pljava as TRUSTED when the underlying implementation isn't really trustworthy. (What the PL template approach *would* do is make it difficult to create a language that is trusted but named pljavau, or untrusted and named pljava. Personally I don't see that as a bad thing, however. The opportunity for confusion is far too great if you go against the established naming conventions.) regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Tom Lane wrote: Now this certainly discriminates against installing PLs outside $libdir, but I haven't heard any good reason why people would need to do that. Development, testing, staging, ... If I have PL/foo 1.0 installed and upgrade from PostgreSQL 8.0 to 8.1, the validator in PL/foo 1.0 will not magically appear or disappear. As a general rule, PLs have to at least be recompiled to move to a new release of the backend, and usually need some source code tweaking as well. You keep saying that, but the fact is that most of the non-core PLs will work just fine across several releases, if only because they have some #ifdef's. So, no, you do not need to upgrade your PLs when you upgrade PostgreSQL. You really don't. You just recompile them and put them back in the same place. There are certainly constraints and exceptions, but as a general rule it simply is not the case. If it were, I would not have started this discussion. Taking a step back and considering this validator business in a more general context: Basically, the validator is just a property that may or may not be applicable to a C function hidden inside a shared library. We don't know what's in the shared library, so we (currently) have to rely on the meta information in the dump to find out. This is a special case of a more general problem, which is why I mentioned PostGIS earlier. Any plug-in will evolve, and if it's just a bit sophisticated it will have fairly tight dependencies on the server version, which is certainly the case for much of the GIS and GiST stuff. So here we have the same problem. The old dump will have the meta-information on the old plug-in version. Under your theory, which is surely true in certain cases, the user will have to upgrade the plug-in at the same time. So the restore of the dump will have the old, now wrong information. I don't suppose hard-coding the PostGIS schema and ignoring special cases of CREATE FUNCTION will be the answer. One might object that these cases -- procedural languages and PostGIS sort of things -- are different, but they are not. The chance that an upgrade of PostgreSQL will require a version upgrade of the plug-in is about the same. Certainly, the number of users of PostGIS and the various GiST modules (FTS et al.) is comparable to, if not higher than that of some of the PLs. So that means two things: 1. The problem is much worse. 2. The problem is really much less bad because external plug-ins, PL or not, are often coded to work with multple server versions. And they should be, because otherwise the work forced upon the development teams to synchronize and the users to figure all that out will grow more than linearly. In any case, not one of these arguments seems to me to favor the alternative of preloading definitions into pg_language: That is not the alternative I am proposing. Your template idea, hard-coded even, is just fine for core languages. For non-core languages I am proposing that we simply do nothing because the problem we are solving does not exist, or at least has a wildly different nature. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: In any case, not one of these arguments seems to me to favor the alternative of preloading definitions into pg_language: That is not the alternative I am proposing. Your template idea, hard-coded even, is just fine for core languages. For non-core languages I am proposing that we simply do nothing because the problem we are solving does not exist, or at least has a wildly different nature. Ah. We have been talking at cross-purposes then, because I thought you were arguing for putting exactly the same template information into a different place. Given that, I think we can just agree to disagree: whether a particular PL could benefit from a template entry is up to the author of that PL to decide. Depending on the extent of the changes needed for 8.1, it might or might not make sense to assume that a source code update is needed, and if there isn't then maybe adding a template is a bad idea. It does seem though that your arguments indicate a possible need for local adjustment of the template info ... which means the hard-wired approach is not good enough, and we have to take the next step of creating a system catalog. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Thomas Hallgren wrote: Well, yes. But use the word environment in singular please :-) To my knowledge the security is full-proof with all other VM's since they all use the standard runtime libraries. It's not quite as simple as that. There are a bunch of VMs and a bunch of libraries (and a bunch of compilers), and they can be combined in many permutations. Not all of them work with PL/Java at the moment, but we should not hardcode support for just one of them. The GCJ support is as experimental as the GCJ in itself and cannot be trusted in production. You should not say that too loud when someone from Red Hat is listening. :-) To my knowledge GCJ is Ready(tm) as of version 4.0. And it's being used. Distributions such as Fedora and Ubuntu will ship (or do ship?) with everything compiled using GCJ to the extent possible. And there are people, in particular at or near Red Hat, who have been specifically charged for several years now to make sure that every piece of Java code out there compiles with GCJ. Regarding the security issue: Word from Andrew Haley of Red Hat is that it has simply been too much work to implement security up to now. This should not affect the judgement of the quality of GCJ, it's simply a missing feature. Of course, I don't intend to undermine your judgement as the author about what you consider experimental or not, but you should expect that if you put your code out there, people will use it in whatever way they see fit, and in particular with whatever Java toolchain they see fit. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Tom Lane wrote: Are you seriously suggesting that it's a good idea for the single language name java to mean different things at different installations? I can't believe that that wouldn't lead to chaos. There is a standard for the SQL integration of a java language, and I don't see why there can't be multiple implementations of that same specification. It in fact appears that there are. Of course we would not want the programming interfaces to differ, but they don't have to. In any case, java has not been put forward as one of the template entries, and as long as we don't accept a template for it, we have not made the situation any worse. Hmm, Thomas Hallgren sent in a template using java as name and you answered OK, so we're already there if it's already committed. Yes, I am assuming that, and I challenge you to supply examples of PLs that won't require at least a recompile before there's any hope of their working on 8.1. There is no hope of that, but a mere recompilation does not change the validator or the schema or any other property that may be under consideration. The current code will force a *version* upgrade of all PLs with every PostgreSQL upgrade. I need to download new code and deal with it. That is currently not required. And considering the general breakage of PLs out there, I don't think it's acceptable to require it. What if the new PL/R also requires a new R? What if the new R requires a new GCC? We don't know that, we can't control that, we should not interfere in that. I'm not making this up; these problems are real (although not necessarily in PL/R). -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_config/share_dir
Andrew Dunstan wrote: Why would they need pkglibdir either? To determine what $libdir resolves to. I was asked about this by an author who wanted to use it to find where to put module config/setup scripts. Probably not in PostgreSQL's data directory, but his own. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] Attention PL authors: want to be listed in template table?
Tom Lane wrote: (What the PL template approach *would* do is make it difficult to create a language that is trusted but named pljavau, or untrusted and named pljava. But the latter is exactly what I would like to do. Personally I don't see that as a bad thing, however. The opportunity for confusion is far too great if you go against the established naming conventions.) Extensibility means you don't control the naming. I guess if you want to say that this whole idea of extensibility in the language handler area is hereby withdrawn, doesn't work, never existed, then let's make that clear. Then we can hardcode everything, tell people, if you want to write a language handler, you should talk to us so we can arrange the hooks. That is the direction we're headed in. The PostgreSQL developers and the language handler authors dictate to the user what language he can use in what mode. If you don't like it, here's a way to do manual surgery to change it. Of course you can always change everything with varying effort. So yeah, that would work, but then it should be called that. But sacrificing user options to reduce confusion is hardly our game. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] pg_config/share_dir
On Wednesday 07 September 2005 15:52, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Andrew Dunstan wrote:
pg_config doesn't currently seem to have an option to report the
share_dir. Should it?
Is there a case where a user would need anything from there?
the way wo do this in slony is with the following macro:
AC_MSG_CHECKING(for postgresql.conf.sample)
PGSHARE_POSSIBLE_LOCATIONS=${with_pgsharedir} /usr/local/pgsql/share
/usr/local/share/postgresql /usr/share/postgresql /usr/local/share/pgsql
/usr/share/pgsql /opt/local/pgsql/share /opt/pgsql/share
${PG_BINDIR}/../share
for i in $PGSHARE_POSSIBLE_LOCATIONS; do
if test -s $i/postgresql.conf.sample ; then
PG_SHAREDIR=$i/
break;
fi
done
if test -n $PG_SHAREDIR ; then
AC_MSG_RESULT(${PG_SHAREDIR}postgresql.conf.sample)
AC_DEFINE(PG_SHAREDIR_VERIFIED,1,[PostgreSQL sharedir])
else
AC_MSG_RESULT(not found)
AC_MSG_ERROR(
postgresql.conf.sample not found! Please specify the sharedir
with --with-pgsharedir=dir
)
fi
(where ${PG_BINDIR} is the result of: pg_config --bindir )
Why would they need pkglibdir either? I was asked about this by an
author who wanted to use it to find where to put module config/setup
scripts.
cheers
andrew
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
--
Darcy Buskermolen
Wavefire Technologies Corp.
http://www.wavefire.com
ph: 250.717.0200
fx: 250.763.1759
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] initdb profiles
Andrew Dunstan wrote: But I wondered if it might not be a good idea to allow an option to initdb which would provide a greater possible range of settings for max_connections, shared_buffers and so on. For example, we might offer a profile which is very conservative for memory bound That reminds me of an identical proposal that was rejected years ago... machines, medium size for a development platform, large for a server running with other server processes, and huge for a decdicated box, and then provide some heuristics that initdb could apply. We'd have And before long we'll have 750 profiles... to let all of these degrade nicely, so that even if the user select the machine hog setting, if we find we can only do something like the tiny setting that's what s/he would get. Also, we might need to have And degrading nicely was a feature that we removed a long time ago. Now you get what you ask for. some tolerably portable way of finding out about machine resources. And that doesn't exist. And power users will still want to tube things more. But it might help to alleviate our undeserved reputation for poor performance if we provide some help to start off at least in the right ballpark. And mind reading devices are not yet available. So it's doesn't look all that good. All jokes aside, tuning aids are surely needed, but letting initdb guess the required profile isn't going to do it. -- 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] Attention PL authors: want to be listed in template table?
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: In any case, java has not been put forward as one of the template entries, and as long as we don't accept a template for it, we have not made the situation any worse. Hmm, Thomas Hallgren sent in a template using java as name and you answered OK, so we're already there if it's already committed. Oh, I hadn't noticed. That seems like rather a bad idea --- shouldn't it be pljava? (javaU isn't going to work either, because of case_translate_language_name.) Yes, I am assuming that, and I challenge you to supply examples of PLs that won't require at least a recompile before there's any hope of their working on 8.1. There is no hope of that, but a mere recompilation does not change the validator or the schema or any other property that may be under consideration. The current code will force a *version* upgrade of all PLs with every PostgreSQL upgrade. I need to download new code and deal with it. That is currently not required. Really? See the oidvector changes. I think that will force at least minor source changes on every PL. Now there may be people out there who will prefer making a few small changes by hand to downloading a new version ... but they can probably manage throwing in a stub validator function too. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_config/share_dir
Peter Eisentraut [EMAIL PROTECTED] writes: Andrew Dunstan wrote: pg_config doesn't currently seem to have an option to report the share_dir. Should it? Is there a case where a user would need anything from there? pg_config serves a function of recording the configuration, so I tend to agree with Andrew that this should be available. I notice that SYSCONFDIR, PKGINCLUDEDIR, and LOCALEDIR aren't available either. 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] pg_config/share_dir
Tom Lane wrote: pg_config serves a function of recording the configuration, pg_config was meant (as opposed to serves) to provide information that is of use for building third-party things. Hence includedir, libdir for building, pkglibdir for installing. The option --configure records the configuration, if you like, but I don't see the point of giving users direct access to directories that they have no use for. I mean, what would anyone want to do with pg_config --localedir? Certainly not store the locale files of his own module there. There is a point to be made that sysconfdir should be exposed, perhaps for the benefit of GUI configuration editors, but that seems theoretical to me. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] initdb profiles
Peter Eisentraut [EMAIL PROTECTED] writes: All jokes aside, tuning aids are surely needed, but letting initdb guess the required profile isn't going to do it. initdb is really the wrong place for this anyway, because in many situations (RPM installations for instance) initdb is run behind the scenes with no opportunity for user interaction. We should be doing our best to remove options from initdb, not add them. I think Andrew has a good point that we need to work more on making configuration tuning easier ... but initdb isn't the place. regards, tom lane ---(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] pg_config/share_dir
Darcy Buskermolen wrote:
On Wednesday 07 September 2005 15:52, Andrew Dunstan wrote:
Peter Eisentraut wrote:
Andrew Dunstan wrote:
pg_config doesn't currently seem to have an option to report the
share_dir. Should it?
Is there a case where a user would need anything from there?
the way wo do this in slony is with the following macro:
AC_MSG_CHECKING(for postgresql.conf.sample)
PGSHARE_POSSIBLE_LOCATIONS=${with_pgsharedir} /usr/local/pgsql/share /usr/local/share/postgresql /usr/share/postgresql /usr/local/share/pgsql /usr/share/pgsql /opt/local/pgsql/share /opt/pgsql/share
${PG_BINDIR}/../share
for i in $PGSHARE_POSSIBLE_LOCATIONS; do
if test -s $i/postgresql.conf.sample ; then
PG_SHAREDIR=$i/
break;
fi
done
if test -n $PG_SHAREDIR ; then
AC_MSG_RESULT(${PG_SHAREDIR}postgresql.conf.sample)
AC_DEFINE(PG_SHAREDIR_VERIFIED,1,[PostgreSQL sharedir])
else
AC_MSG_RESULT(not found)
AC_MSG_ERROR(
postgresql.conf.sample not found! Please specify the sharedir
with --with-pgsharedir=dir
)
fi
(where ${PG_BINDIR} is the result of: pg_config --bindir )
That's foul, and looks horribly fragile too. You have just provided what
seems to me a perfect use case.
cheers
andrew
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[HACKERS] PQ versions request message
I have been writing a PQ client and I have come to think that a supported PQ versions request startup packet would be useful to client authors. That is, sending a StartupPacket(Version(0, 0))(or whatever) would return a message containing a list of supported PQ versions, and maybe the server version as well. Having the said feature would allow client authors to select the connection code based on the versions returned, rather than using a trial and error process. It also gives the client the ability to quickly error out and notify the user that it cannot connect to the server if the client doesn't support any of the server versions. I find the trial and error process unseemly as it could require code to be loaded that simply does not need to be loaded--of course, making assumptions about the client design(this would likely be the case for my client). In addition, the trial and error process could be time consuming depending on how the connection to the server is established, thus further decreasing the appeal of the trial and error process(hrm, this may not be a useful criticism of te if pg keeps the pipe open until the client sends a suitable startup packet?). Although, I do see that the trial and error process would only need to happen once(per process, I figure) if the client author cached the code selection information about a given server. Thoughts? Has this been proposed/shot down before? -- Regards, James William Pye ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Tom Lane [EMAIL PROTECTED] writes: Now this certainly discriminates against installing PLs outside $libdir, but I haven't heard any good reason why people would need to do that. Well one example would be distributions that package up some PLs but want to allow you to install some on your own. The normal model for that is to have a directory in /usr/lib/program/ for the packaged software and a separate place in /usr/local/lib/program/ for the locally installed add-ons. I'm not sure how that relates to the template work you're discussing. Are all of the templates you're creating for components that are built out of core and therefore can be expected to be packaged? -- greg ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] initdb profiles
Andrew Dunstan wrote: The idea was in fact to allow the user to provide additional information to allow initdb to make better guesses than it currently does. There's certainly going to be opposition to making initdb an interactive tool. The other problem is that no one has ever managed to show that it is possible to derive reasonable settings from a finite set of questions presented to the user, plus perhaps from a reasonably portable system analysis. If you can do that, that would be a cool tool in its own right. And then you could call that from initdb or not depending on taste. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PQ versions request message
James William Pye [EMAIL PROTECTED] writes: I have been writing a PQ client and I have come to think that a supported PQ versions request startup packet would be useful to client authors. Given that it'd be guaranteed not to work with any existing server versions, I find the usefulness a bit debatable... In particular I disagree with the premise that clients should expend an extra connection setup/teardown cycle to find out which protocol versions the server supports. We change protocol versions seldom enough that I think the optimal strategy is try the newest version you know of, then back off one at a time until it works. This is always optimal if the server is newer than the client, and it's only pessimal if the server is much older than the client --- how often does that happen? To put it more concretely: there are currently only two protocol versions in live use (V1 died a long time ago). If you try V3 and then V2, you will expend either one or two connection cycles, with the average converging towards one as time passes and more people update their servers. If you probe for the right answer and then do it, you will always expend two connection cycles. That is a win how exactly? regards, tom lane ---(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] PQ versions request message
James William Pye wrote: I have been writing a PQ client and I have come to think that a supported PQ versions request startup packet would be useful to client authors. That is, sending a StartupPacket(Version(0, 0))(or whatever) would return a message containing a list of supported PQ versions, This doesn't make sense to me, because a server does not have any version requirements on the client (aside from the protocol versions, which are negotiated automatically). and maybe the server version as well. That is already available automatically. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] initdb profiles
What I would like to see is that initdb would end with saying that the system is not really tuned and that I should run pg-some-program to improve that. pg-some-program would analyze my system, ask me a few questions, and then output a suggested configuration (or apply it right away). Again, the challenge is to write that program. Perhaps at the end of initdb it would say would you like to run the PostgreSQL configuration program? Which would be a wizard that would ask 10 or so questions and automatically configure us based on those questions? -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(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] initdb profiles
Joshua D. Drake [EMAIL PROTECTED] writes: What I would like to see is that initdb would end with saying that the system is not really tuned and that I should run pg-some-program to improve that. Perhaps at the end of initdb it would say would you like to run the PostgreSQL configuration program? You're both assuming that the output of initdb goes someplace other than /dev/null ... I do agree with trying to create a configuration wizard program, but I think having initdb advertise it will be of only marginal use. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Attention PL authors: want to be listed in template table?
Greg Stark [EMAIL PROTECTED] writes: I'm not sure how that relates to the template work you're discussing. Are all of the templates you're creating for components that are built out of core and therefore can be expected to be packaged? Well, that's exactly the point Peter is arguing: he thinks (if I understand correctly) that the template mechanism should only be used for stuff that's included with the core distribution. I disagree; I have seldom seen any good reason for restricting mechanisms to work with only core components. It does seem apparent however that we need the templates to be reconfigurable for local conditions ... so the hardwired table is out, even as a one-release stopgap. I'll work on building a catalog tomorrow. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] initdb profiles
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: I accept the run from init.d argument. So then, is there a case for increasing the limits that initdb works with, to reflect the steep rise we have seen in typically available memory at the low end? I can't see any particular harm in having initdb try somewhat-larger values ... but how far does that really go towards fixing the issues? Personally, the default value I currently see as far too tight is max_fsm_pages. I'd rather see initdb trying to push that up if it's able to establish shared_buffers and max_connections at their current maxima. Ok. how would the logic go? Just have a function that runs max_fsm_pages checks after we call test_connections() and test_buffers(), or should there be some interplay between those settings? As I understand it, the current setting would consume all of 120,000 bytes of shared memory, so there could well be lots of head room. ... it would be nice to try to allow one connection per standard allowed apache client (default is 256 non-threaded and 400 threaded, I think). That's a mostly independent consideration, but it seems fair enough. Can we check the exact values rather than relying on I think? That's my reading of http://httpd.apache.org/docs/2.0/mod/mpm_common.html#maxclients ---(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] pg_config/share_dir
Why do you need access to postgresql.conf.sample? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] initdb profiles
Peter Eisentraut [EMAIL PROTECTED] writes: There is a compromise that I think we cannot make. For production deployment, shared buffers are typically sized at about 10% to 25% of available phyiscal memory. I don't think we want to have a default installation of PostgreSQL that takes 10% or more of memory just like that. It just doesn't look good. The fundamental issue there is box dedicated to (one instance of) Postgres versus box serves multiple uses. If you don't know what fraction of the machine resources you're supposed to take up, it's difficult to be very smart. I think that we have to default to a socially friendly don't eat the whole box position ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PQ versions request message
On Thu, 2005-09-08 at 03:48 +0200, Peter Eisentraut wrote: This doesn't make sense to me, because a server does not have any version requirements on the client (aside from the protocol versions, which are negotiated automatically). The use case primarily applies to custom clients(non-libpq, atm) that support multiple PQ versions that may be implemented in separate modules/libraries. (Avoid loading client-2.0 code for a 3.0 connection, and/or future versions.) libpq automatically negotiates the version using trial and error, effectively(assume 3.0 by sending 'S', if 'E', fallback to 2.0, and reestablish the connection, apparently). and maybe the server version as well. That is already available automatically. Yes, but, AFAIK, only after the protocol has been negotiated and authentication is complete. Really, I'm not sure if such a feature should include the server version as selecting feature implementations based on it is probably a bad idea(TM). -- Regards, James William Pye ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] initdb profiles
Peter Eisentraut wrote: Andrew Dunstan wrote: I accept the run from init.d argument. So then, is there a case for increasing the limits that initdb works with, to reflect the steep rise we have seen in typically available memory at the low end? There is a compromise that I think we cannot make. For production deployment, shared buffers are typically sized at about 10% to 25% of available phyiscal memory. I don't think we want to have a default installation of PostgreSQL that takes 10% or more of memory just like that. It just doesn't look good. I have a single instance of apache running on this machine. It's not doing anything, but even so it's consuming 20% of physical memory. By contrast, my 3 postmasters are each consuming 0.5% of memory. All with default settings. I don't think we are in any danger of looking bad for being greedy. If anything we are in far greater danger of looking bad from being far too conservative and paying a performance price for that. There's nothing magical about the numbers we use. So the question whether initdb should by default consider up to 1000 or up to 4000 buffers is still worth discussion, but doesn't solve the tuning issue to a reasonable degree. True, but that doesn't mean it's not worth doing anyway. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Update timezone data files to release 2005m of the zic database
Michael Fuhr [EMAIL PROTECTED] writes: On Wed, Sep 07, 2005 at 18:39:26 -0300 (ADT), Tom Lane wrote: Update timezone data files to release 2005m of the zic database. Among other changes, this reflects the recently passed change in USA daylight savings rules. Looks like some horology tests need to be updated as well. Example: Ooops, didn't occur to me to check the regression tests :-( The comments added in the zic database point out that Congress reserved the right to undo this change if the administration couldn't prove a sufficient energy savings. Ignoring the point that all the transition costs would have to be paid over again to undo the law change (commentary suppressed by sheer force of will), should we consider modifying the regression tests to be unaffected, rather than just updating the expected outputs? The original test author certainly wasn't expecting dates in March to be affected by DST. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PQ versions request message
James William Pye wrote: The use case primarily applies to custom clients(non-libpq, atm) that support multiple PQ versions that may be implemented in separate modules/libraries. (Avoid loading client-2.0 code for a 3.0 connection, and/or future versions.) libpq automatically negotiates the version using trial and error, effectively(assume 3.0 by sending 'S', if 'E', fallback to 2.0, and reestablish the connection, apparently). The JDBC driver does exactly the same (or you can explicitly specify a protocol version to use) and is effectively loading code on demand anyway, being Java -- but I've seen no problems with the current approach. I think you're trying tho fix a problem that doesn't exist. -O ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] initdb profiles
heuristics that initdb could apply. We'd have to let all of these degrade nicely, so that even if the user select the machine hog setting, if we find we can only do something like the tiny setting that's what s/he would get. Also, we might need to have some tolerably portable way of finding out about machine resources. And power users will still want to tube things more. But it might help to alleviate our undeserved reputation for poor performance if we provide some help to start off at least in the right ballpark. I think we should just do what MySQL does and include: postgresql.conf postgresql-large.conf postgresql-huge.conf Chris ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PQ versions request message
On Wed, 2005-09-07 at 22:02 -0400, Tom Lane wrote: Given that it'd be guaranteed not to work with any existing server versions, I find the usefulness a bit debatable... Indeed =(. However, older servers could be easily detected then if the returned message type is 'E'. If 'E' is returned, it would likely be on a pre 8.x server running 2.0 and/or 3.0. Thus signalling the client connection code to fall back on old-style version detection, if need be. Alas, this would, of course, require yet another connection expenditure for any so called pre-version list supporting servers. In particular I disagree with the premise that clients should expend an extra connection setup/teardown cycle to find out which protocol versions the server supports. We change protocol versions seldom enough that I think the optimal strategy is try the newest version you know of, then back off one at a time until it works. This is always optimal if the server is newer than the client, and it's only pessimal if the server is much older than the client --- how often does that happen? [Assuming you're not referring to connection attempts to the pre-version list supporting servers] Why does it have to be torn down? I imagine that it could easily be an extra, optional part of connection negotiation. Wait for startup packet, If Version(0,0), Send PQ version list, wait for real startup packet, Else take it as the real startup packet, or ssl neg message, or etc. If I implied that it should be torn down entirely, it was probably due to how I was planning to manage the initial connection that I establish to a server to validate that a connection can actually be made and resolve any/some server specific issues(int timestamps, etc). Although, this is all specific to the implementation that I'm brewing. (not sure about all the specifics yet, as I've just been toying with the idea) To put it more concretely: there are currently only two protocol versions in live use (V1 died a long time ago). If you try V3 and then V2, you will expend either one or two connection cycles, with the average converging towards one as time passes and more people update their servers. If you probe for the right answer and then do it, you will always expend two connection cycles. That is a win how exactly? Like I asked above, why does it have to be done in two connection cycles? I'm assume by connection cycle you are referring to reopening the socket, or...? -- Regards, James William Pye ---(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
