[HACKERS] Remote PL/Java, Summary
Hi all, And thanks for very good input regarding a remote alternative to PL/Java (thread titled "Shared Memory"). I'm convinced that such an alternative would be a great addition to PL/Java and increase the number of users. The work to create such a platform that has the stability and quality of todays PL/Java is significant (I really do think it is a production-grade product today). So significant in fact, that I'm beginning to think of a third alternative. An alternative that would combine the performance of using in-process calls with the benefits of sharing a JVM. The answer is of course to make the backend multi-threaded. This question has been debated before and always promptly rejected. One major reason is of course that it will not bring any benefits over the current multi-process approach on a majority of the platforms where PostgreSQL is used. A process-switch is just as fast as a thread-switch on Linux based systems. Over the last year however, something has happen that certainly speaks in the favor of multi-threading. PostgreSQL is getting widely adopted on Windows. On Windows, a process-switch is at least 5 times more expensive then a thread-switch. In order to appropriate locking, PostgreSQL is forced to do a fair amount of switching during transaction processing so the gain in using a multi-threaded approach on Windows is probably significant. The same is true for other OS'es where process-switching is relatively expensive. There are other benefits as well. PostgreSQL would no longer need shared memory and semaphores and lot more resources could be shared between backend processes. The one major drawback of a multi-threaded approach (the one that's been the main argument for the defenders of the current approach) is vulnerability. If one thread is messing things up, then the whole system will be brought to a halt (on the other hand, that can be said about the current shared-memory approach as well). The cure for this is to have a system that, to the extent possible, prevents this from happening. How would that be possible? Well, such systems are widely used today. Huge companies use them in mission critical applications all over the world. They are called Virtual Machines. Two types in particular are gaining more an more ground. The .NET based CLR and the Java VM. Although there's an Open Source initiative called Mono that implements the CLR, I still don't see it as a viable alternative to create a production-grade multi-platform database. Microsofts CLR is of course confined to Microsoft platforms. The Java VM's are however a different matter altogether. And with the java.nio.channels package that was introduced in Java 1.4 and the java.util.concurrent package from Java 5.0, Java has taken a major steps forward in being a very feasible platform for a database implementation. There's actually nothing stopping you from doing a high-performance MVCC system using Java today. A SQL parser would be based on JavaCC technology (the grammar is already written although it needs small adjustments to comply with the PostgreSQL dialect). Lots of technology is there out-of-the-box such as regular expressions, hash-maps, linked lists, etc. Not to forget an exceptionally great threading system, now providing atomic operations, semaphores, copy-on-write arrays etc. In short, everything that a database implementor could ever wish for. The third alternative for PL/Java, an approach that gets more viable every minute I think about it, is to implement the PostgreSQL backend completely in Java. I'm involved in the development of one of the commercial JVM's. I know that an enormous amount of resources are constantly devoted to performance optimizations. The days when a complex system written in C or C++ could outperform a JVM have passed. A static optimizer can only do so well. A JVM, that collects heuristics, communicates with the CPU about cache usage etc., can be a great deal smarter on how the final machine code will be optimized, and re-optimized should the conditions change. It would be great if PostgreSQL could benefit from all this research. If a commercial JVM is perceived as a problem, then combine^h^h^hpile the code with GNU gcj instead of gcc like today. The list of advantages can be made a mile long. There's no point in listing everything here. From my own standpoint, I'm of course thinking first and foremost about the advantages with PL/Java. It will become the absolute most efficient PL of them all. Other languages, for which no good Java implementation exists (I'm thinking Jython for Python, etc.), can be implemented using JNI. The most common functions used by say, PL/Perl could probably be implemented as callbacks into the Java domain in order to make the changes in the respective PL minimal. Opinions? Suggestions? Kind Regards, Thomas Hallgren ---(end of broadcast)-
Re: [HACKERS] [GENERAL] PANIC: heap_update_redo: no block
"Qingqing Zhou" <[EMAIL PROTECTED]> wrote > > "Tom Lane" <[EMAIL PROTECTED]> wrote >> >> What we should be seeing, and don't see, is an indication of a backup >> block attached to this WAL record. Furthermore, I don't see any >> indication of a backup block attached to *any* of the WAL records in >> Alex's printout. The only conclusion I can draw is that he had >> full_page_writes turned OFF, and as we have just realized that that >> setting is completely unsafe, that is the explanation for his failure. >> > According to Alex, seems the problem is not because of full_page_writes OFF > >> According to the discussion in pgsql-hackers, to finish this case, did >> you >> turn off the full_page_writes parameter? I hope the answer is "yes" ... >> > > If by off you mean full_page_writes = on then yes. Regards, Qingqing ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Remote PL/Java, Summary
Thomas Hallgren wrote: Hi all, And thanks for very good input regarding a remote alternative to PL/Java (thread titled "Shared Memory"). I'm convinced that such an alternative would be a great addition to PL/Java and increase the number of users. The work to create such a platform that has the stability and quality of todays PL/Java is significant (I really do think it is a production-grade product today). So significant in fact, that I'm beginning to think of a third alternative. An alternative that would combine the performance of using in-process calls with the benefits of sharing a JVM. The answer is of course to make the backend multi-threaded. This question has been debated before and always promptly rejected. One major reason is of course that it will not bring any benefits over the current multi-process approach on a majority of the platforms where PostgreSQL is used. A process-switch is just as fast as a thread-switch on Linux based systems. Over the last year however, something has happen that certainly speaks in the favor of multi-threading. PostgreSQL is getting widely adopted on Windows. On Windows, a process-switch is at least 5 times more expensive then a thread-switch. In order to appropriate locking, PostgreSQL is forced to do a fair amount of switching during transaction processing so the gain in using a multi-threaded approach on Windows is probably significant. The same is true for other OS'es where process-switching is relatively expensive. There are other benefits as well. PostgreSQL would no longer need shared memory and semaphores and lot more resources could be shared between backend processes. The one major drawback of a multi-threaded approach (the one that's been the main argument for the defenders of the current approach) is vulnerability. If one thread is messing things up, then the whole system will be brought to a halt (on the other hand, that can be said about the current shared-memory approach as well). The cure for this is to have a system that, to the extent possible, prevents this from happening. How would that be possible? Well, such systems are widely used today. Huge companies use them in mission critical applications all over the world. They are called Virtual Machines. Two types in particular are gaining more an more ground. The .NET based CLR and the Java VM. Although there's an Open Source initiative called Mono that implements the CLR, I still don't see it as a viable alternative to create a production-grade multi-platform database. Microsofts CLR is of course confined to Microsoft platforms. The Java VM's are however a different matter altogether. And with the java.nio.channels package that was introduced in Java 1.4 and the java.util.concurrent package from Java 5.0, Java has taken a major steps forward in being a very feasible platform for a database implementation. There's actually nothing stopping you from doing a high-performance MVCC system using Java today. A SQL parser would be based on JavaCC technology (the grammar is already written although it needs small adjustments to comply with the PostgreSQL dialect). Lots of technology is there out-of-the-box such as regular expressions, hash-maps, linked lists, etc. Not to forget an exceptionally great threading system, now providing atomic operations, semaphores, copy-on-write arrays etc. In short, everything that a database implementor could ever wish for. The third alternative for PL/Java, an approach that gets more viable every minute I think about it, is to implement the PostgreSQL backend completely in Java. I'm involved in the development of one of the commercial JVM's. I know that an enormous amount of resources are constantly devoted to performance optimizations. The days when a complex system written in C or C++ could outperform a JVM have passed. A static optimizer can only do so well. A JVM, that collects heuristics, communicates with the CPU about cache usage etc., can be a great deal smarter on how the final machine code will be optimized, and re-optimized should the conditions change. It would be great if PostgreSQL could benefit from all this research. If a commercial JVM is perceived as a problem, then combine^h^h^hpile the code with GNU gcj instead of gcc like today. The list of advantages can be made a mile long. There's no point in listing everything here. From my own standpoint, I'm of course thinking first and foremost about the advantages with PL/Java. It will become the absolute most efficient PL of them all. Other languages, for which no good Java implementation exists (I'm thinking Jython for Python, etc.), can be implemented using JNI. The most common functions used by say, PL/Perl could probably be implemented as callbacks into the Java domain in order to make the changes in the respective PL minimal. We already do use threads on Windows to a limited extent to do things like timers and pseudo-
Re: [HACKERS] Remote PL/Java, Summary
Andrew Dunstan wrote: We already do use threads on Windows to a limited extent to do things like timers and pseudo-signal handling. If this were a greenfields project then your arguments would have force. But for how long would you like to suspend Postgres development activity while we re-implement everything in Java? Not to mention the effort to recruit new developers to replace those who leave because they can't or don't want to be part of the effort. For better or worse, PostgreSQL is written in C, and I can't see that changing. It might be interesting to take a frozen code base for PostgreSQL and reimplement it in Java, and then run some comparisons, both for performance and crash stability. I just counted roughly 100k lines of source code, so a reimplementation effort would be distinctly non-trivial. and a happy April 1 to you too, btw. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Postgres dies when using an intarray operator
Hi all, When using intarray operator in a query, postgres dies and restart itself when executing the following query: select r1.bet_sentence & r2.bet_sentence from related r1,related r2 where r1.bet_sentence && r2.bet_sentence the log file contains the following: LOG: server process (PID 14283) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2006-04-01 15:07:04 CEST LOG: checkpoint record is at 1/E9178B1C This is the only information I can find 'related' has the following definition: Column| Type | Modifiers --++--- id | integer| not null id_line | integer| id_linegroup | integer| id_word_1| integer| id_word_2| integer| rtype| character varying(100) | bet_sentence | integer[] | there are about 100 000 records in this table. The crash only happends when I create the gist index on bet_sentence: create index ind_related_7 on related using gist ( bet_sentence gist__int_ops); Using unbuntu 5.1 ,postgres version 8.1.3,compiled from source and intarray installed Can someone explain this crash? Thanks Jeroen ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Suggestion: Which Binary?
David Wheeler wrote: > Yes, but even the environment variables get me what I want. I > therefore respectfully submit the attached patch to document them in > the INSTALL file. Next time you submit a patch, please consider reading it before sending it out. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_class catalog question...
On Fri, Mar 31, 2006 at 11:29:15AM -0500, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > About the only reason I use CHAR in other databases systems is when I > > know that the field will always contain the same amount of data, ie: > > storing a SHA1. In these cases it's silly to have a 4 byte overhead to > > store length. I really wish CHAR in PostgreSQL worked this way, so it > > would be a welcome addition to have a type that did work this way. In > > fact, I'd argue that CHAR should be made to work that way, and what's > > currently called CHAR should be renamed for those who wish to use it. > > This argument falls flat when you consider that the width of a CHAR > entry is measured in characters, not bytes, and therefore its physical > size is not fixed even if its logical width is. True, but in every case I've used char it was to store something that would never be multi-byte, like a GUID, or a SHA1. Though I guess in retrospect, what would really be handy is 'hex' datatype, that stores a hex string (possibly with a custom format, such as a GUID) in it's native binary format. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(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] Suggestion: Which Binary?
On Fri, Mar 31, 2006 at 07:01:18PM -0500, Tom Lane wrote: > David Wheeler <[EMAIL PROTECTED]> writes: > > Yes, but even the environment variables get me what I want. I > > therefore respectfully submit the attached patch to document them in > > the INSTALL file. > > It seems rather pointless to document two instances of what is in fact > a generic autoconf-script behavior ... The problem is that PostgreSQL is moving out of the realm of "hard-core geeks only" and more into the mainstream. I'd bet a number of our users have very little idea how autoconf and it's progeny work. It's probably not unlikely that those folks would be able to figure out where their perl was, but then not know how to tell it to configure. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Suggestion: Which Binary?
Jim C. Nasby wrote: > The problem is that PostgreSQL is moving out of the realm of > "hard-core geeks only" and more into the mainstream. Someone who has a non-default Perl installation is hardly mainstream. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pg_class catalog question...
Jim C. Nasby wrote: On Fri, Mar 31, 2006 at 11:29:15AM -0500, Tom Lane wrote: This argument falls flat when you consider that the width of a CHAR entry is measured in characters, not bytes, and therefore its physical size is not fixed even if its logical width is. True, but in every case I've used char it was to store something that would never be multi-byte, like a GUID, or a SHA1. Though I guess in retrospect, what would really be handy is 'hex' datatype, that stores a hex string (possibly with a custom format, such as a GUID) in it's native binary format. Why not simply a fixed number of bytes, i.e. byte(16) or octet(16)? Hexadecimal is just a convenient human-readable representation. Regards, Thomas Hallgren ---(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] Remote PL/Java, Summary
Andrew Dunstan wrote: and a happy April 1 to you too, btw. ;-) - thomas ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Suggestion: Which Binary?
Jim C. Nasby wrote: On Fri, Mar 31, 2006 at 07:01:18PM -0500, Tom Lane wrote: David Wheeler <[EMAIL PROTECTED]> writes: Yes, but even the environment variables get me what I want. I therefore respectfully submit the attached patch to document them in the INSTALL file. It seems rather pointless to document two instances of what is in fact a generic autoconf-script behavior ... The problem is that PostgreSQL is moving out of the realm of "hard-core geeks only" and more into the mainstream. I'd bet a number of our users have very little idea how autoconf and it's progeny work. It's probably not unlikely that those folks would be able to figure out where their perl was, but then not know how to tell it to configure. Most such users would use a binary distribution, though - either from the OS supplier or from our collection of binaries. If people are going to build postgres themselves from source then I *do* expect them to be moderately hard-core geeks. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Postgres dies when using an intarray operator
On Sat, Apr 01, 2006 at 03:40:19PM +0200, jeroen van iddekinge wrote:
> When using intarray operator in a query, postgres dies and restart
> itself when executing the following query:
>
> select r1.bet_sentence & r2.bet_sentence
> from related r1,related r2
> where r1.bet_sentence && r2.bet_sentence
Here's a complete test case:
CREATE TABLE foo (a integer[]);
INSERT INTO foo (a)
SELECT array[random() * 10, random() * 10, random() * 10]
FROM generate_series(1, 24);
CREATE INDEX foo_a_idx ON foo USING gist (a gist__int_ops);
SET enable_seqscan TO off;
SELECT f1.a & f2.a FROM foo f1, foo f2 WHERE f1.a && f2.a;
This crashes for me in 8.1.3 on FreeBSD 6.1-PRERELEASE and Solaris 9.
An assert-enabled 8.1.3 logs the following:
TRAP: BadArgument("!(((header->context) != ((void *)0) &&
(Node*)((header->context)))->type) == T_AllocSetContext", File:
"mcxt.c", Line: 612)
--
Michael Fuhr
---(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] control pg_hba.conf via SQL
Unfortunately, there is still one serious deficiency with the solution
below- it may not be the actual information postgresql is currently
using to determine who can log in and how- the file can be easily
changed behind the scenes and there is currently no way to know.
I (speaking as a DBA) would still very much appreciate a static, frozen
table view accessible from SQL.
On Mar 30, 2006, at 3:05 PM, David Fetter wrote:
On Thu, Mar 30, 2006 at 10:43:31AM -0500, Andrew Dunstan wrote:
A.M. wrote:
Could postgres offer at least a read-only view of the data in the
interim? Ordering could be controlled by line number.
You can get the contents as a single text field like this:
| select pg_read_file|('pg_hba.conf', 0, 50*1024);
Writing a plperl function that would strip comments and blank lines
and return the rest as a numbered set of lines would be fairly
trivial.
You don't even need PL/Perl :)
SELECT * FROM (
SELECT
s.t AS "Ordering",
(string_to_array(pg_read_file(
'pg_hba.conf',
0,
(pg_stat_file('pg_hba.conf')).size
), '\n'))[s.t] AS "Line"
FROM
generate_series(
1,
array_upper(
string_to_array(pg_read_file(
'pg_hba.conf',
0,
(pg_stat_file('pg_hba.conf')).size
), '\n'),
1
)
) AS s(t)
) AS foo
WHERE
"Line" !~ '^#'
AND
"Line" !~ '^\s*$'
;
Cheers,
D
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
[EMAIL PROTECTED]
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] control pg_hba.conf via SQL
Er, how can the file be changed behind the scenes? Only if you have
opened up permission to the directory to someone else, or you don't
trust your sysadmins.
Either way you would then have much bigger problems than this.
cheers
andrew
Agent M wrote:
Unfortunately, there is still one serious deficiency with the solution
below- it may not be the actual information postgresql is currently
using to determine who can log in and how- the file can be easily
changed behind the scenes and there is currently no way to know.
I (speaking as a DBA) would still very much appreciate a static,
frozen table view accessible from SQL.
On Mar 30, 2006, at 3:05 PM, David Fetter wrote:
On Thu, Mar 30, 2006 at 10:43:31AM -0500, Andrew Dunstan wrote:
A.M. wrote:
Could postgres offer at least a read-only view of the data in the
interim? Ordering could be controlled by line number.
You can get the contents as a single text field like this:
| select pg_read_file|('pg_hba.conf', 0, 50*1024);
Writing a plperl function that would strip comments and blank lines
and return the rest as a numbered set of lines would be fairly
trivial.
You don't even need PL/Perl :)
SELECT * FROM (
SELECT
s.t AS "Ordering",
(string_to_array(pg_read_file(
'pg_hba.conf',
0,
(pg_stat_file('pg_hba.conf')).size
), '\n'))[s.t] AS "Line"
FROM
generate_series(
1,
array_upper(
string_to_array(pg_read_file(
'pg_hba.conf',
0,
(pg_stat_file('pg_hba.conf')).size
), '\n'),
1
)
) AS s(t)
) AS foo
WHERE
"Line" !~ '^#'
AND
"Line" !~ '^\s*$'
;
Cheers,
D
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
[EMAIL PROTECTED]
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
---(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] control pg_hba.conf via SQL
But there is still no way to verify that the information in the file is what postgres saw last. DBAs make mistakes too. A simple way to view the current access state would be much appreciated. On Apr 1, 2006, at 1:01 PM, Andrew Dunstan wrote: Er, how can the file be changed behind the scenes? Only if you have opened up permission to the directory to someone else, or you don't trust your sysadmins. Either way you would then have much bigger problems than this. cheers andrew ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ AgentM [EMAIL PROTECTED] ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] libpq Describe Extension [WAS: Bytea and perl]
Hi,
On Mar 25 08:47, John DeSoi wrote:
> I have not looked at libpq in any detail, but it should have access
> to the type of all the parameters in the prepared statement. The
> Describe (F) statement in the frontend/backend protocol identifies
> the type of each parameter.
I've prepared a patch for the Describe <-> ParameterDescription
messaging which is available via current extended query protocol.
Usage (and implementation) is explained in the patch's documentation
related part. (Also I tried to place informative comments in the code
too.)
But I've a problem with ereport() error calls caused by erronous
target_type entries. After an error in exec_describe_statement_message()
(or exec_describe_portal_message()) it leaves block with ereport() call
and client side stalls in PGASYNC_BUSY state while backend stalls in
PostgresMain() by calling ReadCommand(). To summerize, an error
returning pqDescribe() call causes both side to stall.
I'd be so appreciated to hear your thoughts about the patch and above
problem.
Regards.
? src/interfaces/libpq/.deps
? src/interfaces/libpq/cscope.out
? src/interfaces/libpq/libpq.so.4.2
Index: doc/src/sgml/libpq.sgml
===
RCS file: /projects/cvsroot/pgsql/doc/src/sgml/libpq.sgml,v
retrieving revision 1.206
diff -c -r1.206 libpq.sgml
*** doc/src/sgml/libpq.sgml 10 Mar 2006 19:10:48 - 1.206
--- doc/src/sgml/libpq.sgml 1 Apr 2006 18:27:41 -
***
*** 2045,2053
! PQprintPQprint
Prints out all the rows and, optionally, the
column names to the specified output stream.
--- 2045,2081
!
PQdescPreparedPQdescPrepared
!
PQdescPortalPQdescPortal
+ Describe a prepared statement or portal.
+ int PQdescPrepared(PGconn *conn, const char *stmt);
+ int PQdescPortal(PGconn *conn, const char *portal);
+
+
+ These two functions are used to describe a prepared statement or portal.
+ Functions return 1 on success and 0 on failure. (An appropriate error
+ message will be placed in an error situation.) NULL values in
+ the stmt and portal parameters will be
treated
+ as an empty string.
+
+
+ After a PQdescPrepared or PQdescPortal
function
+ call, issuing a PQgetResult will place backend's response
+ into a PGresult structure - that'll be
+ extractable via PQftype.
+
+
+ These functions are available within extended query protocol which is
+ available in version 3.0 and above.
+
+
+
+
+
+ PQprintPQprint
+
Prints out all the rows and, optionally, the
column names to the specified output stream.
Index: src/backend/tcop/postgres.c
===
RCS file: /projects/cvsroot/pgsql/src/backend/tcop/postgres.c,v
retrieving revision 1.482
diff -c -r1.482 postgres.c
*** src/backend/tcop/postgres.c 14 Mar 2006 22:48:21 - 1.482
--- src/backend/tcop/postgres.c 1 Apr 2006 18:28:08 -
***
*** 3391,3396
--- 3391,3398
describe_type)));
break;
}
+
+ send_ready_for_query = true;
}
break;
Index: src/interfaces/libpq/fe-exec.c
===
RCS file: /projects/cvsroot/pgsql/src/interfaces/libpq/fe-exec.c,v
retrieving revision 1.182
diff -c -r1.182 fe-exec.c
*** src/interfaces/libpq/fe-exec.c 14 Mar 2006 22:48:23 - 1.182
--- src/interfaces/libpq/fe-exec.c 1 Apr 2006 18:28:15 -
***
*** 55,60
--- 55,62
static void parseInput(PGconn *conn);
static bool PQexecStart(PGconn *conn);
static PGresult *PQexecFinish(PGconn *conn);
+ static int pqDescribe(PGconn *conn, const char desc_type,
+ const char *desc_target);
/*
***
*** 2281,2286
--- 2283,2400
return 0;
}
+
+ /*
+ * pqDescribe - Describe given prepared statement or portal.
+ *
+ * Available options for target_type are
+ * 's' to describe a prepared statement; or
+ * 'p' to describe a portal.
+ * Returns 1 on success and 0 on failure.
+ *
+ * By issuing a PQgetResult(), response from the server will be placed
+ * in an empty PGresult that will be extractable via PQftype().
+ */
+ static int
+ pqDescribe(PGconn *conn, const char desc_type, const char *desc_target)
+ {
+ int ret;
+
+ /* This isn't gonna work on a 2.0 server. */
+ if (PG_PROTOCOL_MAJOR(conn->pversion) < 3)
+ {
+ printfPQExpBuffer(&conn->errorMessage,
+
Re: [HACKERS] Slony-I for circular replication
Ozsu show us some solution for the problem in the book "Principles of distributed database systems". On 4/1/06, D'Arcy J.M. Cain wrote: > On Fri, 31 Mar 2006 17:57:25 -0300 > "Gustavo Tonini" <[EMAIL PROTECTED]> wrote: > > why there's no way to make multi-master replication generic? > > Well, that's the material for a paper but the simplest example I can > suggest is serial. How do multiple machines insert into a database > table with a sequential primary key? > > -- > D'Arcy J.M. Cain | Democracy is three wolves > http://www.druid.net/darcy/| and a sheep voting on > +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. > ---(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] Postgres dies when using an intarray operator
[Please copy the mailing list on replies.]
On Sat, Apr 01, 2006 at 07:20:57PM +0200, jeroen van iddekinge wrote:
> > TRAP: BadArgument("!(((header->context) != ((void *)0) &&
> > (Node*)((header->context)))->type) == T_AllocSetContext", File:
> > "mcxt.c", Line: 612)
> >
>
> I started the postmaster with -d 5 but I didn't get something like
> above, only a signal 11 message.
> How can I get more information from a crash?
The above error would be logged only if the server was built with
assertions enabled. See the documentation for the --enable-cassert
configure option:
http://www.postgresql.org/docs/8.1/interactive/install-procedure.html
If the server was built with debugging symbols (--enable-debug)
then you could obtain useful information from a core dump by using
a debugger like gdb to display a stack trace. To see examples
search the archives for words like "gdb" and "stack trace"
--
Michael Fuhr
---(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] Suggestion: Which Binary?
On Mar 31, 2006, at 20:02, Tom Lane wrote: You can give `configure' initial values for configuration parameters by setting variables in the command line or in the environment. Here is an example: ./configure CC=c89 CFLAGS=-O2 LIBS=-lposix This isn't super helpful, of course, since it doesn't say exactly which variables any particular autoconf script responds to. But pretty much all of the programs that a configure script searches for are reflected as variables. A quick grep through our configure script for the phrase "Let the user override" finds a couple dozen hits, and that's just for programs, never mind non-program variables. Right, but me, while I compile lots of stuff, I don't understand configure or autconf at all. So I was completely unaware of this feature. I'm very pleased to know it now, of course. But I don't see how it could be any harm to add notes to the INSTALL file explicitly letting users know how to do stuff like this. The INSTALL file is, after all, what folks like me read when looking for information beyond ./configure && make && make install. It would have helped me a lot, and I see no disadvantage to including it. Am I missing something? Thanks, David ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Suggestion: Which Binary?
On Apr 1, 2006, at 06:58, Peter Eisentraut wrote: Next time you submit a patch, please consider reading it before sending it out. I just read the patch, and it looks fine to me. No typos that I noticed. I might have screwed up the SGML stuff, but I know even less about SGML than I do about autoconf and configure. :-) So, pray tell, what have I screwed up? I would of course be happy to submit a corrected patch. Best, David ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Problem compiling with mingw
I run configure (no complains about bison o flex), after a few seconds I receive the next errors: make[4]: Leaving directory `/pgsql/src/backend/access/nbtree'make -C transam SUBSYS.omake[4]: Entering directory `/pgsql/src/backend/access/transam'make[4]: `SUBSYS.o' is up to date.make[4]: Leaving directory `/pgsql/src/backend/access/transam'make[3]: Leaving directory `/pgsql/src/backend/access'make -C bootstrap allmake[3]: Entering directory `/pgsql/src/backend/bootstrap'gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -fno-strict-aliasing -I. -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND "-I../../../src/include/port/win32" -DBUILDING_DLL -c -o bootparse.o bootparse.cbootparse.y:101:10: "b4_file_name" is not a valid filenamemake[3]: *** [bootparse.o] Error 1make[3]: Leaving directory `/pgsql/src/backend/bootstrap'make[2]: *** [bootstrap-recursive] Error 2make[2]: Leaving directory `/pgsql/src/backend'make[1]: *** [all] Error 2make[1]: Leaving directory `/pgsql/src'make: *** [all] Error 2 My enviroment, installed in that order: MSYS-1.0.8.exe --> d:\msys inGW-3.1.0-1.exe --> d:\msys\mingw msysDTK-1.0.1.exe -> d:\msys bison-2.1.exe --> d:\gnuwin32 flex-2.5.4a-1.exe --> d:\gnuwin32 fstab -- #Win32_Path Mount_Point#c:/mingw /mingw#c:/ActiveState/perl /perld:/gnuwin32 /gnuwin32 profile --- ... if [ $MSYSTEM == MINGW32 ]; then export PATH=".:/usr/local/bin:/mingw/bin:/bin:/gnuwin32/bin:$PATH"else export PATH=".:/usr/local/bin:/bin:/mingw/bin:/gnuwin32/bin:$PATH"fi ... S.O. : Windows 2003 server Can any body help ? Thanks in advance. Atte.Juan Manuel Díaz Lara New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates.
Re: [HACKERS] Suggestion: Which Binary?
On Apr 1, 2006, at 15:39, David Wheeler wrote: So, pray tell, what have I screwed up? I would of course be happy to submit a corrected patch. Sorry, I'm an idiot. New version attached. Best, David Index: doc/src/sgml/installation.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/installation.sgml,v retrieving revision 1.252 diff -u -r1.252 installation.sgml --- doc/src/sgml/installation.sgml 5 Jan 2006 03:01:32 - 1.252 +++ doc/src/sgml/installation.sgml 31 Mar 2006 22:08:07 - @@ -182,6 +182,14 @@ PL/Perl you need a full Perl installation, including the libperl library and the header files. + configure will collect this information + from whatever perl is in your PATH; + if you'd like it to use an alternate perl, simply + specify its location via the PERL environment + variable, e.g., PERL=/usr/bin/per5.8.6 + + + Since PL/Perl will be a shared library, the libperl libperl library must be a shared library @@ -219,6 +227,11 @@ Python 1.6 and later; users of earlier versions of Python will need to install it. + configure will collect this information + from whatever python is in your PATH; + if you'd like it to use an alternate python, simply + specify its location via the PYTHON environment + variable, e.g., PYTHON=/usr/bin/python2.3 ---(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] Suggestion: Which Binary?
David Wheeler wrote: > On Apr 1, 2006, at 15:39, David Wheeler wrote: > > So, pray tell, what have I screwed up? I would of course be happy > > to submit a corrected patch. > > Sorry, I'm an idiot. New version attached. Well, you got one of them, but I still have my doubts about "/usr/bin/per5.8.6". -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Suggestion: Which Binary?
On Apr 1, 2006, at 15:49, Peter Eisentraut wrote: Well, you got one of them, but I still have my doubts about "/usr/bin/per5.8.6". LOL! God, what an oaf! David Index: doc/src/sgml/installation.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/installation.sgml,v retrieving revision 1.252 diff -u -r1.252 installation.sgml --- doc/src/sgml/installation.sgml 5 Jan 2006 03:01:32 - 1.252 +++ doc/src/sgml/installation.sgml 31 Mar 2006 22:08:07 - @@ -182,6 +182,14 @@ PL/Perl you need a full Perl installation, including the libperl library and the header files. + configure will collect this information + from whatever perl is in your PATH; + if you'd like it to use an alternate perl, simply + specify its location via the PERL environment + variable, e.g., PERL=/usr/bin/perl5.8.6 + + + Since PL/Perl will be a shared library, the libperl libperl library must be a shared library @@ -219,6 +227,11 @@ Python 1.6 and later; users of earlier versions of Python will need to install it. + configure will collect this information + from whatever python is in your PATH; + if you'd like it to use an alternate python, simply + specify its location via the PYTHON environment + variable, e.g., PYTHON=/usr/bin/python2.3 ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Suggestion: Which Binary?
David Wheeler <[EMAIL PROTECTED]> writes:
> Right, but me, while I compile lots of stuff, I don't understand
> configure or autconf at all. So I was completely unaware of this
> feature. I'm very pleased to know it now, of course. But I don't see
> how it could be any harm to add notes to the INSTALL file explicitly
> letting users know how to do stuff like this.
Just to clarify my point: what'd make sense to me is to describe this
generic autoconf behavior, and maybe include a small table listing some
of the more-likely-to-be-useful variables. ("configure --help" already
does that, on a very small scale.) It doesn't make much sense to me to
document two specific variables in a way that fails to draw the reader's
attention to the fact that there are many other ones. After all, the
reader might have some other problem to solve than "use this perl". If
he knows that there might be a way to solve it by setting a variable,
he's ahead of the game.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Postgres dies when using an intarray operator
Michael Fuhr <[EMAIL PROTECTED]> writes: > Here's a complete test case: > CREATE TABLE foo (a integer[]); > INSERT INTO foo (a) > SELECT array[random() * 10, random() * 10, random() * 10] > FROM generate_series(1, 24); > CREATE INDEX foo_a_idx ON foo USING gist (a gist__int_ops); > SET enable_seqscan TO off; > SELECT f1.a & f2.a FROM foo f1, foo f2 WHERE f1.a && f2.a; This seems to bear out the concern expressed at _int_gist.c line 44: /* XXX are we sure it's safe to scribble on the query object here? */ regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Slony-I for circular replication
The world rejoiced as [EMAIL PROTECTED] ("Gustavo Tonini") wrote:
> Ozsu show us some solution for the problem in the book "Principles of
> distributed database systems".
Would it be "telling" to outline some of the solutions he suggests?
--
(format nil "[EMAIL PROTECTED]" "cbbrowne" "gmail.com")
http://linuxdatabases.info/info/slony.html
Rules of the Evil Overlord #189. "I will never tell the hero "Yes I
was the one who did it, but you'll never be able to prove it to that
incompetent old fool." Chances are, that incompetent old fool is
standing behind the curtain."
