From: Steven M. Wheeler <swheeler@sabre.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-sql@hub.org
Subject: Re: [SQL] Questions about vacuum analyze
Date: Tue, 12 Oct 1999 09:55:49 -0500
Message-ID: <38034BF5.AE40BBB4@sabre.com> (raw)
References: <28912.939305310@sss.pgh.pa.us>
Tom,
I tried your suggestion for -S 32 through -S 1 running a select distinct against
my history table. I normally run with -S 2048 on the startup of the master
process. FYI: the history table uses the same layout as the currnt table, its
just an hourly summation of the minute by minute data in currnt. history has
189,724 records.
Bottom line: The select never failed.
Thanks
--
Steven Wheeler
Mid-Range UNIX Engineering
Sabre Inc.
(918) 292-4119
Tom Lane wrote:
> "Steven M. Wheeler" <swheeler@sabre.com> writes:
> > I am now running into another problem. I need to do select distinct from the
> > currnt to get dates for maintenance activity (rows to summarize and move to
> > history). When ever I do I get this message in my server.log file:
>
> > NOTICE: BufFileRead: should have flushed after writing
>
> Hmph --- just looking at the code that issues that message, it looks
> like it is a harmless gripe (it complains, but then goes and does the
> missing step). However, it's suggestive that there may be a logic error
> in the sorting code that's calling the BufFileXXX routines.
>
> > And I get 0 records selected.
>
> And that's even more suggestive ;-)
>
> This is going to be tough to debug if it takes a multi-gig database to
> replicate. But if I'm guessing right about where the problem is, it
> probably can be replicated on smaller tables if you use a smaller -S
> (sort memory limit) setting when starting the backend. You can set -S
> as small as 32 (kb), and having done that the bug might show up on tables
> with a few hundred K of data. Would you try that and let me know?
>
> The easiest way to experiment is to set -S on a per-backend basis
> via the PGOPTIONS environment variable, eg
> setenv PGOPTIONS "-S 32"
> psql ...
> The backend started for this psql session will set S=32 instead of
> whatever the prevailing default is.
>
> regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-sql@postgresql.org
Cc: swheeler@sabre.com, tgl@sss.pgh.pa.us, pgsql-sql@hub.org
Subject: Re: [SQL] Questions about vacuum analyze
In-Reply-To: <38034BF5.AE40BBB4@sabre.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox