On Wed, Mar 07, 2007 at 07:07:45PM -0700, Ed L. wrote:
> How would I go about correctly creating the missing file? That
> sounds appealing, as if it were something I could do without
> taking downtime. Is it?
Depends if it's because the file got deleted prematurly, or because
it's the result o
On Wednesday March 7 2007 3:13 am, Martijn van Oosterhout wrote:
> On Wed, Mar 07, 2007 at 02:29:08AM -0700, Ed L. wrote:
> > Perhaps my question was not clear enough. Let me rephrase:
> > Does the fix for this problem comes from a *fresh* DB
> > structure resulting from the initdb, or from a sof
On Wed, Mar 07, 2007 at 02:29:08AM -0700, Ed L. wrote:
> Perhaps my question was not clear enough. Let me rephrase: Does
> the fix for this problem comes from a *fresh* DB structure
> resulting from the initdb, or from a software fix in 8.1.8, or
> both? The answer makes a big difference with
On Tuesday March 6 2007 11:52 pm, Peter Eisentraut wrote:
> Ed L. wrote:
> > Right. I'm asking if the fix for this problem is in the new
> > 8.1.8 software, or in the new DB structure resulting from
> > the initdb, or perhaps both.
>
> There is no new DB structure in 8.1.8, which is why you can
>
Ed L. wrote:
> Right. I'm asking if the fix for this problem is in the new
> 8.1.8 software, or in the new DB structure resulting from the
> initdb, or perhaps both.
There is no new DB structure in 8.1.8, which is why you can update
without initdb. Consult the release notes for details.
--
Pe
On Tuesday March 6 2007 3:53 pm, Joshua D. Drake wrote:
>
> > Is restarting with 8.1.8 a known solution for this problem?
> > Or is an initdb required to fix it?
>
> You can update to 8.1.8 (if you are running 8.1.x) without an
> initdb.
Right. I'm asking if the fix for this problem is in the n
If initdb is required, we might as well move to the latest stable
8.2 version. I understand my options to minimize downtime to be
limited to async replication. Other ideas?
BTW, the RAM looks good.
You can update to 8.1.8 (if you are running 8.1.x) without an initdb.
Joshua D. Drake
On Tuesday March 6 2007 12:20 pm, Peter Eisentraut wrote:
> Ed L. wrote:
> > I am seeing the following error in pgsql 8.1.2:
> >
> > ERROR: could not access status of transaction 3229475082
> > DETAIL: could not open file "pg_clog/0C07": No such file or
> > directory
> >
> > What does it mean, an
Ed L. wrote:
> I am seeing the following error in pgsql 8.1.2:
> ERROR: could not access status of transaction 3229475082
> DETAIL: could not open file "pg_clog/0C07": No such file or directory
>
> What does it mean, and what should I do about it?
1. Read this thread:
http://archives.postgresq
Ulrich Wisser <[EMAIL PROTECTED]> writes:
>indexrelid
> ---
> userclick_i01
> userclick_i02
> userclick_i03
> userclick_i04
> userclick_i05
> userclick_i06
> userclick_i07
> (7 rows)
OK, so userclick_i02 appears to be the broken index.
> How do I proceed? How can I t
Hi Tom,
No, it would be the one next to be processed. VACUUM does them in OID
order, so try something like
select indexrelid::regclass from pg_index
where indrelid = 'public.userclick'::regclass
order by indexrelid;
indexrelid
---
userclick_i01
usercli
Ulrich Wisser <[EMAIL PROTECTED]> writes:
> INFO: vacuuming "public.userclick"
> INFO: index "userclick_i01" now contains 13715747 row versions in 60640
> pages
> DETAIL: 0 index row versions were removed.
> 14209 index pages have been deleted, 14209 are currently reusable.
> CPU 2.46s/6.06u se
Hi Tom,
I did run vacuum verbose".
INFO: vacuuming "public.userclick"
INFO: index "userclick_i01" now contains 13715747 row versions in 60640
pages
DETAIL: 0 index row versions were removed.
14209 index pages have been deleted, 14209 are currently reusable.
CPU 2.46s/6.06u sec elapsed 186.
Hello Tom,
thanks for your fast answer. And yes it is reproducible. It started
during my vacation (of course!!!) and I get the message ever since
(approx. 6 weeks, vacuum daily).
We use
Fedora Linux Core 2
PostgreSQL 7.4.2
I'll try to get the information you asked for over the weekend.
Ulr
Ulrich Wisser <[EMAIL PROTECTED]> writes:
> vacuumdb: vacuuming of database "CLIX2" failed: ERROR: left link
> changed unexpectedly
Hm, is this repeatable? When I wrote the code I thought it was
a can't-happen case, which is why the error message is so terse
(it was only pure paranoia that made
Kragen Sitaker <[EMAIL PROTECTED]> writes:
> On Mon, Jan 12, 2004 at 06:20:23PM -0500, Tom Lane wrote:
>> No; an OID collision would have occurred when you tried to create a
>> table. If two tables are present in pg_class then they have different
>> OIDs, and shouldn't have any conflicts in pg_sta
16 matches
Mail list logo
