AW: AW: AW: [HACKERS] Issue NOTICE for attempt to raise lock level?
> > Will we still have readers-dont-block-writers behaviour? > > Sure. The only thing this really affects is VACUUM and schema-altering > commands, which will now have to wait until reader transactions commit. And "lock table ...", which would need some deadlock resolution code, because two sessions with select * from foo; lock table foo; should not need to deadlock, since one of the two could get the lock without breaking anything. > In other words > > Session 1 Session 2 > > BEGIN; > SELECT * FROM foo; > > ALTER TABLE foo ... > > ... > > COMMIT; > > Session 2 will have to wait for session 1 to commit; before it didn't. > An example of why this is a good idea is The below is a completely different thing than the above. In the below it is clear that a shared lock is needed until the last row from c is fetched, since the statement is still active. In this particular example there would be two different behaviors in my proposal depending on how many rows are in foo (1 or many). If 0 or 1 row -> relese lock after fetch, if more rows release at commit. > > Session 1 Session 2 > > BEGIN; > DECLARE c CURSOR FOR > SELECT * FROM foo; > > ALTER TABLE foo ... > > FETCH FROM c; > > COMMIT; > > Without a held read lock on foo, session 1 is in deep trouble, > because its cursor is no longer correctly planned. Andreas
AW: [HACKERS] Issue NOTICE for attempt to raise lock level?
> relcache. Not good. Forcing the schema update to be held off in the > first place seems the right answer. Agreed, the only question is, how long. My idea would be until statement end, which is also how Informix does it btw. (If you wanted a prominent example) Of course a "statement" spans open cursor and all subsequent fetches. Andreas
AW: AW: AW: [HACKERS] Issue NOTICE for attempt to raise lock leve l?
> > Unfortunately, session 3 with just SELECT * FROM foo will also wait > > for session 1 & session 2 commit. > > Session 3 would wait for session 2 in any case, no? > > This is all irrelevant unless someone can make a convincing case that > it's safe to release read locks early. In the words of the ancient > sage, "I can make this program arbitrarily fast ... if it doesn't have > to give the right answer". I have already pointed out several cases > where releasing locks early is clearly *not* safe. Your cursor example was busted, I did not yet see an example that would not behave perfectly well when the lock is only held until statement end. (We all agree that the current way of taking several short term locks during the execution of one stmt is wrong) You yourself gave us a perfect example where not releasing the lock is not *safe*, since it leads to an additional deadlock situation (unless you add code to resolve it). > I don't think I > need to produce more examples. The burden of proof is on the other > side to show how it can be done safely see above > (and with an amount of work > that's reasonable for 7.1, which is not too darn much at this point). This is unfortunately true. No idea where to put that piece of code, but didn't you add statement level cleanup somwhere to avoid keeping unnecessary memory until end of tx ? Wouldn't that be the place to release those shared locks ? Andreas
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
At 14:04 7/11/00 -0500, Jan Wieck wrote: >> Thoughts? At the moment I'm afraid that the functionality we have is >> worse than the way prior versions behaved --- not least because anyone >> who was putting user data in template1 has probably gotten used to the >> prior behavior. Maybe we should give up the whole idea of user data >> in template1. > >FWIW, what about having another "template0" database, where >nobody can add user data. Initially, template0 and template1 >are identically. CREATE DATABASE get's a new switch (used by >the pg_dump output) that tells to create it from the vanilla >template0 DB (generalized, so someone can setup a couple of >template's) and all objects inherited from template1 >(those not in template0) are regularly dumped per database. All pg_dump really needs is the abilty to ask for a 'vanilla' database from 'CREATE DATABASE' or createdb. It can use lastsysoid for template1/0 do dump all database definitions. Any altered system objects will not be dumped, which is probably OK (and may even be the Right Thing). The command to create the new database needs to ask for a vanilla database somehow, but extending the SQL doesn't seem like a good idea. *Maybe* we can use a new 'set' command to define the template database for the current session: set pg_template create database... or createdb --template= It would also be good to allow some kind of installation-wide default template (not necessarily template1/0), which is overridden temporarily by the 'set' command. If we can do this, then we create template0 & 1 in the same way we create template1 now, then set template1 as the default template. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Issue NOTICE for attempt to raise lock level?
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > What I mean is to change heap_open(r) like > LockRelationId(Name) -> shared-inval-handling -> > allocate the relation descriptor and increment rd_refcnt > This would ensure that relations with rd_refcnt > 0 > acquire some lock. Could any shared-inval-noti > fication arrive for such relations under the me- > chanism ? Yes, because the system doesn't make any attempt to ensure that relcache entries are held open throughout a statement or transaction. (If they were, we largely wouldn't have a problem.) So we can't use relcache refcount going from 0 to 1 as the sole criterion for when to acquire a lock. I did look at using the relcache to control holding locks throughout statements, but it seems that it doesn't have enough information to grab the right kind of lock. For example, I had to modify the parser to ensure that the right kind of lock is grabbed on the initial relcache access, depending on whether the table involved is accessed for plain SELECT, SELECT FOR UPDATE, or INSERT/UPDATE/DELETE. I still have to make a similar change in the rewriter for table references that are added to a query by rewrite. The code that is doing this stuff knows full well that it is making the first reference to a table, and so the relcache doesn't really have anything to contribute. > However 'reset system cache' message > could arrive at any time. I've examined the error > 'recursive use of cache' for some time. It seems > very difficult to avoid the error if we reconstruct > relation descriptors whose rd_refcnt > 0 in > RelationCacheInvalidate(). I haven't had time to look at that yet, but one possible answer is just to disable the 'recursive use of cache' test. It's only a debugging sanity-check anyway, not essential functionality. regards, tom lane
Re: AW: [HACKERS] Re: [GENERAL] Query caching
Karel Zak wrote: > On Fri, 3 Nov 2000, Christof Petig wrote: > > > Karel Zak wrote: > > > > > On Thu, 2 Nov 2000, Zeugswetter Andreas SB wrote: > > > > > > > > > > > > Well I can re-write and resubmit this patch. Add it as a > > > > > compile time option > > > > > is not bad idea. Second possibility is distribute it as patch > > > > > in the contrib > > > > > tree. And if it until not good tested not dirty with this main tree... > > > > > > > > > > Ok, I next week prepare it... > > > > > > > > One thing that worries me though is, that it extends the sql language, > > > > and there has been no discussion about the chosen syntax. > > > > > > > > Imho the standard embedded SQL syntax (prepare ...) could be a > > > > starting point. > > > > > > Yes, you are right... my PREPARE/EXECUTE is not too much ready to SQL92, > > > I some old letter I speculate about "SAVE/EXECUTE PLAN" instead > > > PREPARE/EXECUTE. But don't forget, it will *experimental* patch... we can > > > change it in future ..etc. > > > > > > Karel > > > > [Sorry, I didn't look into your patch, yet.] > > Please, read my old query cache and PREPARE/EXECUTE description... Sorry I can't find it in my (current) mailbox, do you have a copy around? Or can you give me a keyword? > > What about parameters? Normally you can prepare a statement and execute it > > We have in PG parameters, see SPI, but now it's used inside backend only > and not exist statement that allows to use this feature in be<->fe. Sad. Since ecpg would certainly benefit from this. > > using different parameters. AFAIK postgres' frontend-backend protocol is not > > designed to take parameters for statements (e.g. like result presents > > results). A very long road to go. > > By the way, I'm somewhat interested in getting this feature in. Perhaps it > > should be part of a protocol redesign (e.g. binary parameters/results). > > Handling endianness is one aspect, floats are harder (but float->ascii->float > > sometimes fails as well). > > PREPARE AS > [ USING type, ... typeN ] > [ NOSHARE | SHARE | GLOBAL ] > > EXECUTE > [ INTO [ TEMPORARY | TEMP ] [ TABLE ] new_table ] > [ USING val, ... valN ] >[ NOSHARE | SHARE | GLOBAL ] > > DEALLOCATE PREPARE > [ [ NOSHARE | SHARE | GLOBAL ]] > [ ALL | ALL INTERNAL ] > > An example: > > PREPARE chris_query AS SELECT * FROM pg_class WHERE relname = $1 USING text; I would prefer '?' as a parameter name, since this is in the embedded sql standard (do you have a copy of the 94 draft? I can mail mine to you?) Also the standard says a whole lot about guessing the parameter's type. Also I vote for ?::type or type(?) or sql's cast(...) (don't know it's syntax) instead of abusing the using keyword. > EXECUTE chris_query USING 'pg_shadow'; Great idea of yours to implement this! Since I was thinking about implementing a more decent schema for ecpg but had no mind to touch the backend and be-fe protocol (yet). It would be desirable to do an 'execute immediate using', since using input parameters would take a lot of code away from ecpg. Yours Christof PS: I vote for rethinking the always ascii over the wire strategy. CORBA was proposed as a potential replacement which takes care of endianness and float conversions. But I would not go that far (???), perhaps taking encodings (aka marshalling?) from CORBA.
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
> At 14:04 7/11/00 -0500, Jan Wieck wrote: >> FWIW, what about having another "template0" database, where >> nobody can add user data. Initially, template0 and template1 >> are identically. CREATE DATABASE get's a new switch (used by >> the pg_dump output) that tells to create it from the vanilla >> template0 DB (generalized, so someone can setup a couple of >> template's) and all objects inherited from template1 >> (those not in template0) are regularly dumped per database. I like that a lot. Solves the whole problem at a stroke, and even adds some extra functionality (alternate templates). Do we need an actual enforcement mechanism for "don't modify template0"? I think we could live without that for now. If you're worried about it, one way would be to not allow connections of any sort to template0... in fact template0 needn't be a real database at all, just a $PGDATA/base subdirectory with no pg_database entry. initdb would set it up via cp -r from template1, and thereafter it'd just sit there. Philip Warner <[EMAIL PROTECTED]> writes: > The command to create the new database needs to ask for a vanilla database > somehow, but extending the SQL doesn't seem like a good idea. Why not? CREATE DATABASE isn't a standard command in the first place, and it's got a couple of even-less-standard options already. I like CREATE DATABASE foo WITH TEMPLATE 'template0' better than a SET command. > It would also be good to allow some kind of installation-wide default > template (not necessarily template1/0), Maybe, but let's not go overboard here. For one thing, where are you going to keep that default setting? I think a hard-wired default of template1 is a perfectly good choice. regards, tom lane
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
At 10:15 8/11/00 -0500, Tom Lane wrote: >I like > > CREATE DATABASE foo WITH TEMPLATE 'template0' > >better than a SET command. Just seems like we'd be forcing non-standard syntax on ourselves when/if CREATE DATABASE becomes CREATE SCHEMA; I would assume that the two statements would become synonymous? Since this code is only for pg_dump, polluting CREATE DATABASE even further seems like a bad idea. No big deal, though. [Minor aside: would 'FROM TEMPLATE' be better?] Question: if I issue a "CREATE DATABASE foo WITH TEMPLATE 'my-favorite-db'" will I just get a copy of the specified database, including data? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
Philip Warner <[EMAIL PROTECTED]> writes: > Just seems like we'd be forcing non-standard syntax on ourselves when/if > CREATE DATABASE becomes CREATE SCHEMA; I would assume that the two > statements would become synonymous? No, I don't think so --- we already have WITH LOCATION and WITH ENCODING, neither of which look like schema-level properties to me. > [Minor aside: would 'FROM TEMPLATE' be better?] WITH is already embedded in the CREATE DATABASE syntax. > Question: if I issue a "CREATE DATABASE foo WITH TEMPLATE 'my-favorite-db'" > will I just get a copy of the specified database, including data? If we allow it, that's what would happen. Seems like a potential security hole though ... should we restrict the set of clonable templates somehow? It occurs to me that the current implementation of CREATE DATABASE assumes that no changes are actively going on in the cloned database; for example, you'd miss copying any pages that are sitting in dirty buffers in shared memory. So trying to copy an active database this way is a recipe for trouble. Probably better restrict it to identified template databases. Maybe only allow cloning from DBs that are named templateNNN? regards, tom lane
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
At 10:56 8/11/00 -0500, Tom Lane wrote: >Philip Warner <[EMAIL PROTECTED]> writes: >> Just seems like we'd be forcing non-standard syntax on ourselves when/if >> CREATE DATABASE becomes CREATE SCHEMA; I would assume that the two >> statements would become synonymous? > >No, I don't think so --- we already have WITH LOCATION and WITH >ENCODING, neither of which look like schema-level properties to me. CREATE SCHEMA supports character set specification, so I'd guess 'WITH ENCODING' will apply in some form. It also support a 'schema path name', which may or may not map to locations. >> Question: if I issue a "CREATE DATABASE foo WITH TEMPLATE 'my-favorite-db'" >> will I just get a copy of the specified database, including data? > >If we allow it, that's what would happen. Seems like a potential >security hole though ... should we restrict the set of clonable >templates somehow? It would be nice to have a 'supported' COPY DATABASE (which is what we're talking about, really), so I'd vote for being able to use any DB as a template, if possible. Can we restrict the command to databases that have only one active backend? Or add an 'istemplate' flag set in pg_database? I don't really like relying on specific name formats, if we can avoid it. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: AW: [HACKERS] Re: [GENERAL] Query caching
On Wed, Nov 08, 2000 at 04:05:50PM +0100, Christof Petig wrote: > Karel Zak wrote: > > > > Please, read my old query cache and PREPARE/EXECUTE description... > > Sorry I can't find it in my (current) mailbox, do you have a copy around? Or can > you give me a keyword? > In my archives, there's this one: Date: Wed, 19 Jul 2000 10:16:13 +0200 (CEST) From: Karel Zak <[EMAIL PROTECTED]> To: pgsql-hackers <[EMAIL PROTECTED]> Subject: [HACKERS] The query cache - first snapshot (long) Here's the URL to the archives: http://www.postgresql.org/mhonarc/pgsql-hackers/2000-07/msg01098.html Ross -- Open source code is like a natural resource, it's the result of providing food and sunshine to programmers, and then staying out of their way. [...] [It] is not going away because it has utility for both the developers and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
On Thu, Nov 09, 2000 at 02:48:50AM +1100, Philip Warner wrote: > At 10:15 8/11/00 -0500, Tom Lane wrote: > >I like > > > > CREATE DATABASE foo WITH TEMPLATE 'template0' > > > >better than a SET command. > > Just seems like we'd be forcing non-standard syntax on ourselves when/if > CREATE DATABASE becomes CREATE SCHEMA; I would assume that the two > statements would become synonymous? Since this code is only for pg_dump, > polluting CREATE DATABASE even further seems like a bad idea. No big deal, > though. Nope, we'll still have databases, with schema inside them. Schema are essentially a logical namespace, while a database encompasses all the data objects accessible to one session (via standard SQL), i.e. one backend. As Tom said, creating and maintaining those are 'implementation defined' in the standard. Ross -- Open source code is like a natural resource, it's the result of providing food and sunshine to programmers, and then staying out of their way. [...] [It] is not going away because it has utility for both the developers and users independent of economic motivations. Jim Flynn, Sunnyvale, Calif.
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
Philip Warner <[EMAIL PROTECTED]> writes: > It would be nice to have a 'supported' COPY DATABASE (which is what we're > talking about, really), so I'd vote for being able to use any DB as a > template, if possible. > Can we restrict the command to databases that have only one active backend? No active backends would be more like it. The problem here is that there's a race condition much like the one for DROP DATABASE --- there may be no one connected when you look, but that's no guarantee someone can't connect right after you look. We're already overdue for beta, so I really don't want to start designing/implementing a generalized COPY DATABASE. (We're not officially in feature freeze yet, but inventing new features off the top of our heads doesn't seem like the thing to be doing now.) I'd like to see a proper fix for the inherited-data problem, though, since that's clearly a bug in an existing feature. > Or add an 'istemplate' flag set in pg_database? I don't really like relying > on specific name formats, if we can avoid it. That's reasonable I guess. Do we still need the lastsysoid column in pg_database if we do things this way? Seems like what you really want is to suppress all the objects that are in template0, so you really only need one lastsysoid value, namely template0's. The other entries are useless AFAICS. regards, tom lane
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
At 11:13 8/11/00 -0500, Tom Lane wrote: > >Do we still need the lastsysoid column in pg_database if we do things >this way? Seems like what you really want is to suppress all the >objects that are in template0, so you really only need one lastsysoid >value, namely template0's. The other entries are useless AFAICS. That sounds reasonable; although there may be some value in allowing dumps relative to template0 OR template1. Not sure. Where would you store the value if not in pg_database? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 0500 83 82 82 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Re: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
Philip Warner <[EMAIL PROTECTED]> writes: > Where would you store the value if not in pg_database? No other ideas at the moment. I was just wondering whether there was any way to delete it entirely, but seems like we want to have the value for template0 available. The old way of hardwiring knowledge into pg_dump was definitely not as good. regards, tom lane
[HACKERS] V7.0.3 Released! - According to ZDNet
Title: V7.0.3 Released! - According to ZDNet Just thought I'd tell you that ZDNet have announced that v7.0.3 is released! Didn't think this was true. If it is did I miss the announcement! If its not ready for release then some people may be using software that they don't know is still in beta testing. Not sure if this is such a good idea as it may give PostgreSQL a bad name. Regards Ben Trewern
[HACKERS] [Q] Status of ENUM column type.
I was able to locate snippets of information regarding the implementation of an enum column type on a European maillist archive, but have been unable to locate any addition information regarding this effort. Could someone be so kind as to pass along an update on this effort and possibly suggest where I could find additional resources? Thank you for your time. Daniel Meyer dmeyer tap net
Re: [HACKERS] V7.0.3 Released! - According to ZDNet
It has not been officially released yet ... whoever released such did so
pre-maturely ... we don't even have a link to it from the web site yet ...
On Wed, 8 Nov 2000, Trewern, Ben wrote:
> Just thought I'd tell you that ZDNet have announced that v7.0.3 is released!
> Didn't think this was true. If it is did I miss the announcement! If its
> not ready for release then some people may be using software that they don't
> know is still in beta testing.
>
> Not sure if this is such a good idea as it may give PostgreSQL a bad name.
>
> Regards
>
> Ben Trewern
>
Marc G. Fournier [EMAIL PROTECTED]
Systems Administrator @ hub.org
scrappy@{postgresql|isc}.org ICQ#7615664
RE: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam (xact.c xlog.c)
> > > > New CHECKPOINT command. > > > > Auto removing of offline log files and creating new file > > > > at checkpoint time. > > Can you tell me how to use CHECKPOINT please? You shouldn't normally use it - postmaster will start backend each 3-5 minutes to do this automatically. > > > Is this the same as a SAVEPOINT? > > > > No. Checkpoints are to speedup after crash recovery and > > to remove/archive log files. With WAL server doesn't write > > any datafiles on commit, only commit record goes to log > > (and log fsync-ed). Dirty buffers remains in memory long > > Is log fsynced even I turn of -F? Yes, though we can change this. We also can implement now feature that Bruce wanted so long and so much -:) - fsync log not on each commit but each ~ 5sec, if losing some recent commits is acceptable. Nevertheless, when bufmgr replaces dirty buffer it must ensure first that log record of last buffer update is on disk already and so bufmgr forces log fsync if required. This cannot be changed - rule is simple: log before applying changes to permanent storage. Vadim
Re: [HACKERS] RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.cxlog.c)
[ Charset ISO-8859-1 unsupported, converting... ] > > > > > New CHECKPOINT command. > > > > > Auto removing of offline log files and creating new file > > > > > at checkpoint time. > > > > Can you tell me how to use CHECKPOINT please? > > You shouldn't normally use it - postmaster will start backend > each 3-5 minutes to do this automatically. > > > > > Is this the same as a SAVEPOINT? > > > > > > No. Checkpoints are to speedup after crash recovery and > > > to remove/archive log files. With WAL server doesn't write > > > any datafiles on commit, only commit record goes to log > > > (and log fsync-ed). Dirty buffers remains in memory long > > > > Is log fsynced even I turn of -F? > > Yes, though we can change this. We also can implement now > feature that Bruce wanted so long and so much -:) - > fsync log not on each commit but each ~ 5sec, if > losing some recent commits is acceptable. Great. I think this middle ground is something we could never address before. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Re: [HACKERS] problems with configure
"Martin A. Marques" <[EMAIL PROTECTED]> writes: Is there any kind of info you would need that I could provide? >> >> If you could put >> #include >> #include >> into a file temp.c, and then send the output of "gcc -E temp.c", >> it might shed some light. > There it goes!! Well, that tells the tale all right: the critical lines are typedef uint32_tsocklen_t; typedef void*Psocklen_t; extern int accept(int, struct sockaddr *, Psocklen_t); What brainless idiot decided it would be a good idea to declare accept's last argument as void*, do you suppose? (At least you report that Solaris 8 no longer has this folly, so they did get a clue eventually.) Not sure what to do about this. It will clearly not do to define ACCEPT_TYPE_ARG3 as void. Perhaps we need a special case for Solaris 7: if we detect that accept() is declared with "void *", assume that socklen_t is the thing to use. Peter, any thoughts? regards, tom lane
Re: [HACKERS] problems with configure
On Mié 08 Nov 2000 18:01, Tom Lane wrote: > > Well, that tells the tale all right: the critical lines are > > typedef uint32_tsocklen_t; > > typedef void*Psocklen_t; > > extern int accept(int, struct sockaddr *, Psocklen_t); > > What brainless idiot decided it would be a good idea to declare > accept's last argument as void*, do you suppose? (At least you > report that Solaris 8 no longer has this folly, so they did get > a clue eventually.) > > Not sure what to do about this. It will clearly not do to define > ACCEPT_TYPE_ARG3 as void. Perhaps we need a special case for > Solaris 7: if we detect that accept() is declared with "void *", > assume that socklen_t is the thing to use. Peter, any thoughts? No. Forgot to tell my latest experience. 1) postgres 7.0.2 compiles great on Solaris 7 and Solaris 8. 2) postgres cvs (latest download) doesn't compile (same error on both) on Solaris 7 nor Solaris 8. So it isn't a Solaris 7 problem, but a Solaris problem. ;-) I just wish we could install linux on one of these SPARC to have something good running. ;-) Saludos... :-) -- "And I'm happy, because you make me feel good, about me." - Melvin Udall - Martín Marqués email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
Re: [HACKERS] problems with configure
"Martin A. Marques" <[EMAIL PROTECTED]> writes: > No. Forgot to tell my latest experience. > 1) postgres 7.0.2 compiles great on Solaris 7 and Solaris 8. > 2) postgres cvs (latest download) doesn't compile (same error on both) on > Solaris 7 nor Solaris 8. Ah so. 7.0.*'s configure didn't try to determine the exact datatype of accept()'s arguments, which is why it didn't run into this problem. > So it isn't a Solaris 7 problem, but a Solaris problem. ;-) I guess we not only need a hack, but a nastygram or three sent off to the Solaris people. void *? What in heavens name were they thinking? That essentially means you've got no parameter type checking at all on calls to accept() --- or any other socket function that takes a socklen_t. Pass the wrong-size integer, you're out of luck ... silently. Sheesh. regards, tom lane
Re: [HACKERS] problems with configure
On Mié 08 Nov 2000 18:17, Tom Lane wrote: > > I guess we not only need a hack, but a nastygram or three sent off to > the Solaris people. void *? What in heavens name were they thinking? > That essentially means you've got no parameter type checking at all > on calls to accept() --- or any other socket function that takes a > socklen_t. Pass the wrong-size integer, you're out of luck ... silently. > Sheesh. I have to say that I'm totally with you on the thoughts about Solaris's implementation. It's not the first time I have problems compiling. Trying to compile KDE2-alpha some time ago I had to hack on of the ICE headers which had some sort of problem trying to determine the size of ... I can't remember what, so even Open windows has it's bugs, which aren't fixxed in Solaris 8. To finish, which would be the status all this Solaris + Postgres cvs stuff? Saludos... :-) -- "And I'm happy, because you make me feel good, about me." - Melvin Udall - Martín Marqués email: [EMAIL PROTECTED] Santa Fe - Argentinahttp://math.unl.edu.ar/~martin/ Administrador de sistemas en math.unl.edu.ar -
Re: [HACKERS] Proposal for DROP TABLE rollback mechanism
"Vadim Mikheev" <[EMAIL PROTECTED]> writes: > Please note that there is xlog_bufmgr.c If you'll add/change something in > bufmgr please let me know later. Per your request: I've changed bufmgr.c. I think I made appropriate changes in xlog_bufmgr, but please check. The changes were: 1. Modify FlushRelationBuffers to do plain write, not flush (no fsync) of dirty buffers. This was per your suggestion. FlushBuffer() now takes an extra parameter indicating whether fsync is wanted. I think this change does not affect xlog_bufmgr at all. 2. Rename ReleaseRelationBuffers to DropRelationBuffers to make it more clear what it's doing. 3. Add a DropRelFileNodeBuffers, which is just like DropRelationBuffers except it takes a RelFileNode argument. This is used by smgr to ensure that the buffer cache is clear of buffers for a rel about to be deleted. 4. Update comments about usage of DropRelationBuffers and FlushRelationBuffers. Rollback of DROP TABLE now works in non-WAL code, and seems to work in WAL code too. I did not add WAL logging, because I'm not quite sure what to do, so rollforward probably does the wrong thing. Could you deal with that part? smgr.c is the place that keeps the list of what to delete at commit or abort. regards, tom lane
RE: [HACKERS] Proposal for DROP TABLE rollback mechanism
> Rollback of DROP TABLE now works in non-WAL code, and seems to work in > WAL code too. I did not add WAL logging, because I'm not quite sure > what to do, so rollforward probably does the wrong thing. Could you > deal with that part? smgr.c is the place that keeps the list of what > to delete at commit or abort. Ok, thanks! I'll take list of relfilenodes to delete just before commit and put it into commit record. Vadim
[HACKERS] test .. ignore
Jeff MacDonald, - PostgreSQL Inc | Hub.Org Networking Services [EMAIL PROTECTED] | [EMAIL PROTECTED] www.pgsql.com | www.hub.org 1-902-542-0713 | 1-902-542-3657 - Facsimile : 1 902 542 5386 IRC Nick : bignose
[HACKERS] unreachable block
Hi,
I found an unreachable block during studing the PostgreSQL 7.0.2 by
reading its souce code.
Starting from line 1383 in postgres.c
1383 if (Verbose)
1384 {
1385 if (Verbose)
1386 {
:
1389 }
1390 else
1391 {
: // !! unreachable
1405 }
1406 }
Can someone take a look of it? This shouldn't take long time to fix.
--
Limin Liu
[HACKERS] Text concat problem
Hi:
Have this curious situation and would like some help from you:
Create an employee table:
CREATE TABLE employee(
id_employee SERIAL PRIMARY KEY,
sex CHAR(1) DEFAULT 'm' CHECK(sex = 'f' OR sex = 'm'),
start_date DATE NOT NULL,
charge VARCHAR(50) NOT NULL,
last_name VARCHAR(50),
first_name VARCHAR(50) NOT NULL,
title VARCHAR(10) NOT NULL
);
then fill it with a few values:
insert into employee(title,first_name,start_date,charge) values('Mr.
X','Smith',date(now()),'None');
insert into employee(title,first_name,start_date,charge) values('Mr.
Y','Smith',date(now()),'None');
insert into employee(title,first_name,start_date,charge) values('Mr.
Z','Smith',date(now()),'None');
so far there is no problem at all, the problem comes here:
select title || ' ' || first_name || ' ' || last_name as fullname from employee;
fullname
(3 rows)
Doesn't work , I'm thinking it is because of the null value in last_name. Have
any idea or suggestion on how to workaround this situation.
Thank you.
--
Luis Magaña
Gnovus Networks & Software
www.gnovus.com
Tel. +52 (7) 4422425
[EMAIL PROTECTED]
Re: [HACKERS] unreachable block
Seems to be long gone in current sources. I think at one time the two if's probably tested different flags. You could dig through our CVS server if you want to know the history. regards, tom lane
[HACKERS] Bogosity in new unknown-type resolution code
With current sources I get: regression=# select 'foo' < 'bar'; ERROR: pg_atoi: error in "foo": can't parse "foo" I was expecting the system to resolve this as a text comparison, but it seems to have chosen int4 instead. This is, um, surprising behavior. regards, tom lane
Re: [HACKERS] Text concat problem
Luis Magaña wrote:
>
> Hi:
>
> Have this curious situation and would like some help from you:
>
> Create an employee table:
>
> CREATE TABLE employee(
>id_employee SERIAL PRIMARY KEY,
>sex CHAR(1) DEFAULT 'm' CHECK(sex = 'f' OR sex = 'm'),
>start_date DATE NOT NULL,
>charge VARCHAR(50) NOT NULL,
>last_name VARCHAR(50),
>first_name VARCHAR(50) NOT NULL,
>title VARCHAR(10) NOT NULL
> );
>
> then fill it with a few values:
>
> insert into employee(title,first_name,start_date,charge) values('Mr.
>X','Smith',date(now()),'None');
> insert into employee(title,first_name,start_date,charge) values('Mr.
>Y','Smith',date(now()),'None');
> insert into employee(title,first_name,start_date,charge) values('Mr.
>Z','Smith',date(now()),'None');
>
> so far there is no problem at all, the problem comes here:
>
> select title || ' ' || first_name || ' ' || last_name as fullname from employee;
>
>fullname
>
>
>
>
> (3 rows)
>
> Doesn't work , I'm thinking it is because of the null value in last_name. Have
>any idea or suggestion on how to workaround this situation.
Yup.. it's due to the null.. I believe that the coalesce function can
get you out of this... Speaking of which, why isn't it called NVL()?
http://www.postgresql.org/users-lounge/docs/7.0/user/functions.htm
Try this (untested):
select coalesce(title, ''::varchar) || ' ' || coalesce(first_name,
''::varchar) || ' ' || coalesce(last_name, ''::varchar) as fullname from
employee;
Re: [HACKERS] Text concat problem
Rod Taylor <[EMAIL PROTECTED]> writes: > I believe that the coalesce function can > get you out of this... Speaking of which, why isn't it called NVL()? Because the SQL92 standard calls it coalesce. regards, tom lane
Re: [HACKERS] Text concat problem
That would be an extreamly good reason then. I suppose I've fallen into the 'other' standard :( Tom Lane wrote: > > Rod Taylor <[EMAIL PROTECTED]> writes: > > I believe that the coalesce function can > > get you out of this... Speaking of which, why isn't it called NVL()? > > Because the SQL92 standard calls it coalesce. > > regards, tom lane
[HACKERS] Re: Horology regress test changed?
> I did, but the log didn't say anything about unfixed regression test > cases. If you're going to leave some platform-specific comparison > files un-updated, I think it'd be polite to warn people about that > explicitly... probably on pghackers, not just committers... *sigh* I'll probably always leave some platform-specific comparison files unupdated, and I would expect others to have to do that also. I apparently did not meet your expectations on this, but it is quite in line with our accepted practices. Sorry for the heart stoppage when you saw your regression tests suddenly failing... > I have updated horology-no-DST-before-1970.out, but that still leaves > us needing updates for horology-1947-PDT.out and > horology-solaris-1947.out. I guess that we have already heard from someone on one of those, and the others will come with time. Regards. - Thomas
AW: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
> I like that a lot. Solves the whole problem at a stroke, and even > adds some extra functionality (alternate templates). > > Do we need an actual enforcement mechanism for "don't modify > template0"? > I think we could live without that for now. If you're > worried about it, > one way would be to not allow connections of any sort to template0... > in fact template0 needn't be a real database at all, just a > $PGDATA/base > subdirectory with no pg_database entry. I like this "not really a database" idea. Might even be something for $libdir, no ? Then all that would be needed is a command that creates a database from this location instead of template1. Andreas
AW: [HACKERS] Unhappy thoughts about pg_dump and objects inherited from template1
> Just seems like we'd be forcing non-standard syntax on > ourselves when/if > CREATE DATABASE becomes CREATE SCHEMA; I do not think this will be the way. > I would assume that the two > statements would become synonymous? No, I think we need the schema below the database hierarchy. Thus you create a schema when already connected to a database. Andreas
Re: [HACKERS] Type resolution for operators
Peter Eisentraut <[EMAIL PROTECTED]> writes: > Thomas Lockhart writes: >> select int '1' = '01'; >> which, btw, returns 'true'. > Uh, how can an integer be equal to a character value? Where did the type > system go? Nowhere. This is the same behavior as that statement had in 7.0 (and many versions before, I believe): given "int4-constant operator unknown-constant", the unknown constant is preferentially resolved to int4. Now if you say select int '1' = text '01'; you should and do get ERROR: Unable to identify an operator '=' for types 'int4' and 'text' You will have to retype this query using an explicit cast But this change is *not* to rip out the concept of unknown-type constants entirely, only to fall back to treating them as text *after* all else fails. regards, tom lane
Re: [HACKERS] problems with configure
Peter Eisentraut <[EMAIL PROTECTED]> writes: >> Not sure what to do about this. It will clearly not do to define >> ACCEPT_TYPE_ARG3 as void. Perhaps we need a special case for >> Solaris 7: if we detect that accept() is declared with "void *", >> assume that socklen_t is the thing to use. Peter, any thoughts? > Perhaps we could, in case "void *" is discovered, run a similar deal with > bind() or setsockopt(), i.e., some socket function that takes a > non-pointer socklen_t (or whatever), in order to find out the true nature > of what's behind the "void *". Well, maybe. But is it worth the trouble? Hard to believe anyone else did the same thing. If socklen_t exists, it's presumably the right thing to use, so if we just hardwire "void -> socklen_t", I think it'd be OK. If we're wrong, we'll hear about it... regards, tom lane
