date:20061025

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Cesar Suga


Hi,

I also wrote Bruce about that.

It happens that, if you 'freely advertise' commercial solutions (rather 
than they doing so by other vehicles) you will always happen to be an 
'updater' to the docs if they change their product lines, if they change 
their business model, if and if.


If you cite a commercial solution, as a fair game you should cite *all* 
of them. If one enterprise has the right to be listed in the 
documentation, all of them might, as you will never be favouring one of 
them.


That's the main motivation to write this. Moreover, if there are also 
commercial solutions for high-end installs and they are cited as 
providers to those solutions, it (to a point) disencourages those of 
gathering themselves and writing open source extensions to PostgreSQL.


As Bruce stated, then should the documentation contemplate 
EnterpriseDB's Oracle functions? Should PostgreSQL also come with it? 
Wouldn't it be painful to make, say, another description for an 
alternate product other than EnterpriseDB if it arises?


If people (who read the documentation) professionally work with 
PostgreSQL, they may already have been briefed by those commercial 
offerings in some way.


I think only the source and its tightly coupled (read: can compile along 
with, free as PostgreSQL) components should be packaged into the tarball.


However, I find Bruce's unofficial wiki idea a good one for comparisons.

Regards,
Cesar

Steve Atkins wrote:


On Oct 24, 2006, at 9:20 PM, Bruce Momjian wrote:


Steve Atkins wrote:

If we are to add them, I need to hear that from people who haven't
worked in PostgreSQL commerical replication companies.


I'm not coming to PostgreSQL for open source solutions. I'm coming
to PostgreSQL for _good_ solutions.

I want to see what solutions might be available for a problem I have.
I certainly want to know whether they're freely available, commercial
or some flavour of open source, but I'd like to know about all of them.

A big part of the value of Postgresql is the applications and 
extensions

that support it. Hiding the existence of some subset of those just
because of the way they're licensed is both underselling postgresql
and doing something of a disservice to the user of the document.


OK, does that mean we mention EnterpriseDB in the section about Oracle
functions?  Why not mention MS SQL if they have a better solution?  I
just don't see where that line can clearly be drawn on what to include.
Do we mention Netiza, which is loosely based on PostgreSQL?   It just
seems very arbitrary to include commercial software.  If someone wants
to put in on a wiki, I think that would be fine because that doesn't
seems as official.


Good question. The line needs to be drawn somewhere. It's basically
your judgement, tempered by other peoples feedback, though. If it
were me, I'd ask myself Would I mention this product if it were open
source? Would mentioning it help people using the document?.

Cheers,
  Steve


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org




---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] [SPAM?] Re: Asynchronous I/O Support

2006-10-25 Thread NikhilS

Hi,

While we are at async i/o. I think direct i/o and concurrent i/o also deserve a look at. The archives suggest that Bruce had some misgivings about dio because of no kernel caching, but almost all databases seem to (carefully) use dio (Solaris, Linux, ?) and cio (AIX) extensively nowadays.

Since these can be turned on a per file basis, perf testing them out should be simpler too.

Regards,
Nikhils
On 10/25/06, Martijn van Oosterhout kleptog@svana.org wrote:
On Tue, Oct 24, 2006 at 12:53:23PM -0700, Ron Mayer wrote: Anyway, for those who want to see what they do in Linux,
http://www.gelato.unsw.edu.au/lxr/source/mm/fadvise.c Pretty scary that Bruce said it could make older linuxes dump core - there isn't a lot of code there.
The bug was probably in the glibc interface to the kernel. Google foundthis:http://sourceware.org/ml/libc-hacker/2004-03/msg0.html
i.e. posix_fadvise appears to have been broken on all 64-bitarchitechtures prior to March 2004 due to a silly linking error.And then things like this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=313219Which suggest that prior to glibc 2.3.5, posix_fadvise crashed on 2.4kernels. That's a fairly recent version, so the bug would still befairly widespead.
Have a nice day,--Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ From each according to his ability. To each according to his ability to litigate.
-BEGIN PGP SIGNATURE-Version: GnuPG v1.4.1 (GNU/Linux)iD8DBQFFPnYrIB7bNG8LQkwRAuAqAJ4uqx8y9LxUa9RcEDm7CPwZ2lkS2wCfYxjB2KzJ7iDYU21lumcZT6cHeLI==MzUY-END PGP SIGNATURE-
-- All the world's a stage, and most of us are desperately unrehearsed.

Re: [HACKERS] Replication documentation addition

2006-10-25 Thread Hannu Krosing

Ühel kenal päeval, T, 2006-10-24 kell 22:57, kirjutas Bruce Momjian:
 I don't think the PostgreSQL documentation should be mentioning
 commercial solutions.

IMNSHO, having commercial solutions based on postgresql which extend
postgres in directions not (yet?) done by core postgres is nothing to be
ashamed of.

And we should at least mention the OSS version of Bizgres as a place
where quite a lot of initial development is done on performance
improvements considered too risky for mainline postgresql.

And if you need a more technical reason, you can use free libpq and psql
to connect to even Bizgres MPP ;)


 ---
 
 Luke Lonergan wrote:
  Bruce, 
  
   -Original Message-
   From: [EMAIL PROTECTED] 
   [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
   Sent: Tuesday, October 24, 2006 5:16 PM
   To: Hannu Krosing
   Cc: PostgreSQL-documentation; PostgreSQL-development
   Subject: Re: [HACKERS] Replication documentation addition
   
   
   OK, I have updated the URL.  Please let me know how you like it.
  
  There's a typo on line 8, first paragraph:
  
  perhaps with only one server allowing write rwork together at the same
  time.
  
  Also, consider this wording of the last description:
  
  Single-Query Clustering...
  
  Replaced by:
  
  Shared Nothing Clustering
  ---
  
  This allows multiple servers with separate disks to work together on a
  each query.
  In shared nothing clusters, the work of answering each query is
  distributed among
  the servers to increase the performance through parallelism.  These
  systems will
  typically feature high availability by using other forms of replication
  internally.
  
  While there are no open source options for this type of clustering,
  there are several
  commercial products available that implement this approach, making
  PostgreSQL achieve
  very high performance for multi-Terabyte business intelligence
  databases.
  
  - Luke
 
-- 

Hannu Krosing
Database Architect
Skype Technologies OÜ
Akadeemia tee 21 F, Tallinn, 12618, Estonia

Skype me:  callto:hkrosing
Get Skype for free:  http://www.skype.com


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Markus Schiltknecht


Hi,

Bruce Momjian wrote:
I have updated the text.  Please let me know what else I should change. 
I am unsure if I should be mentioning commercial PostgreSQL products in

our documentation.


I support your POV and vote for not including any pointers to commercial 
extensions in the official documentation. If at all, they should go to 
'external-projects.sgml', where PostGIS, PgAdmin and other projects are 
mentioned.


I can't really get excited about the exclusion of the term 
'replication', because it's what most people are looking for. It's a 
well known term. Sorry if it sounded that way, but I've not meant to 
avoid that term.


The newly created terms 'Query Broadcast Load Balancing' or even worse 
'Multi-Master Load Balancing' are more confusing than helpful, because 
these terms do not exist. (See the googlefight in [1])


Can we name the chapter Fail-over, Load-Balancing and Replication 
Options? That would fit everything and contain the necessary buzz words.


Also, I'm still missing Multi- vs Single-Master, which are also commonly 
used terms.


IMHO, it does not make sense to speak of a synchronous replication for a 
'Shared Disk Fail Over'. It's not replication, because there's no replica.


The Data Partitioning paragraph should probably mention it's close 
relation with data partitioning across table spaces (and make the 
differences clear).


What you call 'Query Broadcast Load Balancing' is also a multi-master 
replication, thus naming only the later 'Multi-Master Load Balancing' 
misleading.


I'd propose to add a subsection 'Synchronous, Multi-Master Replication' 
and explain the different possibilities on how to do that:


* Query-Based
* with 2PC
* Distributed SHMEM
* (perhaps mention the optimized Postgres-R algorithm ;-)

What you called 'Single-Query Clustering' is probably better known as 
'Parallel Query Execution'. It can be combined with all types of 
replication (every combination of async / sync and Single- / 
Multi-Master). It's maybe load balancing, but it depends on some form of 
replication to distribute the data first.


I liked Chris Browns documentation in [2] which was clearer regarding 
replication (which can be used to do fail-over, load-balancing, 
data-partitioning or parallel query execution). I'd like to keep all 
those things a little more separate to get them clear.


Regards

Markus

[1]: Googlefight: Multi-Master Load Balancing vs Multi-Master 
Replication: http://tinyurl.com/y3k76r


[2]: Chris Browns proposal for a replication documentation:
http://archives.postgresql.org/pgsql-patches/2006-08/msg00026.php

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Magnus Hagander

 I don't think the PostgreSQL documentation should be 
 mentioning commercial solutions.

I think maybe the PostgreSQL documentation should be careful about
trying to list a complete list of commercial *or* free solutions.
Instead linking to something on the main website or on techdocs that can
more easily be updated.

//Magnus

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Shane Ambler


Bruce Momjian wrote:


OK, does that mean we mention EnterpriseDB in the section about Oracle
functions?  Why not mention MS SQL if they have a better solution?  I
just don't see where that line can clearly be drawn on what to include.
Do we mention Netiza, which is loosely based on PostgreSQL?   It just
seems very arbitrary to include commercial software.  If someone wants
to put in on a wiki, I think that would be fine because that doesn't
seems as official.


I agree that the commercial offerings shouldn't be named directly in the 
docs, but it should be mentioned that some commercial options are 
available and a starting point to find more information.


If potential new users look through the docs and it says no options 
available for what they want or consider they will need in the future 
then they go elsewhere, if they know that some options are available 
then they will look further if they want that feature.


something like
There are currently no open source solutions available for this option 
but there are some commercial offerings. More details of some available 
solutions can be found at postgresql.org/support/




--

Shane Ambler
[EMAIL PROTECTED]

Get Sheeky @ http://Sheeky.Biz

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code

2006-10-25 Thread JEAN-PIERRE PELLETIER


Here is what I get with loglevel=2

08:47:18.718 (1) PostgreSQL 8.2devel JDBC3 with SSL (build 503)
08:47:18.718 (1) Trying to establish a protocol version 3 connection to 
localhost:5432
08:47:18.859 (1)  FE= StartupPacket(user=postgres, database=main, 
client_encoding=UNICODE, DateStyle=ISO)

08:47:19.218 (1)  =BE AuthenticationOk
08:47:19.234 (1)  =BE ParameterStatus(client_encoding = UNICODE)
08:47:19.234 (1)  =BE ParameterStatus(DateStyle = ISO, MDY)
08:47:19.234 (1)  =BE ParameterStatus(integer_datetimes = off)
08:47:19.234 (1)  =BE ParameterStatus(is_superuser = on)
08:47:19.234 (1)  =BE ParameterStatus(server_encoding = LATIN1)
08:47:19.234 (1)  =BE ParameterStatus(server_version = 8.2beta1)
08:47:19.234 (1)  =BE ParameterStatus(session_authorization = postgres)
08:47:19.234 (1)  =BE ParameterStatus(standard_conforming_strings = off)
08:47:19.234 (1)  =BE ParameterStatus(TimeZone = US/Eastern)
08:47:19.234 (1)  =BE BackendKeyData(pid=3248,ckey=166035706)
08:47:19.234 (1)  =BE ReadyForQuery(I)
08:47:19.234 (1) compatible = 8.2
08:47:19.234 (1) loglevel = 2
08:47:19.234 (1) prepare threshold = 5
getConnection returning 
driver[className=org.postgresql.Driver,[EMAIL PROTECTED]
08:47:19.296 (1) simple execute, 
[EMAIL PROTECTED], 
maxRows=0, fetchSize=0, flags=17
08:47:19.296 (1)  FE= Parse(stmt=null,query=select $1 from (select * from 
pg_database) t,oids={23})

08:47:19.296 (1)  FE= Bind(stmt=null,portal=null,$1=1)
08:47:19.296 (1)  FE= Describe(portal=null)
08:47:19.296 (1)  FE= Execute(portal=null,limit=0)
08:47:19.296 (1)  FE= Sync
08:47:19.718 (1)  FE= Terminate
08:47:19.718 (1) Discarding IOException on close:
java.net.SocketException: Connection reset by peer: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(Unknown Source)
at java.net.SocketOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.flush(Unknown Source)
at org.postgresql.core.PGStream.flush(PGStream.java:532)
	at 
org.postgresql.core.v3.ProtocolConnectionImpl.close(ProtocolConnectionImpl.java:131)
	at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:215)
	at 
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
	at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
	at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:258)

at org.apache.jsp.Test_jsp._jspService(Test_jsp.java:104)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)

at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
	at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
	at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
	at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
	at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
	at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
	at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
	at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
	at 
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:831)
	at 
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:639)

at 
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1196)
at java.lang.Thread.run(Unknown Source)
org.postgresql.util.PSQLException: An I/O error occured while sending to the 
backend.
	at 
org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:216)
	at 
org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
	at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
	at 
org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:258)

at org.apache.jsp.Test_jsp._jspService(Test_jsp.java:104)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
	at 
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)

at 
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)

Re: [HACKERS] Incorrect behavior with CE and ORDER BY

2006-10-25 Thread Matteo Beccati


Tom Lane ha scritto:

Alvaro Herrera [EMAIL PROTECTED] writes:

Limit (50)
  Sort (key: pse_lastlogin)
Result
   Append
  Limit (50)
 SeqScan tbl_profile_search
  Limit (50)
 Indexscan tbl_profile_search_interest_1
  Limit (50)
 IndexScan on the index mentioned above


is wrong because there's no guarantee that the first 50 elements of a
seqscan will be anything special.  You could imagine dealing with that
by sorting the seqscan results and limiting to 50, or by not
sorting/limiting that data at all but letting the upper sort see all the
seqscan entries.  Offhand I think either of those could win depending on
how many elements the seqscan will yield.  Also, it might be interesting
to consider inventing a merge plan node type that takes N
already-sorted inputs and produces a sorted output stream.  Then we'd
need to trade off this approach versus doing the top-level sort, which
could cope with some of its inputs not being pre-sorted.

This seems to have some aspects in common with the recent discussion
about how to optimize min/max aggregates across an appendrel set.


The plan proposed by Alvaro reminds me of:

http://archives.postgresql.org/pgsql-performance/2005-09/msg00047.php

My proposal was in fact (Alvaro's plan + first Tom's suggested change):

Limit (50)
  Sort (key: pse_lastlogin)
Result
   Append
  Limit (50)
 Sort (key: pse_lastlogin)
SeqScan tbl_profile_search
  Limit (50)
 Indexscan tbl_profile_search_interest_1
  Limit (50)
 IndexScan on the index mentioned above

The plan was generated rewriting the query to use explicit subselect and 
forcing the planner to order by and limit for each subquery.


I've tried a few times to write a patch to handle it, but I wasn't able 
to do it because of my lack of internals knowledge and spare time.



Best regards
--
Matteo Beccati
http://phpadsnew.com
http://phppgads.com

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Jim C. Nasby

On Wed, Oct 25, 2006 at 08:22:25PM +0930, Shane Ambler wrote:
 Bruce Momjian wrote:
 
 OK, does that mean we mention EnterpriseDB in the section about Oracle
 functions?  Why not mention MS SQL if they have a better solution?  I
 just don't see where that line can clearly be drawn on what to include.
 Do we mention Netiza, which is loosely based on PostgreSQL?   It just
 seems very arbitrary to include commercial software.  If someone wants
 to put in on a wiki, I think that would be fine because that doesn't
 seems as official.
 
 I agree that the commercial offerings shouldn't be named directly in the 
 docs, but it should be mentioned that some commercial options are 
 available and a starting point to find more information.
 
 If potential new users look through the docs and it says no options 
 available for what they want or consider they will need in the future 
 then they go elsewhere, if they know that some options are available 
 then they will look further if they want that feature.
 
 something like
 There are currently no open source solutions available for this option 
 but there are some commercial offerings. More details of some available 
 solutions can be found at postgresql.org/support/

I think this is probably the best compromise. Keep in mind that many
people who are looking at us will also be looking at MySQL, which is
itself a commercial offering. It's good to let folks know that with
PostgreSQL, they have more control over how much money they spend for
commercial add-ons and support.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Jim C. Nasby

On Wed, Oct 25, 2006 at 11:38:11AM +0200, Markus Schiltknecht wrote:
 I can't really get excited about the exclusion of the term 
 'replication', because it's what most people are looking for. It's a 
 well known term. Sorry if it sounded that way, but I've not meant to 
 avoid that term.
snip 
 IMHO, it does not make sense to speak of a synchronous replication for a 
 'Shared Disk Fail Over'. It's not replication, because there's no replica.

Those to statements are at odds with each other, at least based on
everyone I've ever talked to in a commercial setting. People will use
terms like 'replication', 'HA' or 'clustering' fairly interchangably.
Usually what these folks want is some kind of high-availability
solution. A few are more concerned with scalability. Sometimes it's a
combination of both. That's why I think it's good for the chapter to
deal with both aspects of this.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Joshua D. Drake

 
 I am not inclined to add commercial offerings.  If people wanted
 commercial database offerings, they can get them from companies that
 advertize.  People are coming to PostgreSQL for open source solutions,
 and I think mentioning commercial ones doesn't make sense.
 
 If we are to add them, I need to hear that from people who haven't
 worked in PostgreSQL commerical replication companies.
 

You did, Josh Berkus. Secondly, as many people have stated in the past
not one replication suits everyone's needs and as PostgreSQL has many
replication solutions, it only makes sense to list the more prominent
ones, commercial or not.

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


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Joshua D. Drake


 A big part of the value of Postgresql is the applications and extensions
 that support it. Hiding the existence of some subset of those just
 because of the way they're licensed is both underselling postgresql
 and doing something of a disservice to the user of the document.
 
 OK, does that mean we mention EnterpriseDB in the section about Oracle
 functions?

Way to compare apples to houses their Bruce. We are talking about
*PostgreSQL* replication solutions. Not *Oracle* compatibility
functions, However, *if* we had an Oracle compatibility section, I would
say, Yes it does make sense to list EnterpriseDB as a Proprietary
Commercial solution to migrating from Oracle.

  Why not mention MS SQL if they have a better solution?

Because we aren't talking about MS SQL, we are talking about PostgreSQL.

  I
 just don't see where that line can clearly be drawn on what to include.
 Do we mention Netiza, which is loosely based on PostgreSQL?   It just
 seems very arbitrary to include commercial software.

It is no more arbitrary than including *any* information on PostgreSQL
replication solutions, because PostgreSQL doesn't have any.

PostgreSQL doesn't do replication, except for PITR (and that is pushing
it as a replication solution).

Now.. there are *projects* that enable PostgreSQL to do replication.
Some of them are Open Source, some of them are commercial products.

Sincerely,

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


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code

2006-10-25 Thread Tom Lane

JEAN-PIERRE PELLETIER [EMAIL PROTECTED] writes:
 08:47:19.296 (1)  FE= Parse(stmt=null,query=select $1 from (select * from 
 pg_database) t,oids={23})

Actually, now that I look closely, this command is almost certainly
triggering this beta1 bug:
http://archives.postgresql.org/pgsql-committers/2006-10/msg00107.php

Please try beta2 and see if it isn't fixed.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Markus Schaber

Hi, Cesar,

Cesar Suga wrote:
 If people (who read the documentation) professionally work with
 PostgreSQL, they may already have been briefed by those commercial
 offerings in some way.
 
 I think only the source and its tightly coupled (read: can compile along
 with, free as PostgreSQL) components should be packaged into the tarball.
 
 However, I find Bruce's unofficial wiki idea a good one for comparisons.

My suggestion is that the docs should mention only the pure existence of
important third-party packages and projects in those places where it
talks about the deficits that are supposedly fixed by those.

E. G. There are some third-party packages and projects that aim to
provide multi-master replication, you can search for more information at
http://[unofficial wiki page url] or your favourite search engine.

This way, the docs stay neutral, but point the user to possible
solutions of his problem.

HTH,
Markus
-- 
Markus Schaber | Logical TrackingTracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org



signature.asc
Description: OpenPGP digital signature

Re: [DOCS] [HACKERS] Replication documentation addition

2006-10-25 Thread Joshua D. Drake

Cesar Suga wrote:
 Hi,
 
 I also wrote Bruce about that.
 
 It happens that, if you 'freely advertise' commercial solutions (rather
 than they doing so by other vehicles) you will always happen to be an
 'updater' to the docs if they change their product lines, if they change
 their business model, if and if.

That is no different than the open source offerings. We have had several
open source offerings that have died over the years. Replicator, for
example has always been Replicator and has been around longer than any
of the current replication solutions.

 
 If you cite a commercial solution, as a fair game you should cite *all*
 of them.

No. That doesn't make any sense either. I assume we aren't going to list
all PostgreSQL OSS replication solutions (there are at least a dozen or
more).

You list the ones that are stable in their existence (commercial or not).

 If one enterprise has the right to be listed in the
 documentation, all of them might, as you will never be favouring one of
 them.

You are looking at this the wrong way. This isn't about *any*
enterprise. It is about a PostgreSQL Solution. There happens to be two
or three known working open source solutions, and two or three known
working commercial solutions.

 
 That's the main motivation to write this. Moreover, if there are also
 commercial solutions for high-end installs and they are cited as
 providers to those solutions, it (to a point) disencourages those of
 gathering themselves and writing open source extensions to PostgreSQL.


No it doesn't. Because there is always the, It want's to be free! crowd.


 If people (who read the documentation) professionally work with
 PostgreSQL, they may already have been briefed by those commercial
 offerings in some way.

Maybe, maybe not.

Sincerely,

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


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

55 matches

Mail list logo