Gregory Stark wrote:
> Darren Reed writes:
>
>
>> ERROR: could not read block 1 of relation 1664/0/1233: read only 0 of
>> 8192 bytes
>>
>
> FWIW this is pg_shdepend_reference_index which is actually a bit special. It's
> a "shared" relation which means it spans all your databases. Your
Darren Reed writes:
> For me it has been very reproducible:
If you can put together a self-contained test case that would let
someone else reproduce it, we'd be very interested to take a look.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.
Darren Reed writes:
> ERROR: could not read block 1 of relation 1664/0/1233: read only 0 of
> 8192 bytes
FWIW this is pg_shdepend_reference_index which is actually a bit special. It's
a "shared" relation which means it spans all your databases. Your reindex
didn't rebuild to. To reindex it yo
As another data point, I upgraded from 8.2.6 to 8.3.6
and I saw those corruption messages after restoring
pg_dump files back into the database with psql and
inserting a bunch of data (some duplicate records
got rejected.) The insertion of new data is via
perl's DBI interface.
This was after the u
Marc Schablewski wrote:
If pages with bogus data but correct checksum are
ever found on disk, I think this would prove that there is no hardware /
file system / os issue.
No, it would only suggest that the issue is not in the filesystem or I/O
subsystem. Even then, it wouldn't catch bugs where
I think both approaches (checksum and write protection) might contribute
to finding this bug. If pages with bogus data but correct checksum are
ever found on disk, I think this would prove that there is no hardware /
file system / os issue.
If an access violation resulting from writes to locked pa
Gregory Stark wrote:
John R Pierce <[EMAIL PROTECTED]> writes:
oracle has had an option for some time that uses read/only page protection for
each page of the shared buffer area... when oracle knows it wants to modify a
page, it un-protects it via a system call. this catches any wild w
John R Pierce <[EMAIL PROTECTED]> writes:
> Alexandra Nitzschke wrote:
>> BTW... how about a block checksum that is checked just before writing a block
>> and just after reading it? I know this would degrade performance, but I think
>> we can afford that. Would it be possible to incorporate such
Alexandra Nitzschke wrote:
BTW... how about a block checksum that is checked just before writing
a block and just after reading it? I know this would degrade
performance, but I think we can afford that. Would it be possible to
incorporate such code without having to do too much patching?
ora
Hi,
first of all I would like to thank you for all your efforts.
> We really need a test case.
unfortunately this kind of bugs tend to be non-reproducable. I assume that there is a race condition which is only hit
in rare cases, under heavy load and when mars and venus are exactly aligned... ;
Yes, of course.
After we started up the copied database, the system runs withour error for two
days.
That means some recordsets has been inserted sucessfully already.
Gregory Stark schrieb:
Alexandra Nitzschke <[EMAIL PROTECTED]> writes:
This monday I updated postgres to 8.3.5 on the standb
Alexandra Nitzschke <[EMAIL PROTECTED]> writes:
> This monday I updated postgres to 8.3.5 on the standby server.
> After that I intialized the database
> ( copy once the database from the primary system: removing data/* on stand-by,
> setting the database on primary in backup-modus and then copy t
Alexandra Nitzschke <[EMAIL PROTECTED]> writes:
> Yes, its a btree.
Well, the btree code is sufficiently well tested/debugged that I think
there's zero chance of finding such a bug in it just on the suspicion
that there might be one there. We really need a test case.
rega
Yes, its a btree.
Tom Lane schrieb:
Alexandra Nitzschke <[EMAIL PROTECTED]> writes:
We have had a look at the /var/log files, no system crash, kernel panic or
messages like this has happened.
What this smells like is a failed page split --- somewhere in the index
there is a down-link pointi
Alexandra Nitzschke <[EMAIL PROTECTED]> writes:
> We have had a look at the /var/log files, no system crash, kernel panic or
> messages like this has happened.
What this smells like is a failed page split --- somewhere in the index
there is a down-link pointing at page 77, but page 77 didn't actu
Hi,
here is some information about the server
- no other database system runs on the server
- suse 10.3, standard installation
- jvm 1.5.0_16
- as interface to the database we use jdbc version 8.1-407
- as procdural language we only use pl/pgsql
- we have no specials in the database like custom
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Craig Ringer wrote:
>> Is there any chance you have EVER hard-killed the postmaster manually
>> (eg with "kill -9" or "kill -KILL")?
> There is safeguards against that. If postmaster dies, the backends
> should die quickly and gracefully too. And p
Craig Ringer wrote:
Is there any chance you have EVER hard-killed the postmaster manually
(eg with "kill -9" or "kill -KILL")? If you do that and don't also kill
the backends, it's my understanding that BAD things may happen
especially if you then attempt to relaunch the postmaster.
There is sa
Alexandra Nitzschke wrote:
> Hi,
>
> we have had similar postgres problems in the past.
> Please have a look at Bug 3484.
>
> We didn't resolve the problems metioned in bug 3484. The other postgres
> developers also thought, that there are hardware
> problems.
> So our customer bought a new serve
Hi,
we have had similar postgres problems in the past.
Please have a look at Bug 3484.
We didn't resolve the problems metioned in bug 3484. The other postgres
developers also thought, that there are hardware
problems.
So our customer bought a new server with diffrent hardware configuration ( ..
Alexandra Nitzschke wrote:
> Hi,
>
> we encountered the following error while inserting a record into a table:
>
> org.postgresql.util.PSQLException: ERROR: could not read block 77 of
> relation 1663/16385/388818775: read only 0 of 8192 bytes
>
> Using postgres 8.3.5
>
> The reported object is
Alexandra Nitzschke wrote:
Hi,
we encountered the following error while inserting a record into a table:
org.postgresql.util.PSQLException: ERROR: could not read block 77 of
relation 1663/16385/388818775: read only 0 of 8192 bytes
This is probably a problem with your disk or filesystem. Have
Hi,
we encountered the following error while inserting a record into a table:
org.postgresql.util.PSQLException: ERROR: could not read block 77 of relation 1663/16385/388818775: read only 0 of 8192
bytes
Using postgres 8.3.5
The reported object is an index.
The size of its data file is 63078
23 matches
Mail list logo
