Re: [HACKERS] hex integer input
On Fri, 2 Mar 2007, Tom Lane wrote: Jeremy Drake [EMAIL PROTECTED] writes: On several occasions I have wanted to input integers in hexadecimal rather than in decimal in PostgreSQL. I notice that there is a to_hex function, but there is not (AFAIK) a way to provide an integer in hexadecimal. regression=# select x'abcd'::int; int4 --- 43981 (1 row) Hmm. I actually used the bit(N) type on a project quite some time ago, but it did not occur to me to use the bit string input syntax to input an integer. Well, I guess there is a way after all. So in the immortal words of Emily Litella, Never mind. -- In an organization, each person rises to the level of his own incompetency -- The Peter Principle ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] xlogViewer / xlogdump
Hi Does anyone has an idea how xlogdump works with Windows installation of Postgres. I have postgres 8.2.x installed on my windows PC. How do we install it on Linux box with existing postgres 8.2.x installation Thanks Vishal _ Find a local pizza place, movie theater, and more .then map the best route! http://maps.live.com/?icid=hmtag1FORM=MGAC01 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] CLUSTER, using SHARE UPDATE EXCLUSIVE lock?
That's lock upgrading, which opens you up to deadlocks. If another process grabs a lock after your update exclusive, you're not going to be able to upgrade it. OK I got the point. Is it possible to create a new table-level lock mode that says OK, now I'm on share level, but soon I will upgrade it to exclusive. Then it would be possible to allow any read-only operation, and to forbid all operation that would need to upgrade. I know that there is a sx_try_upgrade function on freeBSD kernel (man sx), so I guess there is a way to do it, isn't it? Regards, Jonathan Scher ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] xlogViewer / xlogdump
I am getting a following error while make install for xlogdump - [EMAIL PROTECTED] xlogdump]# make install gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing xlogdump.o .../../src/port/sprompt.o ../../src/backend/utils/hash/pg_crc.o -L../../src/port -lpgport -L../../src/interfaces/libpq -lpq -L../../src/port -Wl,-rpath,'/usr/local/pgsql/lib' -lpgport -lz -lreadline -ltermcap -lcrypt -ldl -lm -o xlogdumpxlogdump.o(.text+0x163f): In function `dumpXLog': : undefined reference to `__stack_chk_fail' collect2: ld returned 1 exit status make: *** [xlogdump] Error 1 Please anyone can help in the same From: Vishal Arora [EMAIL PROTECTED] To: pgsql-hackers@postgresql.org Subject: [HACKERS] xlogViewer / xlogdump Date: Fri, 02 Mar 2007 08:54:07 + Hi Does anyone has an idea how xlogdump works with Windows installation of Postgres. I have postgres 8.2.x installed on my windows PC. Thanks Vishal _ Find a local pizza place, movie theater, and more .then map the best route! http://maps.live.com/?icid=hmtag1FORM=MGAC01 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings _ With tax season right around the corner, make sure to follow these few simple tips. http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMFebtagline ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] HOT - whats next ?
Hi All, The version 4.0 of HOT patch is very close to the state where we can start considering it for testing for correctness as well as benchmarking, if there is sufficient interest to give it a chance for 8.3 I have very little clue about what community thinks about HOT and the patch, but I am ready to do whatever it needs to increase quality of the patch. But I need reviews and feedback to do that. IMHO there are two things that need to be done to make HOT feature complete. They are, - Support for VACUUM FULL - Support for CREATE INDEX Simon has interest working on these items. I have some ideas for supporting CREATE INDEX, but would wait for Simon's thoughts on this. Then there are several optimization and tuning work that needs to be done. I am planning to start work on the following two items and need suggestions/comments to make sure that I am following the right path: - With Tom/Heikki's recent patch of tracking free line pointers, we have some bits available in the page header for book-keeping. I plan to use one bit to track if there are any LP_DELETEd items on the page. This information would help us to quickly check if its worth searching through the line pointers to find a LP_DELETED item. The flag will be set whenever a tuple is marked LP_DELETEd and reset in page-VACUUM and whenever we fail to find a LP_DELETEd item for reuse. - Another problem with the current HOT patch is that it generates tuple level fragmentation while reusing LP_DELETEd items when the new tuple is of smaller size than the original one. Heikki supported using best-fit strategy to reduce the fragmentation and thats worth trying. But ISTM that we can also correct row-level defragmentation whenever we run out of free space and LP_DELETEd tuples while doing UPDATE. Since this does not require moving tuples around, we can do this by a simple EXCLUSIVE lock on the page. A bit to track row-level fragmentation would help. These would be just hint-bits and changes need not be WAL logged. We could have done better with some sort of counters, but that would require heap-page specific data and that may not necessarily be a good idea. Comments ? Thanks, Pavan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] xlogViewer / xlogdump
On 3/2/07, Vishal Arora [EMAIL PROTECTED] wrote: I am getting a following error while make install for xlogdump - For some reason, Diogo kept his already-built code in there, so you need to do a make clean make install -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] UPSERT
Hello, I'd like to work on TODO item: Add REPLACE or UPSERT command that does UPDATE, or on failure, INSERT could you please tell me if I'm going in the right way? There are some different syntaxes possible, but MySQL has an interesting one here: http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1; This allow to make an insert, and if the key is already there to modify the value depending on the current one. Then I have two choices possible: - Search for existing tuples among key or unique constraint, then if nothing is found, insert it. - Try to insert a new row, catch if there is any error, and then search for all tuple matching. As it would be a new command, I have no idea on what the data could be. Does syntax meet your needs? Which choice should I implement? Regards Jonathan Scher ---(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] UPSERT
Jonathan Scher wrote: Hello, I'd like to work on TODO item: Add REPLACE or UPSERT command that does UPDATE, or on failure, INSERT could you please tell me if I'm going in the right way? There are some different syntaxes possible, but MySQL has an interesting one here: http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1; This allow to make an insert, and if the key is already there to modify the value depending on the current one. Then I have two choices possible: - Search for existing tuples among key or unique constraint, then if nothing is found, insert it. - Try to insert a new row, catch if there is any error, and then search for all tuple matching. As it would be a new command, I have no idea on what the data could be. Does syntax meet your needs? Which choice should I implement? Good. Some thoughts from the top of the head: Is insert or on failure update semantically equivalent to update or on failure insert? If not the former seems more desirable to me anyway. What are the syntax alternatives? This one from MySQL doesn't seem too bad, but it would be good to have them all on the table. My instinct would be to follow your first strategy, i.e. detect which path is needed rather than try one and then if it fails do the other. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] UPSERT
Andrew Dunstan wrote: Jonathan Scher wrote: Hello, I'd like to work on TODO item: Add REPLACE or UPSERT command that does UPDATE, or on failure, INSERT could you please tell me if I'm going in the right way? There are some different syntaxes possible, but MySQL has an interesting one here: http://dev.mysql.com/doc/refman/5.0/en/insert-on-duplicate.html INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1; This allow to make an insert, and if the key is already there to modify the value depending on the current one. May this could be generalized to a generic stmt on error do stmt? You could then write update table set c=c+1 on not_found do insert into table (a,b,c) values (1,2,3) Just an idea I just had... greetings, Florian Pflug ---(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] UPSERT
Florian G. Pflug [EMAIL PROTECTED] writes: INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1; This allow to make an insert, and if the key is already there to modify the value depending on the current one. May this could be generalized to a generic stmt on error do stmt? You could then write update table set c=c+1 on not_found do insert into table (a,b,c) values (1,2,3) Just an idea I just had... We have such a thing, subtransactions. The reason UPSERT or ON DUPLICATE is interesting is because it provides a way to do it atomically. That is, you keep the locks acquired from the duplicate key check and if it fails you update the same records you just found violating the duplicate key. If the user tries to do the same thing he has to repeat the search after the duplicate key check has released the locks so it's possible they've been deleted or updated since. So the user has to loop in case the update fails to find any records and he has to start over trying to insert. The same problem plagues you if you do it the other way around too. The tricky part is avoiding race conditions. The way the unique index code avoids having someone else come along and insert at the same time is by holding a lock on an index page. I'm not sure if you can keep that lock while you go lock the tuples for the update. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] HOT - whats next ?
Pavan Deolasee [EMAIL PROTECTED] writes: - Another problem with the current HOT patch is that it generates tuple level fragmentation while reusing LP_DELETEd items when the new tuple is of smaller size than the original one. Heikki supported using best-fit strategy to reduce the fragmentation and thats worth trying. But ISTM that we can also correct row-level defragmentation whenever we run out of free space and LP_DELETEd tuples while doing UPDATE. Since this does not require moving tuples around, we can do this by a simple EXCLUSIVE lock on the page. You are mistaken. To move existing tuples requires LockBufferForCleanup, the same as VACUUM needs; otherwise some other backend might continue to access a tuple it found previously. How much testing of this patch's concurrent behavior has been done? I'm wondering if any other locking thinkos are in there ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] UPSERT
Andrew Dunstan [EMAIL PROTECTED] writes: My instinct would be to follow your first strategy, i.e. detect which path is needed rather than try one and then if it fails do the other. The very first thing you need to think about is how to solve the race condition problem, ie, two backends concurrently trying to insert identical data. Until you have a plausible mechanism for that, the whole thing is pie-in-the-sky. 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] HOT - whats next ?
On 3/2/07, Tom Lane [EMAIL PROTECTED] wrote: Pavan Deolasee [EMAIL PROTECTED] writes: - Another problem with the current HOT patch is that it generates tuple level fragmentation while reusing LP_DELETEd items when the new tuple is of smaller size than the original one. Heikki supported using best-fit strategy to reduce the fragmentation and thats worth trying. But ISTM that we can also correct row-level defragmentation whenever we run out of free space and LP_DELETEd tuples while doing UPDATE. Since this does not require moving tuples around, we can do this by a simple EXCLUSIVE lock on the page. You are mistaken. To move existing tuples requires LockBufferForCleanup, the same as VACUUM needs; otherwise some other backend might continue to access a tuple it found previously. I am not suggesting moving tuples around. This is a specific case of reusing LP_DELETEd tuples. For example, say the HOT-update chain had two tuples, the first one is of length 100 and next one is of length 125. When the first becomes dead, we remove it from the chain and set its LP_DELETE true. Now, this tuple is say reused to store a tuple of length 80, this results in tuple level fragmentation of 20 bytes. The information about the original size of the tuple is lost. Later of when this tuple is also LP_DELETEd, we can not use it store tuple of size greater than 80, even though there is unused free space of another 20 bytes. What I am suggesting is to clean up this fragmentation (only for LP_DELETEd tuples) by resetting the lp_len of these tuples to the max possible value. None of the live tuples are touched. Btw, I haven't yet implemented this stuff, so I am seeking opinions. How much testing of this patch's concurrent behavior has been done? I'm wondering if any other locking thinkos are in there ... I have tested it on pgbench with maximum 90 clinets and 90 scaling factor, with 5 txns/client (please see my another post of preliminary results). I have done this quite a few time. Not that I am saying there are no bugs, but I have good confidence in the patch. These tests are done on SMP machines. I also run data consistency checks at the end of pgbench runs to validate the UPDATEs. I also ran 4 hour DBT2 tests 3-4 times, not seen any failures. I would appreciate if there are any independent tests, may be in different setups. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] UPSERT
Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: My instinct would be to follow your first strategy, i.e. detect which path is needed rather than try one and then if it fails do the other. The very first thing you need to think about is how to solve the race condition problem, ie, two backends concurrently trying to insert identical data. Until you have a plausible mechanism for that, the whole thing is pie-in-the-sky. How about: 1. Insert new heap tuple 2. Try to insert the index tuple. If there's a duplicate tuple, lock the existing tuple instead of throwing an error. 3. If there was no duplicate, we're done. 4. Otherwise, kill the new tuple inserted in step 1, by setting it's xmin to InvalidTransactionId. 5. Perform the UPDATE on the existing tuple. This requires one change to the indexam api: a duplicate key violation needs to lock the existing tuple instead of throwing an error. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] UPSERT
Gregory Stark wrote:
Florian G. Pflug [EMAIL PROTECTED] writes:
INSERT INTO table (a,b,c) VALUES (1,2,3) ON DUPLICATE KEY UPDATE c=c+1;
This allow to make an insert, and if the key is already there to modify the
value depending on the current one.
May this could be generalized to a generic stmt on error do stmt?
You could then write
update table set c=c+1 on not_found do insert into table (a,b,c) values
(1,2,3)
Just an idea I just had...
We have such a thing, subtransactions.
Yeah, I know - but the syntax above would provide a way to write that inline
instead of doing it at the application (or plpgsql) level.
The reason UPSERT or ON DUPLICATE is interesting is because it provides a way
to do it atomically. That is, you keep the locks acquired from the duplicate
key check and if it fails you update the same records you just found violating
the duplicate key.
If the user tries to do the same thing he has to repeat the search after the
duplicate key check has released the locks so it's possible they've been
deleted or updated since. So the user has to loop in case the update fails to
find any records and he has to start over trying to insert. The same problem
plagues you if you do it the other way around too.
I agree - my generic syntax seems to be too generic, and doesn't take
locking into account.. :-(
The tricky part is avoiding race conditions. The way the unique index code
avoids having someone else come along and insert at the same time is by
holding a lock on an index page. I'm not sure if you can keep that lock while
you go lock the tuples for the update.
Maybe doing the following would work:
start:
do_index_lookup
if (found_row) {
lock_row
if (acquired_lock) {
do_update
return
}
//Row was deleted
}
create_row_on_heap
create_index_entry
if (success)
return
else {
mark_row_as_deleted //or remove row?
goto start
}
It seems like this would work without creating a subtransaction, but
I'm not really sure..
greetings, Florian Pflug
---(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
[HACKERS] GIST and TOAST
I have a problem getting packed varlenas to work with GIST indexes. Namely,
the GIST code doesn't call pg_detoast_datum() enough. Instead of using the
DatumGetFoo() macros it uses DatumGetPointer() and calls PG_DETOAST_DATUM only
when it thinks it'll be necessary.
I've temporarily made the packed varlena code ignore user defined data types.
This isn't very satisfactory though since it means domains over things like
text don't get packed.
And in any case even with this in place it doesn't fix all the problems. The
Postgres regression tests pass but I can still trigger problems because the
GIST code doesn't reliably call detoast even on user data types they're given.
I think these are actual bugs. If you happened to provide a large enough datum
to the gist code it would cause the same problem I'm seeing. The packed
varlena patch just makes it easier to trigger.
I've fixed the problems I'm seeing with the following patch to _int_gist.c.
But I'm not sure it's correct. What I'm afraid of is that I'm not sure where
these functions are being called from and whether they expect to be leaking
memory. If they're expected to not leak memory then they're now leaking the
detoasted datum and that's a problem.
I'm also wondering if there aren't similar problems in the dozens of other
gist indexing modules...
I wouldn't mind a second pair of eyes on the _int_gist.c changes if there's
someone who can tell me whether any of these functions require a
PG_FREE_IF_COPY or equivalent.
Index: _int_gist.c
===
RCS file: /home/stark/src/REPOSITORY/pgsql/contrib/intarray/_int_gist.c,v
retrieving revision 1.16
diff -u -r1.16 _int_gist.c
--- _int_gist.c 4 Oct 2006 00:29:45 - 1.16
+++ _int_gist.c 2 Mar 2007 16:09:26 -
@@ -1,6 +1,6 @@
#include _int.h
-#define GETENTRY(vec,pos) ((ArrayType *)
DatumGetPointer((vec)-vector[(pos)].key))
+#define GETENTRY(vec,pos) (DatumGetArrayTypeP((vec)-vector[(pos)].key))
/*
** GiST support methods
@@ -39,7 +39,7 @@
if (strategy == BooleanSearchStrategy)
{
retval = execconsistent((QUERYTYPE *) query,
- (ArrayType *)
DatumGetPointer(entry-key),
+
DatumGetArrayTypeP(entry-key),
GIST_LEAF(entry));
pfree(query);
@@ -58,7 +58,7 @@
switch (strategy)
{
case RTOverlapStrategyNumber:
- retval = inner_int_overlap((ArrayType *)
DatumGetPointer(entry-key),
+ retval =
inner_int_overlap(DatumGetArrayTypeP(entry-key),
query);
break;
case RTSameStrategyNumber:
@@ -70,21 +70,21 @@
PointerGetDatum(retval)
);
else
- retval = inner_int_contains((ArrayType *)
DatumGetPointer(entry-key),
+ retval =
inner_int_contains(DatumGetArrayTypeP(entry-key),
query);
break;
case RTContainsStrategyNumber:
case RTOldContainsStrategyNumber:
- retval = inner_int_contains((ArrayType *)
DatumGetPointer(entry-key),
+ retval =
inner_int_contains(DatumGetArrayTypeP(entry-key),
query);
break;
case RTContainedByStrategyNumber:
case RTOldContainedByStrategyNumber:
if (GIST_LEAF(entry))
retval = inner_int_contains(query,
- (ArrayType *)
DatumGetPointer(entry-key));
+
DatumGetArrayTypeP(entry-key));
else
- retval = inner_int_overlap((ArrayType *)
DatumGetPointer(entry-key),
+ retval =
inner_int_overlap(DatumGetArrayTypeP(entry-key),
query);
break;
default:
@@ -282,10 +282,10 @@
float tmp1,
tmp2;
- ud = inner_int_union((ArrayType *) DatumGetPointer(origentry-key),
-(ArrayType *)
DatumGetPointer(newentry-key));
+ ud = inner_int_union(DatumGetArrayTypeP(origentry-key),
+
Re: [HACKERS] HOT - preliminary results
On 3/2/07, Tatsuo Ishii [EMAIL PROTECTED] wrote: Just for curiosity, I would like to ask you why you need to modify pgbench. pgbench can accept custom SQL scripts... Oh yes, there was no real need to modify pgbench. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] HOT - whats next ?
On Fri, 2007-03-02 at 10:08 -0500, Tom Lane wrote: How much testing of this patch's concurrent behavior has been done? I'm wondering if any other locking thinkos are in there ... This version of HOT is being developed from scratch, with as much feedback from the community as possible. The idea was to build it up brick by brick, so that each assumption/decision could be challenged as we go. The idea was to avoid a huge review at the end, which could lead to a fatal flaw being discovered too late to make the release. An earlier version had extensive analysis of locking to confirm it worked, but this current version is aiming for minimal invasiveness. So this version hasn't had extensive testing - yet. But we learned lots of lessons along the way and that thinking goes into what we have now - locking is an area of continual concern. Intermediate reviews would be very useful, if thats possible. The right kind of testing is clearly going to be important to getting HOT right. Back in July, we spent some time building concurrent psql specifically to allow test cases to be written that referenced multiple sessions. Even if we don't like that thought for production, it would be great to be able to have a tool that allowed multi-session test cases to be written. Experience was that it was much, much easier to get a test case written in a single script where you could easily read the statement history. It would also be very useful to have a version of pgstattuple that worked with heaps, so test cases can be written that examine the header fields, info flags etc. It would be useful to be able to specify the basic behaviour in terms of explicit test cases. Would those two approaches to test execution be desirable in the regression tests? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Patch license update to developer's FAQ
I have added to the developer's FAQ that we don't want non-BSD-compatible licensed patches: liPostgreSQL is licensed under a BSD license. By posting a patch to the public PostgreSQL mailling lists, you are giving the PostgreSQL Global Development Group the non-revokable right to distribute your patch under the BSD license. If you use code that is available under a BSD-compatible license (eg. public domain), please note that in your email submission. If the license is not BSD-compatible (e.g. GPL), please do not post the patch./li -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UPSERT
On Fri, 2007-03-02 at 15:41 +, Heikki Linnakangas wrote: Tom Lane wrote: Andrew Dunstan [EMAIL PROTECTED] writes: My instinct would be to follow your first strategy, i.e. detect which path is needed rather than try one and then if it fails do the other. The very first thing you need to think about is how to solve the race condition problem, ie, two backends concurrently trying to insert identical data. Until you have a plausible mechanism for that, the whole thing is pie-in-the-sky. How about: 1. Insert new heap tuple 2. Try to insert the index tuple. If there's a duplicate tuple, lock the existing tuple instead of throwing an error. 3. If there was no duplicate, we're done. 4. Otherwise, kill the new tuple inserted in step 1, by setting it's xmin to InvalidTransactionId. 5. Perform the UPDATE on the existing tuple. This requires one change to the indexam api: a duplicate key violation needs to lock the existing tuple instead of throwing an error. So if the INSERT fails we will leave two dead copies of the tuples? Hmm. Seems like we should try to locate a row first, then INSERT if we cannot find one. That's slower on INSERT but more balanced overall - sometimes the input will generate all UPDATEs, sometimes all INSERTs we'll never know. I'm a bit surprised the TODO didn't mention the MERGE statement, which is the SQL:2003 syntax for specifying this as an atomic statement. There are lots of other syntaxes, the most simple of which are the MySQL REPLACE and Teradata's UPDATE ... ELSE INSERT. As seductive as they are, I'd say that's all the more reason to go with the single approved syntax. If MySQL are standards compliant, they will support that also, so we get MySQL compatibility either way. Another thought that really ought to be on the TODO is a MERGE FROM (pick your syntax) that allows MERGE to act like a COPY, reading data from an external data file. That would save effort, since the only way of doing this currently is to do a COPY then an UPDATE and then an INSERT. So the MERGE FROM would reduce three operations to just a single command. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] UPSERT
Simon Riggs [EMAIL PROTECTED] writes: Seems like we should try to locate a row first, then INSERT if we cannot find one. That's slower on INSERT but more balanced overall Except it still has the race condition. I'm a bit surprised the TODO didn't mention the MERGE statement, which is the SQL:2003 syntax for specifying this as an atomic statement. I believe we concluded that MERGE doesn't actually do quite what people want/expect. Please go back and read the archives. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] UPSERT
Simon Riggs wrote: I'm a bit surprised the TODO didn't mention the MERGE statement, which is the SQL:2003 syntax for specifying this as an atomic statement. http://archives.postgresql.org/pgsql-hackers/2004-05/thrd5.php#00497 There is a thread there entitled Adding MERGE to the TODO list ---(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] Updated propsoal for read-only queries on PITRslaves (SoC 2007)
On Thu, 2007-03-01 at 15:45 +0100, Florian G. Pflug wrote: I'm looking forward to any kind of suggestions, ideas, or critism - I'd like my proposal to be as detailed as possible before I submit it to SoC, so that if I get a chance to work on it, I can be reasonable sure that people here are happy with the way I approach the problem. I'm happy with your approach to the problem: - your thinking is in detail, written and clear - you cover various options, not just your favourite - you're doing it on list So I'll support you SoC submission. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch license update to developer's FAQ
Bruce Momjian wrote: I have added to the developer's FAQ that we don't want non-BSD-compatible licensed patches: liPostgreSQL is licensed under a BSD license. By posting a patch to the public PostgreSQL mailling lists, you are giving the PostgreSQL Global Development Group the non-revokable right to distribute your patch under the BSD license. If you use code that is available under a BSD-compatible license (eg. public domain), please note that in your email submission. If the license is not BSD-compatible (e.g. GPL), please do not post the patch./li How about something simpler: liPostgreSQL is licensed under a BSD license. Patches that are submitted another a non-compatible license (such as the GPL) will be ignored./li -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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] UPSERT
Bricklen Anderson [EMAIL PROTECTED] writes: http://archives.postgresql.org/pgsql-hackers/2004-05/thrd5.php#00497 There is a thread there entitled Adding MERGE to the TODO list The more interesting discussion is the one that got it taken off TODO again, from Nov 2005. Try these threads: http://archives.postgresql.org/pgsql-hackers/2005-11/msg00501.php http://archives.postgresql.org/pgsql-hackers/2005-11/msg00536.php regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] GIST and TOAST
On 2007-03-02, Gregory Stark [EMAIL PROTECTED] wrote: I think these are actual bugs. If you happened to provide a large enough datum to the gist code it would cause the same problem I'm seeing. The packed varlena patch just makes it easier to trigger. Are you taking into account the fact that, at least prior to your patch, values in index tuples could never be toasted? -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] UPSERT
On Fri, 2007-03-02 at 13:19 -0500, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: Seems like we should try to locate a row first, then INSERT if we cannot find one. That's slower on INSERT but more balanced overall Except it still has the race condition. I'm not saying it didn't; but dropping in two dead copies of a tuple isn't acceptable either. I'm a bit surprised the TODO didn't mention the MERGE statement, which is the SQL:2003 syntax for specifying this as an atomic statement. I believe we concluded that MERGE doesn't actually do quite what people want/expect. Please go back and read the archives. Yes, it was my thread. I recall that there wasn't any acceptable answer to how it could be done with reasonable efficiency. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(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] Expanding DELETE/UPDATE returning
On Tue, Feb 27, 2007 at 15:07:06 +0100, Florian G. Pflug [EMAIL PROTECTED] wrote: select * from t1, (delete from t2 returning t2.t1_id) where t1.id = t2.t1_id limit 1 ; I for my part couldn't even say what I'd expect that query to do. I would expect it to delete all rows from t2 but only return 1 row as output. I think the ambiguous cases are going to come from cases where deleting some rows in a subquery changes which rows will be deleted in subsequent executions of the same subquery. Something like deleting the row with the least value for some column. ---(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] GIST and TOAST
Andrew - Supernews [EMAIL PROTECTED] writes: On 2007-03-02, Gregory Stark [EMAIL PROTECTED] wrote: I think these are actual bugs. If you happened to provide a large enough datum to the gist code it would cause the same problem I'm seeing. The packed varlena patch just makes it easier to trigger. Are you taking into account the fact that, at least prior to your patch, values in index tuples could never be toasted? False --- see index_form_tuple(). 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] Patch license update to developer's FAQ
Joshua D. Drake wrote: Bruce Momjian wrote: I have added to the developer's FAQ that we don't want non-BSD-compatible licensed patches: liPostgreSQL is licensed under a BSD license. By posting a patch to the public PostgreSQL mailling lists, you are giving the PostgreSQL Global Development Group the non-revokable right to distribute your patch under the BSD license. If you use code that is available under a BSD-compatible license (eg. public domain), please note that in your email submission. If the license is not BSD-compatible (e.g. GPL), please do not post the patch./li How about something simpler: liPostgreSQL is licensed under a BSD license. Patches that are submitted another a non-compatible license (such as the GPL) will be ignored./li No, I don't people even seeing GPL patches on our lists. There is too much of a chance of accident, and possible problems if we re-implemented with a BSD license. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] Patch license update to developer's FAQ
Bruce Momjian wrote: Joshua D. Drake wrote: Bruce Momjian wrote: I have added to the developer's FAQ that we don't want non-BSD-compatible licensed patches: liPostgreSQL is licensed under a BSD license. By posting a patch to the public PostgreSQL mailling lists, you are giving the PostgreSQL Global Development Group the non-revokable right to distribute your patch under the BSD license. If you use code that is available under a BSD-compatible license (eg. public domain), please note that in your email submission. If the license is not BSD-compatible (e.g. GPL), please do not post the patch./li How about something simpler: liPostgreSQL is licensed under a BSD license. Patches that are submitted another a non-compatible license (such as the GPL) will be ignored./li No, I don't people even seeing GPL patches on our lists. There is too much of a chance of accident, and possible problems if we re-implemented with a BSD license. Neither clause solves the issue you describe here. The only thing my clause does it make it so people might actually read it ;). In general, people have very short attention spans and they have no desire to read a long paragraph about something that is really two sentences. We could adjust a bit though: liPostgreSQL is licensed under a BSD license. We will only accept patches that are submitted under a BSD license. All others shall be rejected./li Using the word rejected provides a sense of us declaring outright, NO to anything but BSD versus an implicit ignoring. Thoughts? Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] SOC user quotas
On Thursday 01 March 2007 17:35, Andrew Dunstan wrote:
Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
Andrew Dunstan wrote:
Hitting a file system quota limit is likely to bring you down pretty
hard, isn't it?
Yes, and likely corrupt the database.
As long as you don't keep WAL on the restricted filesystem, it won't
stop or corrupt your database. Whether you can get anything much done
is another story :-(
Yeah. Including recovery. Maybe we could do something that would work in
cooperation with FS quotas - I have no idea what though.
I've actually run postgresql systems out of disk space both on data partitions
and wal partitions and never suffered corruption. Certainly I don't
recommend the practice, but pg can be amazingly resilient at times.
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] UPSERT
Tom Lane wrote: Bricklen Anderson [EMAIL PROTECTED] writes: http://archives.postgresql.org/pgsql-hackers/2004-05/thrd5.php#00497 There is a thread there entitled Adding MERGE to the TODO list The more interesting discussion is the one that got it taken off TODO again, from Nov 2005. Try these threads: http://archives.postgresql.org/pgsql-hackers/2005-11/msg00501.php http://archives.postgresql.org/pgsql-hackers/2005-11/msg00536.php regards, tom lane Yeah, that's a better set of threads. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] UPSERT
Couple notes: (1) Upsert is not just a desire of MySQL users. I just spec'd a major proprietary-database replacement project at a fortune 500 where they want an Upsert and are unhappy that PostgreSQL doesn't have it. Unfortunately, they don't want to spring for development funds :-( (2) Doing upsert by checking for a unique key violaton error leads to horrible performance in addition to the previously mentioned race conditions. -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] GIST and TOAST
On 2007-03-02, Tom Lane [EMAIL PROTECTED] wrote: Andrew - Supernews [EMAIL PROTECTED] writes: On 2007-03-02, Gregory Stark [EMAIL PROTECTED] wrote: I think these are actual bugs. If you happened to provide a large enough datum to the gist code it would cause the same problem I'm seeing. The packed varlena patch just makes it easier to trigger. Are you taking into account the fact that, at least prior to your patch, values in index tuples could never be toasted? False --- see index_form_tuple(). My mistake. A closer reading, however, shows that at least for cases like intarray, btree_gist, etc., the detoasting of an index value is being done in the gist decompress function, so the value seen via GISTENTRY in the other functions should already have been detoasted once. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Google SoC: lots of discussion, very few mentors
Josh, If the new FTS will be accepted I'd like to see phppgadmin, pgadmin3 support for nice FTS configuration. In that case I could be a mentor. In principle, I have candidate for phppgadmin work. Oleg On Thu, 1 Mar 2007, Josh Berkus wrote: All, Well, there were 30+ posts on the Google SoC thread. However, at the end of it only Robert Treat, Dave Page, Mark Wong, and Josh Drake volunteered to be mentors. Note that there's not *one* core-backend-code-committer in that list. We really, really, really need a couple of core-code committers on the mentor list. Or give up on having any core patches from SoC. Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] HOT - preliminary results
Simon Riggs wrote: On Thu, 2007-03-01 at 22:35 +0530, Pavan Deolasee wrote: Merlin Moncure wrote: On 3/1/07, Pavan Deolasee [EMAIL PROTECTED] wrote: seems pretty solid except for one possible problem...at one point when I dropped then later added the index on 'abalance', I got spammed 'WARNING: found a HOT-updated tuple' from psql prompt. Thats intentional. We don't yet support CREATE INDEX on a HOT-updated table. This is one of the major unfinished TODO items before we can consider patch feature complete. I have left the warning to catch this case till then. CREATE INDEX and VACUUM FULL will require changes. Proposals for VACUUM FULL have been posted, CREATE INDEX should be there tomorrow. CLUSTER does not need changes for HOT, as things stand currently, mainly because its MVCC behaviour is broken. That's oddly discouraging. :-) -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] WITH/RECURSIVE plans
Hello, Unfortunately we (the community) will not have WITH/RECURSIVE for 8.3. However I have spoken with a Alexey and Alvaro and Command Prompt has decided to make WITH/RECURSIVE a priority for 8.4. Our current goals are to spend time over the next couple of months determining a roadmap of how to get the feature completed. We will then post that roadmap to the community for comments. Our hope is to begin development on the feature as soon as reasonably possible after the 8.4 tree opens. Sincerely, Joshua D. Drake Command Prompt, Inc. ---(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] WITH/RECURSIVE plans
On Fri, Mar 02, 2007 at 10:52:14AM -0800, Joshua D. Drake wrote: Hello, Unfortunately we (the community) will not have WITH/RECURSIVE for 8.3. However I have spoken with a Alexey and Alvaro and Command Prompt has decided to make WITH/RECURSIVE a priority for 8.4. Any chance we can get WITH without RECURSIVE? That would be very handy all by itself. Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] WITH/RECURSIVE plans
David Fetter wrote: On Fri, Mar 02, 2007 at 10:52:14AM -0800, Joshua D. Drake wrote: Hello, Unfortunately we (the community) will not have WITH/RECURSIVE for 8.3. However I have spoken with a Alexey and Alvaro and Command Prompt has decided to make WITH/RECURSIVE a priority for 8.4. Any chance we can get WITH without RECURSIVE? That would be very handy all by itself. I don't think that we are comfortable committing to that. I will talk with Alvaro and see what he thinks. Joshua D. Drake Cheers, D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] HOT - preliminary results
Pavan Deolasee wrote: Zeugswetter Andreas ADI SD wrote: accounts 157895 (initial size) 49284 (increase) accounts_pkey 19709 (initial size) 19705 (increase) Just to clarify, the relation size and increase is in number of blocks. The numbers are quite impressive :-) Have you removed the selects on accounts too ? Yes. In the first set of results, SELECT on accounts is removed. Seems that should also show improvements. Do you prune chains during update also ? Yes, we do prune the chains during UPDATE, but only when we run out of free space and LP_DELETEd items on the page. And we prune all chains on the page in that case. Yep, that seems the most efficient approach. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(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] HOT - preliminary results
Tatsuo Ishii wrote: Just for curiosity, I would like to ask you why you need to modify pgbench. pgbench can accept custom SQL scripts... P.S. HOT seems to be one of the greatest enhancements since PostgreSQL was born! Yep, I share your enthusiasm. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] HOT - preliminary results
Bruce Momjian escribió: Simon Riggs wrote: On Thu, 2007-03-01 at 22:35 +0530, Pavan Deolasee wrote: Merlin Moncure wrote: On 3/1/07, Pavan Deolasee [EMAIL PROTECTED] wrote: seems pretty solid except for one possible problem...at one point when I dropped then later added the index on 'abalance', I got spammed 'WARNING: found a HOT-updated tuple' from psql prompt. Thats intentional. We don't yet support CREATE INDEX on a HOT-updated table. This is one of the major unfinished TODO items before we can consider patch feature complete. I have left the warning to catch this case till then. CREATE INDEX and VACUUM FULL will require changes. Proposals for VACUUM FULL have been posted, CREATE INDEX should be there tomorrow. CLUSTER does not need changes for HOT, as things stand currently, mainly because its MVCC behaviour is broken. That's oddly discouraging. :-) Apparently no one has been bothered enough to fix CLUSTER. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(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] WITH/RECURSIVE plans
David Fetter wrote: On Fri, Mar 02, 2007 at 10:52:14AM -0800, Joshua D. Drake wrote: Hello, Unfortunately we (the community) will not have WITH/RECURSIVE for 8.3. However I have spoken with a Alexey and Alvaro and Command Prompt has decided to make WITH/RECURSIVE a priority for 8.4. Any chance we can get WITH without RECURSIVE? That would be very handy all by itself. I spoke with Alvaro and he politely but firmly reminded me that we have an autovac committment to the 8.3 tree that we would prefer to keep. Sincerely, Joshua D. Drake Cheers, D -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Possible Bug: high CPU usage for stats collector in 8.2
On Thursday 01 March 2007 11:57, Tom Lane wrote: Darcy Buskermolen [EMAIL PROTECTED] writes: I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats collector on an 8.2.3 box investigation has lead me to belive that the stats file is written a lot more often that once every 500ms the following shows this behavior. Looks like someone broke the usage of PGSTAT_STAT_INTERVAL between 8.1 and 8.2 ... it's waiting 500 microseconds, not the intended 500 milliseconds. I can confirm that rev 1.140.2.3 of pgstat.c does fix this issue. The stats collector CPU usage has dropped from inexcess of 95% to 5% Thanks. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Darcy Buskermolen The PostgreSQL company, Command Prompt Inc. http://www.commandprompt.com/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] proposal: only superuser can change customized_options
Pavel Stehule wrote: From: Tom Lane [EMAIL PROTECTED] To: Pavel Stehule [EMAIL PROTECTED] CC: pgsql-hackers@postgresql.org Subject: Re: [HACKERS] proposal: only superuser can change customized_options Date: Fri, 02 Feb 2007 11:40:10 -0500 Pavel Stehule [EMAIL PROTECTED] writes: I want to use custmized option for security configuration one contrib library. Currently customized options are usable only for default configuration, because everybody can change it. It is substitution of global variables. Decision if option is protected or not can be based on name of option. I dislike making it depend on spelling. There was discussion of this problem before, and we had a much saner answer: when the module that defines the variable gets loaded, discard any local setting if the correct protection level of the variable is SUSET or higher. See the archives. regards, tom lane I am finding it. Pavel, Is there any chance you can work on this? I suspect I won't have time. You can see the original thread here: http://groups.google.com/group/pgsql.hackers/browse_thread/thread/3b7d67e56b83f327/baf344e221116f6e?lnk=gstq=custom+variable+classesrnum=1#baf344e221116f6e cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Possible Bug: high CPU usage for stats collector in 8.2
On Fri, 2 Mar 2007, Darcy Buskermolen wrote: On Thursday 01 March 2007 11:57, Tom Lane wrote: Darcy Buskermolen [EMAIL PROTECTED] writes: I'm observing high CPU usage (95%) of a 2.6GHz opteron by the stats collector on an 8.2.3 box investigation has lead me to belive that the stats file is written a lot more often that once every 500ms the following shows this behavior. Looks like someone broke the usage of PGSTAT_STAT_INTERVAL between 8.1 and 8.2 ... it's waiting 500 microseconds, not the intended 500 milliseconds. I can confirm that rev 1.140.2.3 of pgstat.c does fix this issue. The stats collector CPU usage has dropped from inexcess of 95% to 5% Thanks. Any guess on when we'd see an 8.2.4? I have a business reason for asking. Thanks! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: ler@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] HOT - preliminary results
On Fri, 2007-03-02 at 18:37 -0300, Alvaro Herrera wrote: Bruce Momjian escribió: Simon Riggs wrote: CLUSTER does not need changes for HOT, as things stand currently, mainly because its MVCC behaviour is broken. That's oddly discouraging. :-) Apparently no one has been bothered enough to fix CLUSTER. We learned from Csaba just the other day that this is a backdoor used on production systems. I've not seen anyone admit it before, even though I've seen it discussed. People know that CLUSTER works better than VACUUM FULL and they use that. The reason it hasn't been fixed is because its useful, I observe. The oddly discouraging bit is that VACUUM FULL is only second best at the thing its designed to achieve (compaction). Thats why I'm not enthralled by the prospect of adding code to make VACUUM FULL work with HOT - ISTM a good opportunity to make it work better. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(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] Is there a way to run heap_insert() AFTER ExecInsertIndexTuples() ?
On Thu, Mar 01, 2007 at 11:26:23 +0100, Florian G. Pflug [EMAIL PROTECTED] wrote: But just postponing nextval() until after the uniqueness checks only decreases the *probability* of non-monotonic values, and *does not* preven them. Consindert two transactions A: begin ; B: Begin ; A: insert ... -- IDENTITY generates value 1 B: insert .. -- IDENTITY generates value 2 A: rollback ; B: commit ; Now there is a record with IDENTITY 2, but not with 1. The *only* way to fix this is to *not* use a sequence, but rather do lock table t in exclusive mode ; select max(identity)+1 from t ; to generate the identity - but of course this prevents any concurrent inserts, which will make this unuseable for any larger database. While this demonstrates that you can get holes in the sequence, it doesn't show an example that is not monotonic. Note that this is not a deficency of postgres sequences - there is no way to guarantee stricly monotonic values while allowing concurrent selects at the same time. (Other than lazyly assigning the values, but this needs to be done by the application) With in a single session and barring wrap-around you will get monotonicly increasing values. You are correct that there is no such guaranty between separate sessions that overlap in time. ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] HOT - preliminary results
Simon Riggs escribió: On Fri, 2007-03-02 at 18:37 -0300, Alvaro Herrera wrote: Bruce Momjian escribió: Simon Riggs wrote: CLUSTER does not need changes for HOT, as things stand currently, mainly because its MVCC behaviour is broken. That's oddly discouraging. :-) Apparently no one has been bothered enough to fix CLUSTER. We learned from Csaba just the other day that this is a backdoor used on production systems. I've not seen anyone admit it before, even though I've seen it discussed. Yeah, I had just read that and was about to mention it, but I think (some of?) these cases would be solved by HOT. So that usage of CLUSTER would go away altogether, allowing us to fix the MVCC issue ... which would require HOT to work nicely :-( -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Removing some of the old VC++ stuff
Magnus Hagander wrote: Hi! I would like to suggest that we retire some of the old Visual C++ build infrastructure. Specifically, all the makefiles for VC++ 6.0 *except* libpq. There is a point for keeping libpq - if you want to build a static version, it's easier if you can use the same version. And it's also required if you want to be able to use the PQtrace function. Therefor, I suggest that we keep both the VC++ and Borland makefiles for libpq (since we do seem to have someone touching the Borland stuff every now and then we can keep it, but I wouldn't consider it properly maintained :-P) The argument for removing the rest of the support is that it will get us away from having to maintain it :-) The build files can be generated automatically for Visual C++ 2005 using the new code (and you can build just the frontend part sif you want to), which is available as a free download from MS. Anybody think we need to keep those around? Agreed on removal of non-libpq *.mak files. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Synchronized Scan update
Is there any consensus about whether to include these two parameters as GUCs or constants if my patch is to be accepted? (1) sync_scan_threshold: Use synchronized scanning for tables greater than this many pages; smaller tables will not be affected. (2) sync_scan_offset: Start a new scan this many pages before a currently running scan to take advantage of the pages that are likely already in cache. Right now they are just constants defined in a header, but a GUC might make sense. I'd like to know which version is more acceptable when I submit my final patch. Regards, Jeff Davis ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] SE-Linux/PostgreSQL work?
Folks, I'm chasing a rumor that someone is working on integrating PostgreSQL with the SELinux security framework. Anyone know anything about this? -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] broken doc
Tom Lane wrote: Tatsuo Ishii [EMAIL PROTECTED] writes: CVS HEAD doc won't compile due to broken mark up. Please someone commit following patches if they are appropreate. Done. Also please do not commit broken sgml files without trying to compile them. Some committers are using DocBook installations that seem quite lax about closing tags :-(, so they fail to see this type of breakage. Yep. What should I upgrade, and to what version? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Arrays of Complex Types
Folks, I'd like to take the TODO item that reads, Add support for arrays of complex types, but before I start patching, I'd like to see whether what I'm about to do makes any sense: 1. In src/backend/commands/tablecmds.c, change DefineRelation as follows: * After the first call to heap_create_with_catalog, construct and do another call to for the array type. * Add an appropriate pg_depend entry. 2. Change RemoveRelation to reflect the above. 3. Change TypeRename appropriately, whatever that turns out to be. Does the above make sense? Have I missed anything critical? Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! Consider donating to PostgreSQL: http://www.postgresql.org/about/donate ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] broken doc
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Some committers are using DocBook installations that seem quite lax about closing tags :-(, so they fail to see this type of breakage. Yep. What should I upgrade, and to what version? I dunno --- I just use what ships with Fedora. The relevant FC6 packages seem to be docbook-dtds-1.0-30 docbook-simple-1.0-2.1 docbook-slides-3.3.1-2.1 docbook-style-dsssl-1.79-4 docbook-style-xsl-1.69.1-5 docbook-utils-0.6.14-5 docbook-utils-pdf-0.6.14-5 linuxdoc-tools-0.9.21-6.2.1 but I've got no idea which of these is the critical factor. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] broken doc
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Some committers are using DocBook installations that seem quite lax about closing tags :-(, so they fail to see this type of breakage. Yep. What should I upgrade, and to what version? I dunno --- I just use what ships with Fedora. The relevant FC6 packages seem to be docbook-dtds-1.0-30 docbook-simple-1.0-2.1 docbook-slides-3.3.1-2.1 docbook-style-dsssl-1.79-4 docbook-style-xsl-1.69.1-5 docbook-utils-0.6.14-5 docbook-utils-pdf-0.6.14-5 linuxdoc-tools-0.9.21-6.2.1 but I've got no idea which of these is the critical factor. I am pulling this way out of the back of my head, and Peter might be a better one to ask but I seem to recall that you can set the closing bracket requirement in the stylesheet itself. Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Synchronized Scan update
Jeff, Right now they are just constants defined in a header, but a GUC might make sense. I'd like to know which version is more acceptable when I submit my final patch. As much as I hate the thought of more GUCs, until we have a solid performance profile for synch scan we probably need them. You should include the option to turn synch_scan off, such as by setting synch_scan_threshold to -1. Oh, and remember that these now need to be able to take K/MB/GB. These options should probably go in postgresql.conf under QUERY TUNING, with their own sub-head. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Arrays of Complex Types
David Fetter [EMAIL PROTECTED] writes: 1. In src/backend/commands/tablecmds.c, change DefineRelation as follows: * After the first call to heap_create_with_catalog, construct and do another call to for the array type. I'm still not happy about the idea of doing this for every relation (and doing it for sequences and indexes would be the height of wastefulness). How about we only do it for composite types? * Add an appropriate pg_depend entry. 2. Change RemoveRelation to reflect the above. You only need one of those two: either you drop by hand or you let the dependency machinery deal with it. Not both. Does the above make sense? Have I missed anything critical? Ummm ... making it actually work? Possibly that just falls out, but I'm not sure. If it turns out that it does Just Work, you might take a stab at arrays of domains too. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Synchronized Scan update
On Fri, 2007-03-02 at 15:49 -0800, Josh Berkus wrote: Jeff, Right now they are just constants defined in a header, but a GUC might make sense. I'd like to know which version is more acceptable when I submit my final patch. As much as I hate the thought of more GUCs, until we have a solid performance profile for synch scan we probably need them. You should I will include them in the final patch then. include the option to turn synch_scan off, such as by setting synch_scan_threshold to -1. Naturally. Oh, and remember that these now need to be able to take K/MB/GB. Will do. These options should probably go in postgresql.conf under QUERY TUNING, with their own sub-head. That makes sense to me. Regards, Jeff Davis PS: Did you happen to get my patch for testing (sent off-list)? If testing will take a while, that's OK, I'd just like to know whether to expect the results before feature freeze. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Synchronized Scan update
Jeff, PS: Did you happen to get my patch for testing (sent off-list)? If testing will take a while, that's OK, I'd just like to know whether to expect the results before feature freeze. I'm not sure. We have a bunch to patches in our queue to test, and the benchmark guys don't really expect synch scan to affect OLTP benchmarks much. You might want to pester Greenplum about testing on TPCH. -- --Josh Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Arrays of Complex Types
Tom Lane wrote: David Fetter [EMAIL PROTECTED] writes: 1. In src/backend/commands/tablecmds.c, change DefineRelation as follows: * After the first call to heap_create_with_catalog, construct and do another call to for the array type. I'm still not happy about the idea of doing this for every relation (and doing it for sequences and indexes would be the height of wastefulness). How about we only do it for composite types? I'm not happy about that. I agree that indexes and sequences should not be done, but can we please do plain table types? I would be OK if we skipped catalog tables, if that would make you happier. 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
[HACKERS] Re: Is there a way to run heap_insert() AFTER ExecInsertIndexTuples() ?
Bruno Wolff III wrote: On Thu, Mar 01, 2007 at 11:26:23 +0100, Florian G. Pflug [EMAIL PROTECTED] wrote: But just postponing nextval() until after the uniqueness checks only decreases the *probability* of non-monotonic values, and *does not* preven them. Consindert two transactions A: begin ; B: Begin ; A: insert ... -- IDENTITY generates value 1 B: insert .. -- IDENTITY generates value 2 A: rollback ; B: commit ; Now there is a record with IDENTITY 2, but not with 1. The *only* way to fix this is to *not* use a sequence, but rather do lock table t in exclusive mode ; select max(identity)+1 from t ; to generate the identity - but of course this prevents any concurrent inserts, which will make this unuseable for any larger database. While this demonstrates that you can get holes in the sequence, it doesn't show an example that is not monotonic. Sorry, my formulation was sloppy. What I meant is that you can't guarantee gaplessness. greetings, Florian Pflug ---(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] SE-Linux/PostgreSQL work?
Hello, Josh Berkus wrote: Folks, I'm chasing a rumor that someone is working on integrating PostgreSQL with the SELinux security framework. Anyone know anything about this? I'm currently working on integration PostgreSQL with SELinux security framework. It was named as SE-PostgreSQL. Thanks for your interest. It will provide finer grained mandatory access control on the various kinds of database objects including columns, tuples and binary large objects, based on the security policy of SELinux. Any clients cannot bypass this access control, even if they are privileged database users. Now, I have a plan to release the first alpha version of SE-PostgreSQL within this week, to get any feedbacks from PostgreSQL/SELinux community. Thanks, -- KaiGai Kohei [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] HOT - whats next ?
Simon Riggs wrote: On Fri, 2007-03-02 at 10:08 -0500, Tom Lane wrote: How much testing of this patch's concurrent behavior has been done? I'm wondering if any other locking thinkos are in there ... This version of HOT is being developed from scratch, with as much feedback from the community as possible. The idea was to build it up brick by brick, so that each assumption/decision could be challenged as we go. The idea was to avoid a huge review at the end, which could lead to a fatal flaw being discovered too late to make the release. Yes, as Joshua Drake said, HOT is a model of how to develop complex patches in the community. The right kind of testing is clearly going to be important to getting HOT right. Back in July, we spent some time building concurrent psql specifically to allow test cases to be written that referenced multiple sessions. Even if we don't like that thought for production, it would be great to be able to have a tool that allowed multi-session test cases to be written. Experience was that it was much, much easier to get a test case written in a single script where you could easily read the statement history. Yes, I am assuming we are getting the concurrent psql patch in 8.3. It was stalled because we were waiting for regression tests and use illustrations. It would also be very useful to have a version of pgstattuple that worked with heaps, so test cases can be written that examine the header fields, info flags etc. It would be useful to be able to specify the basic behaviour in terms of explicit test cases. Would those two approaches to test execution be desirable in the regression tests? Sure. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] HOT - whats next ?
Bruce Momjian wrote: Simon Riggs wrote: On Fri, 2007-03-02 at 10:08 -0500, Tom Lane wrote: How much testing of this patch's concurrent behavior has been done? I'm wondering if any other locking thinkos are in there ... This version of HOT is being developed from scratch, with as much feedback from the community as possible. The idea was to build it up brick by brick, so that each assumption/decision could be challenged as we go. The idea was to avoid a huge review at the end, which could lead to a fatal flaw being discovered too late to make the release. Yes, as Joshua Drake said, HOT is a model of how to develop complex patches in the community. It certainly was better than many we have seen. Hats off to Simon and Pavan. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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
[HACKERS] FYI - another open source tpc-c kit
Hi all, Just wanted to share some information I was pointed to in case no one has heard: The kit can be found here: http://www.infor.uva.es/~diego/tpcc-uva.html The SIGMOD paper is here: http://www.sigmod.org/sigmod/record/issues/0612/p06-article-llanos.pdf Mark ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch license update to developer's FAQ
Joshua D. Drake wrote: Bruce Momjian wrote: Joshua D. Drake wrote: Bruce Momjian wrote: I have added to the developer's FAQ that we don't want non-BSD-compatible licensed patches: liPostgreSQL is licensed under a BSD license. By posting a patch to the public PostgreSQL mailling lists, you are giving the PostgreSQL Global Development Group the non-revokable right to distribute your patch under the BSD license. If you use code that is available under a BSD-compatible license (eg. public domain), please note that in your email submission. If the license is not BSD-compatible (e.g. GPL), please do not post the patch./li How about something simpler: liPostgreSQL is licensed under a BSD license. Patches that are submitted another a non-compatible license (such as the GPL) will be ignored./li No, I don't people even seeing GPL patches on our lists. There is too much of a chance of accident, and possible problems if we re-implemented with a BSD license. Neither clause solves the issue you describe here. The only thing my clause does it make it so people might actually read it ;). In general, people have very short attention spans and they have no desire to read a long paragraph about something that is really two sentences. We could adjust a bit though: liPostgreSQL is licensed under a BSD license. We will only accept patches that are submitted under a BSD license. All others shall be rejected./li Using the word rejected provides a sense of us declaring outright, NO to anything but BSD versus an implicit ignoring. Agreed we want simple wording. The existing complexity is caused by trying to explain that if basing a patch on a BSD-compatibile license, we need to know about it. Your wording doesn't have that distinction. Perhaps the distinction isn't important. I didn't write that particular part of the FAQ myself. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] FYI - another open source tpc-c kit
On 3/2/07, Mark Wong [EMAIL PROTECTED] wrote: Just wanted to share some information I was pointed to in case no one has heard: Yep, tpcc-uva is pretty good. I've played with it for over a year now. The only issue with it is that it currently has a 128 warehouse limit. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] FYI - another open source tpc-c kit
Jonah H. Harris wrote: On 3/2/07, Mark Wong [EMAIL PROTECTED] wrote: Just wanted to share some information I was pointed to in case no one has heard: Yep, tpcc-uva is pretty good. I've played with it for over a year now. The only issue with it is that it currently has a 128 warehouse limit. There is also odbc-bench which I was thinking about automating. J -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(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] FYI - another open source tpc-c kit
On 3/2/07, Joshua D. Drake [EMAIL PROTECTED] wrote: There is also odbc-bench which I was thinking about automating. Yep, OpenLink's ODBC Bench is pretty good for both TPC-A and TPC-C. Unfortunately their JDBCBench needs a lot of work. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 3rd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] FYI - another open source tpc-c kit
Jonah H. Harris wrote: On 3/2/07, Joshua D. Drake [EMAIL PROTECTED] wrote: There is also odbc-bench which I was thinking about automating. Yep, OpenLink's ODBC Bench is pretty good for both TPC-A and TPC-C. I haven't ported it yet but I like the fact that it has stored procedures ability as well as just transactions. Joshua D. Drake Unfortunately their JDBCBench needs a lot of work. -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Deadlock with pg_dump?
I will rework this before application to use LOG level. Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches It will be applied as soon as one of the PostgreSQL committers reviews and approves it. --- Simon Riggs wrote: On Mon, 2007-02-19 at 19:38 +, Simon Riggs wrote: On Tue, 2007-02-13 at 22:19 -0500, Bruce Momjian wrote: Simon Riggs wrote: On Thu, 2006-10-26 at 18:45 -0400, Tom Lane wrote: Chris Campbell [EMAIL PROTECTED] writes: Is there additional logging information I can turn on to get more details? I guess I need to see exactly what locks both processes hold, and what queries they were running when the deadlock occurred? Is that easily done, without turning on logging for *all* statements? log_min_error_statement = error would at least get you the statements reporting the deadlocks, though not what they're conflicting against. Yeh, we need a much better locking logger for performance analysis. We really need to dump the whole wait-for graph for deadlocks, since this might be more complex than just two statements involved. Deadlocks ought to be so infrequent that we can afford the log space to do this - plus if we did this it would likely lead to fewer deadlocks. For 8.3 I'd like to have a log_min_duration_lockwait (secs) parameter that would allow you to dump the wait-for graph for any data-level locks that wait too long, rather than just those that deadlock. Many applications experience heavy locking because of lack of holistic design. That will also show up the need for other utilities to act CONCURRENTLY, if possible. Old email, but I don't see how our current output is not good enough? test= lock a; ERROR: deadlock detected DETAIL: Process 6855 waits for AccessExclusiveLock on relation 16394 of database 16384; blocked by process 6795. Process 6795 waits for AccessExclusiveLock on relation 16396 of database 16384; blocked by process 6855. This detects deadlocks, but it doesn't detect lock waits. When I wrote that it was previous experience driving me. Recent client experience has highlighted the clear need for this. We had a lock wait of 50 hours because of an RI check; thats the kind of thing I'd like to show up in the logs somewhere. Lock wait detection can be used to show up synchronisation points that have been inadvertently designed into an application, so its a useful tool in investigating performance issues. I have a patch implementing the logging as agreed with Tom, will post to patches later tonight. Patch for discussion, includes doc entries at top of patch, so its fairly clear how it works. Output is an INFO message, to allow this to trigger log_min_error_statement when it generates a message, to allow us to see the SQL statement that is waiting. This allows it to generate a message prior to the statement completing, which is important because it may not ever complete, in some cases, so simply logging a list of pids won't always tell you what the SQL was that was waiting. Other approaches are possible... Comments? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com [ Attachment, skipping... ] -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] FYI - another open source tpc-c kit
On 3/2/07, Joshua D. Drake [EMAIL PROTECTED] wrote: Jonah H. Harris wrote: On 3/2/07, Joshua D. Drake [EMAIL PROTECTED] wrote: There is also odbc-bench which I was thinking about automating. Yep, OpenLink's ODBC Bench is pretty good for both TPC-A and TPC-C. I haven't ported it yet but I like the fact that it has stored procedures ability as well as just transactions. Joshua D. Drake Unfortunately their JDBCBench needs a lot of work. Cool. Let me know if you see any TPC-E implementations. I'm working with Rilson to improve the one he started. Mark ---(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] Patch license update to developer's FAQ
Bruce Momjian wrote: I have added to the developer's FAQ that we don't want non-BSD-compatible licensed patches: How frequently is this actually a problem? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(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] broken doc
On Friday 02 March 2007 16:46, Joshua D. Drake wrote: I am pulling this way out of the back of my head, and Peter might be a better one to ask but I seem to recall that you can set the closing bracket requirement in the stylesheet itself. XML should require the closing tag. Is it possible that you are using the SGML processor to generate the document instead of the XML processor? wt -- Warren Turkal (w00t) ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
