FW: [HACKERS] Increasing security in a shared environment ...
>Marc G. Fournier wrote > Does anyone know how ppl like Oracle handle this? Are system catalogs > like this open to all users? The system catalogs for Oracle and most other systems I know of are secure. In both Oracle and Teradata the "system tables" are actually views, which are actively granted access to users by the administrator. The common set of views has a lookup in it to make sure only objects that the user has *some* authority over are made available. On Oracle, these are USER_ views, whereas the administrator has ALL_ views These views look identical, so you can't even tell there's anything you can't see. I had been meaning to suggest that the rather useful \d commands in psql make it through to wider use as system views...so now is a good time to raise that suggestion. If they are worth having in psql, they are worth giving to everyone and we can use that to implement security in just the same way other systems already do. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Why is pg_dump using INSERTs instead of COPYs?
I've got a database running PostgreSQL 7.4.2 on Fedora Linux. In the past, pg_dump would dump database backups using COPY to restore the data. This time it appears that it has individual INSERTs for each tuple. Perhaps I'm missing this in the latest documentation, but I thought COPY was the default unless the --inserts switch is declared. Can anyone think of why I'd be getting INSERTs? Thanks. -Tony ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Why is pg_dump using INSERTs instead of COPYs?
Am Mittwoch, 31. März 2004 13:14 schrieb Tony Reina: > I've got a database running PostgreSQL 7.4.2 on Fedora Linux. In the > past, pg_dump would dump database backups using COPY to restore the > data. This time it appears that it has individual INSERTs for each > tuple. Perhaps I'm missing this in the latest documentation, but I > thought COPY was the default unless the --inserts switch is declared. This is still the case. > Can anyone think of why I'd be getting INSERTs? Shell aliases perhaps. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Why is pg_dump using INSERTs instead of COPYs?
> > I've got a database running PostgreSQL 7.4.2 on Fedora Linux. In the > > past, pg_dump would dump database backups using COPY to restore the > > data. This time it appears that it has individual INSERTs for each > > tuple. Perhaps I'm missing this in the latest documentation, but I > > thought COPY was the default unless the --inserts switch is declared. > > This is still the case. > > > Can anyone think of why I'd be getting INSERTs? > > Shell aliases perhaps. No. I just re-checked my aliases in the shell. Nothing for pg_dump. I'm sure the answer is no, but are there any postgres-specific preference files that may be causing the behavior (perhaps something I'm missing in postgresql.conf)? For the actual command, I'm just saying 'pg_dump -d dbname > dboutput.sql' Nothing fancy. -Tony ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] logging statement levels
Bruce Momjian wrote: Andrew Dunstan wrote: wow. that was nearly 3 months ago ... I wrote: If nobody is working on this I am prepared to look at it: . Allow logging of only data definition(DDL), or DDL and modification statements Here are some options: 1. change the type of "log_statement" option from boolean to string, with allowed values of "all, mod, ddl, none" with default "none". 2. same as 1. but make boolean true values synonyms for "all" and boolean false values synonyms for "none". 3. keep "log_statement" option as now and add a new option "log_statement_level" with the same options as 1. but default to "all", which will have no effect unless "log_statement" is true. I like 1. Also, I assume "modification statements" means insert/update/delete, or Yes. are we talking about DDL mods (like "alter table")? Alter is DDL. Finally, what about functions that have side effects? It would be nice to be able to detect the statements to be logged at the syntactic level, but it strikes me that that might not be possible. Not possible. Subsequent discussion suggested we should add "syntax-errors" to the allowed values (and I would favor making it the default). The problem is this - in order to make the decision about whether or not to log, we need to have parsed the statement (unless the level is set to "all"). My simple approach, which would mean that the entire patch would amount to around 100 lines, maybe, plus docco, would have the (I think) trivial side effect of reversing the order in which a logged statement and the corresponding parse error log entry appeared. You objected to that effect, so I stopped work on it. Now I can think of a couple of different approaches which would not have this effect: a. embed a time machine in postgres so we can make a decision based on information we do not yet have, or b. find some spot where we can trap the parse error log message before it is emitted and then first log the statement. That spot is probably somewhere in src/backend/utils/error/elog.c, but I am not quite sure where. I have rejected as ugly and unmaintainable monkeying with the parser itself to produce the desired effect, and I regret that idea a is beyond my humble abilities :-) cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Why is pg_dump using INSERTs instead of COPYs?
"Tony and Bryn Reina" <[EMAIL PROTECTED]> writes: > For the actual command, I'm just saying 'pg_dump -d dbname > dboutput.sql' "-d" is the --inserts switch. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] with vs without oids in pg_catalog.*
Fabien COELHO <[EMAIL PROTECTED]> writes: > I wish I had some way of referencing objects that I need to designate > (say, an attribute, an index, a table, a constraint, and so on). AFAIK, all objects that you might need to designate can be identified using the scheme employed in pg_depend and pg_description: catalog OID, object OID, subobject number. > So my question still is: Given the fact that I have some use for these > oids, would it make sense to submit a patch to add them? It will be rejected. We removed pg_attribute OIDs some time ago, and we aren't going to put them back without a much better reason than this. If you need a specific counterargument, here is one: pg_attribute is normally much the largest catalog. If we required its rows to have unique OIDs, the probability of collisions after OID-counter wraparound would be much greater than it is in other catalogs. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump end comment
On Wed, 31 Mar 2004, Philip Warner wrote: > At 12:13 AM 31/03/2004, Bruce Momjian wrote: > >Yes, they have to check for a proper exit from pg_dump, but there is > >still a file sitting around after the dump, with no way to tell if it is > >accurate. > > Why don't we write a hash into the header or footer. Then use something like: > > pg_restore --verify > > if file integrity is the objective. I like this idea. Nice to be able to check the md5 sig to make sure a backup is not corrupted OR short. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] logging statement levels
Andrew Dunstan wrote: > Bruce Momjian wrote: > > >Andrew Dunstan wrote: > > > > > > > wow. that was nearly 3 months ago ... Oh, I remember why I kept this email now. I am going to try to code this. > Subsequent discussion suggested we should add "syntax-errors" to the > allowed values (and I would favor making it the default). We already have log_min_error_statement. Seems that is what should be used if someone wants only syntax errors. > The problem is this - in order to make the decision about whether or not > to log, we need to have parsed the statement (unless the level is set > to "all"). My simple approach, which would mean that the entire patch > would amount to around 100 lines, maybe, plus docco, would have the (I > think) trivial side effect of reversing the order in which a logged > statement and the corresponding parse error log entry appeared. You > objected to that effect, so I stopped work on it. > > Now I can think of a couple of different approaches which would not have > this effect: > a. embed a time machine in postgres so we can make a decision based on > information we do not yet have, or > b. find some spot where we can trap the parse error log message before > it is emitted and then first log the statement. That spot is probably > somewhere in src/backend/utils/error/elog.c, but I am not quite sure where. > > I have rejected as ugly and unmaintainable monkeying with the parser > itself to produce the desired effect, and I regret that idea a is beyond > my humble abilities :-) I will start on this now. Thanks. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Update on PITR
"Simon Riggs" <[EMAIL PROTECTED]> writes: > [ expecting to finish PITR by early June ] > Is this all still OK for 7.5? (My attempts at cataloguing changes has > fallen by the wayside in concentrating on the more important task of > PITR.) Do we have a planned freeze month yet? There's not really a plan at the moment, but I had June in the back of my head as a good time; it looks to me like the Windows port will be stable enough for beta in another month or two, and it'd be good if PITR were ready to go by then. Is your timeline based on the assumption of doing all the work yourself? If so, how about farming out some of it? I'd be willing to contribute some effort to PITR. (It's been made clear to me that Red Hat really wants PITR in 7.5 ;-)) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Update on PITR
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Wed, 31 Mar 2004, Tom Lane wrote: > I'd be willing to contribute some effort to PITR. (It's been made clear > to me that Red Hat really wants PITR in 7.5 ;-)) Wow! That's exciting news :-) Does Red Hat also want some more enterprise features? ;-) I've been using PostgreSQL since... about 5 years... The great improvement since then really impresses me. Regards, - -- Devrim GUNDUZ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.TDMSoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAaxEytl86P3SPfQ4RAkisAKDoa8yXf9a68TqBabO6uipPwbihxgCdEJoo 0tkna1hIXkCWFsGcINl+gWs= =bNf3 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Update on PITR
* Tom Lane ([EMAIL PROTECTED]) wrote: > Is your timeline based on the assumption of doing all the work yourself? > If so, how about farming out some of it? I'd be willing to contribute > some effort to PITR. (It's been made clear to me that Red Hat really > wants PITR in 7.5 ;-)) Hey, us Debian folks really want it too. ;) Stephen signature.asc Description: Digital signature
Re: [HACKERS] Update on PITR
Tom Lane wrote: > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > [ expecting to finish PITR by early June ] > > > Is this all still OK for 7.5? (My attempts at cataloguing changes has > > fallen by the wayside in concentrating on the more important task of > > PITR.) Do we have a planned freeze month yet? > > There's not really a plan at the moment, but I had June in the back of > my head as a good time; it looks to me like the Windows port will be > stable enough for beta in another month or two, and it'd be good if > PITR were ready to go by then. > > Is your timeline based on the assumption of doing all the work yourself? > If so, how about farming out some of it? I'd be willing to contribute > some effort to PITR. (It's been made clear to me that Red Hat really > wants PITR in 7.5 ;-)) Agreed! Lets see if we can assemble a team to start coding PITR. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: 7.5 or 8.0? (Was: Re: [HACKERS] Update on PITR )
Devrim GUNDUZ <[EMAIL PROTECTED]> writes: > BTW... PITR, Windows port, possibly Tablespaces and more... Does the > core team intend to use 8.0 instead of 7.5? It's premature to have that discussion yet, IMHO. When we get close to beta and know what the feature list will look like, we can think about what to call it ... regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
7.5 or 8.0? (Was: Re: [HACKERS] Update on PITR )
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On Wed, 31 Mar 2004, Tom Lane wrote: > > Is this all still OK for 7.5? (My attempts at cataloguing changes has > > fallen by the wayside in concentrating on the more important task of > > PITR.) Do we have a planned freeze month yet? > > There's not really a plan at the moment, but I had June in the back of > my head as a good time; it looks to me like the Windows port will be > stable enough for beta in another month or two, and it'd be good if > PITR were ready to go by then. BTW... PITR, Windows port, possibly Tablespaces and more... Does the core team intend to use 8.0 instead of 7.5? Regards, - -- Devrim GUNDUZ [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.TDMSoft.com http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAaxprtl86P3SPfQ4RAqDKAKDmLHQS3KJDlNdhKkIJEzCCjzKk0gCeLQiX zOpH7jHB9qpJeLvXnm2/+n8= =DCvJ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] LIKE and Locale
I'm a little frustrated select * from mytable where mystring = 'foo'; Uses an index select * from mytable where mystring like 'foo'; Does not use an index. I know Tom is not to excited about this, but I think it is a serious problem. What really brings me to this is that I just installed 7.4.2. It is my first real deployment of PostgreSQL in about a year and a half. Unknown to me, the default for my latest DB was not type 'C' but "en_US.iso885915" and thus no amount of work would have allowed a 'LIKE' to use an index without surrounding the index and query with some function, like lower(). This "upgrade" seriously broke a working installation. In the foggy recesses of my mind, I vaguely recalled locale issues with various non-english languages. This shouldn't have been a problem as I was, I thought, just using the default. Surprisingly, SHOW ALL, showed differently. I recreate the database with --no-locale, then it works, obviously. Yea, this amounts to an RTFM issue, granted, but shouldn't various locales be able to work with LIKE? Shouldn't "en_US.iso885915" work with "LIKE?" Shouldn't database creation with anything but 'C' issue a warning? The real issue here is that one has to know that the behavior of "LIKE" is dependent on the locale to understand the problem. Yes it is briefly mentioned in the FAQ, but it is not obvious as a common problem in the UNIX world. As far as I can tell it is a PostgreSQL only issue that the locale setting in the system seriously affects functionality. It is further compounded by the fact that this setting can not be changed without recreating the database. Given a non-trivally sized database, this is no small issue. (Don't get me wrong, these RTFM landmines are great for the consultant and support industry, keep up the good work ;-)) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: 7.5 or 8.0? (Was: Re: [HACKERS] Update on PITR )
On Wed, 31 Mar 2004, Tom Lane wrote: > Devrim GUNDUZ <[EMAIL PROTECTED]> writes: > > BTW... PITR, Windows port, possibly Tablespaces and more... Does the > > core team intend to use 8.0 instead of 7.5? > > It's premature to have that discussion yet, IMHO. When we get close > to beta and know what the feature list will look like, we can think > about what to call it ... Agreed ... all of the above are still, in my mind, considered 'wish list items' for the next release, up until they are actually committed ... but, I do agree that several of them should warrant a major jump, so let's see what we can get into place before 1st of June ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Update on PITR
>Bruce Momjian wrote > Tom Lane wrote: > > "Simon Riggs" <[EMAIL PROTECTED]> writes: > > > [ expecting to finish PITR by early June ] > > > > > Is this all still OK for 7.5? (My attempts at cataloguing > changes has > > > fallen by the wayside in concentrating on the more > important task of > > > PITR.) Do we have a planned freeze month yet? > > > > There's not really a plan at the moment, but I had June in > the back of > > my head as a good time; it looks to me like the Windows port will be > > stable enough for beta in another month or two, and it'd be good if > > PITR were ready to go by then. > > > > Is your timeline based on the assumption of doing all the > work yourself? > > If so, how about farming out some of it? I'd be willing to > contribute > > some effort to PITR. (It's been made clear to me that Red > Hat really > > wants PITR in 7.5 ;-)) > > Agreed! Lets see if we can assemble a team to start coding PITR. > Thank you all for your offers of help. Yes, is the short answer; we should be able to cut enough code on independent work streams to get this system testable by end April. As I say, I started coding some time back and am well into what I've called Phase 1, so its probably best for me to complete that. You guys will be contributing by looking at my code anyhow, so your goodwill is certainly going to be called in, don't worry. There isn't anything too hairy code wise anyhow, if I'm honest. For clarity, this will give the facility to archive xlogs beyond their current short lifetime in the recycling method currently used. Phase 2 is definitely another matter...There doesn't seem to be any dependency that I can see for that I called it Phase 2 because, yes, I did make the assumption that I was doing it all myself, but I did set off on this journey as a team effort and I welcome that still... I described this piece of work earlier as: Phase 2: add code to control recovery (to a point-in-time) - will allow rollforward along extended archive history to point in time, diskspace permitting In my earlier summary of all design contributions there was the idea for a postmaster command line switch which would make rollforward recovery stop at the appropriate place. Two switches were discussed: i) roll forward to point in time. This sounds relatively easy...recovery is already there, all you have to do is stop it at the right place...but I haven't looked into the exact mechanism of reading the xlog headers etc.. [There's also a few bits of work to do there in terms of putting in hooks for the command mechanism. Something like postmaster -R "2004/12/10 19:37:04" as a loose example ii) roll forward on all available logs, but shutdown at end, leaving pg in a recovery-pending state (still). This then gives the DBA a chance to do either a) switch in a new batch of xlogs, allowing an infinite sequence of xlogs to be applied one batch at a time, or b) keep a "hot standby" system continually primed and ready to startup should the primary go down. Neither of those looks too hard to me, so should be able to be done by about mid-April when I'm thinking to have finished XLogArchive API. As I say there's no particular dependency on the XLogArchive API stuff all working, since they can both be tested independently, though we must put them together for system testing. Further tasks (what I had thought of as "Phase 3", but again these can be started now...) - what to do should a cancel CTRL-C be issued during recovery..what state is the database left in? - How do you say "this is taking to long, I really need my database up now, whatever state its in" (when recovery is grinding away, not before you start it or after it has failed, which is where you would use pg_resetxlog) - can you change your mind on that once its up and you see what a mess its in! i.e. put it back into recovery? what would that take - saving clogs? an optional "trial recovery" mode? - how would we monitor a lengthy recovery? watch for "starting recovery of log XXX" messages and do some math to work out the finish time, or is there a better way? - is it possible to have parallel recovery processes active simultaneously for faster recovery?? can we work anything into the design now that would allow that to be added later? What I think is really important is a very well coordinated test plan. Perhaps even more importantly a test plan not written by me, since I might make some dangerous assumptions in writing it. Having a written test plan would allow us to cover all the edge cases that PITR is designed to recover from. It will be pretty hard for most production users of PostgreSQL to fully test PITR, though of course many will "kick the tyres" shall we say, to confirm a full implementation. Many of the tests are not easily automatable, so we can't just dream up some more regression tests. A written plan would then allow coordinated testing to occur across platforms, so a QNX user may spot something that also effects Solaris etc..
Re: [HACKERS] LIKE and Locale
> > On Wed, 31 Mar 2004 [EMAIL PROTECTED] wrote: > >> I'm a little frustrated >> >> select * from mytable where mystring = 'foo'; >> >> Uses an index >> >> select * from mytable where mystring like 'foo'; >> >> Does not use an index. >> >> I know Tom is not to excited about this, but I think it is a serious >> problem. What really brings me to this is that I just installed 7.4.2. >> It > > I agree with Tom mostly. It'd be nice for cases to be better optimized in > general, but optimizing basically degenerate cases seems futile especially > when there's a generally better workaround (see below) I'm not convinced that one optimization must de-optimize something else. Also, I am suspicious of "work arounds" being suggested as norms. > >> is my first real deployment of PostgreSQL in about a year and a half. >> Unknown to me, the default for my latest DB was not type 'C' but >> "en_US.iso885915" and thus no amount of work would have allowed a 'LIKE' >> to use an index without surrounding the index and query with some > > What about making an index with the _pattern_ops opclass which > IIRC is supposed to allow index use on LIKE even for anchored searches > in non-C locales. At issue, would this require a change of the SQL query? If it requires changing the query, then PostgreSQL places too much of a burden on the application writer when it comes to supporting multiple databases. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] LIKE and Locale
On Wed, 31 Mar 2004 [EMAIL PROTECTED] wrote: > I'm a little frustrated > > select * from mytable where mystring = 'foo'; > > Uses an index > > select * from mytable where mystring like 'foo'; > > Does not use an index. > > I know Tom is not to excited about this, but I think it is a serious > problem. What really brings me to this is that I just installed 7.4.2. It I agree with Tom mostly. It'd be nice for cases to be better optimized in general, but optimizing basically degenerate cases seems futile especially when there's a generally better workaround (see below) > is my first real deployment of PostgreSQL in about a year and a half. > Unknown to me, the default for my latest DB was not type 'C' but > "en_US.iso885915" and thus no amount of work would have allowed a 'LIKE' > to use an index without surrounding the index and query with some What about making an index with the _pattern_ops opclass which IIRC is supposed to allow index use on LIKE even for anchored searches in non-C locales. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] LIKE and Locale
On Wed, 31 Mar 2004 [EMAIL PROTECTED] wrote: > > On Wed, 31 Mar 2004 [EMAIL PROTECTED] wrote: > > > >> I'm a little frustrated > >> > >> select * from mytable where mystring = 'foo'; > >> > >> Uses an index > >> > >> select * from mytable where mystring like 'foo'; > >> > >> Does not use an index. > >> > >> I know Tom is not to excited about this, but I think it is a serious > >> problem. What really brings me to this is that I just installed 7.4.2. > >> It > > > > I agree with Tom mostly. It'd be nice for cases to be better optimized in > > general, but optimizing basically degenerate cases seems futile especially > > when there's a generally better workaround (see below) > > I'm not convinced that one optimization must de-optimize something else. But, given limited developer resources, optimizing degenerate sql is probably not the best use unless someone feels strongly enough about it to do it themselves. > Also, I am suspicious of "work arounds" being suggested as norms. The workaround in this case is to make an index that works with LIKE even in non "C" locales. I qualified it as a workaround because potentially you might need two indexes on the field. However, given that it's not limited to non-wildcard containing strings, it's also more generally useful. > >> is my first real deployment of PostgreSQL in about a year and a half. > >> Unknown to me, the default for my latest DB was not type 'C' but > >> "en_US.iso885915" and thus no amount of work would have allowed a 'LIKE' > >> to use an index without surrounding the index and query with some > > > > What about making an index with the _pattern_ops opclass which > > IIRC is supposed to allow index use on LIKE even for anchored searches > > in non-C locales. > > At issue, would this require a change of the SQL query? If it requires > changing the query, then PostgreSQL places too much of a burden on the > application writer when it comes to supporting multiple databases. No, it involves making an index using the built-in _pattern_ops operator class (which is mentioned in the operator class part of the index documentation I think, but probably needs better mention) Something like: CREATE INDEX indblah on tab(col text_pattern_ops) ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] The incompaitiblity of libpq and non-GCC compilers
After making the following change in port.h: /* vvv */ /* open() replacement to allow delete of held files */ extern int win32_open(const char*,int,...); #ifdef _MSC_VER #define openwin32_open #else #define open(a,b,...) win32_open(a,b,##__VA_ARGS__) #endif /* ^^^ */ I can get a little further towards a build of libpq... U:\postgresql-snapshot\src>nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd include if not exist pg_config.h copy pg_config.h.win32 pg_config.h cd .. cd interfaces\libpq nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. Building the Win32 static library... cl.exe @u:\tmp\nma01920. getaddrinfo.c cl.exe @u:\tmp\nmb01920. thread.c ..\..\include\utils/elog.h(37) : warning C4005: 'ERROR' : macro redefinition C:\Program Files\Microsoft SDK\Include\.\wingdi.h(98) : see previous definition of 'ERROR' cl.exe @u:\tmp\nmc01920. inet_aton.c cl.exe @u:\tmp\nmd01920. crypt.c cl.exe @u:\tmp\nme01920. path.c cl.exe @u:\tmp\nmf01920. dllist.c cl.exe @u:\tmp\nmg01920. md5.c cl.exe @u:\tmp\nmh01920. ip.c cl.exe @u:\tmp\nmi01920. wchar.c cl.exe @u:\tmp\nmj01920. encnames.c cl.exe @u:\tmp\nmk01920. win32.c fe-auth.c ..\..\include\libpq/libpq-be.h(21) : fatal error C1083: Cannot open include file: 'sys/time.h': No such file or directory fe-protocol2.c fe-protocol3.c fe-connect.c fe-exec.c fe-lobj.c C:\lang\VC98\include\io.h(176) : error C2375: 'pgrename' : redefinition; different linkage ..\..\include\port.h(45) : see declaration of 'pgrename' C:\lang\VC98\include\io.h(238) : error C2375: 'win32_open' : redefinition; different linkage ..\..\include\port.h(55) : see declaration of 'win32_open' C:\lang\VC98\include\io.h(244) : error C2375: 'pgunlink' : redefinition; different linkage ..\..\include\port.h(46) : see declaration of 'pgunlink' fe-misc.c fe-print.c fe-secure.c pqexpbuffer.c NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\lang\VC98\bin\NMAKE.EXE' : return code '0x2' Stop. Some notions: 1. For the macro ERROR above, we should #undef ERROR 2. #include should have #ifndef _MSC_VER around it. I did this: #ifndef _MSC_VER #include #endif 3. For the errors in io.h, it appears that there are some macros that redefine rename and unlink I did this: /*-- --- * * fe-lobj.c *Front-end large object interface * * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * * * IDENTIFICATION *$PostgreSQL: pgsql-server/src/interfaces/libpq/fe-lobj.c,v 1.48 2004/03/05 01:53:59 tgl Exp $ * *--- -- */ #include "postgres_fe.h" #include #include #include #ifdef WIN32 #include "win32.h" #undef rename #undef open #undef unlink #include "io.h" #else #include #endif There remains one problem on the build -- an unresolved symbol: U:\postgresql-snapshot\src>nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd include if not exist pg_config.h copy pg_config.h.win32 pg_config.h cd .. cd interfaces\libpq nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. Building the Win32 static library... cl.exe @u:\tmp\nma02216. fe-auth.c link.exe -lib @u:\tmp\nmb02216. cl.exe @u:\tmp\nmc02216. libpqdll.c rc.exe /l 0x409 /fo".\Release\libpq.res" libpq.rc link.exe @u:\tmp\nmd02216. Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp libpq.lib(fe-connect.obj) : error LNK2001: unresolved external symbol _set_noblock .\Release\libpq.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. NMAKE : fatal error U1077: 'C:\lang\VC98\bin\NMAKE.EXE' : return code '0x2' Stop. This stuff really needs to be functional with compilers besides GCC derivatives. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[PERFORM] linux and anotime mount option
Do you know if postgres made assumption on the access time time stamp for the files on his own file sistem ? If not I'm wondering if mount a partition with the option "anotime" can improve the disk i/o performance. Regards Gaetano Mendola ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] The incompaitiblity of libpq and non-GCC compilers
Some of this looks at first glance like it doesn't belong in an interface library - maybe we should be wrapping more in #ifdef FRONTEND ? cheers andrew Dann Corbit wrote: After making the following change in port.h: /* vvv */ /* open() replacement to allow delete of held files */ extern int win32_open(const char*,int,...); #ifdef _MSC_VER #define openwin32_open #else #define open(a,b,...) win32_open(a,b,##__VA_ARGS__) #endif /* ^^^ */ I can get a little further towards a build of libpq... U:\postgresql-snapshot\src>nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd include if not exist pg_config.h copy pg_config.h.win32 pg_config.h cd .. cd interfaces\libpq nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. Building the Win32 static library... cl.exe @u:\tmp\nma01920. getaddrinfo.c cl.exe @u:\tmp\nmb01920. thread.c ..\..\include\utils/elog.h(37) : warning C4005: 'ERROR' : macro redefinition C:\Program Files\Microsoft SDK\Include\.\wingdi.h(98) : see previous definition of 'ERROR' cl.exe @u:\tmp\nmc01920. inet_aton.c cl.exe @u:\tmp\nmd01920. crypt.c cl.exe @u:\tmp\nme01920. path.c cl.exe @u:\tmp\nmf01920. dllist.c cl.exe @u:\tmp\nmg01920. md5.c cl.exe @u:\tmp\nmh01920. ip.c cl.exe @u:\tmp\nmi01920. wchar.c cl.exe @u:\tmp\nmj01920. encnames.c cl.exe @u:\tmp\nmk01920. win32.c fe-auth.c ..\..\include\libpq/libpq-be.h(21) : fatal error C1083: Cannot open include file: 'sys/time.h': No such file or directory fe-protocol2.c fe-protocol3.c fe-connect.c fe-exec.c fe-lobj.c C:\lang\VC98\include\io.h(176) : error C2375: 'pgrename' : redefinition; different linkage ..\..\include\port.h(45) : see declaration of 'pgrename' C:\lang\VC98\include\io.h(238) : error C2375: 'win32_open' : redefinition; different linkage ..\..\include\port.h(55) : see declaration of 'win32_open' C:\lang\VC98\include\io.h(244) : error C2375: 'pgunlink' : redefinition; different linkage ..\..\include\port.h(46) : see declaration of 'pgunlink' fe-misc.c fe-print.c fe-secure.c pqexpbuffer.c NMAKE : fatal error U1077: 'cl.exe' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\lang\VC98\bin\NMAKE.EXE' : return code '0x2' Stop. Some notions: 1. For the macro ERROR above, we should #undef ERROR 2. #include should have #ifndef _MSC_VER around it. I did this: #ifndef _MSC_VER #include #endif 3. For the errors in io.h, it appears that there are some macros that redefine rename and unlink I did this: /*-- --- * * fe-lobj.c * Front-end large object interface * * Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group * Portions Copyright (c) 1994, Regents of the University of California * * * IDENTIFICATION * $PostgreSQL: pgsql-server/src/interfaces/libpq/fe-lobj.c,v 1.48 2004/03/05 01:53:59 tgl Exp $ * *--- -- */ #include "postgres_fe.h" #include #include #include #ifdef WIN32 #include "win32.h" #undef rename #undef open #undef unlink #include "io.h" #else #include #endif There remains one problem on the build -- an unresolved symbol: U:\postgresql-snapshot\src>nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cd include if not exist pg_config.h copy pg_config.h.win32 pg_config.h cd .. cd interfaces\libpq nmake /f win32.mak Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. Building the Win32 static library... cl.exe @u:\tmp\nma02216. fe-auth.c link.exe -lib @u:\tmp\nmb02216. cl.exe @u:\tmp\nmc02216. libpqdll.c rc.exe /l 0x409 /fo".\Release\libpq.res" libpq.rc link.exe @u:\tmp\nmd02216. Creating library .\Release\libpqdll.lib and object .\Release\libpqdll.exp libpq.lib(fe-connect.obj) : error LNK2001: unresolved external symbol _set_noblock .\Release\libpq.dll : fatal error LNK1120: 1 unresolved externals NMAKE : fatal error U1077: 'link.exe' : return code '0x460' Stop. NMAKE : fatal error U1077: 'C:\lang\VC98\bin\NMAKE.EXE' : return code '0x2' Stop. This stuff really needs to be functional with compilers besides GCC derivatives. ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Update on PITR
Is your timeline based on the assumption of doing all the work yourself? If so, how about farming out some of it? I'd be willing to contribute some effort to PITR. (It's been made clear to me that Red Hat really wants PITR in 7.5 ;-)) What is RedHat's interest in PostgreSQL? Last time I heard they weren't interested in their database product anymore. Why do they care about the PostgreSQL project? Of course, it's awesome that they are - but why? What's their plan? Chris ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Update on PITR
Christopher Kings-Lynne wrote: > > Is your timeline based on the assumption of doing all the work yourself? > > If so, how about farming out some of it? I'd be willing to contribute > > some effort to PITR. (It's been made clear to me that Red Hat really > > wants PITR in 7.5 ;-)) > > What is RedHat's interest in PostgreSQL? Last time I heard they weren't > interested in their database product anymore. Why do they care about > the PostgreSQL project? > > Of course, it's awesome that they are - but why? What's their plan? > SRA wants PITR too, as does everyone else. :-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (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 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Update on PITR
On Thu, 1 Apr 2004, Christopher Kings-Lynne wrote: > > Is your timeline based on the assumption of doing all the work yourself? > > If so, how about farming out some of it? I'd be willing to contribute > > some effort to PITR. (It's been made clear to me that Red Hat really > > wants PITR in 7.5 ;-)) > > What is RedHat's interest in PostgreSQL? Last time I heard they weren't > interested in their database product anymore. Why do they care about > the PostgreSQL project? Just speculation, but I'd go with end goal being to be able to dump Oracle altogether, once PostgreSQL actually has all the various enterprise features ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] GUID
I know I'm probably being a bomb tosser, but would it be practical to incorporate, like the serial type, and automatic GUID type? While I love PostgreSQL, I am frequently forced to deal with Oracle and MSSQL. While there is a great deal of focus on making PostgreSQL a good competitor to Oracle, making it a good competitor for MSSQL is a good idea as well. (Yes, I know this is not a very difficult target.) The reference code is readily available and postgresql functions are trivial to write, if one were to submit code properly addorned with the various copyright notices, could it be included in the main catalog? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] GUID
Ð ??, 01.04.2004, Ð 08:00, [EMAIL PROTECTED] ÐÐÑÐÑ: > I know I'm probably being a bomb tosser, but would it be practical to > incorporate, like the serial type, and automatic GUID type? > > While I love PostgreSQL, I am frequently forced to deal with Oracle and > MSSQL. While there is a great deal of focus on making PostgreSQL a good > competitor to Oracle, making it a good competitor for MSSQL is a good > idea as well. (Yes, I know this is not a very difficult target.) > > The reference code is readily available and postgresql functions are > trivial to write, if one were to submit code properly addorned with the > various copyright notices, could it be included in the main catalog? > There exists uniqueidentifier project on gborg.postgresql.org. It adds uniqueidentifier datatype to postgresql, but depends on libuuid from e2fsprogs. Take a look on http://gborg.postgresql.org/projects/uniqueidentifier. Regards, Dmitry ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
