I suspect it might be because I'm running in a jail'd environment, but
what should I be looking at to confirm?
could not create socket for statistics collector: Protocol not supported
it appears to be running though:
pgsql 60120 0.0 0.1 14112 3420 ?? SsJ 3:32AM 0:00.01
/usr/local/pgsql
On Sat, Nov 22, 2003 at 11:54:45AM -0800, Josh Berkus wrote:
> > In a nutshell, the features on my short list are all about heap
> > management (e.g. partitioning). This is really important when databases
> > reach a certain size, but something for which Postgres has almost no
> > support.
>
>
> >CREATE TABLE a (col integer primary key);
> >CREATE TABLE b (col integer primary key);
> >ALTER TABLE a ADD FOREIGN KEY (col) REFERENCES b INITIALLY DEFERRED;
> >ALTER TABLE b ADD FOREIGN KEY (col) REFERENCES a;
> Still, using cyclic references is IMHO bad design style. I can't accept
They'r
Rod Taylor wrote:
CREATE TABLE a (col integer primary key);
CREATE TABLE b (col integer primary key);
ALTER TABLE a ADD FOREIGN KEY (col) REFERENCES b INITIALLY DEFERRED;
ALTER TABLE b ADD FOREIGN KEY (col) REFERENCES a;
How does MSSQL deal with the above?#
It depends. Restricting FKs are gen
Josh Berkus <[EMAIL PROTECTED]> writes:
> I'm a little unclear, personally, about what can be accomplished through table
> partitioning that we can't currently do through partial indexes and inherited
> tables, especially after Gavin finishes his tablespaces patch (btw, Gavin
> could use spons
On Sat, 2003-11-22 at 16:53, Andreas Pflug wrote:
> Stephan Szabo wrote:
>
> >You're going to potentially have the constraints scattered in any case due
> >to circular dependency chains. I'd think that having all the constraints
> >in one place would be easier than trying to go through the list of
Stephan Szabo wrote:
You're going to potentially have the constraints scattered in any case due
to circular dependency chains. I'd think that having all the constraints
in one place would be easier than trying to go through the list of tables
that might be in a circular chain in order to find the
On Fri, Nov 21, 2003 at 04:24:25PM -0500, Matthew T. O'Connor wrote:
> I don't want to add tables to existing databases, as I consider that
> clutter and I never like using tools that clutter my production
> databases. [...]
>
> Actually, this might be a necessary addition as pg_autovacuum cur
On 2003.11.19 14:17 Austin Gonyou wrote:
> All,
>
> I sincerely apologize for possibly starting a flame war, I wasn't aware
> this might be a hot-button issue. Hopefully some good will come of it
> none-the-less, like others who come after me might see the reasons our
> db application developers
James,
> I'm not sure what Oracle has to do with any of this. If I wanted to use
> Oracle, I would buy Oracle.
Good. Your original post, which appeared to propose carbon-copying a number
of features from Oracle -- I didn't necessarily read it that way, but several
other people did, including
Oops, sorry folks. That was only meant to go to Joshua.
On Sat, 22 Nov 2003, Nigel J. Andrews wrote:
>
> > However, I would love to see those patches.
>
> Sure. Should be in the archive. The version for 7.4 was submitted and applied
> ...
---(end of broadcast)--
> However, I would love to see those patches.
Sure. Should be in the archive. The version for 7.4 was submitted and applied
pre-release but if you really do want the 7.3 runnable stuff I can send it. It
was only the unchecked returns from malloc and family patch in the snowball
directory. I thin
> Does that mean I have supplied Logictree Systems PostgreSQL? PostgreSQL with
> Logictree Systems TSearch2?
Actually to some degree, yes. Of course a lot would depend on the type
of contract you have with them you may be "responsible" for that code.
However, I would love to see those patches.
On 19 Nov 2003, Robert Treat wrote:
> I don't think *we* thought it was a hot button issue.. at least I
> certainly didn't when I initially responded. There is no need for you to
> apologize, in fact, I'll apologize for the list, we sometimes get a
> little heated on -hackers. Hopefully you've not
On Wed, 19 Nov 2003, Joshua D. Drake wrote:
> Hello,
>
> I think what the person is looking for is:
>
> COMPANY PostgreSQL for Red Hat Enterprise 3.0.
>
> They probably have some commercial mandate that says that they have
> to have a commercial company backing the product itself. This d
On Sat, 22 Nov 2003, Andreas Pflug wrote:
> Christopher Kings-Lynne wrote:
>
> >
> >
> > There are two levels (sort of) of dependency. The first is that whole
> > classes of objects can be dependent on whole other classes. eg.
> > databases depend on users, or ALL FK's can be dumped after ALL ta
Christopher Kings-Lynne wrote:
There are two levels (sort of) of dependency. The first is that whole
classes of objects can be dependent on whole other classes. eg.
databases depend on users, or ALL FK's can be dumped after ALL tables,
etc.. It would make the dump more readable if you dump
17 matches
Mail list logo