On Mon, Nov 06, 2000 at 08:59:38AM -0400, The Hermit Hacker wrote:
what version of CVS are you running? when was the last time you did
anything with it?
It works again. I have no idea what failed.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian
The Hermit Hacker writes:
ftp://ftp.postgresql.org/pub/source/v7.0.3
Please take a minute to download and test these out, so that when
we release, we don't get a bunch of "oops, you forgot this"
messages :)
I've tried it on a couple of platforms:
IRIX 6.5.5m, MIPSpro 7.3.
I have updated horology-no-DST-before-1970.out, but that still leaves
us needing updates for horology-1947-PDT.out and
That one is mine (AIX), I'll do it.
Andreas
This somehow gets moot. Is there a way to make gcc reject those comments ?
Andreas
*** ./src/backend/utils/adt/varbit.c.orig Wed Nov 1 10:00:22 2000
--- ./src/backend/utils/adt/varbit.cTue Nov 7 11:07:28 2000
***
*** 1212,1218
Hi
While examining recursive use of catalog cache,I found
a refcnt leak of relations.
After further investigation,I found that the following seems
to be the cause.
[ in EndAppend() in nodeAppend.c ]
appendstate-as_result_relation_info_list = NIL;
/*
* This next step is critical to prevent
Applied.
[ Charset ISO-8859-1 unsupported, converting... ]
This somehow gets moot. Is there a way to make gcc reject those comments ?
Andreas
*** ./src/backend/utils/adt/varbit.c.orig Wed Nov 1 10:00:22 2000
--- ./src/backend/utils/adt/varbit.c Tue Nov 7 11:07:28 2000
Kevin O'Gorman pointed out to me that this example fails in current
sources:
select a from foo union all (select b from foo except select a from foo);
The problem is that the result of the EXCEPT has a resjunk column (which
is added by the EXCEPT code so that it can tell lefthand input rows
I am working on eliminating the "relation NNN modified while in use"
misfeature by instead grabbing a lock on each relation at first use
in a statement, and holding that lock till end of transaction. The
main trick here is to make sure that the first lock grabbed is adequate
--- for example, it
-Original Message-
From: Tom Lane [mailto:[EMAIL PROTECTED]]
Hiroshi Inoue [EMAIL PROTECTED] writes:
While examining recursive use of catalog cache,I found
a refcnt leak of relations.
After further investigation,I found that the following seems
to be the cause.
[ in
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
I am working on eliminating the "relation NNN modified
while in use"
misfeature by instead grabbing a lock on each relation at first use
in a statement, and holding that lock till end of transaction.
As anticipated, I object :-)
For a "select colname from tablename" we do not currently hold any lock
until end of tx. This is the situation you described, and I am worried about.
That's a bug in itself, because the executor's read lock is grabbed by
heap_beginscan and released by heap_endscan, which means it may
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
but, there is eighter an optimizer bug or a code bug in nabstime.c
leading to regression failure in abstime, tinterval and horology.
The rest all passes.
Does anybody see similar behavior ?
IIRC, the same regression tests fail on Linux/Alpha
Will we still have readers-dont-block-writers behaviour?
Sure. The only thing this really affects is VACUUM and
schema-altering
commands, which will now have to wait until reader
transactions commit.
In other words
Session 1 Session 2
BEGIN;
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
BTW, what about indices?
CREATE/DROP INDEX grab exclusive lock on the parent table, so there's no
problem with indexes as long as transactions that use the parent table
hold some kind of lock on that table. I figure it's OK for the executor
to
OK, it's me again with news on how I'm doing (bad) with the compilation of
PostgreSQL 7.1 alpha (I think I'll call that way the cvsup download).
I still can't finish the execution of the configure script (still don't know
why), and I could compile 7.0.2 perfectly on the same SPARC.
What could
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Unfortunately, session 3 with just SELECT * FROM foo will also wait
for session 1 session 2 commit.
Session 3 would wait for session 2 in any case, no?
This is all irrelevant unless someone can make a convincing case that
it's safe to release read
Unfortunately, session 3 with just SELECT * FROM foo will also wait
for session 1 session 2 commit.
Session 3 would wait for session 2 in any case, no?
But now it will wait longer - for the duration of session 1' transaction.
This is all irrelevant unless someone can make a convincing
The Hermit Hacker [EMAIL PROTECTED] writes:
If its that easy to fix the regress test so that it passes, can we get it
committed and build a new tarball so that ppl doing regression on v7.0.3
see a clean regress?
The way I want to fix it will probably require getting new geometry
files for all
"Hiroshi Inoue" [EMAIL PROTECTED] writes:
I am working on eliminating the "relation NNN modified while in use"
misfeature by instead grabbing a lock on each relation at first use
in a statement, and holding that lock till end of transaction.
Isn't "relation NNN modified while in use" itself
I've committed patches to do the following:
o Support AT TIME ZONE date/time syntax.
o Fix INTERVAL mixed-sign output representation. "ISO format" has
changed a little, and no longer uses the "AGO" qualifier but instead
uses signed numbers.
o Allow functions called with untyped constant
I've committed changes to parse_oper.c to enable fallback to string type
when argument(s) are of UNKNOWN type. This is the same code (verbatim)
as I recently added for function resolution.
An obvious example is for
select '1' = '01';
which used to throw an error and which now resolves to two
Hmm, I started this reply planning on arguing that _keeping_ the 'ago'
was easiest on my ears. Now I find I've talked myself into losing it,
because it implies too much: 'ago' claims that that one end of the
interval is 'now' and the other end is in the past. If what you've got
is actually
Due to problems with some parts of the world not being able to access the
http://www.retep.org.uk/ site for the JDBC driver archives (ie: the past
precompiled drivers, the current pre-beta driver etc), I'm currently moving
that site to a new ISP.
Because of this, there may be a brief break in
Tom Lane wrote:
"Mikheev, Vadim" [EMAIL PROTECTED] writes:
Required frequency of *successful* vacuum over *all* tables.
We would have to remember something in pg_class/pg_database
and somehow force vacuum over "too-long-unvacuumed-tables"
*automatically*.
I don't think this is a
Tom Lane wrote:
We've hacked up pg_dump so that it won't dump objects inherited from
template1. Unfortunately I have realized there are a couple of serious
problems:
1. What if the inherited object is a table or a sequence? Its state may
no longer be the same as it was in template1 (eg, a
If its that easy to fix the regress test so that it passes, can we get it
committed and build a new tarball so that ppl doing regression on v7.0.3
see a clean regress?
On Tue, 7 Nov 2000, Tom Lane wrote:
Pete Forman [EMAIL PROTECTED] writes:
The only remaining failure is geometry. The
Pete Forman writes:
The only remaining failure is geometry. The results I got were
nearly identical to geometry-powerpc-aix4.out. The only
differences were the order of rows returned by three of the tables.
I'll submit the results file to pgsql-patches.
I've submitted a one line patch
Pete Forman [EMAIL PROTECTED] writes:
The only remaining failure is geometry. The results I got
were nearly
identical to geometry-powerpc-aix4.out. The only
differences were the
order of rows returned by three of the tables. I'll submit the
results file to pgsql-patches.
How do you run the regression tests ?
gmake all
gmake install
initdb
start postmaster
cd src/test/regress
gmake runtest
?
The build looks ok, but remember, that all shared libs and postmaster will only
work in the configured location. (gmake runcheck will fail, since it installs into a
My guess is that your patches are in current, but not in this
subrelease. We only put in show-stopper fixes.
The Hermit Hacker writes:
ftp://ftp.postgresql.org/pub/source/v7.0.3
Please take a minute to download and test these out, so that when
we release, we don't get a
Zeugswetter Andreas SB writes:
AIX 4.3.2, xlc 3.6.6.
Same regression test failures as 7.0.2.
The nasty failures are triggers, misc, and plgpgsql which
consistently give "pqReadData() -- backend closed the channel
unexpectedly." at the same point. Also the
I was unable to get runcheck to pass even when I altered all the
LD_LIBRARY_PATH entries in run_check.sh to LIBPATH for the benefit of
AIX. If this cannot be fixed there ought to be an entry added to the
faq-aix.
The fix for AIX below 4.3 would be to relink both postmaster and the libs
with
Pete Forman [EMAIL PROTECTED] writes:
The only remaining failure is geometry. The results I got were nearly
identical to geometry-powerpc-aix4.out. The only differences were the
order of rows returned by three of the tables. I'll submit the
results file to pgsql-patches.
Rather than
On Lun 06 Nov 2000 18:25, Peter Eisentraut wrote:
Martin A. Marques writes:
Is there any kind of info you would need that I could provide? If you
want I can send the config.log, output of the configure execution, etc.
Even the socket.h and the types.h.
BTW, I didn't find diffs between
34 matches
Mail list logo
