Re: [HACKERS] [PATCHES] thousands comma numeric formatting in psql
Am Dienstag, 12. Juli 2005 05:29 schrieb Bruce Momjian: Bruce Momjian wrote: I have heavily modified your patch and have applied it. Instead of using langinfo, I used a \pset variable numericsep. Because I don't have langinfo on my system, so I can't test it, nor add configure code for it. It also prevents us from using space as the separator, which is the international standard. OK, so let's discuss what we really want here. The original submitter wanted locale-dependent output, which seems reasonable, because that's what locale settings are intended for. The current state allows users to manually set the format, or actually only one aspect of the format? Where can you set the decimal separator and the size of the grouping (3 digits or 4 digits)? Is this capability even useful to get localized behavior? My other concern is that if we allow manual specification of the output format of some data type, then eventually someone will want to specify the format of some other data type as well, such as the date/time types. We should think about whether we want to be consistent here. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
On Mon, Jul 11, 2005 at 04:47:18PM -0700, Kris Jurka wrote: Marko Kreen wrote: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04 Linking problem with zlib on Solaris 9/x86. I am clueless about this. I can anyone look into it? It appears to be finding the static /usr/local/lib/libz.a instead of the dynamic /usr/lib/libz.so. So it is a local problem? I see that the configure line contains: --with-includes=/usr/local/include --with-libs=/usr/local/lib explicitly. -- marko ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] PL/Perl list value return causes segfault
In the latest HEAD, a PL/Perl function that returns a list value instead of a reference causes a segmentation fault: CREATE FUNCTION foo() RETURNS integer[] AS $$ return (1, 2, 3, 4); $$ LANGUAGE plperl; SELECT foo(); server closed the connection unexpectedly Here's the stack trace: #0 0xfed45bcc in plperl_call_handler (fcinfo=0xffbfe230) at plperl.c:1031 #1 0x0010e7d4 in ExecMakeFunctionResult (fcache=0x44af00, econtext=0x44ae58, isNull=0x44b470 \177~\177\177\177\177\177\177, isDone=0x44b4d8) at execQual.c:1031 #2 0x001122b0 in ExecProject (projInfo=0x44af00, isDone=0x44ae58) at execQual.c:3607 -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Where is the decision about placement of new tuple made ?
Where in the source is the decision about the placement new tuple (on which page to put it) made ? I'd like to take a look at adding gravity to that decision, do that I can make postgres to decide to place new tuple (inserted or updated) near the beginning of file, in order to make it possible for ordinary (lazy) vacuum to shrink relations more often, initially controlled by GUC, maybe later by some other, more automatic hints, like % of empty pages. My current jedi mindtricks (seqscan + update pk=pk on last tuple until its page nr in ctid changes) for shrinking relations do work, but not as well as I'd like them to ;) -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
CONCURRENT INDEXing again (was: [HACKERS] Must be owner to truncate?)
On L, 2005-07-09 at 16:50 -0400, Alvaro Herrera wrote: On Sat, Jul 09, 2005 at 11:43:52PM +0300, Hannu Krosing wrote: Could the new file not be made to cover the next available 1GB of file space, that is a new physical file ? This could made using of same kind of machinery my proposal for concurrent index does (i.e. locks that forbid putting new tuples in certain tuple ranges) I think your proposals are too handwavy, but there is a similar mechanism outlined for on-line index reorganizarion, whereby new tuples can be inserted concurrently with the reorganization, being stored on a spill area. See I try to state my reworked idea of concurrent indexing in a more clear way: The index build in done 2 transactions, need one new type of lock and a new system column in pg_class to tell planner not to use an incomplete index. This similar to vacuum in thet ot needs its own transactions and is not rollbackable. Perhaps the decision to use either this or current INDEX should be based on weather (RE)INDEX command is run in its own transaction. 1st transaction: The index for the part of datafile that exists at the start of INDEX command, is created within the 1st transacton, in similar way we do now. the part is definded as all tuples with ctid below (=) the max(ctid) stored at the start as MAX_CTID_1. To be sure that we cover all the tuples in range = MAX_CTID_1, and no new tuples are stored there as the result of INSERT or UPDATE, we need a new type of lock (lets call it TupleStoreRangeLock), which prevents new tuples to be placed below MAX_CTID_1 and which is aquired before starting the initial build. After the initial build of index for tuples below MAX_CTID_1 is finished, it is made visible to the rest of the system by committing the transaction, but marking the index as incomplete (probably a new column in pg_class is needed for that), so that it will not be used by planner, but all new inerts/updates will see and use it. 2nd transaction --- After that we need to wait for all other running transactions to complete, so we can be sure that all other backends know about the new index. Once we are sure they do, we record the new max(ctid) as MAX_CTID_2. At this point we can release the TupleStoreRangeLock, to make it possible to place new tuples below MAX_CTID_1 As the final step we need to scan all tuples in range ( MAX_CTID_1 to MAX_CTID_2 ) and insert their corresponding index entries into the new index. If the entry already exists for exact same ctid, that is ok. After reaching MAX_CTID_2, the index is ready for use by planner as well and can be marked as complete in pg_class. In case of REINDEX, the new index can be made to replace the old one at this point. TODO: work out with which locks TupleStoreRangeLock conflicts and with which it can coexists. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] About postgres C++ APIs...
Hi, Are there C++ APIs that enable data in postgres database to be extracted in xml format? Rgds Bhanu
[HACKERS] New dot releases?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, There are many commits to back branches and 8.0 branch since the last dot releases were announced. Any plans for new releases before 8.1beta1? Regards, - -- Devrim GUNDUZ devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.tdmsoft.com.tr http://www.gunduz.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFC08YJtl86P3SPfQ4RAnv7AKDRWRV1fBx+ngHwEZ8Cd13EhI/zyACfSfp4 5tjG2iZm25DPhOAWnBgblDA= =0ZL5 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Where is the decision about placement of new tuple made ?
On Tue, Jul 12, 2005 at 04:30:04PM +0300, Hannu Krosing wrote: Where in the source is the decision about the placement new tuple (on which page to put it) made ? heap_insert and heap_update. They get a page with free space from the FSM, or extend the relation, or --in heap_update case-- try to use the same page. I'd like to take a look at adding gravity to that decision, do that I can make postgres to decide to place new tuple (inserted or updated) near the beginning of file, in order to make it possible for ordinary (lazy) vacuum to shrink relations more often, initially controlled by GUC, maybe later by some other, more automatic hints, like % of empty pages. You'll have to modify the FSM code, I guess. -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) Ni aun el genio muy grande llegaría muy lejos si tuviera que sacarlo todo de su propio interior (Goethe) ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Where is the decision about placement of new tuple made ?
Hannu Krosing [EMAIL PROTECTED] writes: Where in the source is the decision about the placement new tuple (on which page to put it) made ? RelationGetBufferForTuple() and the free space map src/backend/access/heap/hio.c src/backend/storage/freespace/freespace.c I'd like to take a look at adding gravity to that decision, do that I can make postgres to decide to place new tuple (inserted or updated) near the beginning of file, I have strong doubts about this idea. The existing policy is designed to reduce contention by having different backends inserting into different pages. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [PATCHES] thousands comma numeric formatting in psql
Peter Eisentraut wrote: Am Dienstag, 12. Juli 2005 05:29 schrieb Bruce Momjian: Bruce Momjian wrote: I have heavily modified your patch and have applied it. Instead of using langinfo, I used a \pset variable numericsep. Because I don't have langinfo on my system, so I can't test it, nor add configure code for it. It also prevents us from using space as the separator, which is the international standard. OK, so let's discuss what we really want here. The original submitter wanted locale-dependent output, which seems reasonable, because that's what locale settings are intended for. True, but there were no locale configure tests, and I don't have langinfo, so I just made it a \pset 'string' variable. Also, when I learned that the international system uses a space to separate trigroups, a separate setting seemed best: http://en.wikipedia.org/wiki/Comma_%28punctuation%29#Numbers One thing we could do is to have a special value like 'locale' that uses langinfo, and all other values are taken literally. The current state allows users to manually set the format, or actually only one aspect of the format? Where can you set the decimal separator and the size of the grouping (3 digits or 4 digits)? Is this capability even useful to get localized behavior? You can't change the grouping from three, and the decimal is only be changed by setting the numeric separator to a period. We could add a new \pset for the decimal mark, but then do we auto-set it when the separator is a period? My other concern is that if we allow manual specification of the output format of some data type, then eventually someone will want to specify the format of some other data type as well, such as the date/time types. We should think about whether we want to be consistent here. We do allow MDY and DMY specification, but that controls both input and output in the server, while this just controls psql display. It is a good question how other settings should be handled, but I don't know the answers. Anyone? -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] thousands comma numeric formatting in psql
Bruce Momjian pgman@candle.pha.pa.us writes: We do allow MDY and DMY specification, but that controls both input and output in the server, while this just controls psql display. It is a good question how other settings should be handled, but I don't know the answers. Anyone? This patch sounds quite a lot different from what I thought we had agreed to, which was a way to specify that the client-side LC_NUMERIC locale settings should be used for formatting numbers. I think the only pset should be locale on or locale not on. This business about space is a red herring: if you want that, create a locale spec that specifies it. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] thousands comma numeric formatting in psql
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: We do allow MDY and DMY specification, but that controls both input and output in the server, while this just controls psql display. It is a good question how other settings should be handled, but I don't know the answers. Anyone? This patch sounds quite a lot different from what I thought we had agreed to, which was a way to specify that the client-side LC_NUMERIC locale settings should be used for formatting numbers. I think the only pset should be locale on or locale not on. This business about space is a red herring: if you want that, create a locale spec that specifies it. Well, how many people have langinfo? I don't. If this is what the group wants, Someone with langinfo is going to have to code the configure tests and convert it to a binary setting, or remove the patch. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] thousands comma numeric formatting in psql
Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: This patch sounds quite a lot different from what I thought we had agreed to, which was a way to specify that the client-side LC_NUMERIC locale settings should be used for formatting numbers. I think the only pset should be locale on or locale not on. This business about space is a red herring: if you want that, create a locale spec that specifies it. Well, how many people have langinfo? I don't. What's langinfo got to do with it? To minimize our portability exposure, the patch should use the same facilities that src/backend/utils/adt/pg_locale.c already depends on, namely setlocale() and localeconv(). regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [PATCHES] thousands comma numeric formatting in psql
Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: This patch sounds quite a lot different from what I thought we had agreed to, which was a way to specify that the client-side LC_NUMERIC locale settings should be used for formatting numbers. I think the only pset should be locale on or locale not on. This business about space is a red herring: if you want that, create a locale spec that specifies it. Well, how many people have langinfo? I don't. What's langinfo got to do with it? To minimize our portability exposure, the patch should use the same facilities that src/backend/utils/adt/pg_locale.c already depends on, namely setlocale() and localeconv(). The original patch included langinfo.h and used this call to set the default separator: char *dec_point = nl_langinfo(__DECIMAL_POINT); I don't see __DECIMAL_POINT defined anywhere on the FreeBSD 4.11 box we use for CVS. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Don't 'kill -9' the postmaster
Re: CONCURRENT INDEXing again (was: [HACKERS] Must be owner to truncate?)
Hannu Krosing [EMAIL PROTECTED] writes: I try to state my reworked idea of concurrent indexing in a more clear way: The index build in done 2 transactions, need one new type of lock and a new system column in pg_class to tell planner not to use an incomplete index. This similar to vacuum in thet ot needs its own transactions and is not rollbackable. Not rollbackable is certainly not acceptable... what if there's a crash partway through? VACUUM FULL is designed so that there isn't anything special that needs to be done to clean up after it if it fails partway through, but this seems to be untrue of your proposal. You'd have committed-created but useless indexes that have to be got rid of somehow. To be sure that we cover all the tuples in range = MAX_CTID_1, and no new tuples are stored there as the result of INSERT or UPDATE, we need a new type of lock (lets call it TupleStoreRangeLock), which prevents new tuples to be placed below MAX_CTID_1 and which is aquired before starting the initial build. Checking for such a lock will put a nontrivial distributed cost on every insert and update, whether the facility is in use or not. After the initial build of index for tuples below MAX_CTID_1 is finished, it is made visible to the rest of the system by committing the transaction, but marking the index as incomplete (probably a new column in pg_class is needed for that), so that it will not be used by planner, but all new inerts/updates will see and use it. I can see how this might work for a new index build, but it doesn't work for REINDEX --- you get to have other transactions inserting into either the old or the new index, not both. You could possibly make it work by creating a complete new index with its own OID, and then swapping that out for the old index at completion --- but see below. After that we need to wait for all other running transactions to complete, so we can be sure that all other backends know about the new index. That could be a pretty long time ... and presumably the index build is pretty long, too, or we'd not be bothering with all this mechanism. All the while, tuples are getting inserted into highly nonoptimal pages far from the start of the table. Doesn't this idea conflict rather badly with your desire expressed nearby to force tuples to be inserted near the front of the table? As the final step we need to scan all tuples in range ( MAX_CTID_1 to MAX_CTID_2 ) and insert their corresponding index entries into the new index. If the entry already exists for exact same ctid, that is ok. I don't think that's as easy as it sounds; at the very least it requires mechanism comparable to the unique-index checking code, which we don't have for any index type except btree. Also, in an index that's actually highly non-unique, that mechanism is *expensive* --- you may have to scan many pages of identically-keyed entries to see if any of them match the target ctid ... all the while holding a lock that prevents anyone else from inserting on the same starting page. What's more, the pseudo uniqueness check has to be done on both sides --- else index build might decide the entry's not there, insert it, only to have the original tuple inserter come along right after and insert again. So this is a second major operational mode that has to affect everybody in the system, not only index build. I'm not sure whether there are race conditions associated with getting in and out of this mode, but it wouldn't surprise me. After reaching MAX_CTID_2, the index is ready for use by planner as well and can be marked as complete in pg_class. In case of REINDEX, the new index can be made to replace the old one at this point. AFAICS, the replace bit requires exclusive lock to make sure that no one is in the midst of using the old index. This means that you have a situation where you need to upgrade your table lock at the very end of the operation --- which means the whole thing is prone to failing at the very end because of deadlock. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [PATCHES] thousands comma numeric formatting in psql
Bruce Momjian pgman@candle.pha.pa.us writes: Ah, I see this now in our code: CurrentLocaleConv.decimal_point = strdup(extlconv-decimal_point); CurrentLocaleConv.grouping = strdup(extlconv-grouping); CurrentLocaleConv.thousands_sep = strdup(extlconv-thousands_sep); Is this what we should be using? That's what I'd think. We know that localeconv() is portable --- that code has been there for years. Does psql use any of this now (I think no). A quick grep shows this is the only call of localeconv() in our code. Note: it occurs to me that those strdup's could fail in low-memory conditions, and we're not checking. Probably the routine should be rewritten to palloc into TopMemoryContext. Will see about it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] thousands comma numeric formatting in psql
On Tue, Jul 12, 2005 at 10:48:40AM -0400, Bruce Momjian wrote: Peter Eisentraut wrote: Am Dienstag, 12. Juli 2005 05:29 schrieb Bruce Momjian: Bruce Momjian wrote: The current state allows users to manually set the format, or actually only one aspect of the format? Where can you set the decimal separator and the size of the grouping (3 digits or 4 digits)? Is this capability even useful to get localized behavior? You can't change the grouping from three, This makes it a non-starter, IMHO. One set of people who use 4 digits is this little ethnic group called the Chinese. My other concern is that if we allow manual specification of the output format of some data type, then eventually someone will want to specify the format of some other data type as well, such as the date/time types. We should think about whether we want to be consistent here. We do allow MDY and DMY specification, but that controls both input and output in the server, while this just controls psql display. It is a good question how other settings should be handled, but I don't know the answers. Anyone? Hrm. I think we can safely tackle input and output as separate features here. What do we do for to_char() with such separators? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] New dot releases?
On Tue, Jul 12, 2005 at 16:30:48 +0300, Devrim GUNDUZ [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, There are many commits to back branches and 8.0 branch since the last dot releases were announced. Any plans for new releases before 8.1beta1? I seem to remember seeing a message suggesting that an 8.0.4 is probably worthwhile. That was about a month ago and developers were pretty busy getting stuff done before feature freeze. My expectation would be that any 8.0.4 would be done after 8.1beta1. I expect developers to be pretty busy until then and that with people looking through the code while adding features, that finding bugs that could be fixed in 8.0 will be higher than at other times in the development process. So that it makes sense to do a possible 8.0.4 release after 8.1beta1 is done. (Barring some critical bug beeing found in the mean time.) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Must be owner to truncate?
On Sat, Jul 09, 2005 at 11:48:35AM -0400, Tom Lane wrote: Stephen Frost [EMAIL PROTECTED] writes: * Mike Mascari (mascarm@mascari.com) wrote: And when the transaction that issued the TRUNCATE aborts after step 3, but newer transactions commit? The newer transactions would have to check for that situation. How would they do that? They might be long gone by the time the truncating transaction rolls back. It might be possible to do something that preserves full MVCC-ness for concurrent readers, but I don't believe there is any choice but to lock out concurrent writers until the truncate commits. If you try to allow that, there's no way to keep straight whose change goes into which file. What about if inserts go into both files until the truncate commits? Updates are a bit trickier; AFAICS they would have to block until the truncate commits because they would have different effects depending on if the commit happenend or not. But I don't see this as an issue. Likewise, inserts that would violate a unique constraint would have to wait until the truncate committed, but inserts that are unique could commit. Of course something else to consider is that just being able to support concurrent reads against truncate would be a step forward, even if writes were still blocked. That alone means this is probably worth-while, although it might require a slightly different syntax since it would behave differently than the existing truncate does. -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] pg_dump schema search_path; selectSourceSchema()
As I mentioned in the last post to a thread in general detailing some of the hurdles of attempting to set up PostgreSQL virtual hosting, we've had to hack pg_dump to achieve the behavior that we want.The modifications we made call into question (for us, anyway) a few design decisions in PostgreSQL utilities, and we're wondering if our modification has unintentional ramifications or if, as an option, it's something that the hackers see value in.The main issue for us is that we are relying on search_path to cause phpPgAdmin and pg_dump to find restricted views into the system catalogs. selectSourceSchema as written breaks our expectations when it is called with pg_catalog as a single argument.Our first attempt to get things working was to remove all calls to selectSourceSchema. Clearly, this is playing with fire, and I'll admit to not understanding all the references to schemas other than the explicit pg_catalog references.What we're currently thinking of doing is adding a flag like --search-path-prefix that would let us prepend any path requirements we have to the built-in calls to selectSourceSchema(). So that if we're putting our user-restricted system catalog views in public (as we're currently doing) or a custom schema (which would be my ideal preference), we can prepend that to the search_path, and pg_dump will behave as expected when run by a user in a hardened environment as long as users haven't done anything foolish. I'm just wondering whether such a patch seems sane and adds value from the perspective of hackers. Are we overlooking any scenarios in which pg_dump specifically requires a more restrictive search_path in order to behave properly?From a bigger picture standpoint, this is mostly necessary because there's no way to configure PostgreSQL to restrict access to the system catalogs in any meaningful way. I'm not really sure how to search for discussions on this topic in the archives, and I'm also not sure whether the forthcoming roles features will go any way toward eliminating the need for such behavior. -- Thomas F. O'Connell Co-Founder, Information Architect Sitening, LLC Strategic Open Source: Open Your i™ http://www.sitening.com/ 110 30th Avenue North, Suite 6 Nashville, TN 37203-6320 615-260-0005
[HACKERS] multibyte regression tests
Should we add the multibyte regression tests to the buildfarm test suite? Does anyone know how portable they are? I guess adding them would be one way to find out. cheers andrew ---(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] Where is the decision about placement of new tuple made ?
If you're going to do this I would suggest keeping in mind that a similar tactic could be used to help keep a table clustered (I think there may even be a TODO on that). The basic idea there is to use the clustering index to decide the best page to put a tuple on and try and return that page (or one close to it) from the FSM. On Tue, Jul 12, 2005 at 04:30:04PM +0300, Hannu Krosing wrote: Where in the source is the decision about the placement new tuple (on which page to put it) made ? I'd like to take a look at adding gravity to that decision, do that I can make postgres to decide to place new tuple (inserted or updated) near the beginning of file, in order to make it possible for ordinary (lazy) vacuum to shrink relations more often, initially controlled by GUC, maybe later by some other, more automatic hints, like % of empty pages. My current jedi mindtricks (seqscan + update pk=pk on last tuple until its page nr in ctid changes) for shrinking relations do work, but not as well as I'd like them to ;) -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Jim C. Nasby, Database Consultant [EMAIL PROTECTED] Give your computer some brain candy! www.distributed.net Team #1828 Windows: Where do you want to go today? Linux: Where do you want to go tomorrow? FreeBSD: Are you guys coming, or what? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
On Tue, 12 Jul 2005, Marko Kreen wrote: On Mon, Jul 11, 2005 at 04:47:18PM -0700, Kris Jurka wrote: Marko Kreen wrote: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=dragonflydt=2005-07-11%2003:30:04 Linking problem with zlib on Solaris 9/x86. I am clueless about this. I can anyone look into it? It appears to be finding the static /usr/local/lib/libz.a instead of the dynamic /usr/lib/libz.so. So it is a local problem? I see that the configure line contains: --with-includes=/usr/local/include --with-libs=/usr/local/lib explicitly. Well the buildfarm machine kudu is actually the same machine just building with the Sun compiler and it works fine. It links all of libz.a into libpgcrypto.so while gcc refuses to. Kris Jurka ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PL/Perl list value return causes segfault
Michael Fuhr wrote:
In the latest HEAD, a PL/Perl function that returns a list value
instead of a reference causes a segmentation fault:
CREATE FUNCTION foo() RETURNS integer[] AS $$
return (1, 2, 3, 4);
$$ LANGUAGE plperl;
SELECT foo();
server closed the connection unexpectedly
Here's the stack trace:
#0 0xfed45bcc in plperl_call_handler (fcinfo=0xffbfe230) at plperl.c:1031
#1 0x0010e7d4 in ExecMakeFunctionResult (fcache=0x44af00, econtext=0x44ae58,
isNull=0x44b470 \177~\177\177\177\177\177\177, isDone=0x44b4d8) at execQual.c:1031
#2 0x001122b0 in ExecProject (projInfo=0x44af00, isDone=0x44ae58) at
execQual.c:3607
Patch below fixes the SEGV, and you will see instead:
andrew=# select foo();
ERROR: array value must start with { or dimension information
which might not immediately point you to the source of the error :-( ,
but is certainly better than a SEGV.
Note that all plperl functions are called in scalar context, and it is
always wrong to return a list (as opposed to a listref). In fact, the
value received might surprise you even if it worked (it would be the
value of the last member of the list).
cheers
andrew
Index: plperl.c
===
RCS file: /projects/cvsroot/pgsql/src/pl/plperl/plperl.c,v
retrieving revision 1.85
diff -c -r1.85 plperl.c
*** plperl.c12 Jul 2005 01:16:21 - 1.85
--- plperl.c12 Jul 2005 18:52:54 -
***
*** 1021,1027
char *val;
! if (prodesc-fn_retisarray SvTYPE(SvRV(perlret)) == SVt_PVAV)
{
array_ret = plperl_convert_to_pg_array(perlret);
SvREFCNT_dec(perlret);
--- 1021,1028
char *val;
! if (prodesc-fn_retisarray SvROK(perlret)
! SvTYPE(SvRV(perlret)) == SVt_PVAV)
{
array_ret = plperl_convert_to_pg_array(perlret);
SvREFCNT_dec(perlret);
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pg_dump schema search_path; selectSourceSchema()
Thomas F. O'Connell [EMAIL PROTECTED] writes: Our first attempt to get things working was to remove all calls to selectSourceSchema. Clearly, this is playing with fire, No, it's breaking it entirely; and so would your proposed change. The reason for the restrictive search path is to ensure that references to stuff in other schemas is dumped with fully qualified names. Anything you add to the search path creates added risk of incorrect recreation of object definitions at reload. If the added schema contains *only* your replacement pg_database and pg_user views, the risk might be relatively small --- but I trust you can see that in general such a thing would be a bug not a feature. On the whole I continue to regard this project as a dead end. It will be a whole lot simpler and more reliable to give each user his own postmaster, if you want airtight separation between users. 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: [HACKERS] PL/Perl list value return causes segfault
On Tue, Jul 12, 2005 at 02:59:37PM -0400, Andrew Dunstan wrote: Note that all plperl functions are called in scalar context, and it is always wrong to return a list (as opposed to a listref). In fact, the value received might surprise you even if it worked (it would be the value of the last member of the list). Hmm, I don't know if it's feasible to do in Perl, but maybe check whether the function wants to return something in list context and throw an appropiate error message? -- Alvaro Herrera (alvherre[a]alvh.no-ip.org) Nunca se desea ardientemente lo que solo se desea por razón (F. Alexandre) ---(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] PL/Perl list value return causes segfault
Alvaro Herrera wrote: On Tue, Jul 12, 2005 at 02:59:37PM -0400, Andrew Dunstan wrote: Note that all plperl functions are called in scalar context, and it is always wrong to return a list (as opposed to a listref). In fact, the value received might surprise you even if it worked (it would be the value of the last member of the list). Hmm, I don't know if it's feasible to do in Perl, but maybe check whether the function wants to return something in list context and throw an appropiate error message? In perl, if there is any ambiguity it is the called function that is responsible for checking, not the caller. See perldoc -f wantarray. PLPerl explicitly passed G_SCALAR as a flag on all calls to plperl routines. So returning a list is a case of pilot error. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] dbt2 opteron performance
I'm starting to get results with dbt2 on a 4-way opteron system and wanted to share what I've got so far since people have told me in the past that this architecture is more interesting than the itanium2 that I've been using. This 4-way has 8GB of memory and four Adaptec 2200s controllers attached to 80 spindles (eight 10-disk arrays). For those familiar with the schema, here is a visual of the disk layout: http://www.osdl.org/projects/dbt2dev/results/dev4-015/layout-6.html Results for a 600 warehouse run are there: http://www.osdl.org/projects/dbt2dev/results/dev4-015/6/ The tuning is a still a bit off, but feel free to let me know if there are any issues anyway. Mark ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
Seems like down mail server ate first mail.
Here it is again.
On Tue, Jul 12, 2005 at 12:51:44PM +0300, Marko Kreen wrote:
Hopefully the last regression failure.
- openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
constants for buffers, which are small in case of
OpenSSL 0.9.6x and internal AES. (I tested it with
0.9.7 only, so I didn't notice...)
- Also I noticed that the wrapper macros for CBC mode
do not update IV buffer.
- As the previous mistake was not picked up by current
regression tests, I added a 'longer than a block'
test to all ciphers.
--
marko
Index: contrib/pgcrypto/openssl.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.24
diff -u -c -r1.24 openssl.c
*** contrib/pgcrypto/openssl.c 11 Jul 2005 15:07:59 - 1.24
--- contrib/pgcrypto/openssl.c 12 Jul 2005 09:27:59 -
***
*** 40,45
--- 40,50
#include openssl/rand.h
#include openssl/err.h
+ /*
+ * Max lengths we might want to handle.
+ */
+ #define MAX_KEY (512/8)
+ #define MAX_IV(128/8)
/*
* Does OpenSSL support AES?
***
*** 78,87
#define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
do { \
memcpy((dst), (src), (len)); \
! if (enc) \
aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
! else \
aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
} while (0)
#endif/* old OPENSSL */
--- 83,95
#define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
do { \
memcpy((dst), (src), (len)); \
! if (enc) { \
aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
! memcpy((iv), (dst) + (len) - 16, 16); \
! } else { \
aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
+ memcpy(iv, (src) + (len) - 16, 16); \
+ } \
} while (0)
#endif/* old OPENSSL */
***
*** 243,250
CAST_KEYcast_key;
AES_KEY aes_key;
} u;
! uint8 key[EVP_MAX_KEY_LENGTH];
! uint8 iv[EVP_MAX_IV_LENGTH];
unsignedklen;
unsignedinit;
const struct ossl_cipher *ciph;
--- 251,258
CAST_KEYcast_key;
AES_KEY aes_key;
} u;
! uint8 key[MAX_KEY];
! uint8 iv[MAX_IV];
unsignedklen;
unsignedinit;
const struct ossl_cipher *ciph;
Index: contrib/pgcrypto/expected/3des.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/3des.out,v
retrieving revision 1.2
diff -u -c -r1.2 3des.out
*** contrib/pgcrypto/expected/3des.out 5 Jul 2005 18:15:36 - 1.2
--- contrib/pgcrypto/expected/3des.out 12 Jul 2005 09:41:16 -
***
*** 54,56
--- 54,69
foo
(1 row)
+ -- long message
+ select encode(encrypt('Lets try a longer message.', '0123456789012345678901',
'3des'), 'hex');
+ encode
+ --
+ b71e3422269d0ded19468f33d65cd663c28e0871984792a7b3ba0ddcecec8d2c
+ (1 row)
+
+ select decrypt(encrypt('Lets try a longer message.',
'0123456789012345678901', '3des'), '0123456789012345678901', '3des');
+ decrypt
+
+ Lets try a longer message.
+ (1 row)
+
Index: contrib/pgcrypto/expected/blowfish.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/blowfish.out,v
retrieving revision 1.4
diff -u -c -r1.4 blowfish.out
*** contrib/pgcrypto/expected/blowfish.out 21 Mar 2005 05:24:51 -
1.4
--- contrib/pgcrypto/expected/blowfish.out 12 Jul 2005 09:32:13 -
***
*** 158,160
--- 158,173
foo
(1 row)
+ -- long message
+ select encode(encrypt('Lets try a longer message.', '0123456789', 'bf'),
'hex');
+ encode
+ --
+ a76059f7a1b627b5b84080d9beb337714c7a7f8b70300023e5feb6dfa6813536
+ (1 row)
+
+ select decrypt(encrypt('Lets try a longer message.', '0123456789', 'bf'),
'0123456789', 'bf');
+ decrypt
+
+ Lets try a longer message.
+ (1 row)
+
Index: contrib/pgcrypto/expected/cast5.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/cast5.out,v
retrieving revision
Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
Hopefully the last regression failure.
- openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH
constants for buffers, which are small in case of
OpenSSL 0.9.6x and internal AES. (I tested it with
0.9.7 only, so I didn't notice...)
- Also I noticed that the wrapper macros for CBC mode
do not update IV buffer.
- As the previous mistake was not picked up by current
regression tests, I added a 'longer than a block'
test to all ciphers.
--
marko
Index: contrib/pgcrypto/openssl.c
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/openssl.c,v
retrieving revision 1.24
diff -u -c -r1.24 openssl.c
*** contrib/pgcrypto/openssl.c 11 Jul 2005 15:07:59 - 1.24
--- contrib/pgcrypto/openssl.c 12 Jul 2005 09:27:59 -
***
*** 40,45
--- 40,50
#include openssl/rand.h
#include openssl/err.h
+ /*
+ * Max lengths we might want to handle.
+ */
+ #define MAX_KEY (512/8)
+ #define MAX_IV(128/8)
/*
* Does OpenSSL support AES?
***
*** 78,87
#define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
do { \
memcpy((dst), (src), (len)); \
! if (enc) \
aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
! else \
aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
} while (0)
#endif/* old OPENSSL */
--- 83,95
#define AES_cbc_encrypt(src, dst, len, ctx, iv, enc) \
do { \
memcpy((dst), (src), (len)); \
! if (enc) { \
aes_cbc_encrypt((ctx), (iv), (dst), (len)); \
! memcpy((iv), (dst) + (len) - 16, 16); \
! } else { \
aes_cbc_decrypt((ctx), (iv), (dst), (len)); \
+ memcpy(iv, (src) + (len) - 16, 16); \
+ } \
} while (0)
#endif/* old OPENSSL */
***
*** 243,250
CAST_KEYcast_key;
AES_KEY aes_key;
} u;
! uint8 key[EVP_MAX_KEY_LENGTH];
! uint8 iv[EVP_MAX_IV_LENGTH];
unsignedklen;
unsignedinit;
const struct ossl_cipher *ciph;
--- 251,258
CAST_KEYcast_key;
AES_KEY aes_key;
} u;
! uint8 key[MAX_KEY];
! uint8 iv[MAX_IV];
unsignedklen;
unsignedinit;
const struct ossl_cipher *ciph;
Index: contrib/pgcrypto/expected/3des.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/3des.out,v
retrieving revision 1.2
diff -u -c -r1.2 3des.out
*** contrib/pgcrypto/expected/3des.out 5 Jul 2005 18:15:36 - 1.2
--- contrib/pgcrypto/expected/3des.out 12 Jul 2005 09:41:16 -
***
*** 54,56
--- 54,69
foo
(1 row)
+ -- long message
+ select encode(encrypt('Lets try a longer message.', '0123456789012345678901',
'3des'), 'hex');
+ encode
+ --
+ b71e3422269d0ded19468f33d65cd663c28e0871984792a7b3ba0ddcecec8d2c
+ (1 row)
+
+ select decrypt(encrypt('Lets try a longer message.',
'0123456789012345678901', '3des'), '0123456789012345678901', '3des');
+ decrypt
+
+ Lets try a longer message.
+ (1 row)
+
Index: contrib/pgcrypto/expected/blowfish.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/blowfish.out,v
retrieving revision 1.4
diff -u -c -r1.4 blowfish.out
*** contrib/pgcrypto/expected/blowfish.out 21 Mar 2005 05:24:51 -
1.4
--- contrib/pgcrypto/expected/blowfish.out 12 Jul 2005 09:32:13 -
***
*** 158,160
--- 158,173
foo
(1 row)
+ -- long message
+ select encode(encrypt('Lets try a longer message.', '0123456789', 'bf'),
'hex');
+ encode
+ --
+ a76059f7a1b627b5b84080d9beb337714c7a7f8b70300023e5feb6dfa6813536
+ (1 row)
+
+ select decrypt(encrypt('Lets try a longer message.', '0123456789', 'bf'),
'0123456789', 'bf');
+ decrypt
+
+ Lets try a longer message.
+ (1 row)
+
Index: contrib/pgcrypto/expected/cast5.out
===
RCS file: /opt/arc/cvs2/pgsql/contrib/pgcrypto/expected/cast5.out,v
retrieving revision 1.1
diff -u -c -r1.1 cast5.out
*** contrib/pgcrypto/expected/cast5.out 21 Mar 2005 05:24:51 - 1.1
---
Re: [HACKERS] 4 pgcrypto regressions failures - 1 unsolved
Marko Kreen marko@l-t.ee writes: Hopefully the last regression failure. - openssl.c used EVP_MAX_KEY_LENGTH / EVP_MAX_IV_LENGTH constants for buffers, which are small in case of OpenSSL 0.9.6x and internal AES. (I tested it with 0.9.7 only, so I didn't notice...) - Also I noticed that the wrapper macros for CBC mode do not update IV buffer. - As the previous mistake was not picked up by current regression tests, I added a 'longer than a block' test to all ciphers. Applied, thanks. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] PL/Perl list value return causes segfault
Andrew Dunstan [EMAIL PROTECTED] writes: Michael Fuhr wrote: In the latest HEAD, a PL/Perl function that returns a list value instead of a reference causes a segmentation fault: Patch below fixes the SEGV, and you will see instead: Applied, thanks. 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] PL/Perl list value return causes segfault
On Tue, Jul 12, 2005 at 03:45:55PM -0400, Andrew Dunstan wrote: Alvaro Herrera wrote: On Tue, Jul 12, 2005 at 02:59:37PM -0400, Andrew Dunstan wrote: Note that all plperl functions are called in scalar context, and it is always wrong to return a list (as opposed to a listref). In fact, the value received might surprise you even if it worked (it would be the value of the last member of the list). Hmm, I don't know if it's feasible to do in Perl, but maybe check whether the function wants to return something in list context and throw an appropiate error message? In perl, if there is any ambiguity it is the called function that is responsible for checking, not the caller. See perldoc -f wantarray. PLPerl explicitly passed G_SCALAR as a flag on all calls to plperl routines. So returning a list is a case of pilot error. Is this a kind of pilot error that documents could help avert in some useful way? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 510 893 6100 mobile: +1 415 235 3778 Remember to vote! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Quick-and-dirty compression for WAL backup blocks
Hi all, I examined the effect of block-hole compression patch. I compared the amounts of writing of the WAL data of CVS(7/11) and 8.0.3. (The amount of the WAL data writing was measured by the number of executions of the write() function in XLogWrite().) And, I measured the size of the hole. Environment; IBM x206 P4 3.0GHz Mem 4GB CentOS 4.0 (Linux 2.6.9-5.0.3.ELsmp) Parameters; shared_buffers = 65535 checkpoint_segments = 30 default_with_oids = false (8.0.3) default_with_oids = off (CVS) How to exam; 0) initdb --no-locale 1) pgbench -i -s 100 pgbench 2) pgbench -n -c 50 -t 5000 pgbench 3) vacuumdb -d pgbench 4) pgbench -n -c 50 -t 5000 pgbench Results; |8.0.3| CVS(7/11) Exam | | | | |block-hole (byte) | write |C.P| write |C.P| total | min | max | avg -+-+---+-+---+---+-+--+- 1) | 187505 | 3 | 187373 | 4 |194056 | 36 | 8124 | 3881.12 2) | 509725 | 6 | 513489 | 5 | 115564476 | 12 | 8096 | 347.69 3) | 280456 | 2 | 172973 | 2 | 95923360 | 248 | 8156 | 614.08 4) | 533971 | 7 | 525135 | 6 | 171147256 | 12 | 8140 | 482.11 C.P = Checkpoint frequency It has been understood that patchs seems to be effective at VACUUM as a result of the measurement. But, in other cases, the effect was not so seen. -- Junji Teramoto ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] HEAD doesn't cope with libraries in non-default
Could we please get this patch applied? It seems like the right thing to do. cheers andrew Jim C. Nasby wrote: On Tue, Jul 05, 2005 at 10:09:19PM +0200, Peter Eisentraut wrote: I wrote: So either we code up some intelligence to put the C in the right position or we have to pass down A B and D separately from the main makefile. The following patch might just do the former. Please try it out. diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib --- ../cvs-pgsql/src/Makefile.shlib 2005-07-04 16:32:57.0 +0200 +++ ./src/Makefile.shlib2005-07-05 22:02:10.556162778 +0200 @@ -240,7 +240,7 @@ SHLIB_LINK += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86 endif -SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK) +SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) ifeq ($(enable_rpath), yes) SHLIB_LINK += $(rpath) endif Worked on platypus: http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=platypusdt=2005-07-05%2022:03:35 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Vacuum summary?
On Mon, 2005-07-11 at 12:38 -0700, Joshua D. Drake wrote: Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: What do you guys think of having a vacuum summary command? E.g.; VACUUM [FULL] [ANALYZE] SUMMARY ... that will turn SUMMARY into a fully reserved word ... Hmmm... good point. Other options would be: brief short terse? nutshell ;) review report -- This one is interesting although sufffers from the same problem. Good idea. I think its a good idea to make that info easily accessible. How about putting this in the logfile, without any command changes? Best Regards, Simon Riggs ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Vacuum summary?
Simon Riggs [EMAIL PROTECTED] writes: On Mon, 2005-07-11 at 12:38 -0700, Joshua D. Drake wrote: What do you guys think of having a vacuum summary command? E.g.; How about putting this in the logfile, without any command changes? Actually, tying it to VACUUM might not have been such a great idea in the first place. I think I did that because (a) the info is more likely to be up to date just after a VACUUM (though when you consider an entire installation rather than just one DB, this argument has big holes); and (b) people were already accustomed to seeing a lot of blather from a VACUUM VERBOSE command. It'd be relatively easy I think to extract the current FSM statistics in a function that could be invoked separately from VACUUM. Not sure how we ought to return 'em though --- the VACUUM way of a bunch of INFO messages is a bit old-fashioned. Maybe a statistics view? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Vacuum summary?
It'd be relatively easy I think to extract the current FSM statistics in a function that could be invoked separately from VACUUM. Not sure how we ought to return 'em though --- the VACUUM way of a bunch of INFO messages is a bit old-fashioned. Maybe a statistics view? That would work for me. regards, tom lane -- Your PostgreSQL solutions company - Command Prompt, Inc. 1.800.492.2240 PostgreSQL Replication, Consulting, Custom Programming, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, plPerlNG - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] dbt2 opteron performance
Hi Mark, Great stuff. One of the things that led me to PostgreSQL a couple years back was the exceptional OLTP performance I was able to wring out of it when running my own internal benchmarks against it. I have a couple questions (that I apologize if they are answered elsewhere). Note that the reason I ask is that I want to make sure we are getting close to comparing apples to apples with how the commercial companies legally run their tpc benchmarks. 1 - R we using 15,000 RPM SCSI drives mostly configured together as RAID-0. Also what about write-ahead logging and background writing and grouping transactions and ... 2 - I forget the brand off the top of my head, but, I don't think that most commercial tpc tests use Adaptec controllers. 3 - R we yet testing with dual core Opterons (or at least two dual core opterons) It's perfectly reasonable if because of cost considerations the answer is not yet to my questions above. For #1 above, a lot of people say but that's a bad idea To that I say yeah, but... it's the only way to compare apples to apples when comparing Postgres to published benchmarks commercial rdbms performance. Please email me privately if there is some way EntepriseDB may be able to help. --Denis Lussier Chief Architect and Chairman EnterpriseDB Corporation -Original Message- From: [EMAIL PROTECTED] [mailto:pgsql-hackers- [EMAIL PROTECTED] On Behalf Of Mark Wong Sent: Tuesday, July 12, 2005 3:47 PM To: pgsql-hackers@postgresql.org; [EMAIL PROTECTED] Subject: [HACKERS] dbt2 opteron performance I'm starting to get results with dbt2 on a 4-way opteron system and wanted to share what I've got so far since people have told me in the past that this architecture is more interesting than the itanium2 that I've been using. This 4-way has 8GB of memory and four Adaptec 2200s controllers attached to 80 spindles (eight 10-disk arrays). For those familiar with the schema, here is a visual of the disk layout: http://www.osdl.org/projects/dbt2dev/results/dev4-015/layout-6.html Results for a 600 warehouse run are there: http://www.osdl.org/projects/dbt2dev/results/dev4-015/6/ The tuning is a still a bit off, but feel free to let me know if there are any issues anyway. Mark ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(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: [HACKERS] PL/Perl list value return causes segfault
David Fetter wrote: On Tue, Jul 12, 2005 at 03:45:55PM -0400, Andrew Dunstan wrote: In perl, if there is any ambiguity it is the called function that is responsible for checking, not the caller. See perldoc -f wantarray. PLPerl explicitly passed G_SCALAR as a flag on all calls to plperl routines. So returning a list is a case of pilot error. Is this a kind of pilot error that documents could help avert in some useful way? Sure. A plperl function must always return a scalar value.More complex structures (arrays, records, and sets) can be returned in the appropriate context by returning a reference. A list should never be returned. Salt to taste and insert where appropriate. cheers andrew ---(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] PL/Perl list value return causes segfault
On Tue, Jul 12, 2005 at 02:59:37PM -0400, Andrew Dunstan wrote: Note that all plperl functions are called in scalar context, and it is always wrong to return a list (as opposed to a listref). In fact, the value received might surprise you even if it worked (it would be the value of the last member of the list). Yeah, I knew that returning a list was contrary to what was expected, but I wanted to see what would happen. I wasn't expecting a core dump :-( Thanks for the patch. -- Michael Fuhr http://www.fuhr.org/~mfuhr/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] HEAD doesn't cope with libraries in non-default
Patch applied. Thanks. --- Peter Eisentraut wrote: I wrote: So either we code up some intelligence to put the C in the right position or we have to pass down A B and D separately from the main makefile. The following patch might just do the former. Please try it out. diff -ur ../cvs-pgsql/src/Makefile.shlib ./src/Makefile.shlib --- ../cvs-pgsql/src/Makefile.shlib 2005-07-04 16:32:57.0 +0200 +++ ./src/Makefile.shlib2005-07-05 22:02:10.556162778 +0200 @@ -240,7 +240,7 @@ SHLIB_LINK += -ltermcap -lstdc++.r4 -lbind -lsocket -L/boot/develop/lib/x86 endif -SHLIB_LINK := $(filter -L%, $(LDFLAGS)) $(SHLIB_LINK) +SHLIB_LINK := $(filter -L%, $(SHLIB_LINK)) $(filter -L%, $(LDFLAGS)) $(filter-out -L%, $(SHLIB_LINK)) ifeq ($(enable_rpath), yes) SHLIB_LINK += $(rpath) endif -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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 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] [PATCHES] thousands comma numeric formatting in psql
David Fetter wrote: On Tue, Jul 12, 2005 at 10:48:40AM -0400, Bruce Momjian wrote: Peter Eisentraut wrote: Am Dienstag, 12. Juli 2005 05:29 schrieb Bruce Momjian: Bruce Momjian wrote: The current state allows users to manually set the format, or actually only one aspect of the format? Where can you set the decimal separator and the size of the grouping (3 digits or 4 digits)? Is this capability even useful to get localized behavior? You can't change the grouping from three, This makes it a non-starter, IMHO. One set of people who use 4 digits is this little ethnic group called the Chinese. I didn't know that. My other concern is that if we allow manual specification of the output format of some data type, then eventually someone will want to specify the format of some other data type as well, such as the date/time types. We should think about whether we want to be consistent here. We do allow MDY and DMY specification, but that controls both input and output in the server, while this just controls psql display. It is a good question how other settings should be handled, but I don't know the answers. Anyone? Hrm. I think we can safely tackle input and output as separate features here. What do we do for to_char() with such separators? Well, it isn't so much the input/output issue, but that the output control is only in psql. Is that OK? I don't image we could ever put input functionality in psql, only in the server. -- Bruce Momjian| http://candle.pha.pa.us pgman@candle.pha.pa.us | (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: Have you searched our list archives? http://archives.postgresql.org
