As it turns out, it was prepared transactions at fault. I restored my test
bed, forced a rollback and the locks were gone. At least now I can connect
those dots. :-)
On Fri, Feb 22, 2013 at 1:15 AM, Albe Laurenz wrote:
> Ned Wolpert wrote:
> > I'm doing a postmortem on a corruption event we ha
Ned Wolpert wrote:
> I'm doing a postmortem on a corruption event we had. I have an idea on what
> happened, but not sure.
> I figure I'd share what happened and see if I'm close to right here.
>
> Event: Running 9.1.6 with hot-standby, archiving 4 months of wal files, and
> even a nightly p
Folks-
I'm doing a postmortem on a corruption event we had. I have an idea on
what happened, but not sure. I figure I'd share what happened and see if
I'm close to right here.
Event: Running 9.1.6 with hot-standby, archiving 4 months of wal files,
and even a nightly pg_dump all. 50G database.
Due to Hard disk space issue on the WAL partition, database was down , When I
am going to start postgres again ,got following error message
This DB is grater than 1 TB restore will take long time , any other way
other than pg_resetxlog ?
Nov 14 04:32:41 dbname postgres[4384]: [2-1] 2011-11-14
Postgres version 8.4.4
Hardware:
12 cpu intel
sda 15K 600GB raid 1
sdb ssd 173GB raid 1 (most tables and indexes on sdb)
adaptec controller
24G of memory
shared buffers 12GB
Machine age 3 months
Normal load 2-4
200-300 Transactions per second
We had a database failure last night after one of
On Sun, Feb 22, 2009 at 1:53 PM, wrote:
> Greetings,
>
>
>
> I had a hardware problem this morning, which I believe is now resolved, but
> I seem to have a little database corruption issue. This is what I am seeing
> when I restart postgres:
>
> PANIC: right sibling's left-link doesn't match
>
ken.col...@sage.com writes:
> I had a hardware problem this morning, which I believe is now resolved, but
> I seem to have a little database corruption issue. This is what I am seeing
> when I restart postgres:
> PANIC: right sibling's left-link doesn't match
8.2.6 and later provide a little more
Greetings,
I had a hardware problem this morning, which I believe is now resolved, but
I seem to have a little database corruption issue. This is what I am seeing
when I restart postgres:
PANIC: right sibling's left-link doesn't match
So I attempted to reindex the database and now I ge
I'm running ubuntu and can see references to only one log file which i'm
assuming is the postmaster log..
Anyway the only relevant bits are:
GMT LOG: relation "pg_class" TID 15538/4: dead HOT-updated tuple ---
cannot shrink relation
2009-02-12 21:06:40 GMT STATEMENT: VACUUM FULL VERBOSE ANA
John Lister writes:
> I seem to have more dead rows now..
> doing a vacuum full on pg_class gives me
> INFO: vacuuming "pg_catalog.pg_class"INFO: "pg_class": found 37
> removable, 1845 nonremovable row versions in 18905 pages
> DETAIL: 27 dead row versions cannot be removed yet.
> Nonremovabl
I seem to have more dead rows now..
doing a vacuum full on pg_class gives me
INFO: vacuuming "pg_catalog.pg_class"INFO: "pg_class": found 37
removable, 1845 nonremovable row versions in 18905 pages
DETAIL: 27 dead row versions cannot be removed yet.
Nonremovable row versions range from 160
Sorry, had exported it - bad cut/pasting...
I even tried it in single-user mode passing -P directly but got the same
result
Also confused/concerned by the 7 dead rows in pg_class. as i've
restarted the server all transaction should have finished so i'd like to
reclaim these - especially as vacu
John Lister writes:
> still getting the same problem.
>>> PGOPTIONS="-P"
>>> psql backend
I think you need export PGOPTIONS="-P" to make that work. Whether
it's related to your problem isn't clear though.
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-a
>Yeah, if you have reason not to trust the system indexes then -P is
>a good idea until they are fixed. Standalone mode per se isn't that
>important --- you could do this from a regular session with -P specified
>via PGOPTIONS.
still getting the same problem.
> PGOPTIONS="-P"
> psql backend
>>
John Lister writes:
> Although saying that..
> reindex now works, but doing a vacuum verbose complains that the index
> is out of step with the table and i should reindex..
> would i be better shutting the db down, restarting in standalone mode
> (and also using the -P option) before reindexing
Cheers tom, that did it - i've removed the duplicates and seeing what else
is broken.
.
"John Lister" writes:
ERROR: could not create unique index "pg_class_oid_index"
a quick inspection of the pg_class table doesn't show any duplicates, is
there anyway i can find out which row(s) are d
"John Lister" writes:
> ERROR: could not create unique index "pg_class_oid_index"
> a quick inspection of the pg_class table doesn't show any duplicates, is
> there anyway i can find out which row(s) are duplicated and remove them
> without a full db restore?
> also doing something like this
Hi, my wal archiving broke and postgresql filled up the local disk with
transaction logs, which i foolishly deleted in a moment of madness, after
resetting the transaction log a few of my tables are damaged but repairable.
However the system tables also seemed to have suffered. My main problem i
Hello to all, it's my first mail in this group ...
I have a problem with a database 8.0.4 (installed on a Windows XP),
yesterday during startup my windows-xp generate an error message and
postgresql service don't start more.
I try to start service manually but nothing, appare a message that sa
On Sun, Apr 24, 2005 at 03:43:20PM +0600, Alan Donald wrote:
>
> I have a few databases running on a postgres database server.
>
> Everything was working fine and then yesterday when I logged in, there
> were a few databases that are missing. These tables cannot be seen in
> the pg_database table
I have a few databases running on a postgres database server.
Everything was working fine and then yesterday when I logged in, there
were a few databases that are missing. These tables cannot be seen in
the pg_database table. Also I cannot see these tables via pg_admin and
understandable so.
Ple
> In your previous emails, you stated that these errors were seen on
> multiple systems. Multiple systems, configured identically, with
> diverse motherboards/hardware or always identical hardware except for
> the sata/IDE drives?
>
> I ask, because I noted that you are using the Neo 2 ATX mot
Thanks for the tip. Later kernel versions have unrelated problems for
us, but we'll take a look at the filesystem mods and see if we can
backpatch them.
--Ian
> I remember a problem that was fixed in the 2.6.9 kernel concerning XFS
> corruption (shutdowns I think were the worst). Also i
,snipped.
> - SuSE 9.1
> - 2.6.6 kernel
> - Postgres 7.4.2
> - 300 TPS against DB containing 5-50GB data, no more than a dozen
> concurrent connections.
> - fsync (or not) and fdatasync
I remember a problem that was fixed in the 2.6.9 kernel concerning XFS
corruption (shutdowns I think were the
Hi Chris,
> I think it is important to figure out why this is happening. I would
> not want to run any production databases on systems that were failing
> like this.
You and me both :) (in our application though, it is not a total
disaster to lose the last 5 minutes of transactions, it is a
Hi Ian;
I think it is important to figure out why this is happening. I would
not want to run any production databases on systems that were failing
like this.
I am trying to figure out what are the likely causes of the errors...
1) Any other computers suffer random application crashes, power do
For several weeks now we have been experiencing fairly
severe database corruption upon clean reboot. It is very
repeatable, and the corruption is of the following forms:
ERROR: could not access status of transaction foo
DETAIL: could not open file "bar": No such file or directory
ERROR: inval
27 matches
Mail list logo
