R: [HACKERS] Rendezvous/Bonjour broken in 8.1 beta
Hi, wouldn't it be better to implement rendezvous with a free/open/cross-platform implementation like Howl (http://www.porchdogsoft.com/products/howl/) which should help avoiding apple's tricks? Best regards paolo -Messaggio originale- Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] conto di Tom Lane Inviato: venerdì 9 settembre 2005 2.22 A: Joshua D. Drake Cc: Andrew Dunstan; [EMAIL PROTECTED]; pgsql-hackers@postgresql.org Oggetto: Re: [HACKERS] Rendezvous/Bonjour broken in 8.1 beta Joshua D. Drake [EMAIL PROTECTED] writes: Lets at least document the fact that it is borked on everything but apple borked on windows is not necessarily the same thing as borked on everything but apple. BTW, wasn't it you that sent in that old note that said it did work on windows? What did you test exactly? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster ---(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
On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote: Andrew - Supernews wrote: On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote: Andrew - Supernews wrote: Running initdb behind the scenes is a proven dangerous practice Please elaborate. Example instance: http://archives.postgresql.org/pgsql-hackers/2004-12/msg00851.php If you run your database on NFS, your warranty is void. NFS has nothing to do with it. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] initdb profiles
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew - Supernews Sent: 09 September 2005 08:16 To: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] initdb profiles On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote: Andrew - Supernews wrote: On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote: Andrew - Supernews wrote: Running initdb behind the scenes is a proven dangerous practice Please elaborate. Example instance: http://archives.postgresql.org/pgsql-hackers/2004-12/msg00851.php If you run your database on NFS, your warranty is void. NFS has nothing to do with it. Well, it sorta did in that case, but I see where you're coming from. What does have something to do with it is that iirc it was the rc.pgsql script that ran initdb in the background at boot time when it didn't find the data directory, so perhaps your statement would be more accurate as: Automatically running initdb behind the scenes at system startup is a proven dangerous practice We've distributed hundreds of thousands of copies of pgInstaller which initdb's behind the scenes and never had any reported problems. Regards, Dave ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] statement logging / extended query protocol issues
On Thu, 2005-09-08 at 13:14 +1200, Oliver Jowett wrote: Simon Riggs wrote: Oliver, would it be possible to show a simplified call sequence and what you would like to see logged for each call? These are good: Maybe it should even be in the docs for the driver? It would be good if it could be written as a test within the driver, so we can expand it and test the logging. The JDBC driver generates one of these sequences: (1) Parse (unnamed statement) SELECT 1 Bind (unnamed statement - unnamed portal) Execute (unnamed portal, no row limit) (2) Parse (named statement S_1) SELECT 1 repeatedly: Bind (named statement S_1 - unnamed portal) Execute (unnamed portal, no row limit) (3) Parse (named statement S_2) SELECT 1 repeatedly: Bind (named statement S_2 - named portal C_2) repeatedly: Execute (named portal C_2, row limit 42) Are we sure there is just 3 cases? Ideal output is: (1) LOG: statement: SELECT 1 (2) LOG: statement: SELECT 1 LOG: statement: SELECT 1 LOG: statement: SELECT 1 (3) LOG: statement: SELECT 1 LOG: statement: SELECT 1 LOG: statement: SELECT 1 In case (3), that's one log line per repeat of the outer loop, regardless of how many Executes are sent in the inner loop. Note that case (1) is the most common case for application queries via the JDBC driver, and case (2) is the most common for internally generated statements like BEGIN. Even if case (3) is not that common, I still want to know it is occurring, to see what effect or overhead it has. As you can see from the output I'd like, I don't think that synthesizing FETCH / EXECUTE queries that don't actually exist [is a] useful thing to do, at least at the Joe Average User level. Your original point at the top of this thread was valid: a get-next-rows shouldn't look like a re-execute. We can call it something else if you like, as long as we can tell the difference. We'll only see the output for case (3) when someone has programmed things that way by using setFetchSize. Also note that the JDBC driver doesn't exercise all of the extended protocol -- for example it's possible to re-Bind the same unnamed statement repeatedly, or have multiple Executes on an unnamed portal with a row limit, but the JDBC driver never does that. I agree there's not much gained from displaying the BIND statement as it is. I argued previously against including the BIND parameters. Now I would say we should either include them or leave out BIND altogether. Here's a new suggestion and patch that brings together - Oliver and Simon's wish to remove BIND from normal logging - Oliver's suggestion to remove the PREPARE logging for unnamed statements, which would otherwise double-up logging for case(1) - Bruce and Simon's view to keep some form of FETCH logging - Tom's view to rationalise the way ROWS is mentioned (lines beginning jdbc don't show in the log, but are just there to show clearly the time sequence of activities and what gets subsequently logged) (1) Parse (unnamed statement) SELECT * from pg_proc Bind (unnamed statement - unnamed portal) Execute (unnamed portal, no row limit) (1) jdbc parse jdbc bind jdbc execute LOG: statement: SELECT * from pg_proc jdbc parse jdbc bind jdbc execute LOG: statement: SELECT * from pg_proc jdbc parse jdbc bind jdbc execute LOG: statement: SELECT * from pg_proc Notice that the parse of the unnamed statement does *not* now generate a log record. (2) Parse (named statement S_1) SELECT * from pg_proc repeatedly: Bind (named statement S_1 - unnamed portal) Execute (unnamed portal, no row limit) (2) jdbc parse S_1 LOG: statement: PREPARE S_1 AS SELECT * from pg_proc (perhaps this should be logged at BIND time, just like the optimization?) jdbc bind S_1 jdbc execute LOG: statement: EXECUTE unnamed [PREPARE: SELECT * from pg_proc] jdbc bind S_1 jdbc execute LOG: statement: EXECUTE unnamed [PREPARE: SELECT * from pg_proc] jdbc bind S_1 jdbc execute LOG: statement: EXECUTE unnamed [PREPARE: SELECT * from pg_proc] ...I wonder if unnamed just confuses what is going on here? I've left it in for now, but suggest that we take that out again? (3) Parse (named statement S_2) SELECT * from pg_proc repeatedly: Bind (named statement S_2 - named portal C_2) repeatedly: Execute (named portal C_2, row limit 42) (3) jdbc prepare S_2 LOG: statement: PREPARE S_2 AS SELECT * from pg_proc jdbc bind S_2 to C_2 jdbc execute C_2 LOG: statement: EXECUTE C_2 ROWS 42 [PREPARE: SELECT * from pg_proc] jdbc next (after cache has run out on 42nd row) v3 protocol sends E for Execute, execution halts at 49 rows for this set of bind parameters LOG: statement: FETCH C_2 ROWS 7 jdbc bind S_2 to C_2 jdbc execute C_2 LOG: statement: EXECUTE C_2 ROWS 42 [PREPARE: SELECT * from pg_proc] jdbc next (after cache has run out on 42nd row) v3 protocol sends E for Execute LOG:
[HACKERS] Case insensitive indexing in posgtres?
Dear , One of the difference in mysql and postgresql is case insensitiveness. I want to midify the code of posgresql so that it can support case insensitiveness in indexing and in join operation. I dont want that user should always write lower and uppder during using it. I just need information that where exactly in the code of postgres it compare the values of attribute supplied by user and values of attribute present in the database. Thanking you, sandeep -- -- | Sandeep Satpal | | M.Tech Student | | Lab 212 KReSIT | -- ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Case insensitive indexing in posgtres?
On Fri, Sep 09, 2005 at 04:00:57PM +0530, sandeep satpal wrote: Dear , One of the difference in mysql and postgresql is case insensitiveness. I want to midify the code of posgresql so that it can support case insensitiveness in indexing and in join operation. Use citext: http://gborg.postgresql.org/project/citext/projdisplay.php -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. pgpEddh7fOSvK.pgp Description: PGP signature
Re: [HACKERS] Alternative variable length structure
On Thu, 08 Sep 2005 18:02:44 +0900, ITAGAKI Takahiro [EMAIL PROTECTED] wrote: + * The length of varlena2 is encoded as follows: + * + * | First| Trailing | Total | Max | + * | byte | bytes| bits | length | + * +--+--+---+-+ + * | 0*** |0 | 7 | 127 | + * | 10** |1 |14 | 16K -1 | + * | 110* |2 |21 | 2M -1 | + * | 1110 |3 |28 | 256M -1 | + * | |4 |32 | 4G -1 | With external and compression flags this would look like * | ec0* |0 | 5 | 31 | * | ec10 |1 |12 | 4K -1 | * | ec110*** |2 |19 | 512K -1 | * | ec1110** |3 |26 | 64M -1 | * | ec-- |4 |32 | 4G -1 | Only a matter of taste, but I'd just waste one byte for sizes between 4K and 512K and thus get a shorter table: * | ec0* |0 | 5 | 31 | * | ec10 |1 |12 | 4K -1 | * | ec110*** |3 |27 | 128M -1 | * | ec111--- |4 |32 | 4G -1 | And you get back that one byte for sizes between 64M and 128M :-) Another possible tweak: * | 0*** |0 | 5 | 127 | * | 1ec0 |1 |12 | 4K -1 | * | 1ec10*** |3 |27 | 128M -1 | * | 1ec11--- |4 |32 | 4G -1 | I.e. drop the flags for very short strings. If these flags are needed for a string of size 32 to 127, then use a two byte header. Servus Manfred ---(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
[HACKERS] statement_timeout logging
Currently, when we set a statement_timeout and a query runs over that
time there is no log message to say that the statement has timed out. We
do get a message which says
ERROR: canceling query due to user request
and so in the server log it is impossible to tell the difference between
a query that has been cancelled deliberately by the user and a query
whose time(out) has come.
The timeout causes the query to be cancelled, which is an ERROR, so it
is possible that the query will be logged if log_min_error_statement is
set to ERROR or below. Again, there is no way to tell the difference
between an ERROR statement that has occurred during execution and an
ERROR statement that is generated by a syntax error. So, if you do set
log_min_error_statement=ERROR then you get swamped by syntax errors
rather than being able to see statement timeouts.
Logging these queries ought to be a valuable source of tuning
information, but as a result of the above, this is not currently the
case.
For now, I've written a quick patch to the log the query text with a
suitable error message.
I expect some debate as to whether the line
if (log_min_error_statement WARNING)
should be there at all, so comments are sought.
---
Longer term, we might handle this differently. If we differentiate
between two types of ERROR, at least for log_min_error_statement...
- one that prevents the query from ever running (syntax, parse errors)
- one that occurs because the query itself gets into difficulty, but not
so badly that it constitutes a FATAL error. Lets call it RUNERROR for
now.
I expect most people to want to log RUNERRORs, but to want to ignore the
more normal kind of ERRORs.
When/if we can differentiate between levels, I'll reverse out this patch
since we'll be able to handle it simply with the new errorlevel.
Best Regards, Simon Riggs
Index: src/backend/storage/lmgr/proc.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/storage/lmgr/proc.c,v
retrieving revision 1.163
diff -c -c -r1.163 proc.c
*** src/backend/storage/lmgr/proc.c 20 Aug 2005 23:26:24 - 1.163
--- src/backend/storage/lmgr/proc.c 9 Sep 2005 11:28:39 -
***
*** 51,57
#include storage/proc.h
#include storage/procarray.h
#include storage/spin.h
!
/* GUC variables */
int DeadlockTimeout = 1000;
--- 51,58
#include storage/proc.h
#include storage/procarray.h
#include storage/spin.h
! #include tcop/tcopprot.h
! #include utils/elog.h
/* GUC variables */
int DeadlockTimeout = 1000;
***
*** 1179,1184
--- 1180,1196
{
/* Time to die */
statement_timeout_active = false;
+
+ /*
+ * Log the statement that has timed out, unless we already have
+ * log_min_error_statement set low enough that we will log the
+ * query as part of the handling for the kill()
+ */
+ if (log_min_error_statement WARNING)
+ ereport(LOG,
+ (errmsg(timeout cancels statement: %s,
+ debug_query_string ? debug_query_string : )));
+
kill(MyProcPid, SIGINT);
}
else
---(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: R: [HACKERS] Rendezvous/Bonjour broken in 8.1 beta
Paolo Magnoli [EMAIL PROTECTED] writes: Hi, wouldn't it be better to implement rendezvous with a free/open/cross-platform implementation like Howl (http://www.porchdogsoft.com/products/howl/) which should help avoiding apple's tricks? Why bother? AFAIK, no one cares at all about bonjour unless they are running OS X --- and if they are on OS X, switching to howl would just mean there's an additional bit of software they have to get. If this were central to Postgres' purpose, we might feel like doing extra work on it; but it's so peripheral that we've already wasted more time on it than it's worth. IMHO anyway. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Alternative variable length structure
Manfred Koizar [EMAIL PROTECTED] writes: I.e. drop the flags for very short strings. I don't think the interaction of this idea with TOAST has been thought through very carefully. Some points to consider: * If the 'e' (external) bit is set, the actual length is 20 or so bytes. Always. There is no need for an 'e' bit in the variants that store a longer length. * I agree with Manfred that you could blow off the case of compressing strings shorter than 128 bytes, so you really only need the 'c' bit for the longer variants. Hence, just one flag bit is needed in all cases. * The proposal to reduce the alignment to char breaks TOAST pointers, which contain fields that need to be word-aligned (at least on machines that are picky about alignment). Maybe we could just live with that, by copying the in-datum data to and from properly aligned local storage in the routines that need to access the pointer fields. It's an extra cost though, as well as a probable source of bugs that will only be noticed on non-Intel hardware. * In the 'c' case you need to store *two* lengths, the physical length and the decompressed length. Is it worth playing the same kind of game with the decompressed length? Again, you can't just do nothing because the proposal breaks word-alignment of the decompressed length. Another thing that's bothering me about this is that it'll lead to weird new coding rules that will certainly break a lot of code; notably you can't access VARDATA(x) until you've assigned the correct value to VARSIZE(x). This will be a particular pain in the neck for code that likes to fill in the data before it makes a final determination of the result size. So I'm feeling a good deal of sales resistance to the idea that this ought to replace our existing varlena representation. At least for internal use. Maybe the right way to think about this is that a compressed length word is a form of TOASTing, which we apply during toast compression and undo during PG_DETOAST_DATUM. If we did that, the changes would be vastly more localized than if we try to make all the datatype manipulation routines cope. Not sure about the speed tradeoffs involved, though. 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] [PATCHES] Work-in-progress referential action trigger
On Fri, 2 Sep 2005, Stephan Szabo wrote: [Hackers now seems more appropriate] On Thu, 1 Sep 2005, Stephan Szabo wrote: On Tue, 23 Aug 2005, Stephan Szabo wrote: Here's my current work in progress for 8.1 devel related to fixing the timing issues with referential actions having their checks run on intermediate states. I've only put in a simple test that failed against 8.0 in the regression patch and regression still passes for me. There's still an outstanding question of whether looping gives the correct result in the presence of explicit inserts and set constraints immediate in before triggers. As Darcy noticed, the patch as given does definately still have problems with before triggers. I was able to construct a case that violates the constraint with an update in a before delete trigger. I think this might be why the spec has the wierd timing rules for before triggers on cascaded deletes such that the deletions happen before the before triggers. We have a similar problem for before triggers that update the rows that are being cascade updated. The following seems to violate the constraint for me on 8.0.3: drop table pk cascade; drop table fk cascade; drop function fk_move(); create table pk(a int primary key); create table fk(a int references pk on delete cascade on update cascade, b int); create function fk_move() returns trigger as ' begin raise notice '' about to move for % '', old.b; update fk set b=b-1 where b old.b; return new; end;' language 'plpgsql'; create trigger fkmovetrig before update on fk for each row execute procedure fk_move(); insert into pk values(1); insert into pk values(2); insert into fk values(1,1); insert into fk values(1,2); insert into fk values(2,3); select * from pk; select * from fk; update pk set a = 3 where a = 1; select * from pk; select * from fk; This gives me (3,1), (1,1) and (2,2) as the rows in fk where the (1,1) row is invalid. This is obviously wrong, but the question is, what is the correct answer? Should the update in the before trigger trying to change b on a row that no longer has a reference have errored? We can't do that for compatibility reasons, but it would allow us to say that modifying a row in a before trigger that is also a row selected in the outer statement is an error for this update case. It'd presumably be an error for a normal delete as well, although I think it might be relaxable for cascaded deletes because the spec seems to say that the before triggers for deletions caused by the cascade are actually run after the removals. I'm not sure whether we could easily differentiate this case from any other cases where the row was modified twice either yet. Is there a case other than a before trigger updating a row we will want to act upon later in the statement where we'll get a row with xmax of our transaction and cmax greater than the current command? ---(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] [PATCHES] Work-in-progress referential action trigger timing
Stephan Szabo [EMAIL PROTECTED] writes: Is there a case other than a before trigger updating a row we will want to act upon later in the statement where we'll get a row with xmax of our transaction and cmax greater than the current command? The greater-cmax case could occur via any kind of function, not only a trigger, ie update tab set x = foo(x) where ... where foo() is a volatile function that internally updates the tab table. I suppose you could say that this is horrible programming practice and anyone who tries it deserves whatever weird behavior ensues ... but it's not the case that every such situation involves a trigger. 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] [PATCHES] Work-in-progress referential action trigger
On Fri, 9 Sep 2005, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: Is there a case other than a before trigger updating a row we will want to act upon later in the statement where we'll get a row with xmax of our transaction and cmax greater than the current command? The greater-cmax case could occur via any kind of function, not only a trigger, ie update tab set x = foo(x) where ... where foo() is a volatile function that internally updates the tab table. I *thought* I was missing a case, I just couldn't figure out what. I suppose you could say that this is horrible programming practice and anyone who tries it deserves whatever weird behavior ensues ... but it's not the case that every such situation involves a trigger. Well, the change I was thinking of would have made it an error if foo(x) updated a row that was then later selected by the update rather than the current behavior which I think would have ignored the already updated row, so that's probably not going to work. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: R: [HACKERS] Rendezvous/Bonjour broken in 8.1 beta
Just to counter this statement- I am using postgresql mDNSReponder discovery on Linux. In my case, I have several satellite machines that need to send events to the database. Zeroconf makes the discovery trivial and I don't have to worry about network settings. I would like to see postgresql support this feature natively so that I could just add a line to postgresql.conf and have it work. I am currently using howl to do this- howl wraps the Apple libs in Darwin and hooks into the standard mDNSResponder on other OSs. Since obviously no one else is working on this, I can work on a patch. On Sep 9, 2005, at 8:46 AM, Tom Lane wrote: Paolo Magnoli [EMAIL PROTECTED] writes: Hi, wouldn't it be better to implement rendezvous with a free/open/cross-platform implementation like Howl (http://www.porchdogsoft.com/products/howl/) which should help avoiding apple's tricks? Why bother? AFAIK, no one cares at all about bonjour unless they are running OS X --- and if they are on OS X, switching to howl would just mean there's an additional bit of software they have to get. If this were central to Postgres' purpose, we might feel like doing extra work on it; but it's so peripheral that we've already wasted more time on it than it's worth. IMHO anyway. regards, tom lane |-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- AgentM [EMAIL PROTECTED] |-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|-|- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] initdb profiles
Dave Page wrote: perhaps your statement would be more accurate as: Automatically running initdb behind the scenes at system startup is a proven dangerous practice We've distributed hundreds of thousands of copies of pgInstaller which initdb's behind the scenes and never had any reported problems. And anyway you need to come up with a reasonable alternative for packagers, rather than just say don't do this.. The only one I can think of is to run initdb as part of a package postinstall, although packagers and especially distro preparers might find that more than something of a nuisance. cheers andrew ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] initdb profiles
On Thu, Sep 08, 2005 at 08:29:38PM -, Andrew - Supernews wrote: On 2005-09-08, Peter Eisentraut [EMAIL PROTECTED] wrote: Andrew - Supernews wrote: Running initdb behind the scenes is a proven dangerous practice Please elaborate. Example instance: http://archives.postgresql.org/pgsql-hackers/2004-12/msg00851.php More generally, you risk running initdb and doing a normal database startup despite missing filesystems (assuming your db is substantial and important enough that you don't keep in it /var or /usr). There are a number of ways that this can bite you, whether due to thinking that the database is up when it really isn't usable, or subsequently mounting over the new data dir, or any number of other potential issues. A missing data directory on startup should mean something is wrong, not oh look, I'll run initdb and start up anyway. I think we read entirely different things into behind the scenes. I have an installer script that's run to install a software package. It runs an initdb to create the database it uses behind the scenes. Running initdb as part of an installation process is a very different scenario to randomly running it whenever you think something may not be quite right (although that is the pattern used by many other daemon startup scripts on the OS in question, so it's at least consistent). Cheers, Steve ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL from source using MinGW
Andrew Dunstan wrote: 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 Agreed. Patch? :-) (You knew I was going to ask, right?) -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Build with Visual Studio MSVC
Just for fun, I went through PostgreSQL 8.1 and did a complete build using Microsofts C and the latest Visual Studio. With a few minor tweaks, everything compiled with no errors. My assumption is that because PostgreSQL is a UNIX/Linux-centric project (and gcc/gdb centric), this really isnt of much interest to anyone. So other than this e-mail, I dont plan to do anything with this except for my own amusement. If Im wrong, and there is some real interest in supporting MSVC, let me know, and Ill put some work into cleaning it up and making patches out of it, etc.
Re: [HACKERS] Build with Visual Studio MSVC
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Chuck McDevittSent: 09 September 2005 19:38To: [EMAIL PROTECTED]Cc: PostgreSQL-developmentSubject: [HACKERS] Build with Visual Studio MSVC Just for fun, I went through PostgreSQL 8.1 and did a complete build using Microsofts C and the latest Visual Studio. With a few minor tweaks, everything compiled with no errors. My assumption is that because PostgreSQL is a UNIX/Linux-centric project (and gcc/gdb centric), this really isnt of much interest to anyone. So other than this e-mail, I dont plan to do anything with this except for my own amusement. If Im wrong, and there is some real interest in supporting MSVC, let me know, and Ill put some work into cleaning it up and making patches out of it, etc. Hi Chuck, We discussed this again on list only the otherday in fact! Basically we're not particulalry interested in supporting VS prject files in place of gmake/autoconf, purely because they will undoubtedly cause maintenance headaches as the majority of our developers don't have Windows boxes, let alone a copy of Visual Studio. However, if you need something to keep yourself amused (unless I can persuade you to come help out with psqlODBC :-) ), we would be interested in patches that allow us to use Microsoft's compileras an alternative to gcc. It's interesting to know it built fairly easily though... Regards, Dave.
Re: [HACKERS] Build with Visual Studio MSVC
However, if you need something to keep yourself amused (unless I can persuade you to come help out with psqlODBC :-) ), we would be interested in patches that allow us to use Microsoft's compiler as an alternative to gcc. It's interesting to know it built fairly easily though... What would be of interest to me, would be to know if there is an actual gain to compiling with the Microsoft compiler. I understand the maintenance issues but if the Microsoft compiler gives us 25% better performance on Win32 then Mingw... Sincerely, Joshua D. Drake Regards, Dave. -- 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: [pgsql-hackers-win32] [HACKERS] Build with Visual Studio MSVC
Dave Page wrote: Just for fun, I went through PostgreSQL 8.1 and did a complete build using Microsoft’s C and the latest Visual Studio. With a few minor tweaks, everything compiled with no errors. My assumption is that because PostgreSQL is a UNIX/Linux-centric project (and gcc/gdb centric), this really isn’t of much interest to anyone. So other than this e-mail, I don’t plan to do anything with this except for my own amusement. If I’m wrong, and there is some real interest in supporting MSVC, let me know, and I’ll put some work into cleaning it up and making patches out of it, etc. Hi Chuck, We discussed this again on list only the other day in fact! Basically we're not particulalry interested in supporting VS prject files in place of gmake/autoconf, purely because they will undoubtedly cause maintenance headaches as the majority of our developers don't have Windows boxes, let alone a copy of Visual Studio. However, if you need something to keep yourself amused (unless I can persuade you to come help out with psqlODBC :-) ), we would be interested in patches that allow us to use Microsoft's compiler as an alternative to gcc. It's interesting to know it built fairly easily though... There is also a pgfoundry project for maintaining Visual Studio project files. see http://pgfoundry.org/projects/vcproject/ cheers andrew ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL from source using MinGW
Bruce Momjian wrote: Andrew Dunstan wrote: 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 Agreed. Patch? :-) (You knew I was going to ask, right?) I will put something together. While we're on the subject, is this still true?: The most recent version of this document can be viewed at [2]http://momjian.postgresql.org/main/writings/pgsql/project/win32.html. Or is the authoritative source the HTML file in CVS? And if I patch that file do I also patch the derived text file? cheers andrew ---(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] initdb profiles
On Thu, Sep 08, 2005 at 03:43:17AM +0200, Peter Eisentraut wrote: 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. FYI, http://pgfoundry.org/projects/configurator/ -- 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 6: explain analyze is your friend
Re: [HACKERS] initdb profiles
Jim C. Nasby wrote: On Thu, Sep 08, 2005 at 03:43:17AM +0200, Peter Eisentraut wrote: 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. FYI, http://pgfoundry.org/projects/configurator/ Jim, it's been referred to several times in this debate. It might do what Peter wants, but for reasons already explained I don't see it as a substitute for getting initdb to generate more realistic settings. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL from source using MinGW
Andrew Dunstan wrote: I think we should also tell people how about --without-readline and about installing zlib or using --without-zlib Agreed. Patch? :-) (You knew I was going to ask, right?) I will put something together. While we're on the subject, is this still true?: The most recent version of this document can be viewed at [2]http://momjian.postgresql.org/main/writings/pgsql/project/win32.html. No. I have fixed it. Or is the authoritative source the HTML file in CVS? Yes, the HTML is the right file to patch. And if I patch that file do I also patch the derived text file? Yes, I regenerate the text version before commit. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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
