I barely understand the items sometimes.
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can this now be marked as done?
> * Modification of pg_class can happen while table in use by another
> backend. Might lead to MVCC inside
No? :-)
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can this now be marked as done?
> * Modification of pg_class can happen while table in use by another
> backend. Might lead to MVCC inside of syscache
> >>
> >> I'm no
> > On Tue, 9 Jan 2001, Bruce Momjian wrote:
> >
> > > I think the issue here was that these functions don't make any sense for
> > > PHP because you can't register C functions.
> >
> > I mean (I know) that you can register some common (internal) PHP
> > function and this function can call your
"Robert B. Easter" <[EMAIL PROTECTED]> writes:
> This quote from the SQL standard (1999) has it:
Oh, I didn't realize SQL99 had added it. Creeping featurism strikes
again ;-). Well, I suppose it'll get added to PG whenever someone
feels like implementing it, then ...
re
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Bruce Momjian <[EMAIL PROTECTED]> writes:
Can this now be marked as done?
* Modification of pg_class can happen while table in use by another
backend. Might lead to MVCC inside of syscache
>>
>> I'm not sure. Do you have any
On Tue, Jan 09, 2001 at 05:05:34PM +, Thomas Lockhart wrote:
> > What I do not understand is, that I thought a time in december cannot be
> > affected by such math because it is clearly not in the daylight savings
> > months of the year ? Also I thought that you recognize daylight savings
> >
>
> I don't really see this as important enough to justify introducing a
> nonstandard syntax for it...
>
> regards, tom lane
Sorry to quote like this, it makes me feel like a real nerd. :)
This quote from the SQL standard (1999) has it:
8.3
Function
"Robert B. Easter" <[EMAIL PROTECTED]> writes:
> subselects=# SELECT 2 BETWEEN 3 AND 1;
> ?column?
> --
> f
> (1 row)
SQL92 quoth:
6) "X BETWEEN Y AND Z" is equivalent to "X>=Y AND X<=Z".
so this is correct behavior, even if it might seem surprising.
> Any chance of BETWEEN
Anyone read the [NOT] SIMILAR TO syntax for regular expressions? Looks like
it might be close to an SQL standard synonym for [!]~. I don't know if it
can match the case insensitive ops though.
--
Robert B. Easter [EMAIL PROTECTED] -
-- CompTechNews Message Board http://www.
Michael J Schout wrote:
> We would definately beta test 7.1 beta releases on our test machines if RPMS
> were made available. However, if rpms are not made available, its unlikely
> that anyone around here will get time to build the sources from scratch. So
> you can count me as one beta tester
Here is current cvs:
SELECT 2 BETWEEN 1 AND 3;
?column?
--
t
(1 row)
subselects=# SELECT 2 BETWEEN 3 AND 1;
?column?
--
f
(1 row)
Any chance of BETWEEN [SYMMETRIC | ASYMMETRIC] being implemented?
SELECT 2 BETWEEN SYMMETRIC 3 AND 1;
?column?
--
t
(1 row)
ASYMM
On Fri, 5 Jan 2001, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > I am inclined to wait until a Release Candidate, if we have one this go
> > around, is available before releasing RPM's, but my mind can be
> > changed :-)
>
> Please do make beta RPMs available. Seems to me
> Yup. I had just come to the realization that we'd be best
> off to treat the *entire* period from SpinAcquire to SpinRelease
> as a critical section for the purposes of die(). That is, response
> to SIGTERM will be held off until we have released the spinlock.
> Most of the places where we gra
[EMAIL PROTECTED] (Nathan Myers) writes:
> If a backend dies while holding a lock, doesn't that imply that
> the shared memory may be in an inconsistent state?
Yup. I had just come to the realization that we'd be best off to treat
the *entire* period from SpinAcquire to SpinRelease as a critical
On Wed, Jan 10, 2001 at 12:46:50AM +0600, Denis Perchine wrote:
> > > Didn't you get my mail with a piece of Linux kernel code? I think all is
> > > clear there.
> >
> > That was implementing CPU-time-exceeded kill, which is a different
> > issue.
>
> Opps.. You are talking about OOM killer.
>
>
On Tue, 9 Jan 2001, Bruce Momjian wrote:
> >
> > On Tue, 9 Jan 2001, Bruce Momjian wrote:
> >
> > > I think the issue here was that these functions don't make any sense for
> > > PHP because you can't register C functions.
> >
> > I mean (I know) that you can register some common (internal) P
>
> On Tue, 9 Jan 2001, Bruce Momjian wrote:
>
> > I think the issue here was that these functions don't make any sense for
> > PHP because you can't register C functions.
>
> I mean (I know) that you can register some common (internal) PHP
> function and this function can call your PHP functi
On Tue, 9 Jan 2001, Bruce Momjian wrote:
> I think the issue here was that these functions don't make any sense for
> PHP because you can't register C functions.
I mean (I know) that you can register some common (internal) PHP
function and this function can call your PHP function. It is some u
I think the issue here was that these functions don't make any sense for
PHP because you can't register C functions.
>
> On Tue, 9 Jan 2001, Martin A. Marques wrote:
>
> > I'm working with PHP and Postgres, and if I try to do an EXPLAIN query, with
> > PHP, to the postgres backend the output
El Mar 09 Ene 2001 16:30, Karel Zak escribió:
> On Tue, 9 Jan 2001, Martin A. Marques wrote:
> > I'm working with PHP and Postgres, and if I try to do an EXPLAIN query,
> > with PHP, to the postgres backend the output goes to the error_log file
> > of apache and I don't know how to redirect that o
On Tue, 9 Jan 2001, Martin A. Marques wrote:
> I'm working with PHP and Postgres, and if I try to do an EXPLAIN query, with
> PHP, to the postgres backend the output goes to the error_log file of apache
> and I don't know how to redirect that output to the browser.
Good point, before some t
Denis Perchine <[EMAIL PROTECTED]> writes:
> You will get SIGKILL in most cases.
Well, a SIGKILL will cause the postmaster to shut down and restart the
other backends, so we should be safe if that happens. (Annoyed as heck,
maybe, but safe.)
Anyway, this is looking more and more like the SIGTER
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>> Yeah, I suppose. We already do record locking of all the fixed
>> spinlocks (BufMgrLock etc), it's just the per-buffer spinlocks that
>> are missing from that (and CRIT_SECTION calls). Would it be
>> reasonable to assume that only one buffer spinlo
I'm working with PHP and Postgres, and if I try to do an EXPLAIN query, with
PHP, to the postgres backend the output goes to the error_log file of apache
and I don't know how to redirect that output to the browser.
Does anyone know how I can do this?
Saludos... ;-)
--
System Administration: I
> > START_/END_CRIT_SECTION is mostly CritSectionCount++/--.
> > Recording could be made as
> > LockedSpinLocks[LockedSpinCounter++] = &spinlock
> > in pre-allocated array.
>
> Yeah, I suppose. We already do record locking of all the fixed
> spinlocks (BufMgrLock etc), it's just the per-buffer
> > Didn't you get my mail with a piece of Linux kernel code? I think all is
> > clear there.
>
> That was implementing CPU-time-exceeded kill, which is a different
> issue.
Opps.. You are talking about OOM killer.
/* This process has hardware access, be more careful. */
if (cap_t(p->cap_effecti
Denis Perchine <[EMAIL PROTECTED]> writes:
> Didn't you get my mail with a piece of Linux kernel code? I think all is
> clear there.
That was implementing CPU-time-exceeded kill, which is a different
issue.
regards, tom lane
"Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
> START_/END_CRIT_SECTION is mostly CritSectionCount++/--.
> Recording could be made as LockedSpinLocks[LockedSpinCounter++] = &spinlock
> in pre-allocated array.
Yeah, I suppose. We already do record locking of all the fixed
spinlocks (BufMgrLock etc
> > The relevance to the issue at hand is that processes dying during
> > heavy memory load is a documented feature of our supported platforms.
>
> Ugh. Do you know anything about *how* they get killed --- ie, with
> what signal?
Didn't you get my mail with a piece of Linux kernel code? I think
> > 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
> without an unreasonable amount of overhead. The case at hand was a
> stuck spinlock because die() --> elog(FATAL) had neglected t
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Can this now be marked as done?
> > * Modification of pg_class can happen while table in use by another
> > backend. Might lead to MVCC inside of syscache
>
> I'm not sure. Do you have any record of what the concern was, in
> detail? I
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Can this now be marked as done?
> * Modification of pg_class can happen while table in use by another
> backend. Might lead to MVCC inside of syscache
I'm not sure. Do you have any record of what the concern was, in
detail? I don't underst
[EMAIL PROTECTED] (Nathan Myers) writes:
> The relevance to the issue at hand is that processes dying during
> heavy memory load is a documented feature of our supported platforms.
Ugh. Do you know anything about *how* they get killed --- ie, with
what signal?
regards,
> What I do not understand is, that I thought a time in december cannot be
> affected by such math because it is clearly not in the daylight savings
> months of the year ? Also I thought that you recognize daylight savings time
> by the PDT instead of PST, and PostgreSQL shows a result with PST as
> > On AIX timestamp and horology regression fails in current, because
> > timestamp - interval for result timestamps that are before
> 1970 (epoch ?)
> > are off by one hour. I think this is not an issue for an
> adapted expected file,
> > but a new (in 7.1beta) bug. But I am at no means an ex
> 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
Applied. Thanks.
[ Charset ISO-8859-1 unsupported, converting... ]
>
> The KAME files md5.* and sha1.* have the following changelog
> entry:
>
>
> revision 1.2
> date: 2000/12/04 01:20:38; author: tgl; state: Exp; lines:
> +18 -18
> Eliminate some of the more bl
On Tue, 9 Jan 2001, The Hermit Hacker wrote:
> On Tue, 9 Jan 2001, Kaare Rasmussen wrote:
>
> > I wonder why http://www.postgresql.org is not updated with news. The
> > latest "Latest News" is from Nov 16. I have to go to
> > http://www.pgsql.com to find some interesting news later than that:
> >
> On AIX timestamp and horology regression fails in current, because
> timestamp - interval for result timestamps that are before 1970 (epoch ?)
> are off by one hour. I think this is not an issue for an adapted expected file,
> but a new (in 7.1beta) bug. But I am at no means an expert at what th
> There are two versions of sprintf() available in SunOS 4 - 8. The
> standard one (ANSI C) in libc returns an int, the number of characters
> written (excluding '\0'). The BSD version returns a char* which
> points to the target. If you have a -lbsd on your link line then you
> get the BSD ver
Applied. Thanks.
> "Mikheev, Vadim" <[EMAIL PROTECTED]> writes:
>
> > > Does the SPI interface support recursion? That is, can a function
> > > use SPI to make a query which involves calling another function which
> > > uses SPI?
> >
> > >From http://www.postgresql.org/docs/programmer/spi.htm
Can this now be marked as done?
* Modification of pg_class can happen while table in use by another
backend. Might lead to MVCC inside of syscache
> I just finished running the parallel regress tests with inval.c rigged
> to flush the relcache and syscache at every available opportun
Added to TODO:
* Add SQL standard function bit_length()
> It seems we do not have the standard SQL function "bit_length()"?
> --
> Tatsuo Ishii
>
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life
On AIX timestamp and horology regression fails in current, because
timestamp - interval for result timestamps that are before 1970 (epoch ?)
are off by one hour. I think this is not an issue for an adapted expected file,
but a new (in 7.1beta) bug. But I am at no means an expert at what the re
> > Well, it's not good idea because of SIGTERM is used for ABORT + EXIT
> > (pg_ctl -m fast stop), but shouldn't ABORT clean up everything?
>
> Er, shouldn't ABORT leave the system in the exact state that it's
> in so that one can get a crashdump/traceback on a wedged process
> without it trying
45 matches
Mail list logo
