Re: [HACKERS] Fwd: Apple Darwin disabled fsync?

Peter Bierman <[EMAIL PROTECTED]> writes: >> I believe that what the above comment refers to is the fact that >> fsync() is not sufficient to guarantee that your data is on stable >> storage and on MacOS X we provide a fcntl(), called F_FULLFSYNC, >> to ask the drive to flush all buffered data to s

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

Mark Kirkwood <[EMAIL PROTECTED]> writes: > To be fair to Mark, there does seem to be an increasing number of > reports of this issue. In spite of the in-the-works fix for 8.1, it > would be a pity to see customers losing data from xid wrap-around. The question is whether we are willing to back-

Re: [HACKERS] Get rid of system attributes in pg_attribute?

Robert Treat <[EMAIL PROTECTED]> writes: > If I am understanding this correctly, they could only be displayed if > selected > explicitly right? That's always been true. The behavior at the level of SQL commands wouldn't change. The question is whether any apps out there examine pg_attribute an

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

> [ Shrugs ] and looks at other database systems ... > > CA has put Ingres into Open Source last year. > > Very reliable system with a replicator worth looking at. > > Just a thought. The discussion on hackers is how to make PostgreSQL better. There are many different perspectives, differences are

Re: [HACKERS] Get rid of system attributes in pg_attribute?

On Saturday 19 February 2005 12:17, Tom Lane wrote: > Andreas Pflug <[EMAIL PROTECTED]> writes: > >>> Does anyone know of client code that actually pays attention to > >>> pg_attribute rows with negative attnums? > > > > Would those columns remain selectable for debugging/maintenance > > purposes,

[HACKERS] Fwd: Apple Darwin disabled fsync?

Date: Sat, 19 Feb 2005 17:59:21 -0800 From: Dominic Giampaolo <[EMAIL PROTECTED]> Subject: Re: bad fsync? (A.M.) To: [EMAIL PROTECTED] MySQL makes the following claim at: http://dev.mysql.com/doc/mysql/en/news-4-1-9.html "InnoDB: Use the fcntl() file flush method on Mac OS X versions 10.3 and up. A

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

Andrew Dunstan wrote: There is no news in the problem you're complaining of. It's completely known and documented. You've stated before that you've been using PostgreSQL for years - why is this suddenly so urgent that we have to drop everything and backpatch old releases? Please move along, ther

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

[EMAIL PROTECTED] wrote: PostgreSQL is such an awesome project. The only thing it seems to suffer from is a disregard for its users. Mark, This is completely untrue and very offensive. Here's a tip I've often found useful even though I have also often ignored it (and later regretted doing so)

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

> On Sat, Feb 19, 2005 at 13:35:25 -0500, > [EMAIL PROTECTED] wrote: >> >> The catastrophic failure of the database because a maintenence function >> is >> not performed is a problem with the software, not with the people using >> it. > > There doesn't seem to be disagreement that something shoul

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

> On Fri, 18 Feb 2005 22:35:31 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: >> [EMAIL PROTECTED] writes: >> > I think there should be a 100% no data loss fail safe. >> >> Possibly we need to recalibrate our expectations here. The current >> situation is that PostgreSQL will not lose data if: >> >>

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

On Sat, Feb 19, 2005 at 13:35:25 -0500, [EMAIL PROTECTED] wrote: > > The catastrophic failure of the database because a maintenence function is > not performed is a problem with the software, not with the people using > it. There doesn't seem to be disagreement that something should be done goi

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

In <[EMAIL PROTECTED]>, on 02/19/05 at 02:23 PM, Jaime Casanova <[EMAIL PROTECTED]> said: >On Fri, 18 Feb 2005 22:35:31 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: > >[EMAIL PROTECTED] writes: >> > I think there should be a 100% no data loss fail safe. >> >> Possibly we need to recalibrate our

Re: [HACKERS] postgres crashing on a seemingly good query

Abhijit Menon-Sen <[EMAIL PROTECTED]> writes: > Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be > a valid query. Good catch. I've applied the attached patch (this is against 8.0/CVS tip but applies with some fuzz to 7.4). regards, tom lane *** src

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

On Fri, 18 Feb 2005 22:35:31 -0500, Tom Lane <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] writes: > > I think there should be a 100% no data loss fail safe. > > Possibly we need to recalibrate our expectations here. The current > situation is that PostgreSQL will not lose data if: > >1

Re: [HACKERS] postgres crashing on a seemingly good query

At 2005-02-19 23:18:01 +0530, [EMAIL PROTECTED] wrote: > > If I change my code (by means of an unspeakably vile hack, but never > mind that) to specify each parameter types in the parse message, the > server no longer crashes. In fact, it works if I specify only the two integer types, and leave th

Re: [HACKERS] postgres crashing on a seemingly good query

At 2005-02-19 21:38:56 +0530, [EMAIL PROTECTED] wrote: > > I couldn't reproduce this with SQL PREPARE/EXECUTE statements in psql, > so I conjectured that it may have something to do with the parameter > types being unspecified. I added a statement-describe message between > the parse and the bind,

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

[ Shrugs ] and looks at other database systems ... CA has put Ingres into Open Source last year. Very reliable system with a replicator worth looking at. Just a thought. Ursprüngliche Nachricht Betreff: Re: [HACKERS] Data loss, vacuum, transaction wrap-around Datum: Sat, 19 Feb 2

Re: [HACKERS] Get rid of system attributes in pg_attribute?

Andreas Pflug <[EMAIL PROTECTED]> writes: >>> Does anyone know of client code that actually pays attention to >>> pg_attribute rows with negative attnums? > Would those columns remain selectable for debugging/maintenance > purposes, despite not appearing in system catalogs? Certainly. They just

Re: [HACKERS] Get rid of system attributes in pg_attribute?

Dave Page wrote: Does anyone know of client code that actually pays attention to pg_attribute rows with negative attnums? pgAdmin certainly knows about them, but I don't believe it'll break if they go. It only knows that attnum < 0 must be a system column; no specific knowledge or interpretation o

Re: [HACKERS] postgres crashing on a seemingly good query

At 2005-02-19 21:38:56 +0530, [EMAIL PROTECTED] wrote: > > Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be > a valid query. A couple of things I forgot to mention: 1. I turned the logging all the way up and I've uploaded the messages from the crashing backend to

[HACKERS] postgres crashing on a seemingly good query

Summary: I can crash 7.4-CVS and 8.0/HEAD by sending what appears to be a valid query. I'm trying to insert a unique entry into this table: create table bodyparts ( id serial primary key, bytes integer not null, lines integer not null, has

Re: [HACKERS] Data loss, vacuum, transaction wrap-around

> [EMAIL PROTECTED] writes: >> I think there should be a 100% no data loss fail safe. OK, maybe I was overly broad in my statement, but I assumed a context that I guess you missed. Don't you think that in normal operations, i.e. with no hardware of OS failure, we should see any data loss as unacce

Re: [HACKERS] SPI_finish and RegisterExprContextCallback

Tom Lane wrote: The comment for AtCommit_Portals points out that there are risks of this sort, but I don't think you've described it properly. The SPI_cursor_close operation is probably failing not succeeding, because AtCommit_Portals will never find an already-deleted portal --- hash_seq_search()