On Mon, 2004-02-02 at 22:11, Alvaro Herrera wrote:
> On Mon, Feb 02, 2004 at 04:22:29PM +1100, Stephen Robert Norris wrote:
> > On Fri, 2004-01-30 at 13:04, Alvaro Herrera wrote:
> > > On Thu, Jan 29, 2004 at 08:50:47PM -0500, Manuel Tejada wrote:
> > >
> > >
On Fri, 2004-01-30 at 13:04, Alvaro Herrera wrote:
> On Thu, Jan 29, 2004 at 08:50:47PM -0500, Manuel Tejada wrote:
>
> > By the way, what does mean RHEL3?
>
> "Red Hat Entreprise Linux", a commercial Linux distribution (meaning you
> shouldn't use it unless you pay for it).
No, it means you won
On Wed, 2004-01-21 at 11:55, Marc G. Fournier wrote:
> On Tue, 20 Jan 2004, Gavin M. Roy wrote:
>
> > I'm currently one of the targets of SCO's linux licensing extortion
> > business plan, and am contemplating switching to one of the BSD's to
> > avoid any potential problems. I'm curious which B
On Tue, 2003-11-25 at 16:58, Randolf Richardson wrote:
> [sNip]
> >> In summary, you could be charging them for some very expensive courier
> >> services, if for which they don't pay then you won't deliver. =)
> >
> > Of course a competitor could purchase a copy or get it from a customer
> > and
On Thu, 2003-11-20 at 02:06, JosuĂ Maldonado wrote:
> Hi Stephen,
>
> Stephen Robert Norris wrote:
> >
> >
> > Speaking from long experimentation, you're much, much better off making
> > sure your indices and queries are optimal that messing around with
On Thu, 2003-11-13 at 10:01, Tom Lane wrote:
> Mark Harrison <[EMAIL PROTECTED]> writes:
> > Since these are all unique things, and will only be tested for
> > equality, I am guessing that making a hash index will be better
> > than making a btree index.
>
> You are mistaken. If there were any re
On Tue, 2003-08-26 at 08:40, Dennis Gearon wrote:
> Hee Hee, but I _**LIKE**_ top quoting.
That's good. Top-quoting is good.
Top posting, on the other hand, is bad. It's also what you did.
Stephen
--
Stephen Robert Norris <[EMAIL PROTECTED]>
CommSecur
sql/data/pg_clog/0323 failed: No such file or
directory
and I have to drop/restore the table in question.
Is this a known problem? Is there some safe way to dump databases that
avoids it?
Stephen
--
Stephen Robert Norris <[EMAIL PROTECTED]>
CommSecure Aus
On Wed, 2001-10-17 at 16:56, Denis Gasparin wrote:
> At 16/10/01 14.00, you wrote:
> >Does the python interface leak memory? We are seeing the process grow
> >with basically every select. Any suggestions on what's going on? There
> >are no cycles, and a trivial program (basically a loop around a s
On Sun, Aug 19, 2001 at 10:02:02AM +0800, Lincoln Yeoh wrote:
> At 09:18 AM 8/19/01 +1000, Stephen Robert Norris wrote:
> >Recreating the sequence solves the problem, of course. So does setval(102).
> >My problem is that it got into this state originally. The test case that
>
On Sun, Aug 19, 2001 at 01:23:13PM +1000, Justin Clift wrote:
> Hmmm...
>
> Well, that would be a
>
> CREATE SEQUENCE foo_seq START 1 MINVALUE 4 MAXVALUE 101 CYCLE
>
> Still, that's not helpful. :(
>
> Is there any chance that the application created the sequence, or that
> someone created i
On Sun, Aug 19, 2001 at 12:42:36PM +1000, Justin Clift wrote:
> Hi Stephen,
>
> That's weird behaviour. If you'd manually created the sequence like
> this :
>
> CREATE SEQUENCE foo_seq MINVALUE 4 MAXVALUE 101 CYCLE
>
> Then referenced it as the default like this :
>
> CREATE TABLE bar (idnum
On Sat, Aug 18, 2001 at 03:49:10PM -0700, Joe Conway wrote:
> > > > Sometimes (about 20%, it seems) with several of the data sets, we
> > > > get an error trying to insert rows into the table with the serial in
> it.
> > > > On investigation, it seems that the serial number has got to 101, then
>
13 matches
Mail list logo
