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 ---
[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
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,
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
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
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 wouldn't
[ 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
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,
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 the
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. Your
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
***
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 expectations
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 going
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. Your
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
[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
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,
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.
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, despite not
[ 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
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 and
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
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 stable
23 matches
Mail list logo
