Matthew T. O'Connor wrote:
> That seems a big jump. BTW, I know .08 and .04 were suggested, but I
> didn't see confirmation that it was a good idea. I know my initial
> values were grossly over-conservative, but I am concerned about
> bogging down the server with lots of vacuums, especially since
On 8/27/06, Tom Lane <[EMAIL PROTECTED]> wrote:
My take on all this is that there's no one-size-fits-all replication
solution, and therefore the right approach is to have multiple active
subprojects.
Can't help but agree there. Maybe someday the subprojects will get
together and come up with a
Hello,
The community jabber server is now up. We are using the Wildfire server
from Jive Software, backed to a PostgreSQL database (of course).
Our current enabled features are:
1. Server side storage (for static groups etc..)
-- We currently have a Slaves_to_WWW group for example
2. MUC (
Chahine Hamila <[EMAIL PROTECTED]> writes:
> I posted a patch on the pgcluster mailing list
> but I already have two significant fixes related to
> pgcluster and one minor change related to the upgrade
> itself. I am to use PGCluster in a real time embedded
> fault-tolerant system, so I'm likely to
ECPG has several discrepancies between the documented connection
target formats and actual behavior. I'm preparing a documentation
patch as I previously mentioned in the recent "Connection string"
thread in pgsql-general, but before doing so I'd like to distinguish
documentation bugs from code bug
Andrew Dunstan wrote:
>
> Alvaro Herrera wrote:
> >This is trivial to do --- just add a /etc//postgresql file
> >that contains a line like
> >
> >AUTO_INITDB=0
> >
> >to turn the auto-initdb'ing feature of the init script off. If the file
> >is not present or AUTO_INITDB is not defined to zero i
Alvaro Herrera wrote:
Jim C. Nasby wrote:
On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
We also decided to turn off the init script execution entirely. The DBAs
were more comfortable with a manual database startup for a production
machine anyway (this is the way they ty
Caution! Blatant use of sarcasm ahead.
On 8/26/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> Umm, I don't know where you're looking Jim, but the last update was
> February 10, 2006
http://pgcluster.projects.postgresql.org/; the latest date I see there
is Mar. 7, 2005, and the newest version is
On 8/26/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Actually I was thinking in the design rather than the code ...
Doh! We hadn't posted the design just yet. Let me write him and see
where he's at and we'll throw something together for the list.
--
Jonah H. Harris, Software Architect | pho
Jim C. Nasby wrote:
> On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
> > We also decided to turn off the init script execution entirely. The DBAs
> > were more comfortable with a manual database startup for a production
> > machine anyway (this is the way they typically handle Oracle
Jonah H. Harris wrote:
> On 8/26/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >Was it posted?
>
> No, the patch has not yet been posted. I'm not sure of where Mark's
> at with it at this point in time.
Actually I was thinking in the design rather than the code ...
--
Alvaro Herrera
Joshua D. Drake wrote:
Matthew T. O'Connor wrote:
Jim C. Nasby wrote:
As Tom mentioned, it's for newbie-friendliness. While I can understand
that, I think it needs to be easy to shut that off.
I understand that, but it seems the whole problem of people
overwriting there data dir is because w
On 8/26/06, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Was it posted?
No, the patch has not yet been posted. I'm not sure of where Mark's
at with it at this point in time.
--
Jonah H. Harris, Software Architect | phone: 732.331.1300
EnterpriseDB Corporation| fax: 732.331.1301
33 Wo
Jonah H. Harris wrote:
> All,
>
> In the spirit of our previous discussion, I am writing to inform you
> that Mark Cave-Ayland and I will be working on this TODO-item
> together. We are thinking through a new design (not based on the
> current patch) and will post it to -hackers for approval soon
Matthew T. O'Connor wrote:
Jim C. Nasby wrote:
On Sat, Aug 26, 2006 at 01:32:17PM -0700, Joshua D. Drake wrote:
I am not exactly sure why we initdb at all. IMHO it would be better
if the start script just checked if there was a cluster. If not, it
wouldn't start, it would error with: You do no
Jim C. Nasby wrote:
On Sat, Aug 26, 2006 at 01:32:17PM -0700, Joshua D. Drake wrote:
I am not exactly sure why we initdb at all. IMHO it would be better if
the start script just checked if there was a cluster. If not, it
wouldn't start, it would error with: You do not have a cluster, please
re
Jim C. Nasby wrote:
On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
We also decided to turn off the init script execution entirely. The DBAs
were more comfortable with a manual database startup for a production
machine anyway (this is the way they typically handle Oracle databa
On Sat, Aug 26, 2006 at 01:32:17PM -0700, Joshua D. Drake wrote:
> Jim C. Nasby wrote:
> >On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
> >>We also decided to turn off the init script execution entirely. The DBAs
> >>were more comfortable with a manual database startup for a producti
On Sat, Aug 26, 2006 at 11:18:04AM -0700, Chahine Hamila wrote:
> 8.1.2 actually, which I have updated to apply to
> 8.1.4. I posted a patch on the pgcluster mailing list
> but I already have two significant fixes related to
> pgcluster and one minor change related to the upgrade
> itself. I am to
On Sat, Aug 26, 2006 at 08:44:07AM -0400, Jonah H. Harris wrote:
> >Second, pgcluster is (AFAIK) command-based replication, which has some
> >very, very serious drawbacks. If PostgreSQL were to include a
> >replication solution, I'd certainly hope it wouldn't be command-based.
>
> Support of PGClu
On Aug 17, 2006, at 1:41 PM, Peter Eisentraut wrote:
> But we need to work this from the other end anyway. We need to
> determine first, what sort of statistics the planner could make use of.
> Then we can figure out the difficulties in collecting them.
>
There are still some things that the ar
Jim C. Nasby wrote:
On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
We also decided to turn off the init script execution entirely. The DBAs
were more comfortable with a manual database startup for a production
machine anyway (this is the way they typically handle Oracle databases
bear some similarity to PL/Java and PL/J.
I think the big question is whether we are ever going to implement
these? I think we need to decide that before I mention them.
The SQL/Schemata thing is already in. I think we should at least
mention which features that we already have are from what
Bruce Momjian wrote:
Has this been addressed?
Tom Lane wrote:
The reason we could safely list_free inside transformInsertRow is that
we know all its callers have just built the passed-in list and so there
are no other pointers to it. That doesn't apply in the general case of
grammar output.
On Fri, Aug 25, 2006 at 07:21:50AM -0700, Joe Conway wrote:
> We also decided to turn off the init script execution entirely. The DBAs
> were more comfortable with a manual database startup for a production
> machine anyway (this is the way they typically handle Oracle databases
> also). They ge
Bruce Momjian írta:
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.
Thanks. Would you please add this instead?
psql built-i
On Sat, Aug 26, 2006 at 08:38:43PM +0200, Peter Eisentraut wrote:
> David Fetter wrote:
> > We claim SQL standard compliance,
>
> No, we don't. And SQL conformance doesn't require you to implement
> all parts anyway.
Right. It'd be nice to be able to tell what level of conformance we
have to wh
Peter Eisentraut wrote:
David Fetter wrote:
We claim SQL standard compliance,
No, we don't. And SQL conformance doesn't require you to implement all
parts anyway.
so since those are part of
SQL:2003, we probably ought to mention them. SQL/PSM is a
programming language that lives inside
David Fetter wrote:
> The SQL/Schemata thing is already in. I think we should at least
> mention which features that we already have are from what part of the
> standard.
We do. Read the documentation.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(en
Bruce Momjian wrote:
> I made it clear in the section that the XML syntax was being checked,
> not validation against a schema. You want Check and Validation
> sections?
"Valid" and "well-formed" have very specific distinct meanings in XML.
(Note that "check" doesn't have any meaning there.) W
David Fetter wrote:
> We claim SQL standard compliance,
No, we don't. And SQL conformance doesn't require you to implement all
parts anyway.
> so since those are part of
> SQL:2003, we probably ought to mention them. SQL/PSM is a
> programming language that lives inside the database, and DB2
Guillaume Smet wrote:
> IMHO, we shoud also change superuser_reserved_connections from 2 to 3
> because one of the connections will be used by autovacuum.
Yes, good point.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)-
> Support of PGCluster-I, which we're discussing here,
> is being dropped
> in favor of the shared-disk PGCluster-II which was
> demonstrated at the
> anniversary conference. IIRC, PGCluster-I does use
> command-based
> replication but is merged into the parser in such a
> way as to make it
> work
I wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> b) You introduced a LockRelationIdForSession() call (I even didn't realize we
>> had this capability when I wrote the patch). Does this introduce the
>> possibility of a deadlock though?
> Indeed, I had noticed this while testing your point (
David Fetter wrote:
> > > mention which features that we already have are from what part of
> > > the standard. As far as the rest of the standard goes, we might
> > > want to mention whether we've even considered any of each piece in
> > > the TODO list, and what sub-pieces, if any, are already
>
On Sat, Aug 26, 2006 at 01:16:06PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > On Sat, Aug 26, 2006 at 12:48:32PM -0400, Bruce Momjian wrote:
> > > David Fetter wrote:
> > > > On Fri, Aug 25, 2006 at 08:37:19PM -0400, Bruce Momjian wrote:
> >
> > > > > > Speaking of other parts of the SQ
David Fetter wrote:
> On Sat, Aug 26, 2006 at 12:48:32PM -0400, Bruce Momjian wrote:
> > David Fetter wrote:
> > > On Fri, Aug 25, 2006 at 08:37:19PM -0400, Bruce Momjian wrote:
>
> > > > > Speaking of other parts of the SQL:2003 standard, how about one
> > > > > section each that mentions them?
On Sat, Aug 26, 2006 at 12:48:32PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > On Fri, Aug 25, 2006 at 08:37:19PM -0400, Bruce Momjian wrote:
> > > > Speaking of other parts of the SQL:2003 standard, how about one
> > > > section each that mentions them? There's
> > > >
> > > > Part 4:
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.
---
B?
Andrew Dunstan wrote:
>
> I will try to draw all this together today or tomorrow. It's not only
> the FAQ that should be patched - the docs and the FAQ should agree with
> each other.
Right.
> In fact, this info arguably belongs in one place only. Which should it be?
Uh, if you put it in the
Updated XML documentation based on feedback. Comments?
---
XML Document Support
XML (eXtensible Markup Language) support is not one capability, but a
variety of features supported by a database system.
David Fetter wrote:
> On Fri, Aug 25, 2006 at 08:37:19PM -0400, Bruce Momjian wrote:
> > David Fetter wrote:
> > > On Fri, Aug 25, 2006 at 07:46:57PM -0400, Bruce Momjian wrote:
> > > > Here is an new XML section for our SGML documentation. It
> > > > explains the various XML capabilities, if we s
Nikolay Samokhvalov wrote:
> On 8/26/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
> > Bruce Momjian wrote:
> > > Validation
> > > --
> > > /contrib/xml2 has a function called xml_valid() that can be used in
> > > a CHECK constraint to enforce that a field contains valid XML. It
> > > do
Magnus Hagander wrote:
> > Indexing
> >
> > Because XML documents are stored as text, full-text indexing tool
> > /contrib/tsearch2 can be used to index XML documents. Of
> > course, the searches are text searches, with no XML
> > awareness, but tsearch2 can be used with other XML
> >
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > XML Document Support
> >
> > XML support is not one capability, but a variety of features
> > supported by a database.
>
> database system
Done.
> > Storage
> > ---
> > PostgreSQL stores XML documents as ordinary text do
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Is this being kept for 8.3?
No, it was committed a month ago.
regards, tom lane
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Gregory Stark <[EMAIL PROTECTED]> writes:
> A few concerns
> a) The use of ShareUpdateExclusiveLock is supposed to lock out concurrent
>vacuums. I just tried it and vacuum seemed to be unaffected.
Can't reproduce such a problem here.
>Do we still need to block concurrent vacuums if we're
On Fri, Aug 25, 2006 at 08:02:21PM -0500, Jim C. Nasby wrote:
> On Fri, Aug 25, 2006 at 06:57:58PM +0100, Gregory Stark wrote:
> > I'll use this opportunity to plug that feature again. I think most
> > people should use autocommit off with on_error_rollack on for most
> > of their daily use. Being
On Fri, Aug 25, 2006 at 08:37:19PM -0400, Bruce Momjian wrote:
> David Fetter wrote:
> > On Fri, Aug 25, 2006 at 07:46:57PM -0400, Bruce Momjian wrote:
> > > Here is an new XML section for our SGML documentation. It
> > > explains the various XML capabilities, if we support them, and
> > > how to
I will try to draw all this together today or tomorrow. It's not only
the FAQ that should be patched - the docs and the FAQ should agree with
each other.
In fact, this info arguably belongs in one place only. Which should it be?
cheers
andrew
Bruce Momjian wrote:
I am still waiting for an
On 8/26/06, Markus Schiltknecht <[EMAIL PROTECTED]> wrote:
Didn't Atsushi Mitani say he wanted to continue PgCluster-I? As they
serve quite different needs that would make sense.
Hmm... I was pretty sure he said that he couldn't devote time to both projects.
--
Jonah H. Harris, Software Archit
Tom Lane <[EMAIL PROTECTED]> writes:
> Barring objections, I'm off to program this.
A few concerns
a) The use of ShareUpdateExclusiveLock is supposed to lock out concurrent
vacuums. I just tried it and vacuum seemed to be unaffected. I'm going to
retry it with a clean cvs checkout to be su
Jonah H. Harris wrote:
Support of PGCluster-I, which we're discussing here, is being dropped
in favor of the shared-disk PGCluster-II which was demonstrated at the
anniversary conference. IIRC, PGCluster-I does use command-based
replication but is merged into the parser in such a way as to make
Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] (Peter Eisentraut)
would write:
> Jim C. Nasby wrote:
>> I thought we had agreed it would be a good idea to turn autovac_delay
>> on?
>
> We had not, because there was no experience available about where to put
> the default numbers.
I wo
Second, pgcluster is (AFAIK) command-based replication, which has some
very, very serious drawbacks. If PostgreSQL were to include a
replication solution, I'd certainly hope it wouldn't be command-based.
Support of PGCluster-I, which we're discussing here, is being dropped
in favor of the shared
On 8/25/06, Peter Eisentraut <[EMAIL PROTECTED]> wrote:
Summarizing this thread, I see support for the following:
- autovacuum set to on by default in 8.2.
- stats_row_level also defaults to on.
- Delayed vacuum and delayed autovacuum will stay disabled.
- Scale factor set to 0.08 (vacuum) and 0.
On 8/26/06, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
[...]
If you decide to include the mentioning about contrib/xml2 to docs, I
would suggest the patch for this module. The patch renames that
function to xml_check() and adds xml_array() (issue from the current
TODO). Or it's too late for 8
57 matches
Mail list logo
