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 (
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
Tom Lane wrote:
> "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 "relati
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 ema
Tom Lane wrote:
>
> Philip Warner <[EMAIL PROTECTED]> writes:
> >> * disk space --- letting pg_log grow without bound isn't a pleasant
> >> prospect either.
>
> > Maybe this can be achieved by wrapping XID for the log file only.
>
> How's that going to improve matters? pg_log is ground truth f
> 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 actual
> I'm seeing a whole bunch of miscompares in the horology test today.
> Is this stuff supposed to have changed behavior?
Yup. RTFCVSL :)
It is a result of fixing the date/time math across daylight savings time
boundaries. You will find that there is no longer an artifical one hour
offset in resu
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
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 strings
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> There's probably little reason to start a backend standalone. If you want
> to do stock-of-the-trade debugging you simply start a postmaster, then
> psql (or whatever floats your boat), and attach gdb to the resulting
> backend process.
Right, that'
"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
> -Original Message-
> From: Tom Lane
> Sent: Wednesday, November 08, 2000 1:26 AM
> To: [EMAIL PROTECTED]
> Subject: [HACKERS] Issue NOTICE for attempt to raise lock level?
>
>
> I am working on eliminating the "relation NNN modified while in use"
> misfeature by instead grabbing a lock
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
> > 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 conv
"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 re
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
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 be
I said:
> CREATE/DROP INDEX grab exclusive lock on the parent table,
Correction: DROP INDEX grabs exclusive lock, CREATE only grabs a
ShareLock on the parent. But that's OK since addition of an index
doesn't hurt existing readers.
regards, tom lane
"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 conti
> > 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
>
>
I've just started fooling with some modifications to the backend.
I'm new at doing this in PG, so I'm blundering I'm sure.
In any event when I start the backend standalone (i.e. running
the 'postgres -D ' command, it seems I have to be the root
or postgres root user because of file permission
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I do not believe it is safe to drop read locks intra-transaction, and
>> I am unwilling to take a chance on it being safe so close to 7.1 beta.
> Will we still have readers-dont-block-writers behaviour?
Sure. The only thing this rea
Tom Lane wrote:
> I am not nearly as worried about long-running transactions that delay
> admin actions as I am about admin actions that crash other transactions.
> I do not believe it is safe to drop read locks intra-transaction, and
> I am unwilling to take a chance on it being safe so close to
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/Al
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 ? It is a little sad, because the
optimized code really runs a lot faster and those are somehow
obsolete d
Tom Lane writes:
> To help debug this, I'm planning to add a little bit of code to the
> lock manager that detects a request for a lock on an object on which
> we already hold a lock of a lower level. What I'm wondering about is
> whether to make the report be elog(DEBUG) --- ie, send to postmas
> > In the second place, we already grab locks that we do not release till
> > end of xact for all user-level queries. The problem is that we grab
>
> Even for select?
No. Tom plans to change that, and I still think this is a bad idea.
> > them too late
> > 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
> 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 o
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> Ok, but I thought there was some optimization for readonly statements.
Doesn't have anything to do with locking, only with avoiding disk
writes.
>> In the second place, we already grab locks that we do not release till
>> end of xact for all u
> >> 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 :-)
>
> Your objection is founded on two misund
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 :-)
You
> -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.
>
> A NOTICE might be useful to users since it would complain about
> deadlock-prone user-level coding practices too, such as
>
> begin;
> select * from foo; -- grabs read lock
> lock table foo; -- grabs exclusive lock
Although this is deadlock prone praxis, there i
> 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 :-)
If you do this you will most likely add the code to the wro
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 w
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> This somehow gets moot. Is there a way to make gcc reject those comments ?
It looks like -ansi would cause gcc to reject // comments, but -ansi has
enough not-so-desirable side effects that I would vote against making
that switch part of our st
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> This looks like a different plan is chosen now. I don't beleive this can be
> platform dependent.
Well, the plan choice *could* be platform-dependent, given that the
planner uses comparisons of floating-point cost estimates. But I agree
that'
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 from
> 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-patch
On Tue, 7 Nov 2000, Tom Lane wrote:
> 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 EndAppend() in nodeAppend.c
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 EndAppend() in nodeAppend.c ]
appendstate-> as_result_relation_info_list = NIL
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
> 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
w
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 pat
Zeugswetter Andreas SB writes:
> 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 con
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
>
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
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
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
d
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 th
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 En
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
is_match
> 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
> 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 sanity_check hangs
> during a VACUUM. Killing t
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
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 GNU/Linu
57 matches
Mail list logo
