Alex Derbes <[EMAIL PROTECTED]> writes:
> deleting the indexes from the table did not help. Is there a tool or
> method that that I could use to simply skip the bad data and at least
> recover the good blocks?
Just zero out the broken page, eg with dd from /dev/zero. Note it
might be a good id
for the annals of postgres maintenance I got my DB running by using DD to
copy the blocks before the corrupt block, then add block from /dev/zero,
then add the remaining blocks from the file. I discovered the block size
by looking at he output of pg_filedump. To find the offending file select
re
Tom,
> One question that comes to mind is were you reindexing a system or user
> table?
User.
> Another is whether you were using disks that lie about write
> completion (SCSI vs IDE)?
First thing I thought of. Haven't been able to verify, yet.
The basic symptoms are:
1) Machine stated sche
Josh Berkus <[EMAIL PROTECTED]> writes:
> The basic symptoms are:
> 1) Machine stated scheduled REINDEX.
> 2) Unexpected power-out
> 3) On reboot, we have 2 different versions of the index file on disk,
> one with 0 bytes. Attempts to use the index (via SELECT) result in
> statement-fatal errors
Tom,
> That's a definite possibility. Before 7.4 we did not emit WAL records
> for data written during index build. What we could have here is that
> the transaction completed and synced to WAL, but none of the data-file
> writes were sent to disk before power-out. On restart, WAL replay would
Josh Berkus <[EMAIL PROTECTED]> writes:
> Would this be back-patchable by a good PG hacker? The client has $$$.
It'd be more productive for them to update to 7.4 ...
regards, tom lane
---(end of broadcast)---
TIP 7: don't
Tom,
> It'd be more productive for them to update to 7.4 ...
It's a distributed app, meaning that they have boxes in the field which can
not be practically updated by remote.
They'll be using 7.4 for *new* boxes, sometime around November. Their
requirements include 6 months of testing before
Hello,
I downloaded an install the 'PeerDirect PostgreSQL beta for Windows'.
I followed all instructions ' started the server and I verified that port
5432 is listening.
Also : 'pg_ctl ststus' = running.
However when I try to createdb , I get stucked and do nothing.
What is the problem?
Tom Lane wrote:
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
/* this statement will reverse the order of CURRVAL()/NEXTVAL() to match the
column order of the table */
INSERT INTO testing (col_b, col_a) VALUES (NEXTVAL('seq'), CURRVAL('seq'));
This is not a bug. The order of evalua
Tom Lane wrote:
How about
SELECT nextval('seq'); -- ignore result
INSERT INTO ... VALUES (currval('seq'), currval('seq'));
Well, it works for my sample case, I have to agree. Maybe I should
mention that I tried to boil down the bugreport to the simplest repro
case I could.
My actual
Dear Sir,
I would like to tell you that the SQL about "Create Domain" is still
cannot involve constraints other than NULL | NOT NULL in Postgresql 7.4.1.
For instances, when I type the following sentences, it shows error
message:
Create Domain GenderDomain CHAR(1) Constraint g Check Value in
Tom Lane wrote:
"PostgreSQL Bugs List" <[EMAIL PROTECTED]> writes:
Description:Order by doesn't sort correctly.
It almost certainly is the correct sort order according to the locale
you're using. Use pg_controldata to check the database locale. You'll
probably want to re-initdb in C lo
Dear Tom,
Thank you for your explanation. It's very helpful, although I was
extremely surprised! I agree, it's not a postgresql bug.
Can I suggest it might be worth a mention on the "Order By" part of the
documentation.
i.e. this page:
http://www.postgresql.org/docs/7.3/static/sql-select.html#
name: Damon Hart
email: [EMAIL PROTECTED]
System Configuration
-
Architecture :
Intel PIII dual 800MHz, 1.5 GB RAM
Operating System :
Linux xs1.xd 2.4.22-1.2115.nptlsmp #1 SMP Wed Oct 29 15:30:09 EST 2003
i686 i686 i386 GNU/Linux
(Fedora Core 1)
PostgreSQL versi
On Tue, 24 Feb 2004, Gary WAN wrote:
> Dear Sir,
> I would like to tell you that the SQL about "Create Domain" is still
> cannot involve constraints other than NULL | NOT NULL in Postgresql 7.4.1.
>
> For instances, when I type the following sentences, it shows error
> message:
>
> Create Do
"Gary WAN" <[EMAIL PROTECTED]> writes:
> Create Domain GenderDomain CHAR(1) Constraint g Check Value in ('M','F');
You need parentheses around the check expression. AFAICS this is per
spec.
regards, tom lane
---(end of broadcast)
Damon Hart <[EMAIL PROTECTED]> writes:
> I had to remove the attached schema.sql file as the list manager refused
> the complete submission for overall message size (112KB). I tried to
> reduce the size of the data, but ran into trouble reproducing the error.
You can send me the test case off-l
Hi,
I have a postgres data base that is probably about 2gigs in size
spread across a couple of tables. The orders table is about 500megs in
size and is mostly writes.
When running "select count(1) from orders" on the database this
evening, the DB responded with "ERROR: Inval
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
19 matches
Mail list logo
