> John Buckman <[EMAIL PROTECTED]> writes:
> > It seems that with larger database sizes (500,000 rows and larger) and
> > high stress, the server daemon has a tendency to core.
> We'd love to see some stack traces ...
Yeah, I just didn't know what form this list prefers in terms of info to be ab
John Buckman wrote:
> > John Buckman <[EMAIL PROTECTED]> writes:
> > > It seems that with larger database sizes (500,000 rows and larger) and
> > > high stress, the server daemon has a tendency to core.
>
> > We'd love to see some stack traces ...
>
> Yeah, I just didn't know what form this list
> John Buckman <[EMAIL PROTECTED]> writes:
> > It seems that with larger database sizes (500,000 rows and larger) and
> > high stress, the server daemon has a tendency to core.
> We'd love to see some stack traces ...
Yeah, I just didn't know what form this list prefers to work on things, which
On Fri, 20 Sep 2002, Thomas Lockhart wrote:
> Well, what I was hoping for, but no longer expect, is that features
> (store xlog in another area) can be implemented and applied without
> rejection by the new gatekeepers.
It can be, and very simply. So long as you do it in the way which
is not err
Oliver Elphick <[EMAIL PROTECTED]> writes:
>>> 3. A view is being created before one of the tables it refers to.
> While I don't think that the oids have wrapped round, the oid of the
> table in question is larger than the oid of the view. It is quite
> likely that the table was dropped and rec
On Sat, 2002-09-21 at 19:49, Tom Lane wrote:
> > 3. A view is being created before one of the tables it refers to.
>
> On thinking about it, I'm having a hard time seeing how that case could
> arise, unless the source database was old enough to have wrapped around
> its OID counter. I'd be inte
Awhile back, Oliver Elphick <[EMAIL PROTECTED]> wrote:
> I am trying to populate a 7.3 database from a 7.2 dump. I used 7.3's
> pg_dumpall, but this did not handle all the issues:
> 1. The language dumping needs to be improved:
This is now fixed.
> 2. Either casts or extra default conversions
Oleg Bartunov writes:
> > > Someone said that the conversion table is actually koi8r + koi8u,
> > > being different from IANA's koi8_r. Not sure though.
> >
> > I found mention in the archives by Oleg B. that it is in fact koi8_r.
> >
>
> on my system (linux) I have ru_RU.KOI8-R locale.
We're no
I have noticed a change in behavior following the recent changes for
casting of numeric constants. In prior releases, we got
regression=# select log(10.1);
log
--
1.00432137378264
(1 row)
CVS tip gives
regression=# select log(10.1);
log
--
1.0043213738
"Pete St. Onge" <[EMAIL PROTECTED]> writes:
> As a result of some disk errors on another drive, an admin in our group
> brought down the server hosting our pgsql databases with a kill -KILL
> after having gone to runlevel 1 and finding the postmaster process still
> running. No surprise, our insta
On 20 Sep 2002 at 10:27, Mike Benoit wrote:
> On Fri, 2002-09-20 at 08:52, Shridhar Daithankar wrote:
>
> > Besides there is issue of space. Mysql takes 1.4GB space for 1.2GB text data
> > and postgresql takes 3.2GB of space. Even with 40 bytes per row overhead
> > mentioned in FAQ, that shoul
11 matches
Mail list logo