Tatsuo Ishii [EMAIL PROTECTED] writes:
You are right. However, SQL92 spec allows:
select * from t1 where i all values(0,1);
No, I still disagree. The ANY/ALL constructs compare a single row on
the left side with all the rows produced by the query on the right.
"values(0,1)" is effectively
No, I still disagree. The ANY/ALL constructs compare a single row on
the left side with all the rows produced by the query on the right.
"values(0,1)" is effectively the same as "SELECT 0,1", ie, it is a
query that happens to produce just one row. The above is illegal in
SQL92 because the
Nathan Myers writes:
On Fri, Jan 05, 2001 at 11:20:43AM -0500, Tom Lane wrote:
Philip Warner [EMAIL PROTECTED] writes:
how do I
check for a failed write in a way that works on all Unixes? Is the
following OK:
- fwrite: ok if return value equals item count
- fprintf:
On Mon, Jan 08, 2001 at 10:03:25AM +, Pete Forman wrote:
Marko Kreen writes:
On Mon, Jan 08, 2001 at 04:06:09AM +0200, Marko Kreen wrote:
Well, actually they do. glibc in stdint.h and NetBSD in
sys/inttypes.h which is a mess, all rigth. Problem is that
postgres.h does not
How are we on this?
On Sun, 7 Jan 2001, Tom Lane wrote:
heap_update() currently ends with
if (newbuf != buffer)
{
LockBuffer(newbuf, BUFFER_LOCK_UNLOCK);
WriteBuffer(newbuf);
}
LockBuffer(buffer, BUFFER_LOCK_UNLOCK);
WriteBuffer(buffer);
/*
The Hermit Hacker [EMAIL PROTECTED] writes:
How are we on this?
It's fixed.
I've also run the regress tests with bufmgr.c hacked up to discard
pages (with forcible overwriting) as soon as their refcount goes to
zero. That didn't disclose any similar bugs, although the coverage
of the tests
Pete Forman [EMAIL PROTECTED] writes:
Philip Warner writes:
All I need to know is how to detect an error. Does it return EOF on
error?
The standard sprintf() returns a negative int on error.
I thought we were talking about fprintf. sprintf can't really detect
any errors anyway, except
Denis Perchine [EMAIL PROTECTED] writes:
On Monday 08 January 2001 00:08, Tom Lane wrote:
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
No... Just clean log (I redirect log from stderr/out t file, and all
other to syslog).
The
okay, will bundle up beta2 and announce it tonight when I get home ...
gives about 6 hrs or so to "halt the presses" *grin*
On Mon, 8 Jan 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
How are we on this?
It's fixed.
I've also run the regress tests with bufmgr.c
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
No... Just clean log (I redirect log from stderr/out t file, and all
other to syslog).
The error messages would be in the syslog then, not in stderr.
Hmmm... The only strange
On Sat, Jan 06, 2001 at 03:50:03AM +0100, Peter Eisentraut wrote:
Ross J. Reedstrom writes:
Do you really need the thing to be a bootstrap table, and not a plain
system table?
Yup, 'cause it's going to store the schema info, including the system
schema. I forsee it needing to be
Denis Perchine [EMAIL PROTECTED] writes:
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
Actually you can have a look on the logs yourself.
Well, I found a smoking gun:
Jan 7 04:27:51 mx postgres[2501]: FATAL 1: The system is
Tom Lane wrote:
The way that heap_update() and heap_delete() are currently coded, they
hold the buffer context lock on the buffer containing the old tuple
while they invoke heap_tuple_toast_attrs(). This strikes me as at least
inefficient and at worst a source of deadlock. Is it possible to
Tom Lane wrote:
backend/commands/command.c has a routine is_view() that tests for
view-ness by scanning pg_rewrite (all of it) to see if the given
relation has any ON SELECT rules.
This is only used to disallow AlterTableAddConstraint and
LockTableCommand on views. While I don't care much
One last followup on that bizarreness about shutdown's checkpoint
failing on Alpha platforms ---
After changing the checkpoint code to loop, rather than assuming TAS()
must succeed the first time, I noticed that it always looped exactly
once. This didn't make sense to me at the time, but after
On Mon, Jan 08, 2001 at 12:21:38PM -0500, Tom Lane wrote:
Denis Perchine [EMAIL PROTECTED] writes:
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
Actually you can have a look on the logs yourself.
Well, I found a smoking gun:
Has anyone tried 7.1Beta on Tru64?
I've got an app that will be moving to this platform, and would like
to not have any surprises (It's the first production app with PG in
the dallas office, and would like to not make trouble).
Thanks!
LER
--
Larry Rosenman
I think doc/REAME.mb is now deprecated and I would like to remove it.
Also I would like to place the Chinese (Big5) version of README.mb
recently posted by Chih-Chang Hsieh [EMAIL PROTECTED] as
doc/README.mb.big5.
Comments? Objections?
--
Tatsuo Ishii
Compaq has released an open-source database benchmark at:
http://opensource.compaq.com/sourceforge/project/?group_id=19
I must say, Compaq has been more involved with PostgreSQL than any of
the other computer vendors. They have contributed equipment, and now
benchmark source code.
--
One last followup on that bizarreness about shutdown's checkpoint
failing on Alpha platforms ---
After changing the checkpoint code to loop, rather than assuming TAS()
must succeed the first time, I noticed that it always looped exactly
once. This didn't make sense to me at the time, but
Bruce Momjian [EMAIL PROTECTED] writes:
After changing the checkpoint code to loop, rather than assuming TAS()
must succeed the first time, I noticed that it always looped exactly
once. This didn't make sense to me at the time, but after querying some
Alpha experts at DEC^H^H^HCompaq, it
Oh, thanks. That makes sense.
Bruce Momjian [EMAIL PROTECTED] writes:
After changing the checkpoint code to loop, rather than assuming TAS()
must succeed the first time, I noticed that it always looped exactly
once. This didn't make sense to me at the time, but after querying some
Tatsuo Ishii [EMAIL PROTECTED] writes:
I think doc/REAME.mb is now deprecated and I would like to remove it.
Also I would like to place the Chinese (Big5) version of README.mb
recently posted by Chih-Chang Hsieh [EMAIL PROTECTED] as
doc/README.mb.big5.
Go for it. I was surprised you hadn't
Larry Rosenman [EMAIL PROTECTED] writes:
Has anyone tried 7.1Beta on Tru64?
beta1 will not work, but recent snapshots are reported to pass
regression tests. Feel free to pound away on it ...
regards, tom lane
Well, I found a smoking gun: ...
What seems to have happened is that 2501 curled up and died, leaving
one or more buffer spinlocks locked. ...
There is something pretty fishy about this. You aren't by any chance
running the postmaster under a ulimit setting that might cut off
Denis Perchine [EMAIL PROTECTED] writes:
It's worth noting here that modern Unixes run around killing user-level
processes more or less at random when free swap space (and sometimes
just RAM) runs low.
That's not the case for sure. There are 512Mb on the machine, and when I had
this
On Monday 08 January 2001 23:21, Tom Lane wrote:
Denis Perchine [EMAIL PROTECTED] writes:
FATAL: s_lock(401f7435) at bufmgr.c:2350, stuck spinlock. Aborting.
Were there any errors before that?
Actually you can have a look on the logs yourself.
Well, I found a smoking gun:
Jan 7
Denis Perchine [EMAIL PROTECTED] writes:
Hmmm... actually this is real problem with vacuum lazy. Sometimes it
just do something for enormous amount of time (I have mailed a sample
database to Vadim, but did not get any response yet). It is possible,
that it was me, who killed the backend.
Killing an individual backend with SIGTERM is bad luck. The backend
will assume that it's being killed by the postmaster, and will exit
without a whole lot of concern for cleaning up shared memory --- the
What code will be returned to postmaster in this case?
Vadim
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Killing an individual backend with SIGTERM is bad luck. The backend
will assume that it's being killed by the postmaster, and will exit
without a whole lot of concern for cleaning up shared memory --- the
What code will be returned to postmaster in
Killing an individual backend with SIGTERM is bad luck.
The backend will assume that it's being killed by the postmaster,
and will exit without a whole lot of concern for cleaning up shared
memory --- the
SIGTERM -- die() -- elog(FATAL)
Is it true that elog(FATAL) doesn't clean up
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Killing an individual backend with SIGTERM is bad luck.
SIGTERM -- die() -- elog(FATAL)
Is it true that elog(FATAL) doesn't clean up shmem etc?
This would be very bad...
It tries, but I don't think it's possible to make a complete guarantee
* Mikheev, Vadim [EMAIL PROTECTED] [010108 23:08] wrote:
Killing an individual backend with SIGTERM is bad luck.
The backend will assume that it's being killed by the postmaster,
and will exit without a whole lot of concern for cleaning up shared
memory --- the
SIGTERM -- die()
33 matches
Mail list logo
