Re: [HACKERS] Missing ColLabel tokens
Tom Lane wrote: > > Peter Eisentraut <[EMAIL PROTECTED]> writes: > > I have noticed that AND and TRAILING could be made ColLabel's without > > further changes. Currently they are completely reserved. (This is > > especially odd given that OR is a ColLabel.) Would that be okay to > > change? Would BETWEEN a AND b still work ? --- Hannu
Re: [HACKERS] Please review TODO list
Tom Lane wrote: > > * Fix LIKE indexing optimization for non-ASCII locales > > I've applied a brute-force solution, which is not to do any LIKE > optimization in non-ASCII locales :-(. What is a non-ASCII locale ? Anything that is not LC_ALL=ASCII ? BTW, it would really help if we had a way to query for locale at runtime, like SELECT CURRENT_LOCALE(); How should one find out which locale we are in ? >From your comment above I assume that you know it ;) > This is not an ideal answer, > but perhaps the TODO item should read more like "Figure out how to > do LIKE indexing optimization in non-ASCII locales". I think that the cleanest solution should be to define our own locales that can be doctored to satisfy the LIKE optimisation requirements. We will probably need something like that in the future anyway as AFAIK SQL 9x requires ability to have locales applicable on field-to-field basis not just one per host. - Hannu
Re: [HACKERS] Re: [GENERAL] pg_dump return status..
At 20:50 4/01/01 -0500, Tom Lane wrote: > >Talk to Philip Warner about detecting output write failures. I think >this might be a lot easier in current sources than it would have been in >7.0.* or before; the actual I/O is more centralized, and I think you >could reasonably hope to check for write errors at just a couple of >places. There are a few places to check, but a lot less than before. Assuming I should just die on any failed write (which seems reasonable), how do I check for a failed write in a way that works on all Unixes? Is the following OK: - fwrite: ok if return value equals item count - fprintf: ok if return value > 0. - fputc: ok if != EOF 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] Re: [GENERAL] pg_dump return status..
Philip Warner <[EMAIL PROTECTED]> writes: > There are a few places to check, but a lot less than before. Assuming I > should just die on any failed write (which seems reasonable), Yes, I see no point in continuing after a write failure. Just print the strerror() message and exit. > how do I > check for a failed write in a way that works on all Unixes? Is the > following OK: > - fwrite: ok if return value equals item count > - fprintf: ok if return value > 0. > - fputc: ok if != EOF Probably fprintf() >= 0 --- according to my specs, it returns the number of chars emitted, or a negative value on error. The other two are correct. Don't forget to check for a successful fclose() too, since otherwise you won't notice a failure in dumping the last bufferload of data. I do not recall the success/failure return codes for the zlib calls, but I assume they check for write failure and reflect it back ... regards, tom lane
Re: [HACKERS] Well, we seem to be proof against cache-inval problemsnow
On Fri, 5 Jan 2001, Tom Lane wrote: > I just finished running the parallel regress tests with inval.c rigged > to flush the relcache and syscache at every available opportunity, > that is anytime we could recognize a shared-cache-inval message from > another backend (see diff below). This setup gives a whole new universe > of meaning to the word "slow" --- it took *three full days* to run the > standard "make check" procedure, including eighteen hours just to do the > "vacuum template1" part of initdb. I kid you not. But it worked. > Looks like the unexpected-cache-entry-drop class of problems are indeed > gone. Tom, I'm not sure how (or whether) this relates to "alter table" happening when someone else is doing a SELECT from table. Are you saying that it should work without any locking or I'm completely off base? -alex
Re: [HACKERS] Well, we seem to be proof against cache-inval problems now
Alex Pilosov <[EMAIL PROTECTED]> writes: > Tom, I'm not sure how (or whether) this relates to "alter table" happening > when someone else is doing a SELECT from table. The ALTER will wait for the SELECT to finish. That's not related to the internal cache problem that I was worried about. regards, tom lane
[HACKERS] Recursion and SPI
Does the SPI interface support recursion? That is, can a function use SPI to make a query which involves calling another function which uses SPI? The documentation suggests not, saying that if a function which uses SPI calls another function which uses SPI, it won't work, and calling that ``bad practice.'' However, in spi.c I note that there is a stack, and a variable _SPI_curid, and the undocumented functions SPI_push and SPI_pop. If that works to support recursion, then why does the documentation recommend against it? Are there any restrictions on when SPI_connect may be called? The executor can presumably call a function at any time during the execution of a plan if the function is used in a WHERE clause. If that function turns around and calls the executor via SPI, are there any possibilities for deadlock? Ian
RE: [HACKERS] Recursion and SPI
> Does the SPI interface support recursion? That is, can a function > use SPI to make a query which involves calling another function which > uses SPI? >From http://www.postgresql.org/docs/programmer/spi.htm : "SPI procedures are always called by some (upper) Executor and the SPI manager uses the Executor to run your queries. Other procedures may be called by the ^^ Executor running queries from your procedure." > The documentation suggests not, saying that if a function which uses > SPI calls another function which uses SPI, it won't work, and calling > that ``bad practice.'' >From http://www.postgresql.org/docs/programmer/spi-spiconnect.htm : "You may get SPI_ERROR_CONNECT error if SPI_connect is called from an already connected procedure - e.g. if you *directly call* one procedure from another ^^^ connected one. Actually, while the child procedure will be able to use SPI, your parent procedure will not be able to continue to use SPI after the child returns (if SPI_finish is called by the child). It's bad practice." But you are able to run queries which call SPI functions. > However, in spi.c I note that there is a stack, and a variable > _SPI_curid, and the undocumented functions SPI_push and SPI_pop. > If that works to support recursion, then why does the documentation > recommend against it? Afair, there were no SPI_push & SPI_pop originally. Someone added them but forgot to document. Vadim
Re: [HACKERS] pg_dump return status..
[EMAIL PROTECTED] (Nathan Myers) writes: > An fprintf returning 0 is a suspicious event; it's easy to imagine > cases where it makes sense, but I don't think I have ever coded one. > Probably >N (where N is the smallest reasonable output, defaulting > to 1) may be a better test in real code. On older systems fprintf returns 0 on success and EOF on failure. > As I recall, on SunOS 4 the printf()s don't return the number of > characters written. I don't recall what they do instead, and have > no access to such machines any more. Probably 0/EOF. sprintf on SunOS returns its first argument. Ian
[HACKERS] bootstrap tables
Hey hackers - I'm having a bit of trouble with creating a new bootstrap system table. That is, one that is created during initdb via 'create bootstrap' in the PKI file. I realize that for this sort of system table, I need to add tuples via bootstrap DATA statements to pg_class.h, pg_attribute.h, and pg_type.h. Everything seems to work: I get the right output from initdb -d, based on analogy with all the other bootstrap tables, but the file never gets created, as if initial data for my new table never gets commited. If I add a bootstrap index on it (by hand editting the template1.bki file), I get the file, but it's empty. Everything seems to be set up right, though: I can insert data into the table once it's there. I've tried defining the structures and hand building a reldesc, in relcache.c, like the other bootstrap system tables, but that had no effect. One difference between my new table and the other system tables, perhaps, is that there is no code using the table: perhaps something with how mdopen will substitute for mdcreate, and create files while under bootstrapmode? So, is there extra trick I'm missing to getting the final commit done for an initdb bootstrap relation? If this somewhat abstract description of my problem doesn't ring a bell for anyone, I'll go ahead and generate a patch and ask for comment on it later. (I wanted to leave out details because I don't really want to discuss implementation of the specific feature until I've tried a reference implementation, myself) Ross
[HACKERS] Beta2 ... ?
Anyone have anything outstanding that prevents me rolling a Beta2 and
announcing it this weekend? Tom? Vadim? Peter?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
RE: [HACKERS] Beta2 ... ?
> Anyone have anything outstanding that prevents me rolling a Beta2 and > announcing it this weekend? Tom? Vadim? Peter? I'll commit small changes to xlog.c today. Vadim
Re: [HACKERS] Beta2 ... ?
The Hermit Hacker <[EMAIL PROTECTED]> writes: > Anyone have anything outstanding that prevents me rolling a Beta2 and > announcing it this weekend? Tom? Vadim? Peter? Wrap it up, I'd say. I don't have anything pending that seems worth holding up beta2 for. regards, tom lane
Re: [HACKERS] Recursion and SPI
Ian Lance Taylor <[EMAIL PROTECTED]> writes: > Does the SPI interface support recursion? That is, can a function > use SPI to make a query which involves calling another function which > uses SPI? Looks to me like it should work. > The documentation suggests not, saying that if a function which uses > SPI calls another function which uses SPI, it won't work, and calling > that ``bad practice.'' The documentation could be out of date. Why don't you test it out and let us know? regards, tom lane
[HACKERS] Re: Beta2 ... ?
> The Hermit Hacker <[EMAIL PROTECTED]> writes: > > Anyone have anything outstanding that prevents me rolling a Beta2 and > > announcing it this weekend? Tom? Vadim? Peter? > > Wrap it up, I'd say. I don't have anything pending that seems worth > holding up beta2 for. Will RPM's be made availiable for this beta release? Mike
Re: [HACKERS] pg_dump return status..
>> An fprintf returning 0 is a suspicious event; it's easy to imagine >> cases where it makes sense, but I don't think I have ever coded one. >> Probably > N (where N is the smallest reasonable output, defaulting >> to 1) may be a better test in real code. > On older systems fprintf returns 0 on success and EOF on failure. The books I have all recommend testing for "a negative return value" to detect printf errors. The C standard also specifies "a negative value" for errors --- it is not guaranteed that that value is EOF. regards, tom lane
Re: [HACKERS] bootstrap tables
"Ross J. Reedstrom" <[EMAIL PROTECTED]> writes: > One difference between my new table and the other system tables, > perhaps, is that there is no code using the table: perhaps something > with how mdopen will substitute for mdcreate, and create files while > under bootstrapmode? I suspect that's got something to do with it. The initialization sequence is pretty haphazard in this area; some of the core tables are physically created by mdopen's that occur before the associated 'create' command from the BKI script, because the table is actually referenced by code that executes before it's "created". Others are not, and come into being during the 'create' the way you'd expect. Still, it sure looks like 'create bootstrap' should cause mdcreate() to be called, so I'm not sure why you'd see the file not get created at all. Have you tried tracing through it with a debugger? Do you really need the thing to be a bootstrap table, and not a plain system table? regards, tom lane
Re: [HACKERS] Re: Beta2 ... ?
mike wrote: >Tom Lane Wrote: > > Wrap it up, I'd say. I don't have anything pending that seems worth > > holding up beta2 for. > Will RPM's be made availiable for this beta release? I intend to do so, but it will be a few days to a week after the tarball release. I am inclined to wait until a Release Candidate, if we have one this go around, is available before releasing RPM's, but my mind can be changed :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Beta2 ... ?
Lamar Owen <[EMAIL PROTECTED]> writes: > I am inclined to wait until a Release Candidate, if we have one this go > around, is available before releasing RPM's, but my mind can be > changed :-) Please do make beta RPMs available. Seems to me that there's a fair-size population of potential beta testers that we're shutting out of the process if we don't put out RPMs. Losing available beta testing work is not a good project management practice ... regards, tom lane
Re: [HACKERS] Re: Beta2 ... ?
Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > I am inclined to wait until a Release Candidate, if we have one this go > > around, is available before releasing RPM's, but my mind can be > > changed :-) > Please do make beta RPMs available. Seems to me that there's a > fair-size population of potential beta testers that we're shutting > out of the process if we don't put out RPMs. Losing available beta > testing work is not a good project management practice ... Ok, consider my mind changed. :-). My only concerns were, due to some feedback I have gotten, is that people would treat the RPM release as _productions_ rather than beta -- but maybe I'm just being paranoid. More than likely I'm being paranoid. Look for RPM's in a few days, then. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Re: [HACKERS] Re: Beta2 ... ?
Lamar Owen <[EMAIL PROTECTED]> writes: > Ok, consider my mind changed. :-). My only concerns were, due to some > feedback I have gotten, is that people would treat the RPM release as > _productions_ rather than beta -- but maybe I'm just being paranoid. As long as the RPMs are clearly marked beta, I don't have a lot of sympathy for anyone who thinks beta == production. regards, tom lane
Re: [HACKERS] Isn't init_irels() dangerous ?
Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes: > It seems that init_irels() should be called after > InitializeTransactionSystem() was called. > >> > >> Can we just swap the order of the RelationCacheInitialize() and > >> InitializeTransactionSystem() calls in InitPostgres? If that > >> works, I'd have no objection. > > > It doesn't work. InitializeTransactionSystem() requires > > pg_log/pg_variable relations which are already built in > > RelationCacheInitialize(). > > OK. Second proposal: do the init_irels() call in > RelationCacheInitializePhase2(). I've just looked through the > other stuff that's done in between, and I don't think any of it > needs valid relcache entries. > Oops, I neglected to reply "agreed", sorry. It would be much safer for init_irels() to be called in a proper transaction than the current implementation. Regards. Hiroshi Inoue
Re: [HACKERS] Isn't init_irels() dangerous ?
Hiroshi Inoue <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> OK. Second proposal: do the init_irels() call in >> RelationCacheInitializePhase2(). I've just looked through the >> other stuff that's done in between, and I don't think any of it >> needs valid relcache entries. > Oops, I neglected to reply "agreed", sorry. > It would be much safer for init_irels() to be called > in a proper transaction than the current implementation. Fine. Were you going to do it, or do you want me to? regards, tom lane
Re: [HACKERS] bootstrap tables
On Fri, Jan 05, 2001 at 06:25:38PM -0500, Tom Lane wrote: > > Still, it sure looks like 'create bootstrap' should cause mdcreate() > to be called, so I'm not sure why you'd see the file not get created > at all. Have you tried tracing through it with a debugger? > > Do you really need the thing to be a bootstrap table, and not a plain > system table? Yup, 'cause it's going to store the schema info, including the system schema. I forsee it needing to be accessed immediately during bootstrap. I was fighting with the debugger last night, and decided "I should ask, just to be sure I'm not missing something obvious..." I'll keep on that way, then. Ross
Re: [HACKERS] Isn't init_irels() dangerous ?
Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> OK. Second proposal: do the init_irels() call in > >> RelationCacheInitializePhase2(). I've just looked through the > >> other stuff that's done in between, and I don't think any of it > >> needs valid relcache entries. > > > Oops, I neglected to reply "agreed", sorry. > > It would be much safer for init_irels() to be called > > in a proper transaction than the current implementation. > > Fine. Were you going to do it, or do you want me to? > It would only need to change a few lines. OK, I will do it. Regards. Hiroshi Inoue
Re: [HACKERS] bootstrap tables
Ross J. Reedstrom writes: > > Do you really need the thing to be a bootstrap table, and not a plain > > system table? > > Yup, 'cause it's going to store the schema info, including the system > schema. I forsee it needing to be accessed immediately during bootstrap. Does "schema info" mean SQL schemas or merely additional schema information along the lines of pg_class, etc.? -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
Re: [HACKERS] Beta2 ... ?
The Hermit Hacker writes: > Anyone have anything outstanding that prevents me rolling a Beta2 and > announcing it this weekend? Tom? Vadim? Peter? I'll commit the grammar changes we discussed yesterday, plus some new documentation that goes with it, tomorrow. I'm also going to send you a patch for mk-release so that the right documentation files are shipped this time. -- Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
[HACKERS] replacing shmem
Excuse my ignorance. Is there a way to replace the shmem and sem (ipc.c) to use files. In this way we can have a sort of a parallel server using GFS. 1.Starting a postmaster on ONE machine creates the shared structures, 2.then start on other cluster-machines, the variuos machines share the same datafiles and shared memory (on-file) structures 3.cliets connects (for example) round-robin to the clustered-postgres-nodes. 4.a problem is proper destroy and create of the shared structures thanks, valter >From http://sistina.com/gfs/: he Global File System (GFS [now in beta4]) is a shared disk cluster file system for Linux. GFS supports journaling and recovery from client failures. GFS cluster nodes physically share the same storage by means of Fibre Channel or shared SCSI devices. The file system appears to be local on each node and GFS synchronizes file access across the cluster. GFS is fully symmetric, that is, all nodes are equal and there is no server which may be a bottleneck or single point of failure. GFS uses read and write caching while maintaining full UNIX file system semantics. _ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: [HACKERS] replacing shmem
"Valter Mazzola" <[EMAIL PROTECTED]> writes: > Is there a way to replace the shmem and sem (ipc.c) to use files. In this > way we can have a sort of a parallel server using GFS. Unless GFS offers access bandwidth approaching main memory speeds, this idea is sheer folly :-( regards, tom lane
RE: [HACKERS] replacing shmem
I suppose it won't help here to suggest using memory mapped I/O, because someone will complain their platform doesn't support it. I wonder though if there could be an optional patch to use mmap for all disk I/O, not just shared memory! - Andrew
Re: [HACKERS] replacing shmem
On Sat, 6 Jan 2001, Valter Mazzola wrote: > Excuse my ignorance. > Is there a way to replace the shmem and sem (ipc.c) to use files. In this > way we can have a sort of a parallel server using GFS. ... Besides the slowness of file IO, it also doesn't make sense to have a shared memory area for all nodes. Not all pages in the shared memory area are dirty pages, and it make no sense for all nodes to share the same read cache, when they could have individual read caches. Besides, it is more scalable. Either way, an application level cluster employing two-phase commit is likely going to be a lot more useful. FrontBase (http://www.frontbase.com) supports this now, and on more platforms than GFS supports. Besides, GFS is rather alpha right now. Tom
