Re: [HACKERS] Analysis of ganged WAL writes
[EMAIL PROTECTED] (Tom Lane) writes: [snip] > > So this does seem to be a nice win, and unless I hear objections > I will apply it ... > It does indeed look like a great improvement, so is the fix going to be merged to the 7.3 branch or is it too late for that? _ Mats Lofkvist [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Analysis of ganged WAL writes
Mats Lofkvist <[EMAIL PROTECTED]> writes: > It does indeed look like a great improvement, so is the fix > going to be merged to the 7.3 branch or is it too late for that? Yes, been there done that ... regards, tom lane ---(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] Postgresql and multithreading
Tom Lane wrote: > Greg Copeland <[EMAIL PROTECTED]> writes: > > On Thu, 2002-10-17 at 22:20, Tom Lane wrote: > >> Simple: respond to 'em all with a one-line answer: "convince us why we > >> should use it". The burden of proof always seems to fall on the wrong > >> end in these discussions. > > > ... Now, it seems, that > > people don't want to answer questions at all as it's bothering the > > developers. > > Not at all. But rehashing issues that have been talked out repeatedly > is starting to bug some of us ;-). Perhaps the correct "standard > answer" is more like "this has been discussed before, please read the > list archives". I need to add something to the developers FAQ on this. I will do it soon. -- 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 4: Don't 'kill -9' the postmaster
[HACKERS] ECPG and bison
Could anyone please tell me if we found a solution? It seems I missed any discussion or whatsoever. The only things I know is that postgresql.org still has bison 1.35 installed and 7.3 release is nearing. Michael -- Michael Meskes [EMAIL PROTECTED] 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
Antw: Re: [HACKERS] Postgresql and multithreading
Marc, not only the global variables are a problem. PostgreSQL doesn't clean up all the memory before a process terminates and you must deal with signals between threads. I've modified PostgreSQL that it is completely thread based and nearly clean with allocating/deallocating memory and I'm using signals between threads. I've written the code that it's easy to combine the changes with new releases of PostgreSQL but it has some problems that require a decrease of the number of global variables. This is very hard if you don't want to drift away from the main sourcecode of PostgreSQL. Actually I have a table that holds all the globals that needs to be addressed and I can tell you that there are a lot of global variables. However. I've tried to give the changes with the memory freeing back to the main source tree but my feeling was that they don't like it because it doesn't matter on UNIX if you're only process based. The same with several tools like PSQL. After this I wanted to look closer at the global variables. If this may change in the future you would be very happy if you don't have to search for unreleased memory because it is solved. I'm still VERY interested in giving those changes back to the community, but i think that my changes are still not wanted. Another problem I have is that the build tools i'm using are not GNU and the project file is different in this case. The developers from PostgreSQL don't want this too. Currently i'm working on a project file that uses GNU make but i'm not very happy with this because it is dramatically slower compared to the Metrowerks Tools. With Codewarrior I can build PostgreSQL in around 2 Minutes with all libraires and so on and GNU make needs much much longer. But I still hope that I'll find a way how I can handle all this. PostgreSQL itslef is running very good with "only threads" and the database itself is a VERY GOOD product. In the future I'll make some tests to find out information about the performance and how threads affect the performance on Linux. I'm also working on several additions to PostgreSQL for remote realtime Monitoring and configuration, LDAP authentication and more. Ulrich >>> "Marc G. Fournier" <[EMAIL PROTECTED]> 18.10.2002 05:21:59 >>> On Wed, 16 Oct 2002, Anuradha Ratnaweera wrote: > On Wed, Oct 16, 2002 at 01:25:23AM -0400, Bruce Momjian wrote: > > Anuradha Ratnaweera wrote: > > > > > ... what I want to know is whether multithreading is likely to get > > > into in postgresql, say somewhere in 8.x, or even in 9.x? > > > > It may be optional some day, most likely for Win32 at first, but we see > > little value to it on most other platforms; of course, we may be wrong. > > In that case, I wonder if it is worth folking a new project to add > threading support to the backend? Of course, keeping in sync with the > original would be lot of work. Actually, if you go through the archives, there has been talk about what would have to be done to the main source tree towards getting threading included ... as well as a lengthy discussion about the steps involved. the first and foremost issue that needs to be addressed is cleaning up the global variables that are used throughout ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html -- This e-mail is virus scanned Diese e-mail ist virusgeprueft ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] optimizer question
Hi, I was just approached with an optimizer question I cannot answer. Does our optimizer know how expensive different comparisons are? That is can it do something like: If there are different comparisons in a where clause check the ints first, then the strings, then everything with regexp, or like clauses etc. and finally function calls at last, because in most cases a function call is the most expensive one. Okay, we may argue whether a regexp is more expensive than a function, but you get the idea. Are we able to get that logic in where clauses where no index is defined? I just tried a query that given the order in the where clause either takes a few seconds or forever. Well, I killed the query after quite some time. Michael -- Michael Meskes [EMAIL PROTECTED] 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] optimizer question
Michael Meskes <[EMAIL PROTECTED]> writes: > I was just approached with an optimizer question I cannot answer. Does > our optimizer know how expensive different comparisons are? It does not, because there's noplace it could look to find the info. > If there are different comparisons in a where clause check the ints > first, then the strings, then everything with regexp, or like clauses > etc. and finally function calls at last, because in most cases a > function call is the most expensive one. Unfortunately, these all look like function calls to the optimizer. I have played with the notion of forcing subquery-based WHERE clauses to the end of the list, but that's about all that we could easily manage without great leaps of assumptions... regards, tom lane ---(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] Postgres Windows Native Port
Michael, Please post instead of sending private email. On Fri, Oct 18, 2002 at 12:08:02PM +0200, Michael Steiner wrote: > FAQ says: "A native port to MS Win NT/2000/XP is currently being worked > on." > > => When is it expected to be available as a stable release? I don't know. > Will it be based on cygwin dll's? No. > Will the reliability and performance be comparable to the unix-version? I don't know. > Will it be free for commercial use? I presume so. Maybe others on the CC'd lists can answer your questions better. Jason ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] PL/Perl and Perl 5.8
Peter Eisentraut <[EMAIL PROTECTED]> writes: > The HAS_CRYPT_R is true because the function is available even without the > prototype, but the struct is not. A plain bug in Perl's configury > mechanism. Yeah, that's true. The question is whether it's worth working around the bug. IMHO, yes -- but what do other people think? -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] clusterdb has poor error recovery
$ ./clusterdb psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? psql: could not connect to server: No such file or directory Is the server running locally and accepting connections on Unix domain socket "/tmp/.s.PGSQL.5432"? clusterdb: While clustering peter, the following failed: $ This could probably handled a little more gracefully. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] compile error in CVS HEAD
I see the following error with the current CVS code: make[3]: Entering directory `/home/nconway/pgsql/src/backend/commands' [ ... ] gcc -O2 -DLINUX_PROFILE -g -pg -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o copy.o copy.c copy.c: In function `DoCopy': copy.c:425: `errno' undeclared (first use in this function) copy.c:425: (Each undeclared identifier is reported only once copy.c:425: for each function it appears in.) make[3]: *** [copy.o] Error 1 Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] compile error in CVS HEAD
Neil Conway <[EMAIL PROTECTED]> writes: > I see the following error with the current CVS code: > copy.c:425: `errno' undeclared (first use in this function) Hmm. Needs a "#include " seemingly; but surely that error has been there awhile? (light dawns...) I'll bet it was masked by all the bogus "extern int errno" declarations that we had till this afternoon. I didn't see the failure here, because HPUX's header set seems to include in some pretty basic place. Anywhere else failing for you? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] autocommit vs TRUNCATE et al
There are a number of statements, such as TRUNCATE TABLE, that refuse to run in a transaction block because they perform actions that can't be rolled back later. These statements currently do not look at autocommit, which means that if autocommit is off, their tests will succeed ... but then a transaction block is started anyway, defeating the point of the test. We could fix these statements to fail if autocommit is off, which means that you could not use them at all except by setting autocommit on. Ugh. Or we could fix them to force an autocommit. Which would mean that these "dangerous" statements would become even more dangerous, since that's exactly the behavior a person using autocommit-off would not expect. Also ugh. Anyone see a way out of this catch-22? If not, which is the least bad alternative? 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] autocommit vs TRUNCATE et al
Tom Lane wrote: There are a number of statements, such as TRUNCATE TABLE, that refuse to run in a transaction block because they perform actions that can't be rolled back later. These statements currently do not look at autocommit, which means that if autocommit is off, their tests will succeed ... but then a transaction block is started anyway, defeating the point of the test. We could fix these statements to fail if autocommit is off, which means that you could not use them at all except by setting autocommit on. Ugh. Or we could fix them to force an autocommit. Which would mean that these "dangerous" statements would become even more dangerous, since that's exactly the behavior a person using autocommit-off would not expect. Also ugh. Anyone see a way out of this catch-22? If not, which is the least bad alternative? I think the "least bad" is the first option -- disallow TRUNCATE unless autocommit is on. With the second option, people would be caught by surprise at precisely the worst possible moment. Better to make them take the extra step. Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] autocommit vs TRUNCATE et al
On Fri, 18 Oct 2002, Tom Lane wrote: > Anyone see a way out of this catch-22? If not, which is the least > bad alternative? Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial, I know :-). Regardless, the first option seems the less of the two evils. Gavin ---(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] ECPG and bison
going to be dealing with this this weekend ... Bruce already asked me as well, just been busy during the week, so had to defer to the weekend ... if its not in place by tomorrow around, so, 8pm GMT,please feel free to email-nag me :) On Fri, 18 Oct 2002, Michael Meskes wrote: > Could anyone please tell me if we found a solution? It seems I missed > any discussion or whatsoever. The only things I know is that > postgresql.org still has bison 1.35 installed and 7.3 release is > nearing. > > Michael > -- > Michael Meskes > [EMAIL PROTECTED] > 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 > ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Antw: Re: [HACKERS] Postgresql and multithreading
On 18 Oct 2002 at 18:10, Ulrich Neumann wrote: > Marc, > > not only the global variables are a problem. PostgreSQL doesn't clean > up > all the memory before a process terminates and you must deal with > signals between threads. OK, first of all let me say this. I am interested in seeing postgresql mutlithreaded but I don't think it's a good idea to provide a thread per connection. On slick unices like freebsd/linux, threads and processes are almost equally heavy. Besides if connection opening time for a database is an issue, application should cache the pool of connections. Databases are not web servers which should cater to thousands of connections per minute. I am interested in seeing postgresql multithreaded so that it performs better on SMP machine. Right now I am building/designing a *huge* database which is going to use at least 4 way machines. With number of connections very small, around 10-15 and being persistent, I am afraid that postgresql would not use all the available horsepower. > I've modified PostgreSQL that it is completely thread based and nearly > clean > with allocating/deallocating memory and I'm using signals between > threads. I am sure it must have been massive task. > I'm still VERY interested in giving those changes back to the > community, > but i think that my changes are still not wanted. Well, I understand your feeling but I am sure it's not the cases. People here have stated that there are other optimisation areas which needs to be addresses first. Threading is not ruled out but it's not on current radar either. I would be more than happy to assist you to make this happen. I have some experience in threads(pthreads on linux) but absolute no experience in postgresql code. Can we make a patch that converts a single module/operation to multithreaded? Let's say sequential table scan. I propose that such a conversion should be done under conditional compilation with default threaded behaviour as off. This would not disturb existing setup and behaviour where threads are not good enough. Besides since we are distributing almost exclusive work to threads, there should be little syncronisation issues. I request postgresql hackers to look up to this proposal favourably. This would be a good and gradual way to get threading in postgresql. Awaiting your feedback.. Bye Shridhar -- The Consultant's Curse: When the customer has beaten upon you long enough, give him what he asks for, instead of what he needs. This is very strong medicine, and is normally only required once. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Design decision curiosity
"Dann Corbit" <[EMAIL PROTECTED]> writes: > I am curious as to why it is necessary to add PL/pgSQL as a language > instead of including it by default. I believe security was one of the reasons. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Design decision curiosity
I am curious as to why it is necessary to add PL/pgSQL as a language instead of including it by default. Is it to save space on small systems or??? Since the code necessary PL/pgSQL is very small, it does not seem like there would be much savings. I imagine that there is occasionally some confusion with manuals describing the use of PL/pgSQL and yet the language does not exist until installation. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ECPG and bison
Michael Meskes writes: > Could anyone please tell me if we found a solution? It seems I missed > any discussion or whatsoever. The only things I know is that > postgresql.org still has bison 1.35 installed and 7.3 release is > nearing. I suggest that you merge your branch as soon as you are ready and force the issue a bit. It's not like the bison installation on postgresql.org can make the world stop. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump and large files - is this a problem?
Philip Warner <[EMAIL PROTECTED]> writes: > I don't have a lot of options for testing it - should I just apply the > changes and wait for the problems, or can someone offer a bigendian machine > and/or a 4 byte off_t machine? My HP is big-endian; send in the patch and I'll check it here... 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] Postgresql and multithreading
On Thu, 2002-10-17 at 22:20, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Let me add one more thing on this "thread". This is one email in a long > > list of "Oh, gee, you aren't using that wizz-bang new > > sync/thread/aio/raid/raw feature" discussion where someone shows up and > > wants to know why. Does anyone know how to address these, efficiently? > > Simple: respond to 'em all with a one-line answer: "convince us why we > should use it". The burden of proof always seems to fall on the wrong > end in these discussions. > > regards, tom lane That may be easier said that done. If you don't know what the objections are, it's hard to argue your case. If you do know and understand the objections, chances are you already know the code very well and/or have the mailing lists for a very long time. This basically means, you don't want to hear from anyone unless they are "one" with the code. That seems and sounds very anti-open source. After it's all said and done, I think you guys are barking up the wrong tree. Open Source is all about sharing ideas. Many times I've seen ideas expressed here that were not exact hits yet help facilitate discussion, understanding on the topics in general and in some cases may even spur other ideas or associated code fixes/improvements. When I first started on this list, I was scolded rather harshly for not asking all of my questions on the list. Originally, I was told to ask reasonable questions so that everyone can learn. Now, it seems, that people don't want to answer questions at all as it's bothering the developers. Commonly asked items, such as threading, seems like they are being addressed rather well without core developer participation. Right now, I'm not seeing any down sides to what's currently in place. If the core developers still feel like they are spending more time then they like, then perhaps those that following the mailing list can step forward a little more to address general questions and defer when needed. The topic, such as threading, was previously addressed yet people still followed up on the topic. Perhaps those that don't want to be bothered should allow more time for others to address the topic and leave it alone once it has been addressed. That alone seems like it would be a huge time saver for the developers and a better use of resources. Greg signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Postgresql and multithreading
Greg Copeland <[EMAIL PROTECTED]> writes: > On Thu, 2002-10-17 at 22:20, Tom Lane wrote: >> Simple: respond to 'em all with a one-line answer: "convince us why we >> should use it". The burden of proof always seems to fall on the wrong >> end in these discussions. > ... Now, it seems, that > people don't want to answer questions at all as it's bothering the > developers. Not at all. But rehashing issues that have been talked out repeatedly is starting to bug some of us ;-). Perhaps the correct "standard answer" is more like "this has been discussed before, please read the list archives". regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ECPG and bison
Yes, we are going to upgrade to bison 1.50 on our main server as soon as Marc gets it installed. If you want to make your changes and commit those now, you can, because I assume your bison 1.50 output will get into CVS. I have bison 1.50 here too. --- Michael Meskes wrote: > Could anyone please tell me if we found a solution? It seems I missed > any discussion or whatsoever. The only things I know is that > postgresql.org still has bison 1.35 installed and 7.3 release is > nearing. > > Michael > -- > Michael Meskes > [EMAIL PROTECTED] > 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 > -- 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] Postgresql and multithreading
On Fri, 2002-10-18 at 09:28, Tom Lane wrote: > Greg Copeland <[EMAIL PROTECTED]> writes: > > On Thu, 2002-10-17 at 22:20, Tom Lane wrote: > >> Simple: respond to 'em all with a one-line answer: "convince us why we > >> should use it". The burden of proof always seems to fall on the wrong > >> end in these discussions. > > > ... Now, it seems, that > > people don't want to answer questions at all as it's bothering the > > developers. > > Not at all. But rehashing issues that have been talked out repeatedly > is starting to bug some of us ;-). Perhaps the correct "standard > answer" is more like "this has been discussed before, please read the > list archives". I agree. That sounds like a much more reasonable response. In fact, if you were to simply let the fledglings respond, it would completely take you guys out of the loop. Perhaps something like a Wiki or FAQ-O-Matic can be added whereby, the user base can help maintain it? That would seemingly help take some load off of Bruce too. Greg ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] pg_encoding doesn't reject invalid input
pg_encoding doesn't reject invalid input (like 'pg_encoding foo'). I think it should exit with a non-zero status. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Current CVS has strange parser for float type
Teodor Sigaev writes: > wow=# select 5.3::float; > ERROR: Bad float8 input format '5.3' Does it accept '5,4'::float? Try running initdb with --locale=C. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] memcpy testing
Seems we aren't the only ones concerned about memset-like optimizations: http://www.bsdforums.org/forums/showthread.php?threadid=3778 This talks about using MMX assembly instructions for memcpy. -- 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] ECPG and bison
On Fri, Oct 18, 2002 at 11:48:33AM -0400, Bruce Momjian wrote: > Yes, we are going to upgrade to bison 1.50 on our main server as soon as > Marc gets it installed. If you want to make your changes and commit Okay. > those now, you can, because I assume your bison 1.50 output will get > into CVS. I have bison 1.50 here too. The changes are there already, I just have to fold the ecpg.big branch into HEAD. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_encoding doesn't reject invalid input
Peter Eisentraut <[EMAIL PROTECTED]> writes: > pg_encoding doesn't reject invalid input (like 'pg_encoding foo'). I > think it should exit with a non-zero status. Seems reasonable to me ... shouldn't it complain on stderr as well? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ECPG and bison
Michael Meskes <[EMAIL PROTECTED]> writes: >> those now, you can, because I assume your bison 1.50 output will get >> into CVS. I have bison 1.50 here too. > The changes are there already, I just have to fold the ecpg.big branch > into HEAD. Probably you should refrain from doing that until Marc installs 1.50 at postgresql.org, else the nightly snapshots will be broken, to no one's advantage. Marc, can you do something about installing bison 1.50 soon? (Guess I'd better get it loaded on my own machines, too...) regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ECPG and bison
On Fri, 2002-10-18 at 13:51, Tom Lane wrote: > Michael Meskes <[EMAIL PROTECTED]> writes: > >> those now, you can, because I assume your bison 1.50 output will get > >> into CVS. I have bison 1.50 here too. > > > The changes are there already, I just have to fold the ecpg.big branch > > into HEAD. > > Probably you should refrain from doing that until Marc installs 1.50 > at postgresql.org, else the nightly snapshots will be broken, to no > one's advantage. > > Marc, can you do something about installing bison 1.50 soon? > > (Guess I'd better get it loaded on my own machines, too...) Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly by). LER > > regards, tom lane > > ---(end of broadcast)--- > TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] > -- 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 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] Cleanup of /contrib
Peter Eisentraut wrote: > Bruce Momjian writes: > > > I am cleaning up /contrib by adding "autocommit = 'on'" > > Is everyone in the world now required to add "autocommit = on" in all > scripts, interfaces, programs, applications that are not strictly personal > use? Is there no better solution? If there is, I would love to hear it. If you write a script that creates/modifies objects, you either have to use "autocommit = on" or use transactions. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump and large files - is this a problem?
Philip Warner writes: > > I have made the changes to pg_dump and verified that (a) it reads old > files, (b) it handles 8 byte offsets, and (c) it dumps & seems to restore > (at least to /dev/null). > > I don't have a lot of options for testing it - should I just apply the > changes and wait for the problems, or can someone offer a bigendian machine > and/or a 4 byte off_t machine? Any old machine has a 4-byte off_t if you configure with --disable-largefile. This could be a neat way to test: Make two installations configured different ways and move data back and forth between them until it changes. ;-) -- Peter Eisentraut [EMAIL PROTECTED] ---(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] PL/Perl and Perl 5.8
Neil Conway writes: > #ifdef HAS_CRYPT_R > #if CRYPT_R_PROTO == REENTRANT_PROTO_B_CCD > CRYPTD* _crypt_data; > #else > struct crypt_data _crypt_struct; > #endif > #endif /* HAS_CRYPT_R */ > > The "crypt_data" struct is defined in crypt.h, but only if _GNU_SOURCE > is defined -- just like crypt_r(). The HAS_CRYPT_R is true because the function is available even without the prototype, but the struct is not. A plain bug in Perl's configury mechanism. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] ECPG and bison
Peter Eisentraut wrote: > Michael Meskes writes: > > > Could anyone please tell me if we found a solution? It seems I missed > > any discussion or whatsoever. The only things I know is that > > postgresql.org still has bison 1.35 installed and 7.3 release is > > nearing. > > I suggest that you merge your branch as soon as you are ready and force > the issue a bit. It's not like the bison installation on > postgresql.org can make the world stop. Agreed. We need to push this. -- 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] autocommit vs TRUNCATE et al
Tom Lane wrote: > There are a number of statements, such as TRUNCATE TABLE, that refuse to > run in a transaction block because they perform actions that can't be > rolled back later. > > These statements currently do not look at autocommit, which means that > if autocommit is off, their tests will succeed ... but then a > transaction block is started anyway, defeating the point of the test. > > We could fix these statements to fail if autocommit is off, which means > that you could not use them at all except by setting autocommit on. > Ugh. > > Or we could fix them to force an autocommit. Which would mean that > these "dangerous" statements would become even more dangerous, since > that's exactly the behavior a person using autocommit-off would not > expect. Also ugh. > > Anyone see a way out of this catch-22? If not, which is the least > bad alternative? Ugh, I see what you mean. With the old code, you had to do a BEGIN to start a multi-statement transaction, while with autocommit off, you are always in one. I don't think forcing them to turn on autocommit makes any sense; it isn't obvious, and it doesn't buy anything. I think we should just do an automatic COMMIT if it is the first statement of a transaction, and if not, throw the same error we used to throw. We are performing autocommit for SET at the start of a transaction now anyway, so it isn't totally strange to do it for TRUNCATE, etc. too. In fact, you can just put the xact commit check in the same place SET is handled in postgres.c. It isn't great, but it is clean. ;-) You could also throw a NOTICE mentioning it was committed as a separate transaction. -- 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] autocommit vs TRUNCATE et al
Bruce Momjian <[EMAIL PROTECTED]> writes: > ... I think we > should just do an automatic COMMIT if it is the first statement of a > transaction, and if not, throw the same error we used to throw. We are > performing autocommit for SET at the start of a transaction now anyway, > so it isn't totally strange to do it for TRUNCATE, etc. too. In fact, > you can just put the xact commit check in the same place SET is handled > in postgres.c. It isn't great, but it is clean. ;-) Well, "clean" isn't the adjective I would use ;-), but this might be the most useful approach. The analogy to SET hadn't occurred to me. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] autocommit vs TRUNCATE et al
Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > ... I think we > > should just do an automatic COMMIT if it is the first statement of a > > transaction, and if not, throw the same error we used to throw. We are > > performing autocommit for SET at the start of a transaction now anyway, > > so it isn't totally strange to do it for TRUNCATE, etc. too. In fact, > > you can just put the xact commit check in the same place SET is handled > > in postgres.c. It isn't great, but it is clean. ;-) > > Well, "clean" isn't the adjective I would use ;-), but this might be the Clean in coding terms, _only_. > most useful approach. The analogy to SET hadn't occurred to me. Yea, the SET behavior appeared pretty queer to me, but now that I have used it, I am getting used to it. -- 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] autocommit vs TRUNCATE et al
Bruce Momjian wrote:
most useful approach. The analogy to SET hadn't occurred to me.
Yea, the SET behavior appeared pretty queer to me, but now that I have
used it, I am getting used to it.
So does that mean:
set autocommit to off;
begin;
insert into foo values('a');
insert into bar values('b');
truncate table foobar;
will automatically commit the two inserts?
Joe
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] autocommit vs TRUNCATE et al
Joe Conway wrote:
> Bruce Momjian wrote:
> >>most useful approach. The analogy to SET hadn't occurred to me.
> >
> >
> > Yea, the SET behavior appeared pretty queer to me, but now that I have
> > used it, I am getting used to it.
> >
>
> So does that mean:
>
>set autocommit to off;
>begin;
>insert into foo values('a');
>insert into bar values('b');
>truncate table foobar;
>
> will automatically commit the two inserts?
No, the entire transaction will aborted because TRUNCATE has to be at
the start of a multi-statement transaction. This will also fail:
>set autocommit to off;
>begin;
>truncate table foobar;
>insert into foo values('a');
>insert into bar values('b');
but this will work:
>set autocommit to off;
>truncate table foobar;
>insert into foo values('a');
>insert into bar values('b');
In the last case, the TRUNCATE will happen, and the INSERTs will be in
their own multi-statement transaction. A SET in place of TRUNCATE will
behave the same way.
--
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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] autocommit vs TRUNCATE et al
Bruce Momjian wrote: Joe Conway wrote: Bruce Momjian wrote: most useful approach. The analogy to SET hadn't occurred to me. Yea, the SET behavior appeared pretty queer to me, but now that I have used it, I am getting used to it. In the last case, the TRUNCATE will happen, and the INSERTs will be in their own multi-statement transaction. A SET in place of TRUNCATE will behave the same way. Hmmm. It does look strange. We ought to make this prominent in the release notes and docs. Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] autocommit vs TRUNCATE et al
Gavin Sherry wrote: On Fri, 18 Oct 2002, Tom Lane wrote: Anyone see a way out of this catch-22? If not, which is the least bad alternative? Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial, I know :-). Regardless, the first option seems the less of the two evils. Even though TRUNCATE was modeled after Oracle's TRUNCATE and Oracle's TRUNCATE commits the running tx, truncates the relation, and starts a new tx, regardless of whether or not TRUNCATE is the first statement of the tx? Mike Mascari [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] autocommit vs TRUNCATE et al
Mike Mascari wrote: > Gavin Sherry wrote: > > On Fri, 18 Oct 2002, Tom Lane wrote: > > > > > >>Anyone see a way out of this catch-22? If not, which is the least > >>bad alternative? > > > > > > Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial, > > I know :-). > > > > Regardless, the first option seems the less of the two evils. > > Even though TRUNCATE was modeled after Oracle's TRUNCATE and > Oracle's TRUNCATE commits the running tx, truncates the > relation, and starts a new tx, regardless of whether or not > TRUNCATE is the first statement of the tx? That seems just too harsh to me. I think we should impose some structure to it, though we will have compatibility issues. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] /contrib/retep to gborg
I think we should move /contrib/retep to gborg. It is 400k and isn't anywhere near our core functionality. I will add to TODO: Move /contrib/retep to gborg Can I move this during beta? I don't think so. -- 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/users-lounge/docs/faq.html
Re: [HACKERS] autocommit vs TRUNCATE et al
On Fri, 18 Oct 2002, Mike Mascari wrote: > Gavin Sherry wrote: > > On Fri, 18 Oct 2002, Tom Lane wrote: > > > > > >>Anyone see a way out of this catch-22? If not, which is the least > >>bad alternative? > > > > > > Ultimately, fix TRUNCATE to be transaction safe. This is non-trivial, > > I know :-). > > > > Regardless, the first option seems the less of the two evils. > > Even though TRUNCATE was modeled after Oracle's TRUNCATE and > Oracle's TRUNCATE commits the running tx, truncates the > relation, and starts a new tx, regardless of whether or not > TRUNCATE is the first statement of the tx? Why should we be *only* as good as Oracle? :-) Gavin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] ECPG and bison
On Fri, 2002-10-18 at 22:03, Marc G. Fournier wrote: > On Fri, 18 Oct 2002, Tom Lane wrote: > > > Bruce Momjian <[EMAIL PROTECTED]> writes: > > > Larry Rosenman wrote: > > >> Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly > > >> by). > > > > > I can confirm that: > > > http://ftp.gnu.org/gnu/bison/ > > > Attached is the Changelog since 1.50. > > > > Urgh. Nothing like major releases 2 weeks apart to give one a nice warm > > comfy feeling about the stability of one's tools. > > > > Offhand it looks like these are nearly all bug fixes, and so we'd better > > standardize on 1.75 not 1.50. But I wonder what will be out next > > week... > > that's one of hte reasons I've been holding off (the other being a busy > week) ... I *try* to keep stuff like this to what the FreeBSD ports > collection considers a stable release, and it hasn't been updated yet :( The PR I referred to above is the PR to update to 1.75. > -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] ECPG and bison
On Fri, 18 Oct 2002, Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Larry Rosenman wrote: > >> Looks like threre is a 1.75 out (based on a FreeBSD PR I just saw fly > >> by). > > > I can confirm that: > > http://ftp.gnu.org/gnu/bison/ > > Attached is the Changelog since 1.50. > > Urgh. Nothing like major releases 2 weeks apart to give one a nice warm > comfy feeling about the stability of one's tools. > > Offhand it looks like these are nearly all bug fixes, and so we'd better > standardize on 1.75 not 1.50. But I wonder what will be out next > week... that's one of hte reasons I've been holding off (the other being a busy week) ... I *try* to keep stuff like this to what the FreeBSD ports collection considers a stable release, and it hasn't been updated yet :( ---(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] Postgresql and multithreading
On Fri, Oct 18, 2002 at 10:28:38AM -0400, Tom Lane wrote: > Greg Copeland <[EMAIL PROTECTED]> writes: > > On Thu, 2002-10-17 at 22:20, Tom Lane wrote: > >> Simple: respond to 'em all with a one-line answer: "convince us why we > >> should use it". The burden of proof always seems to fall on the wrong > >> end in these discussions. > > > ... Now, it seems, that > > people don't want to answer questions at all as it's bothering the > > developers. > > Not at all. But rehashing issues that have been talked out repeatedly > is starting to bug some of us ;-). Perhaps the correct "standard > answer" is more like "this has been discussed before, please read the > list archives". Let me explain my posting which started this `thread': - The developer's FAQ section 1.9 explains why PostgreSQL doesn't use threads (and many times it has been discussed on the list). - The TODO list has an item `Experiment with multi-threaded backend' and points to a mailing list discussion about the implementation by Myron Scott. His final comment is that he didn't `gain much performance' and `ended up with some pretty unmanagable code'. He also says that he wouldn't `personally try this again ... but there probably was a better way'. - I was going through the TODO list, and was wondering if I should try on this. But before doing that, naturally, I wanted to figure out if any of the core developers themselves have any plans of doing it. Now, I am trying hard to figure out why this `are you going to do this? otherwise I can try it', type posting was not differentiated from numerous `why don't YOU implement this feature' type postings ;) Anuradha -- Debian GNU/Linux (kernel 2.4.18-xfs-1.1) "Life is too important to take seriously." -- Corky Siegel ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pg_dump and large files - is this a problem?
At 12:07 AM 19/10/2002 +0200, Peter Eisentraut wrote: Any old machine has a 4-byte off_t if you configure with --disable-largefile. Thanks - done. I just dumped to a custom backup file, then dumped it do SQL, and compared each version (V7.2.1, 8 byte & 4 byte offsets), and they all looked OK. Also, the 4 byte version reads the 8 byte offset version correctly - although I have not checked reading > 4GB files with 4 byte offset, but it's not a priority for obvious reasons. So once Giles gets back to me (Monday), I'll commit the changes. 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 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump and large files - is this a problem?
I have put the latest patch at: http://downloads.rhyme.com.au/postgresql/pg_dump/ along with two dump files of the regression DB, one with 4 byte and the other with 8 byte offsets. I can read/restore each from the other, so it looks pretty good. Once the endianness is tested, we should be OK. Known problems: - will not cope with > 4GB files and size_t not 64 bit. - when printing data position, it is assumed that off_t is UINT64 (we could remove this entirely - it's just for display) - if seek is not supported, then an intXX is assigned to off_t when file offsets are needed. This *should* not cause a problem since without seek, the offsets will not be written to the file. Changes from Prior Version: - No longer stores or outputs data length - Assumes result of ftello is correct if it disagrees with internally kept tally. - 'pg_restore -l' now shows sizes of int and offset. 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 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] /contrib/retep to gborg
Bruce Momjian <[EMAIL PROTECTED]> writes: > I think we should move /contrib/retep to gborg. It is 400k and isn't > anywhere near our core functionality. I will add to TODO: > Move /contrib/retep to gborg > Can I move this during beta? I don't think so. Why not? Feature addition during beta is frowned on, but I never heard anyone say you couldn't remove features during beta. (In fact that's a pretty standard response to serious bugs, no?) Whether retep *should* be moved is not something I feel qualified to comment on, but I don't put any stock in an argument that it can't be done simply because we're in beta. 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
