Re: [HACKERS] Header files installed for contrib modules?
On Sat, 23 Aug 2003 21:16:38 +0200 (CEST) Peter Eisentraut [EMAIL PROTECTED] said something like: Robert Creager writes: Just wondering if there is currently any mechanism in the contrib makefile hierarchy for installing header files into an appropriate directory. There isn't, because until now there was no need for it. But there is no reason that it couldn't be added. So would one of you fine hackers be willing to add this feature? If not, I'll have a go of it. Would this be best accomplished using a sub-directory which contains the header files to install, or a make variable containing the headers? Cheers, Rob -- 17:11:53 up 22 days, 9:53, 4 users, load average: 2.34, 2.18, 2.05 pgp0.pgp Description: PGP signature
Re: [HACKERS] Header files installed for contrib modules?
Robert Creager writes: So would one of you fine hackers be willing to add this feature? If not, I'll have a go of it. There isn't any contrib module that would use it, so why bother? Would this be best accomplished using a sub-directory which contains the header files to install, or a make variable containing the headers? The latter. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] LOCK.tag(figuring out granularity of lock)
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tupleId is still invalid. Finally if this is a tuple level lock (we currently never do this) then both the blockId and tupleId are set to valid specifications. is blockId same as tag.objId.blkno? what field in LOCK.tag is tupleId? thanks jenny _ Get MSN 8 and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] table-level and row-level locks.
A row lock is represented by storing the locking transaction's ID in xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. Where is 'xmax' found? is it at code level or on disk? thanks Jenny From: Tom Lane [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: [HACKERS] table-level and row-level locks. Date: Wed, 20 Aug 2003 14:45:23 -0400 Koichi Suzuki [EMAIL PROTECTED] writes: I need to know where such lock marks are stored in the source level. A row lock is represented by storing the locking transaction's ID in xmax and setting the HEAP_MARKED_FOR_UPDATE infomask bit. The bit is needed to distinguish this from the case where the transaction is deleting the tuple. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html _ Get MSN 8 and help protect your children with advanced parental controls. http://join.msn.com/?page=features/parental ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Collation rules and multi-lingual databases
Stephan Szabo [EMAIL PROTECTED] writes: On Fri, 22 Aug 2003, Tom Lane wrote: I'd go so far as to make it a critical section --- that ensures that any ERROR will be turned to FATAL, even if it's in a subroutine you call. I didn't know we could do that, could be handy, although the comments imply that it turns into PANIC which would force a complete restart. Right, my imprecision, it actually goes to PANIC. Then again, it's better than a corrupted database. Exactly. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Collation rules and multi-lingual databases
Greg Stark [EMAIL PROTECTED] writes: The glibc docs sample code suggests using 2x the original string length for the initial buffer. My testing showed that *always* triggered the exceptional case. A bit of experimentation lead to the 3x+4 which eliminates it except for 0 and 1 byte strings. I'm still tweaking it. But on another OS, or in a more complex collation locale maybe you would still trigger it a lot. On HPUX it seems you always need 4x. Also, *there are bugs* in some platforms' implementations of strxfrm, such that an undersized buffer may get overrun anyway. I had originally tried to optimize the buffer size like this in src/backend/utils/adt/selfuncs.c's use of strxfrm, and eventually was forced to give it up as hopeless. I strongly suggest using the same code now seen there: char *xfrmstr; size_txfrmlen; size_txfrmlen2; /* * Note: originally we guessed at a suitable output buffer size, * and only needed to call strxfrm twice if our guess was too * small. However, it seems that some versions of Solaris have * buggy strxfrm that can write past the specified buffer length * in that scenario. So, do it the dumb way for portability. * * Yet other systems (e.g., glibc) sometimes return a smaller value * from the second call than the first; thus the Assert must be = * not == as you'd expect. Can't any of these people program * their way out of a paper bag? */ xfrmlen = strxfrm(NULL, val, 0); xfrmstr = (char *) palloc(xfrmlen + 1); xfrmlen2 = strxfrm(xfrmstr, val, xfrmlen + 1); Assert(xfrmlen2 = xfrmlen); regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ambiguous sql states
Peter Eisentraut [EMAIL PROTECTED] writes: Dave Cramer writes: I'm working on identifying various errors in ecpg using sql state and one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a file which isn't found. This is returned in a number of places. Is it possible to get a set of file specific error codes? That error code if for undefined objects, not files that can't be found. Dave's correct, that's what we're currently using. I'm happy to change it if someone can suggest an appropriate SQLSTATE (even a category...) to use instead. I would however like to know why ecpg cares. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PostgreSQL 7.4 Beta 1 + SSL + Cygwin
Thomas, [I would have responded sooner, but I have been on vacation.] On Thu, Aug 21, 2003 at 11:10:05AM -0500, Thomas Swan wrote: On 8/8/2003 5:49 AM, Jason Tishler wrote: Is this just the --with-openssl option? Does it build cleanly under Cygwin? If so, would you like me to include this in the next Cygwin PostgreSQL release? 7.4beta1 would not compile under Cygwin with or without SSL. However, the CVS tip for 2003/08/20 did compile and run under Cygwin both with and without SSL. I had to adjust some path variables to include cygwin/usr/lib and cygwin/usr/lib/postgresql. postgresql was configured with ./configure --prefix=/usr --with-openssl make make install I used ipc-daemon2, and I had to use cygwin.dll v1.5.x. I will give CVS tip a ride and try to supply a patch. Thanks for the heads up. Jason -- PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers Fingerprint: 7A73 1405 7F2B E669 C19D 8784 1AFD E4CC ECF4 8EF6 ---(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] Which cursor-related warnings should be errors?
Since no one responded to the message below (posted on pgsql-sql), I made the change from warning to error in the indicated cases. Fetching from a non-existent cursor: peter=# FETCH ALL FROM non_existent; WARNING: portal non_existent does not exist FETCH 0 Closing a non-existent cursor: peter=# CLOSE non_existent; WARNING: portal non_existent does not exist CLOSE CURSOR Declaring a new cursor that uses a name already in use: peter=# BEGIN; BEGIN peter=# DECLARE foo CURSOR FOR SELECT 1; DECLARE CURSOR peter=# DECLARE foo CURSOR FOR SELECT 2; WARNING: Closing pre-existing portal foo DECLARE CURSOR So if anyone can come up with a reason that theses WARNING: messages should not be changed to errors, please speak up. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ambiguous sql states
Tom Lane writes: Dave's correct, that's what we're currently using. I'm happy to change it if someone can suggest an appropriate SQLSTATE (even a category...) to use instead. I had a private chat with Dave about this. It was my view that a missing file that is read by a backend COPY is indistinguishable from, say, a missing table or trigger, as far as recovery options by the client application are concerned. I would however like to know why ecpg cares. It doesn't. This is related to an Informix porting project, which apparently has a separate error code for its LOAD command. Why exactly that would affect our COPY isn't totally clear to me. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] ambiguous sql states
Tom, The reason it is of importance to me/ecpg is for informix compatibility. informix returns a unique errorcode for the copy operation when the file is not found. this isn't much of an argument from a postgres POV, however I still find the sqlstate to be ambiguous. Dave On Sun, 2003-08-24 at 16:46, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Dave Cramer writes: I'm working on identifying various errors in ecpg using sql state and one which is particularly ambiguous is ERRCODE_UNDEFINED_OBJECT for a file which isn't found. This is returned in a number of places. Is it possible to get a set of file specific error codes? That error code if for undefined objects, not files that can't be found. Dave's correct, that's what we're currently using. I'm happy to change it if someone can suggest an appropriate SQLSTATE (even a category...) to use instead. I would however like to know why ecpg cares. regards, tom lane -- Dave Cramer [EMAIL PROTECTED] fastcrypt ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ambiguous sql states
Peter Eisentraut [EMAIL PROTECTED] writes: I had a private chat with Dave about this. It was my view that a missing file that is read by a backend COPY is indistinguishable from, say, a missing table or trigger, as far as recovery options by the client application are concerned. Hm. One problem in this area is that a file-not-found error could be a user error (if the user-specified name in COPY or lo_import() or some such is not found). Or it could be a Postgres internal error (if a file internal to the database can't be found). I'm not sure it's real practical to distinguish these cases in the code, unfortunately --- unless people are excited enough about it to invent errcode_for_user_file_access() as distinct from errcode_for_file_access(). (Even if we wanted to do this, I'm unsure how far up the changes might need to propagate.) In either case, though, it is arguable that it's not appropriate to put it under the syntax error SQLSTATE category. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [SQL] SELECT IN Still Broken in 7.4b
Stephan Szabo [EMAIL PROTECTED] writes: Well, if you want to be safer, I guess you could (at runtime) decide that the table's gotten too big and fall back to the old method if you didn't entirely rip it out. I'm not sure if that'd be too ugly though, but it would mean that you wouldn't have to worry about it returning too many tuples. I did it this way --- it falls back to the old code if the TID hash table grows to exceed SortMem. Should be noticeably faster than the old code for reasonably-sized IN lists. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Single-file DBs WAS: Need concrete 'Why Postgres
Andrew Dunstan [EMAIL PROTECTED] writes: Is anyone seriously suggesting that postgres should support either raw devices or use some sort of virtual file system? If not, this whole discussion is way off topic. I have zero interest in actually doing it. However, it'd be nice if the existing storage manager API were clean enough that our response to this type of question could be sure, go implement it, and when you're done let us know what performance improvement you see. We've allowed the smgr API to degenerate over the years. CREATE/DROP DATABASE both bypass it, and the support for alternate database locations messes up the API pretty thoroughly (not that there's anything clean about that feature at all), and I think there are some other issues with specific commands bypassing the smgr abstractions. I think it would be reasonable to fix this as part of the tablespaces work that people keep wanting to do. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
