* 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
>
"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 gua
> >> 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'
"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 postm
> 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
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
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 foun
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
> th
> > 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
I think this was fixed today.
>
> > Any ideas on why this error would occur after dropping an existing
> > database and than re-creating it (createdb)? The only work around so far
> > is to completely destroy the postgres instance and start over.
> >
> > It appears that the pg_database may b
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
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
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 queryin
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^HCompa
On Mon, Jan 08, 2001 at 10:15:30PM -0500, Bruce Momjian wrote:
> > 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
> 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,
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
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 http://www.le
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.
--
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.
>
> We
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 q
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
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
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: T
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 nee
> 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
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
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
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, exce
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
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);
>
>
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 and NetBSD in
> > > which is a mess, all rigth. Problem is that
> > > postgres.h does not know about th
Philip Warner writes:
> At 09:36 8/01/01 +, Pete Forman wrote:
> >There are no compiler errors, just run time errors if you rely on
> >the return from sprintf() being the number of characters.
>
> All I need to know is how to detect an error. Does it return EOF on
> error?
The standard
At 09:36 8/01/01 +, Pete Forman wrote:
>There are no compiler errors, just run time
>errors if you rely on the return from sprintf() being the number of
>characters.
All I need to know is how to detect an error. Does it return EOF on error?
--
Marko Kreen writes:
> On Mon, Jan 08, 2001 at 04:06:09AM +0200, Marko Kreen wrote:
> > On Sun, Jan 07, 2001 at 08:09:07PM -0500, Tom Lane wrote:
> > > Marko Kreen <[EMAIL PROTECTED]> writes:
> > > > Which basically changes u_int*_t -> uint*_t, so now it does
> > > > not compile neither under
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 coun
> 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
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 effective
38 matches
Mail list logo
