Re: [HACKERS] I cant find it or I'm just lazy ?
On Tuesday 25 February 2003 18:57, Jeroen T. Vermeulen wrote: > On Tue, Feb 25, 2003 at 07:34:12PM +, Darko Prenosil wrote: > > Unfortunately it is application written in QT library that should work on > > Windows too, but I'll take a look, I'm sure I can learn something from it > > ! > > Well, libpqxx also runs on Windows but it takes a decent compiler (e.g. > Visual C++ 6.0 isn't quite good enough) and some manual labour to set up > your own project file. > I got the sources yesterday. Thank you ! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] numeric datataypes as seperate library
Did anyone ever think about creating a library that is able to handle our numeric datatype? I'm currently thinking about adding this datatype among others to the ones know to ecpg so no one is forced to convert them or work on the strings. On the other hand I'm not sure if anyone's interested in this feature as you could always keep the numbers as strings and let the database do all calculation stuff. But then you cannot use the datatype in C. And of course I don't like the idea of linking in the GPLed GNU MP library on default as this would create licensing problems. Michael -- Michael Meskes Email: [EMAIL PROTECTED] ICQ: 179140304 Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] numeric datataypes as seperate library
Michael Meskes kirjutas K, 26.02.2003 kell 13:00: > Did anyone ever think about creating a library that is able to handle > our numeric datatype? I'm currently thinking about adding this datatype > among others to the ones know to ecpg so no one is forced to convert > them or work on the strings. On the other hand I'm not sure if anyone's > interested in this feature as you could always keep the numbers as > strings and let the database do all calculation stuff. But then you > cannot use the datatype in C. I see at least 3 datatypes that would be nice to have libraries for using in client programs - NUMERIC, VARBIT and our DATE/TIME/TIMESTAMP. --- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] autocommit off mode, how does it work?
Sorry for the noise, my instance of postgres was broken. Dave On Wed, 2003-02-26 at 02:19, Dave Cramer wrote: > what cvs version are you working with? > > Dave > On Wed, 2003-02-26 at 01:11, Tom Lane wrote: > > Dave Cramer <[EMAIL PROTECTED]> writes: > > > Can someone point me to the documentation for the new autocommit mode > > > behaviour, I must be doing something wrong > > > > Must be :-(. I repeated your example as best I could, and it behaved > > as expected. > > > > << session 1 >> > > > > regression=# set autocommit=off; > > SET > > regression=# begin; > > BEGIN > > regression=# create table foo (f1 int); > > CREATE TABLE > > regression=# insert into foo values (1); > > INSERT 933631 1 > > regression=# end; > > COMMIT > > regression=# > > > > << session 2 >> > > > > regression=# \d foo > > Table "public.foo" > > Column | Type | Modifiers > > +-+--- > > f1 | integer | > > > > regression=# select * from foo; > > f1 > > > > 1 > > (1 row) > > > > > > regards, tom lane -- Dave Cramer <[EMAIL PROTECTED]> Cramer Consulting ---(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] Thread safe ecpg
On Tue, Feb 25, 2003 at 03:58:51PM +, Lee Kindness wrote: > Okay guys, i've been a bit tight of time recently to move forward on > this, but I plan to do a small amount of work on the patches to clean > them up so they can be merged into the sources. Thanks a lot for your work Lee. Michael -- Michael Meskes Email: [EMAIL PROTECTED] ICQ: 179140304 Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] I cant find it or I'm just lazy ?
On Wed, Feb 26, 2003 at 09:44:14AM +, Darko Prenosil wrote: > > I got the sources yesterday. Thank you ! Let me know whether everything works for you. There's also a mailing list on pqxx.tk if you need it. Jeroen ---(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] autocommit off mode, how does it work?
Dave Cramer <[EMAIL PROTECTED]> writes: > what cvs version are you working with? CVS tip in either HEAD or REL7_3_STABLE branches works for me. There are some known issues with autocommit getting turned off as part of a multi-statement command that's sent to tbe backend in a single query string. But your example in psql wouldn't have triggered that problem. regards, tom lane ---(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] CHECK constraints in pg_dump
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes: >> Why would there be any speed advantage? > Is it not faster to add it when all the data is there, rather than > evaluating it as each row is inserted, like indexes? I don't see why. There are good algorithmic reasons why bulk-loading an index is faster than retail insertions --- mainly that btree goes out of its way to make it so, with a special code path. But I see no reason why checking a constraint expression is going to be any faster as a post-pass than when done while loading the data. If anything, I'd guess it to be slower because you have to re-read the table. regards, tom lane ---(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
[HACKERS] Can pessimistic locking be emulated?
I am trying to emulate a pessimistic locking system you would find in an old school database file system, for example cobol. Generally, when a cobol program tries to read a record that is locked by somebody else, the read fails and either a message is displayed by the user or a error handling procedure is executed. I would like to emulate this behavior for legacy code while using mvcc for newer procedures I write. 4 questions: 1. Can you query if a tuple is locked by another transaction (the documentation unclearly suggests this can't be done via the pg_lock view) before executing select for update...? 2. If so, is this reasonable efficient to do, i.e. straight join on oid/xid? 3. If so, is this possible to query without a race condition regarding the lock status? 4. If so, is this likely to be possible in future versions of postgres without non-trivial changes? In other words, if User B attempts to select for update a record that user A has selected for update, it would be nice if User B's query would fail with a NOTICE to act upon. Thanks in advance, Merlin ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] numeric datataypes as seperate library
On Wed, 2003-02-26 at 06:00, Michael Meskes wrote: > And of course I don't like the idea of linking in the GPLed > GNU MP library on default as this would create licensing problems. Actually, GNU MP is released under the LGPL. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] Free-space-map management thoughts
I've been thinking about improving the algorithm that the free space map (FSM) uses to decide what to store when it's not got enough shared memory to keep track of everything. The present design uses a dynamically adjusted threshold for each relation, throwing away pages whose free space amount is less than the threshold. This unfortunately seems not to work as well as I'd hoped when I wrote it :-(. In particular it cannot cope effectively with situations where many pages have exactly the same amount of free space --- it degenerates to all-or-nothing. This problem has become acute now that btree indexes use the FSM to keep track of free pages: by definition, all those pages have exactly the same amount of free space. I had some off-list discussions last fall with Steve Marshall, who was trying to improve the thresholding algorithm to work better, but what he ended up with seemed to me to have a lot of ad-hoc logic and magic numbers in it. So I wasn't real satisfied with that. This is a request for comments about the following redesign: 1. Continue to keep track of the average request size seen by GetPageWithFreeSpace(), but make it a pure request-size average; don't muck it up with thresholding adjustments. Add an entry point to make the average request size for a relation available to callers. VACUUM can use this as a starting point for its internal decisions about which pages are even worth reporting to the FSM. 2. Eliminate "retail" addition of FSM entries. RecordFreeSpace() isn't being used anyway, and we can restrict RecordAndGetPageWithFreeSpace() to only update existing entries not make new ones. Only wholesale replacement of a relation's FSM data, via MultiRecordFreeSpace(), need be supported as a way of adding page entries to FSM. 3. With the above two changes, the numbers of pages passed to the FSM by MultiRecordFreeSpace() calls become useful statistics in themselves. We can keep track of those numbers in the FSM's per-relation statistics independently of the number of pages actually stored in FSM. 4. In particular, the sum of the MultiRecordFreeSpace (henceforth MRFS) page counts gives us the total number of pages we would *like* to keep track of; the ratio of this number to the actual allocated max_fsm_pages is our "oversubscription ratio". (One thing we can do in passing is make VACUUM VERBOSE print these numbers, so that people finally have some intelligent way of adjusting their FSM parameters.) 5. When FSM space is oversubscribed, we can divide each relation's MRFS requested page count by the oversubscription ratio to arrive at an exact target page count for each relation. This page count is stable as long as the space-allocation picture isn't changing much, which is a big improvement over the existing inherently history-dependent thresholding algorithm. 6. A reasonably effective way to reduce a relation's stored page list to the target (or select out the pages to actually remember from an MRFS request) is as follows: * Prescan the page data to compute a histogram of available-space values, with maybe 32 bins. * Find the histogram bin whose inclusion would make us exceed the target page count. Set thresholdL = its lower edge value, thresholdU = its upper edge value, and bincount = target page count minus sum of counts in higher histogram bins. * Scan pages. Keep all those >= thresholdU; drop those < thresholdL; of the pages between the thresholds, keep the first bincount entries. This approach will drop some pages with more free space while keeping some with less --- but the difference between those dropped and those kept is no more than the bin width. This algorithm still requires some heuristics around the edges --- in particular, in step 5 we probably don't want a purely linear division of available space, but should allow some minimum number of pages for each relation before divvying up the leftover space. But it doesn't seem to need nearly as much ad-hoc tuning as the thresholding approach does. One thing this does not do that the original code tries to do is give preference to more-heavily-used relations --- in this approach, each table's share of FSM is determined only by its number of pages with free space. However, one could argue that that is an indirect measure of activity, since it certainly reflects past deletion/update activity. So it may be okay not to give any explicit preference to active tables. Comments anyone? regards, tom lane PS: Another idea I'm toying with is to dump out the FSM contents at postmaster shutdown and reload them at restart, so that the FSM doesn't have to start from ground zero on every restart cycle. But that's independent of the management algorithm... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Hey! I thought this was fixed in 7.2.4
PgPeople: I thought this bug was fixed in 7.2.4: DBD::PgPP::st execute failed: ERROR: Parent tuple was not found Process Failed: ERROR: Parent tuple was not found from step VACUUM FULL ANALYZE version - PostgreSQL 7.2.4 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.2 20020903 (Red Hat Linux 8.0 3.2-7) (1 row) (a second VACUUM FULL ANALYZE succeeded) -- Josh Berkus [EMAIL PROTECTED] Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] ecpg in REL7_3_2
I'm trying to compile a co of REL_7_3_2 for my laptop (initially a suse 7.3 install) and it fails w/ this from bison: make -C preproc all make[1]: Entering directory `.../pgsql-server-7.3.2/src/interfaces/ecpg/preproc' bison -y -d preproc.y preproc.y:5560: fatal error: maximum table size (32767) exceeded make[1]: *** [preproc.h] Error 1 make[1]: Leaving directory `.../pgsql-server-7.3.2/src/interfaces/ecpg/preproc' I also tried using the HEAD version of preproc.y and that gave the same error, but at line 5559. Bison is 1.28. Yacc (version 91.7.30) gives a similar error. Is this a know issue? Is it a bug in the installed versions of bison and yacc? (It has been over a decade since I last wrote a bison/yacc file, and I suspect I've forgotten most everything I knew about them.) My workwaround for now was just to remove ecpg from interfaces/Makefile -JimC ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Hey! I thought this was fixed in 7.2.4
Josh Berkus <[EMAIL PROTECTED]> writes: > I thought this bug was fixed in 7.2.4: > DBD::PgPP::st execute failed: ERROR: Parent tuple was not found > (a second VACUUM FULL ANALYZE succeeded) IIRC, for 7.2.* we only attempted to fix the variants that resulted in hard (repeatable) errors. You've got the soft variant there. The 7.3 sources explain that in fact this condition isn't an error, but is an expected case in some situations (the example given is where a row has been updated twice in the same transaction). So the fix is to downgrade the error to a DEBUG log message and adjust the code to let it keep going rather than erroring out. This change struck me as too risky to put into 7.2.* for a nonfatal condition, though. That part of VACUUM is a real mare's nest, and I dislike messing with it in production branches. (I suppose that at this point we might consider the additional mods proven by 7.3 field experience, and could consider back-porting them if there are any further 7.2 releases.) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Free-space-map management thoughts
> PS: Another idea I'm toying with is to dump out the FSM contents at > postmaster shutdown and reload them at restart, so that the FSM doesn't > have to start from ground zero on every restart cycle. But that's > independent of the management algorithm... Correct me if I'm wrong, but the FSM is only populated by vacuum, so there is no FSM information for any given table / database until it's vacuumed, in a long running production enviornment this may not be that important, but it could result in a large increase in file size any time the database is restarted. I think this change, while independent of your proposal, is important. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] ecpg in REL7_3_2
--On Wednesday, February 26, 2003 17:33:23 -0500 "James H. Cloos Jr." <[EMAIL PROTECTED]> wrote: I'm trying to compile a co of REL_7_3_2 for my laptop (initially a suse 7.3 install) and it fails w/ this from bison: make -C preproc all make[1]: Entering directory `.../pgsql-server-7.3.2/src/interfaces/ecpg/preproc' bison -y -d preproc.y preproc.y:5560: fatal error: maximum table size (32767) exceeded make[1]: *** [preproc.h] Error 1 make[1]: Leaving directory `.../pgsql-server-7.3.2/src/interfaces/ecpg/preproc' I also tried using the HEAD version of preproc.y and that gave the same error, but at line 5559. Bison is 1.28. Yacc (version 91.7.30) gives a similar error. you need Bison 1.50 or later... -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Free-space-map management thoughts
"Matthew T. O'Connor" <[EMAIL PROTECTED]> writes: > Correct me if I'm wrong, but the FSM is only populated by vacuum, so there > is no FSM information for any given table / database until it's vacuumed, in > a long running production enviornment this may not be that important, but it > could result in a large increase in file size any time the database is > restarted. Right. The original assumption was that people don't restart production servers, so startup-transient behavior isn't very important. But that's obviously not a great assumption. It seemed expedient at the time (partly because I wasn't sure FSM would fly at all) --- but now it's time to go back and fill in the holes. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html