Re: [BUGS] could not read block 77 of relation 1663/16385/388818775
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 pages were hit, would it be possible to log a stack backtrace? Especially on our test systems we can easily afford any performance degradations resulting from this. Question: Who is responsible for maintaining this part (buffer cache maintenance, writer etc) of postgres code? Could you provide the necessary patches? Thanks in advance Thomas Goerner Marc Schablewski John R Pierce wrote: > 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 >>> writes >>> into the shared buffer area as a memory protection fault. >>> >> >> The problem with both of these approaches is that most bugs occur >> when the >> code *thinks* it's doing the right thing. A bug in the buffer >> management code >> which returns the wrong buffer or a real wild pointer dereference. I >> don't >> remember ever having either of those. >> >> That said, the second option seems pretty trivial to implement. I >> think the >> performance would be awful for a live database but for a read-only >> database it >> might make more sense. >> > > > FWIW, it has modest overhead on Oracle on Solaris on Sparc... EXCEPT > on the "Niagra" aka 'Coolthreads' CPUs (the T1 processor), on that it > was horribly slow on our write intensive transactional system.Our > environment is on very large scale servers where the shared buffers > are often 32 or 64GB, I suspect this increases our exposure to > bizarro-world writes. > > believe me, especially in earlier Oracle releases (6, 7, 8), this > caught/prevented many problems which otherwise would have ended in a > Oracle fatal Block Corruption error, which would require many hours of > DBA hackery before the database could be restarted. > > > -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] executing SELECT xmlelement(name foo); causes "server closed the connection unexpectedly" Error
Here is an update. the 8.3 version is now working after i reinstalled the OS. most probably the issue was due to corrupt libxml2. Thank you so much for all the help to get rid off the issue. Regards, Sushil Tom Lane wrote: > Peter Eisentraut <[EMAIL PROTECTED]> writes: > >> Sushil wrote: >> >>> *postgres: postgres testdb [local] SELECT: symbol lookup error: >>> postgres: postgres testdb [local] SELECT: undefined symbol: >>> xmlNewTextWriterMemory* >>> > > >> Your problem appears to be here. Check you libxml installation. Maybe >> someone forgot to export this symbol. >> > > I think it most likely is a corrupted download. Red Hat's normal > release process includes checks for ABI breakage such as disappearing > symbols, so it's hard to believe there's really a problem of that ilk. > > The annoying thing about this from a Postgres standpoint is that the > missing symbol results in a runtime crash; a failure at server startup > would be a lot better IMHO. Ideally, shared libraries would be > processed with the equivalent of dlopen(RTLD_NOW). But as far as I > can find we can't easily force that on Linux --- the only available > way to determine it is to set a magic environment variable that the > linker consults. > > I could fix this in the RPM distribution by putting export LD_BIND_NOW=1 > into the postmaster start script, but I wonder whether there's a better > way. > > regards, tom lane > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy the original message all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Please do not print this email unless it is absolutely necessary.begin:vcard fn:Sushil Dive n:;Sushilchandra Dive org:Vertex Software Pvt Ltd;Delivery adr:;;;Pune;MH;;IN email;internet:[EMAIL PROTECTED] tel;work:+91 20 6604 1500 Ex. 554 x-mozilla-html:TRUE version:2.1 end:vcard -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] could not read block 77 of relation 1663/16385/388818775
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 the contents of one block are copied over or swapped with another block. The checksum would be calculated when a page is written to disk, so the corruption could still be caused by faulty memory, memory bus, CPU or OS, while the page sits in the buffer cache. If an access violation resulting from writes to locked pages were hit, would it be possible to log a stack backtrace? I think you'd get a segmentation fault. With a core dump if the system is configured so. Question: Who is responsible for maintaining this part (buffer cache maintenance, writer etc) of postgres code? There's no named individuals, just the community in general. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
