Re: [HACKERS] compiling postgres in winxp
Any Code::Blocks user? http://www.codeblocks.org/ Cannot compile PG-8.2.5 with WinXP SP2 using Code::Blocks. I created a new project including ALL the files decompressed from postgresql-8.2.5.tar.gz and then just clicked on build. What's wrong? Alternative ways to complie it with other IDE or any precise command line? The error messages when building it are: Project : Console application Compiler : GNU GCC Compiler (called directly) Directory : C:\Documents and Settings\manolo\Desktop\postgresql-8.2.5\ Switching to target: default Compiling: contrib\adminpack\adminpack.c contrib\adminpack\adminpack.c:15:22: postgres.h: No such file or directory contrib\adminpack\adminpack.c:21:29: catalog/pg_type.h: No such file or directory contrib\adminpack\adminpack.c:22:21: funcapi.h: No such file or directory contrib\adminpack\adminpack.c:23:23: miscadmin.h: No such file or directory contrib\adminpack\adminpack.c:24:34: postmaster/syslogger.h: No such file or directory contrib\adminpack\adminpack.c:25:24: storage/fd.h: No such file or directory contrib\adminpack\adminpack.c:26:28: utils/datetime.h: No such file or directory contrib\adminpack\adminpack.c:40: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:42: error: syntax error before pg_file_write contrib\adminpack\adminpack.c:42: warning: parameter names (without types) in function declaration contrib\adminpack\adminpack.c:42: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:43: error: syntax error before pg_file_rename contrib\adminpack\adminpack.c:43: warning: parameter names (without types) in function declaration contrib\adminpack\adminpack.c:43: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:44: error: syntax error before pg_file_unlink contrib\adminpack\adminpack.c:44: warning: parameter names (without types) in function declaration contrib\adminpack\adminpack.c:44: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:45: error: syntax error before pg_logdir_ls contrib\adminpack\adminpack.c:45: warning: parameter names (without types) in function declaration contrib\adminpack\adminpack.c:45: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:47: warning: parameter names (without types) in function declaration contrib\adminpack\adminpack.c:47: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:48: warning: parameter names (without types) in function declaration contrib\adminpack\adminpack.c:48: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:49: warning: parameter names (without types) in function declaration contrib\adminpack\adminpack.c:49: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:50: warning: parameter names (without types) in function declaration contrib\adminpack\adminpack.c:50: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:55: error: syntax error before DIR contrib\adminpack\adminpack.c:55: warning: no semicolon at end of struct or union contrib\adminpack\adminpack.c:56: warning: data definition has no type or storage class contrib\adminpack\adminpack.c:69: error: syntax error before '*' token contrib\adminpack\adminpack.c: In function `convert_and_check_filename': contrib\adminpack\adminpack.c:71: error: `arg' undeclared (first use in this function) contrib\adminpack\adminpack.c:71: error: (Each undeclared identifier is reported only once contrib\adminpack\adminpack.c:71: error: for each function it appears in.) contrib\adminpack\adminpack.c:71: error: `VARHDRSZ' undeclared (first use in this function) contrib\adminpack\adminpack.c:72: warning: initialization makes pointer from integer without a cast contrib\adminpack\adminpack.c:74: warning: passing arg 2 of `memcpy' makes pointer from integer without a cast contrib\adminpack\adminpack.c:81: error: `ERROR' undeclared (first use in this function) contrib\adminpack\adminpack.c:82: error: `ERRCODE_INSUFFICIENT_PRIVILEGE' undeclared (first use in this function) contrib\adminpack\adminpack.c:88: error: `DataDir' undeclared (first use in this function) contrib\adminpack\adminpack.c:91: error: `logAllowed' undeclared (first use in this function) contrib\adminpack\adminpack.c:92: error: `Log_directory' undeclared (first use in this function) contrib\adminpack\adminpack.c:99: error: `NULL' undeclared (first use in this function) contrib\adminpack\adminpack.c: In function `requireSuperuser': contrib\adminpack\adminpack.c:115: error: `ERROR' undeclared (first use in this function) contrib\adminpack\adminpack.c:116: error: `ERRCODE_INSUFFICIENT_PRIVILEGE' undeclared (first use in this function) contrib\adminpack\adminpack.c: At top level:
Re: [HACKERS] 8.3beta3 ERROR: cached plan must not change result type
On Wed, Nov 28, 2007 at 04:51:17PM +0100, Louis-David Mitterrand wrote: On Wed, Nov 28, 2007 at 10:45:31AM -0500, Tom Lane wrote: Louis-David Mitterrand [EMAIL PROTECTED] writes: I am seeing this error with 8.3beta3 on debian unstable: 2007-11-28 15:15:46 CET ERROR: cached plan must not change result type Let me know if you need more info. Yes. Okay :) I guess I had it coming. The only thing I know is this error started showing up in the logs at 15:15:46 making our site unavailble until I restarted apache. No postgres code has been modified recently on the app and it's the first time I see that error. Also I don't know, yet, how to reproduce it. Will try and report. Wow, this above email took three days to reach to list. Received: from maia-2.hub.org (maia-2.hub.org [200.46.204.187]) by zenon.apartia.fr (Postfix) with ESMTP id 2B95E59C5B43C for [EMAIL PROTECTED]; Sat, 1 Dec 2007 02:14:00 +0100 (CET) Received: from postgresql.org (postgresql.org [200.46.204.71]) by maia-2.hub.org (Postfix) with ESMTP id C5C1F2CA2E2 for [EMAIL PROTECTED]; Wed, 28 Nov 2007 11:51:20 -0400 (AST) Why did maia-2.hub.org keep it so long in its belly? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Release Note Changes
Josh Berkus wrote: This might be worth mentioning, since it can be quite a big difference in the right circumstances, and it helps a bit with the scalability problem of the recovery. Should mention that it only helps with full_pages_writes=on. One more reason to not gamble with data integrity ;-). Does this mean that recovery from logs with full_page_writes will be faster than recovery from logs without them? In general, yes. Depends a lot on how randomly the data in the WAL is distributed, speed of reading from WAL etc. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Replacement Selection
in puttuple_common(), the transition from an internal to external sort is performed at the bottom of the TSS_INITIAL case in the main switch statement. The transition? Do we internal sort somewhere else and then external sort here in tuplesort.c? The function dumptuples() heapifies the in-core tuples (divides the in-core tuples into initial runs and then advances the state to TSS_BUILDRUNS). Cannot see where dumptuples() advances the state to TSS_BUILDRUNS. I expected something like state-status = TSS_BUILDRUNS; executed through dumptuples() I recommend you run the code in the debugger on a external-sorting query: watch two or three tuples go into the heap and you'll get the idea. The top of the heap is at state-memtuples[0] the heap goes down from there. New tuples are added there and the heap is adjusted (Using the tuplesort_heap_siftup() function). -Tim ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Replacement Selection
[EMAIL PROTECTED] writes: The function dumptuples() heapifies the in-core tuples (divides the in-core tuples into initial runs and then advances the state to TSS_BUILDRUNS). Cannot see where dumptuples() advances the state to TSS_BUILDRUNS. I expected something like state-status = TSS_BUILDRUNS; executed through dumptuples() There's only one state-status = TSS_BUILDRUNS in the whole file. It's called by inittapes which is called in one place, just before dumptuples. Seriously, please try a bit harder before giving up. The code in this file is quite interdependent which means you'll have to read through the whole file (except perhaps the last section which just contains the interface functions to feed different types of datums or tuples) to understand any of it. But it's quite self-contained which makes it one of the easier modules in the system to get a functional grasp of. The hard part is understanding the algorithm itself and working out the details of the array management. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] .NET or Mono functions in PG
Magnus Hagander wrote: I did look at this at some earlier point as well. One big problem at that time was that once you embedded mono, yuo had all sorts of threads running in your backend ;-) Is that necessarily a problem? You have to compile with a thread-capable libc and take some care that the heap implementation is well tuned, but there's no reason why the mono housekeeping threads should cause you any problem is there? It should be much like the embedded Java. Another way to do it is the PL/J way (I think). Which is starting up a separate process with the VM in it and then do RPC of some kind to it. Which has more overhead per call, but lower per backend etc. And a lot less dangerous. Given that one would want to embed to have very low latency both on trigger invocation and on calls back into the data engine, I don't really see the point personally. I'm not sure how important it is to make the embeded interface look like a standard interface (in that way that the embedded CLR in MSSQL does - mostly) or whether it can be a thin wrapper over the C API. I think there's good mileage in starting with the thin wrapper, then at least some common business logic code can be used. James ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] .NET or Mono functions in PG
James Mansion wrote: Magnus Hagander wrote: I did look at this at some earlier point as well. One big problem at that time was that once you embedded mono, yuo had all sorts of threads running in your backend ;-) Is that necessarily a problem? You have to compile with a thread-capable libc and take some care that the heap implementation is well tuned, but there's no reason why the mono housekeeping threads should cause you any problem is there? It should be much like the embedded Java. Depends on what you mean by a problem. It's something you need to think about, and think hard about, and be sure you deal with. But it can be done. And yes, the housekeeping threads could be a problem. If you end up with for example something called on the GC thread calling back out into native mode, while the backend is doing something completely different. And yes, it would be the same as embedding Java. And it has been done with pl/java, so it can be done :) An interesting thing could be to look at if code could be stolen from or even better shared with pl/java, if this is the road to go down. Another way to do it is the PL/J way (I think). Which is starting up a separate process with the VM in it and then do RPC of some kind to it. Which has more overhead per call, but lower per backend etc. And a lot less dangerous. Given that one would want to embed to have very low latency both on trigger invocation and on calls back into the data engine, I don't really see the point personally. I'm not sure how important it is to make the embeded interface look like a standard interface (in that way that the embedded CLR in MSSQL does - mostly) or whether it can be a thin wrapper over the C API. I think there's good mileage in starting with the thin wrapper, then at least some common business logic code can be used. Agreed, that'd be a good start. But it would certainly be convenient if you could have access compatible with the System.Data stuff, since there's bound to be a lot of code (and coders) that know about that... //Magnus ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] compiling postgres in winxp
[EMAIL PROTECTED] wrote: Any Code::Blocks user? http://www.codeblocks.org/ Cannot compile PG-8.2.5 with WinXP SP2 using Code::Blocks. I created a new project including ALL the files decompressed from postgresql-8.2.5.tar.gz and then just clicked on build. What's wrong? Alternative ways to complie it with other IDE or any precise command line? What's wrong is that you have not followed any of the instructions for building Postgres. There are only two known ways to build on Windows: using either Mingw or MSVC. The latter only really works with the HEAD branch, not the released branches. Please read the docs before just trying to build blind like this. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] .NET or Mono functions in PG
Magnus Hagander [EMAIL PROTECTED] writes: James Mansion wrote: Is that necessarily a problem? ... And yes, it would be the same as embedding Java. And it has been done with pl/java, so it can be done :) It is also pretty well established that if pltcl or plperl cause the backend to become multithreaded, things break horribly. I strongly suspect that the only reason we've not seen similar reports about other PLs that might introduce extra threads is that the market penetration of other PLs is epsilon. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Andrew Dunstan [EMAIL PROTECTED] writes: The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. As best I can tell at the moment, I have not tested 5.6.1 with anything later than our 7.2 branch, so I don't know exactly where the breakage slipped in. It may be of long standing. Core was generated by `postgres'. Program terminated with signal 11, Segmentation fault. warning: Can't find file postmaster referenced in dld_list. Reading symbols from /usr/lib/libxnet.1...done. Reading symbols from /usr/lib/libc.1...done. Reading symbols from /usr/lib/libdld.1...done. Reading symbols from /home/postgres/testversion/lib/plperl.sl...done. Reading symbols from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl... done. Reading symbols from /usr/lib/libnsl_s.1...done. Reading symbols from /usr/lib/libM.1...done. Reading symbols from /usr/lib/libsec.1...done. #0 0xc00a02fc in ?? () from /usr/lib/libc.1 (gdb) bt #0 0xc00a02fc in ?? () from /usr/lib/libc.1 #1 0xc6fc3bb4 in ?? () from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #2 0xc6f5a99c in ?? () from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #3 0xc6f570a4 in ?? () from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #4 0xc6f56c88 in ?? () from /opt/perl5.6.1/lib/5.6.1/PA-RISC2.0/CORE/libperl.sl #5 0xc0d2b660 in plperl_init_interp () at plperl.c:429 #6 0xc0d2b2bc in _PG_init () at plperl.c:213 #7 0x3ce9f0 in internal_load_library ( libname=0xf8 Address 0xf8 out of bounds) at dfmgr.c:296 #8 0x3ce4a4 in load_external_function (filename=0x4016086c \037(, funcname=0x40062924 , signalNotFound=1 '\001', filehandle=0x7b03bb8c) at dfmgr.c:110 #9 0x1af7fc in fmgr_c_validator (fcinfo=0x4016086c) at pg_proc.c:509 #10 0x3d1a98 in OidFunctionCall1 (functionId=1075185772, arg1=49153) at fmgr.c:1527 #11 0x1af530 in ProcedureCreate ( procedureName=0x401075f8 plperl_call_handler, procNamespace=11, replace=0 '\000', returnsSet=0 '\000', returnType=2280, languageObjectId=13, languageValidator=2247, regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Tom Lane reports: The version I tested against is 5.8.8 - the latest stable release. The 5.8 series started in 2003 from what I can see - if anyone has a sufficiently old system that they can test on 5.6.2 that will be useful. I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. Sounds like another good reason to start enforcing a minimum modern Perl version. In the past, I advocated making it a minimum of 5.6, but now I think a minimum of 5.8 is in order. The first version of 5.8 was released in July of 2002, so I don't think we'd be upsetting very many people if we did so. Plus, they'd be potentially dumping core anyway, and our energy is better spent improving Pl/Perl itself at this point rather than tweaking things for old versions of Perl. I don't even think I have a pre 5.8 version around anymore. Would such a requirement cause any problems with packagers? I imagine a perl 5.8 prereq is a common thing these days... - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200712011322 http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8 -BEGIN PGP SIGNATURE- iD8DBQFHUaaevJuQZxSWSsgRA44LAJ9N47I0bIjjILxkOAAUv1ud0lDPAACdEX1J b3oIV+o0OPrT+RNW03WsGxg= =0I4i -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
I wrote: I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. As best I can tell at the moment, I have not tested 5.6.1 with anything later than our 7.2 branch, so I don't know exactly where the breakage slipped in. It may be of long standing. Actually, libperl seems to dump core in the same place in every PG version, back to and including 7.2, so what seems more likely is that this copy of perl is just plain broken. Since we didn't have any form of regression test for plperl back then, it's entirely possible that I never tested any further than compiling plperl with that setup. So we still need someone to try it with a good copy of 5.6 ... regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Release Note Changes
On Fri, 30 Nov 2007 06:32:10 -0500 Andrew Dunstan [EMAIL PROTECTED] wrote: Simon Riggs wrote: - Heap-Only Tuples (HOT) accelerate space reuse for UPDATEs change to Heap-Only Tuples (HOT) improve performance of frequent UPDATEs I think we need to qualify this, or it could be quite misleading. perhaps add that don't affect indexed columns or something like that. Heap Only Tuples (HOT) improves performance for heavy update tables where the column being updated isn't indexed? Seems kind of long but isn't that exactly what it does? Sincerely, Joshua D. Drake cheers andrew ---(end of broadcast)--- TIP 1: 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 signature.asc Description: PGP signature
Re: [HACKERS] CommandCounterIncrement versus plan caching
Tom Lane [EMAIL PROTECTED] writes: I think this can be fixed by changing the Executor so that it doesn't use snapshot-curcid for this purpose. Instead, add a field to EState showing the CommandID to mark tuples with. ExecutorStart, which has enough information to know whether the query is read-only or not, can set this field, or not, and tell GetCurrentCommandId to mark the command ID dirty (or not). ExecutorStart could also determine when the query is a write-only query for which the provided command id won't be used for any snapshot checks (ie, a simple INSERT) and tell CCI not to bump the CCI if the previous CC even if it's dirty. That would eliminate the other big use case where users can run out of command ids, batch inserts. If you're importing data from a tool which either generates tons of INSERT statements, uses a plpgsql loop to insert many records, or uses prepared queries and then executes them a few billion times you can run into the same limitation. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] CommandCounterIncrement versus plan caching
Gregory Stark [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: I think this can be fixed by changing the Executor so that it doesn't use snapshot-curcid for this purpose. Instead, add a field to EState showing the CommandID to mark tuples with. ExecutorStart, which has enough information to know whether the query is read-only or not, can set this field, or not, and tell GetCurrentCommandId to mark the command ID dirty (or not). ExecutorStart could also determine when the query is a write-only query for which the provided command id won't be used for any snapshot checks (ie, a simple INSERT) and tell CCI not to bump the CCI if the previous CC even if it's dirty. oops, garbled that. tell CCI not to bump the counter even if it's dirtyq -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [BUGS] BUG #3774: create table like including index doesn't update pg_constraints with primary key
NikhilS [EMAIL PROTECTED] writes: This can be handled by setting index-isconstraint appropriately inside generateClonedIndexStmt(). Done. The fundamental question though is should we allow primary, unique CONSTRAINTS which use the index mechanism just as an implementation to be created using the INCLUDING INDEXES mechanism. Yeah, this bizarreness was foreseen and agreed to back when we set up LIKE INCLUDING CONSTRAINTS the way it was defined (ie, copying only CHECK constraints and not other things called constraints). I was never very thrilled with that definition myself, but it's a bit too late to revisit it. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
Tom Lane wrote: I wrote: I got around to trying it with a dusty 5.6.1 I have laying about on my HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps core deep inside libperl. With or without this patch. As best I can tell at the moment, I have not tested 5.6.1 with anything later than our 7.2 branch, so I don't know exactly where the breakage slipped in. It may be of long standing. Actually, libperl seems to dump core in the same place in every PG version, back to and including 7.2, so what seems more likely is that this copy of perl is just plain broken. Since we didn't have any form of regression test for plperl back then, it's entirely possible that I never tested any further than compiling plperl with that setup. So we still need someone to try it with a good copy of 5.6 ... OK, I have built a fresh copy of perl 5.6.2 and built and linked HEAD against it. It passes the regression tests and the UTF8 test, and doesn't dump core. This is on FC6/x86_64. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] CommandCounterIncrement versus plan caching
Gregory Stark [EMAIL PROTECTED] writes: ExecutorStart could also determine when the query is a write-only query for which the provided command id won't be used for any snapshot checks (ie, a simple INSERT) and tell CCI not to bump the CCI if the previous CC even if it's dirty. Ummm ... I'm not convinced about that. ExecutorStart doesn't have any cheap way of inspecting the query carefully (eg, to see if it invokes volatile functions), nor any understanding of what context the query is being called in (eg, inside a subtransaction or volatile function). That would eliminate the other big use case where users can run out of command ids, batch inserts. If you're planning to insert 4 billion rows without using COPY (or at least multi-VALUES inserts), you've got more patience than I do. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Stored procedure issue
Hello I have a stored procedure which does the billing stuff in our system,it works ok,but if I put in production,where there is some 5-10 billing events per second,the whole database slows down. It won't even drop some test table,reindex,vacuum,things which were done before in the blink of an eye. If I stop the application which calls the procedure,all is back to normal. We didn't implement any special locking mechanism in the procedure,all is default. The procedure is updating user's balance in table 'users'. On the other hand a couple of 'heavy load' table has foreign keys pointing to table 'users'. Is it the matter of concurency and some locking issue or maybe the existing of all those foreign keys pointing to table 'users',or maybe something else which we're not aware at the moment ? Sincerely Pera Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [GENERAL] Stored procedure issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/07 20:40, Dragan Zubac wrote: Hello I have a stored procedure which does the billing stuff in our system,it works ok,but if I put in production,where there is some 5-10 billing events per second,the whole database slows down. It won't even drop some test table,reindex,vacuum,things which were done before in the blink of an eye. If I stop the application which calls the procedure,all is back to normal. We didn't implement any special locking mechanism in the procedure,all is default. The procedure is updating user's balance in table 'users'. On the other hand a couple of 'heavy load' table has foreign keys pointing to table 'users'. Is it the matter of concurency and some locking issue or maybe the existing of all those foreign keys pointing to table 'users',or maybe something else which we're not aware at the moment ? Are you using transactions? Are the tables properly indexed? Are the queries in the SP using the indexes properly? Did you do all the testing on a tiny database. Is the SP written as efficiently? (Think of ways to refactor it in order to get the same results with less effort.) - -- Ron Johnson, Jr. Jefferson LA USA %SYSTEM-F-FISH, my hovercraft is full of eels -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHUh9nS9HxQb37XmcRAjPTAJ4jRUZUaF+j2KAB3+lBY6A3ROfynACfawWT 0QN026Ncl/Iag2M6E1kfjUg= =RlXy -END PGP SIGNATURE- ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Help with release note items
Bruce Momjian [EMAIL PROTECTED] writes: I need help understanding the following two release note items (see XXX): I've tweaked the text for the first one. I do not think the second one needs any changes; the matter is discussed elsewhere in the docs, and the release notes are not the place to go into such detail. regards, tom lane ---(end of broadcast)--- TIP 1: 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: [PATCHES] Re: [HACKERS] [GENERAL] plperl and regexps with accented characters - incompatible?
On Sat, 1 Dec 2007, Tom Lane wrote:
I wrote:
I got around to trying it with a dusty 5.6.1 I have laying about on my
HPPA machine, and the news is not good: CREATE LANGUAGE plperl dumps
core deep inside libperl. With or without this patch.
As best I can tell at the moment, I have not tested 5.6.1 with anything
later than our 7.2 branch, so I don't know exactly where the breakage
slipped in. It may be of long standing.
Actually, libperl seems to dump core in the same place in every PG
version, back to and including 7.2, so what seems more likely is that
this copy of perl is just plain broken. Since we didn't have any form
of regression test for plperl back then, it's entirely possible that
I never tested any further than compiling plperl with that setup.
So we still need someone to try it with a good copy of 5.6 ...
I tested cvs head which includes the patch on Solaris 9/SPARC with perl
5.6.1 and it seems to work fine.
Test output attached.
Steve
regards, tom lane
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
CREATE OR REPLACE FUNCTION test(TEXT) RETURNS bool language plperl as $$
return (shift =~
/[a-z\u0105\u0107\u0119\u0142\u0144ó\u015b\u017a\u017c\u0104\u0106\u0118\u0141\u0143\u015aÓ\u0179\u017b0-9_-]+/i)
|| 0;
$$;
CREATE FUNCTION
select test('depesz');
test
--
t
(1 row)
select test('depesz\u0105\u0107\u0119\u0142');
test
--
t
(1 row)
select test('depesz\u0105\u0107\u0119\u0142$');
test
--
t
(1 row)
select test('dePEsz\u0105\u0106\u0119\u0142$');
test
--
t
(1 row)
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
