Philip Warner <[EMAIL PROTECTED]> writes:
> Yes - it's waiting on the problem Zoltan reported (the select from
> pg_rewrite etc). I can't reproduce the problem on any of my DBs.
I've just realized that the problem is a lot simpler than it appears.
The given string is too long for a NAME:
regress
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> I gather that the following code goes though the heap and removes all check
> contraints associated with a particular table, but how do I extend the code
> to match both a table relid and the constraint name?
Add another ScanKey. Look at us
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> Possible solutions: (a) rename tables in one test or the other,
> or (b) use TEMPORARY tables in one test or the other. I kinda
> like (b), just to exercise temp tables in some interesting new
> ways. Whaddya think?
> I have a preference for (a). If
On Thu, May 10, 2001 at 03:26:07PM -0400, Mark Hollomon wrote:
> On Wednesday 09 May 2001 19:02, Joel Burton wrote:
> >
> > One of the small problems of pl/python is going to similar to pl/perl...
> > many linux distro's don't come with a shared object library for python,
> > but come w/a static
At 22:43 10/05/01 -0400, Tom Lane wrote:
>(Philip, we are just talking about a few days, right?)
Yes - it's waiting on the problem Zoltan reported (the select from
pg_rewrite etc). I can't reproduce the problem on any of my DBs.
If worst comes to worst, I have a (nasty) workaround, but I'm more
The Hermit Hacker <[EMAIL PROTECTED]> writes:
> Isn't this only critical for those that are using it? Does it affect
> those that don't use plpgsql?
No, but I think it's pretty critical for those that do ...
regards, tom lane
---(end of broadcast
On Thu, 10 May 2001, Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> > I agree with you because the bug is very critical.
>
> Yes, I'd like to get that plpgsql bug fix out as soon as possible.
Isn't this only critical for those that are using it? Does it affect
those that don't us
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was doing serial.
Try the parallels a few times, and you *will* see it fail.
Reason: Stephan added a bunch of tests to alter_table.sql that
create/modify/delete tables named pktable and fktable.
Unfortunately, foreign_key.sql uses those same names f
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> I agree with you because the bug is very critical.
Yes, I'd like to get that plpgsql bug fix out as soon as possible.
But the pg_dump things that Philip is fixing are important too,
so I think we should wait a couple more days for those.
(Philip, we ar
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I was doing serial.
And ... ?
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Hmm ... Bruce, were you doing serial or parallel regress tests?
I'm finding that the serial tests work and the parallels blow up.
It might be that this is because of my anti-lseek hacking, but
I kinda doubt it because the failures occur right about where
bpalmer saw trouble with last night's CVS .
Bruce Momjian <[EMAIL PROTECTED]> writes:
> That is fine. I am not crazy about doing it now either. It is just
> that Tom mentioned early in the week we need a release, and you said how
> about Friday. I will brand 7.1.2 so it is ready whenever we want it.
I think I said Friday, not Marc ... a
Mike Mascari <[EMAIL PROTECTED]> writes:
> If your idea works, would it be possible, or even a good idea, to
> have PostgreSQL extend the relation in a non-linear fashion?
The trick would be to ensure that the extra blocks actually got used
for something ... without more logic than is there now,
Tom Lane <[EMAIL PROTECTED]> escreveu:
> [snip]
> Next question: do you still have your 7.0.* DB up? Can you get an
> EXPLAIN that shows how it did it (on the real tables)?
Setting it up right now... unfortunately I will have to do a recompile /
reinstall as I have rm -r'ed the old versions. So
On Thu, 10 May 2001, Bruce Momjian wrote:
> Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
> as 7.1.2.
Not that I'm aware of ... I heard mention something about a couple of
fixes, but we *just* put out 7.1.1 ...
If ppl are affected by the bugs, use cvsup and set yoru tag
At 20:47 10/05/01 -0400, Bruce Momjian wrote:
>Are we releasing tomorrow. I will stamp the CVS STABLE branch tonight
>as 7.1.2.
>
I have not applied the latest pg_dump patches, and I'm still working on a
problem with the view extract.
---
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Here is a small list of big TODO items. I was wondering which ones
> people were thinking about for 7.2?
Peter E. had implied that he wanted to tackle the elog issues for 7.2,
but I'm not sure if he's committed to it or not.
I am wanting to see SQL sc
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I will bump it now. I didn't see anything either, but initdb fixed my
> regression test errors.
That was probably a waste of effort. I just finished pulling down and
recompiling CVS tip. I see no regression failures, either using a data
directory lef
> Here is a small list of big TODO items. I was wondering which ones
> people were thinking about for 7.2?
The need for stored procedures that return a record set.
This is required to migrate from MSSQL, Interbase and others.
This is a commonly requested item.
Nested Transactions. This allow
Jon Lapham <[EMAIL PROTECTED]> writes:
>> Uh, have you VACUUM ANALYZEd yet? Those EXPLAIN numbers look
>> suspiciously like default statistics ...
> Nope, forgot to on the little demonstration tables I made. I tacked the
> post-VACUUM ANALYZE explain results (they look much better) at the end
On Thu, May 10, 2001 at 05:56:11PM -0400, Tom Lane wrote:
> Jon Lapham <[EMAIL PROTECTED]> writes:
> > Yesterday I upgraded my database from Pg v7.1RC1 to v7.1.1. Since this
> > upgrade, I have been having unbelievable performance problems with updates
> > to a particular table, and I've tracked
Jon Lapham <[EMAIL PROTECTED]> writes:
> Yesterday I upgraded my database from Pg v7.1RC1 to v7.1.1. Since this
> upgrade, I have been having unbelievable performance problems with updates
> to a particular table, and I've tracked the problem down to a rule within
> that table.
Uh, have you VACU
Philip Warner <[EMAIL PROTECTED]> writes:
> Can anyone suggest why this might be happening (I think it's in 7.1b4):
Can't duplicate in current sources:
regression=# SELECT definition as viewdef,
regression-# (select oid from pg_rewrite where
regression(#rulename='_RETstreet') as view_oid
r
> + /* I use CMD_UPDATE, because no CMD_MOVE or the like
> +exists, and I would like to provide the same
> +kind of info as CMD_UPDATE */
> + UpdateCommandInfo(CMD_UPDATE, 0, -1*estate->es_processed);
I do not
Hello all-
Yesterday I upgraded my database from Pg v7.1RC1 to v7.1.1. Since this
upgrade, I have been having unbelievable performance problems with updates
to a particular table, and I've tracked the problem down to a rule within
that table.
I've enclosed a simple case study at the end of this
Bruce Momjian <[EMAIL PROTECTED]> writes:
> OK, do an initdb and watch the errors disapper. :-)
Did someone forget to bump catversion.h?
I didn't notice any recent commits that sounded like they'd need to
force an initdb, but maybe I missed something.
regards, tom lane
Kovacs Zoltan <[EMAIL PROTECTED]> writes:
> On Fri, 11 May 2001, Philip Warner wrote:
>> Can anyone suggest why this might be happening (I think it's in 7.1b4):
>>
>> SELECT definition as viewdef,
>> (select oid from pg_rewrite where
>> rulename='_RETszallitolevel_tetele_ervenyes') as view_oid
> If we do that then we still have a problem with overrunning memory
> after a sufficiently large number of tuples. However, that'd improve
> the constant factor by at least an order of magnitude, so it might be
> worth doing as an intermediate step. Still have to figure out whether
> the trigge
We've known for a long time that Postgres does a lot of
redundant-seeming "lseek(fd,0,SEEK_END)" kernel calls while inserting
data; one for each inserted tuple, in fact. This is coming from
RelationGetBufferForTuple() in src/backend/access/heap/hio.c, which does
RelationGetNumberOfBlocks() to ens
My nightly regression tests for OBSD failed for i386 and sparc. Attached
is the regression.diff, I don't know what to make of it.. Looks like
problems w/ foreign keys.
...
parallel group (5 tests): portals_p2 rules select_views alter_table
foreign_key
select_views ... ok
alt
On Thu, May 10, 2001 at 03:33:27PM +0200, Klaus Reger wrote:
> Hi all!
>
> I have to convert functions and procedures from Oracle to PostgreSQL. I
> looked at all the stuff of the Pg-Homepage and I ask me if there are any
> tools, that support the conversion.
That help you in the conv
On Thu, 10 May 2001, Bruce Momjian wrote:
> > On Thu, 10 May 2001, Gilles DAROLD wrote:
> >
> > > Hi,
> > >
> > > Another point regarding /contrib or other directory like /tools is to
> > > centralize tools for Pg. Also I can't be sure to always have an URL.
> > > This one is dependant on the com
On Fri, 11 May 2001, Philip Warner wrote:
> Can anyone suggest why this might be happening (I think it's in 7.1b4):
>
> SELECT definition as viewdef,
> (select oid from pg_rewrite where
> rulename='_RETszallitolevel_tetele_ervenyes') as view_oid
> from pg_views wh
Can anyone suggest why this might be happening (I think it's in 7.1b4):
SELECT definition as viewdef,
(select oid from pg_rewrite where
rulename='_RETszallitolevel_tetele_ervenyes') as view_oid
from pg_views where viewname = 'szallitolevel_tetele_ervenyes';
=> v
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Has the patch that makes MOVE return number of rows actually moved
>> (analoguous to UPDATE and DELETE) been properly submitted to patches ?
> I know MOVE had fixes in 7.1. I don't know of any outstanding MOVE
> bugs.
It wasn't a bug, it was a featur
Michael Meskes <[EMAIL PROTECTED]> writes:
> I just updated my testsystem from 7.0.3 to 7.1 and tried to insert my
> production data just to notice that one function uses textpos(). 7.1 does
> not know about that function.
Neither does 7.0.3. I see "position" and "strpos" in pg_proc in both
vers
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> Perhaps instead
>> of storing each and every trigger-related tuple in memory, we only need
>> to store one value per affected table: the lowest CTID of any tuple
>> that we need to revisit for deferred-trigger purposes. At the end of
>> the t
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> I'm not sure that tm_isdst == -1 is a legitimate indicator for mktime()
> failure on all platforms; it indicates "don't know", but afaik there is
> no defined behavior for the rest of the fields in that case. Can we be
> assured that for all platforms
Hi all!
I have to convert functions and procedures from Oracle to PostgreSQL. I
looked at all the stuff of the Pg-Homepage and I ask me if there are any
tools, that support the conversion.
Writing PS/PGSQL tools seems to be a bit hard, because of the existing
tool-infrastructure on linux. Ar
I just updated my testsystem from 7.0.3 to 7.1 and tried to insert my
production data just to notice that one function uses textpos(). 7.1 does
not know about that function.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---
> Perhaps instead
> of storing each and every trigger-related tuple in memory, we only need
> to store one value per affected table: the lowest CTID of any tuple
> that we need to revisit for deferred-trigger purposes. At the end of
> the transaction, scan forward from that point to the end of th
41 matches
Mail list logo
