On 28 Sep 2002 at 17:08, Justin Clift wrote:
> Have moved the indexes to another drive, then created symlinks to them.
> Ran a benchmark against the database, REINDEX'd the tables, VACUUM FULL
> ANALYZE'd, prepared to re-run the benchmark again and guess what?
>
> The indexes were back on the or
Hi all,
Am experimenting to find out what kind of performance gain are achieved
from moving indexes to a different scsi drives than the WAL files, than
the data itself, etc.
Have come across an interesting problem.
Have moved the indexes to another drive, then created symlinks to them.
Ran a b
Okay, I did some more research into this area. It looks like it will
be feasible to use large TLB pages for PostgreSQL.
Tom Lane <[EMAIL PROTECTED]> writes:
> It wasn't clear from your description whether large-TLB shmem segments
> even have IDs that one could use to determine whether "the segmen
Both are done, and in CVS in /contrib/adddepend.
---
Matthew T. O'Connor wrote:
> From: "Tom Lane" <[EMAIL PROTECTED]>
> > However, if we are going to put that kind of knowledge into pg_dump,
> > it would only be a small fu
I didn't think we were supposed to throw an error on a mismatch, were
we?
---
Alvaro Herrera wrote:
> Hackers,
>
> Seems the functionality to detect old versions of the postmaster with
> newer psql doesn't work. Here, ser
Hackers,
Seems the functionality to detect old versions of the postmaster with
newer psql doesn't work. Here, server is 7.2.1:
$ psql alvherre
ERROR: parser: parse error at or near "."
Welcome to psql 7.3b1, the PostgreSQL interactive terminal.
Type: \copyright for distribution terms
From: "Tom Lane" <[EMAIL PROTECTED]>
> However, if we are going to put that kind of knowledge into pg_dump,
> it would only be a small further step to have it dump these triggers
> as ALTER TABLE ADD CONSTRAINT commands instead. Which would be a lot
> better for forward compatibility than dumping
OK, we need a decision on whether we are going to do a 7.2,3 or just
have it in beta3. If it is in 7.2.3, I would not mention it in the
beta3 release notes.
---
Tom Lane wrote:
> Yesterday I reported a WAL problem that cou
Tom Lane wrote:
> Yesterday I reported a WAL problem that could lead to tuples not being
> marked as committed-good or committed-dead after we'd already removed
> the pg_clog segment that had their transaction's commit status.
> I wasn't completely satisfied with that, though, because on further
>
Yesterday I reported a WAL problem that could lead to tuples not being
marked as committed-good or committed-dead after we'd already removed
the pg_clog segment that had their transaction's commit status.
I wasn't completely satisfied with that, though, because on further
reflection it seemed a ve
Tom Lane <[EMAIL PROTECTED]> writes:
> We'd be happiest with a filesystem that journals its own metadata and
> not the user data in the file(s). I dunno if there are any.
Most journalling file systems work this way. Data journalling is not
very widespread, AFAIK.
--
Florian Weimer
Michael Meskes wrote:
> into. As far as I understand the problem, the application uses stored
> procedures for each and every select statement. Thus he needs his
> procedures to return the whole query result, which is not doable with
> our functions.
It is in 7.3.
If the return tuple definition
On Thu, 26 Sep 2002 16:32:08 -0700
Joe Conway <[EMAIL PROTECTED]> wrote:
> Masaru Sugawara wrote:
> > The previous patch fixed an infinite recursion bug in
> > contrib/tablefunc/tablefunc.c:connectby. But, other unmanageable error
> > seems to occur even if a table has commonplace tree data(see
AFAIK it's because it is a members-only list. It is archived and the
archives are web viewable if you know where to look (not that I can
remember, but I have done it before).
Robert Treat
On Fri, 2002-09-27 at 02:48, Markus Bertheau wrote:
> On Mon, 2002-09-16 at 10:52, Christopher Kings-Lynne
On Thu, 2002-09-26 at 22:42, Tom Lane wrote:
> Jim Mercer <[EMAIL PROTECTED]> writes:
> > as best i can understand, there is no way to get apach/php/pgsql configured
> > (using "PostgreSQL's native access mappings") that would disallow php code
> > in one virtual host from connecting to any databa
> > > could be done based on IP (yes it is inaccurate but it is close enough
> > > and has the same net effect: pushing people off the main web server) or
> > > it could be done by simply redirecting to a random mirror.
> >
> > Have tried both in the past with disastrous results ...
>
> What met
16 matches
Mail list logo
