> I have also mentioned this on two occasions now, and each has met with
> total silence. I have come to interpret this to mean either (a) the idea is
> too stupid to rate a comment, or (b) go ahead with the proposal. Since I am
> not really proposing anything, I assume the correct interpretation
> Results: 5000 transactions took ~60 sec in 7.1, ~550 sec in
> 7.0.2 with fsync and ~60 sec without fsync.
>
> So, seems that WAL added not just complexity to system -:)
Wow, this sounds fantastic :-)
I see my concerns where not justified.
Andreas
Yes it does look like it's the insert that's at fault. I've tested it on a
current backend here and it has the same problem.
Peter
--
Peter Mount
Enterprise Support Officer, Maidstone Borough Council
Email: [EMAIL PROTECTED]
WWW: http://www.maidstone.gov.uk
All views expressed within this email
Hi,
I'm defining a new aggregate using a C transition function. It is of
type TEXT, so the C function gets pointers (*text) to the internal-state1 and
next-data-item parameters.
Question is if the returning value of type *text must be palloc'ed or
can be just taken from the input parameters. I
Maurizio wrote:
> But, how can I do ?
> I have to recall the same routine many times. I tried to prepare and declare
> the cursor inside the routine but when I compile with ecpg I receive the
> error Cursor already defined.
you should drop the cursor (exec sql close name;)
But there is trouble a
> PS: You might consider applying the patch for (update where > not_found) -> 100
No, this is not allowed. sqlcode is supposed to be 0 in above case.
You need to explicitly check for the number of rows updated in your
program if needed.
Andreas
Zeugswetter Andreas SB wrote:
> > PS: You might consider applying the patch for (update where > not_found) -> 100
>
> No, this is not allowed. sqlcode is supposed to be 0 in above case.
> You need to explicitly check for the number of rows updated in your
> program if needed.
>
> Andreas
Accordi
Dirk Lutzebaeck <[EMAIL PROTECTED]> writes:
> I'm defining a new aggregate using a C transition function. It is of
> type TEXT, so the C function gets pointers (*text) to the internal-state1 and
> next-data-item parameters.
> Question is if the returning value of type *text must be palloc'ed or
Tom Lane writes:
> Dirk Lutzebaeck <[EMAIL PROTECTED]> writes:
> > I'm defining a new aggregate using a C transition function. It is of
> > type TEXT, so the C function gets pointers (*text) to the internal-state1 and
> > next-data-item parameters.
>
> > Question is if the returning value
Did someone think about query costs ? Is you prepare
query like SELECT id FROM t1 WHERE type=$1 and
execute it with $1=1 and 2. For 1 there is one record
in t1 a all other have type=2.
Without caching, first query will use index, second
not.
Should cached plan use index or not ?
devik
Christof Pe
> > 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 with 7.0.2, even
> at -O0. I had a
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
> The macro AbsoluteTimeIsReal does not work somehow.
Hm. That expands to
(((int) time) < ((int) 0x7FFC) && \
((int) time) > ((int) 0x8001))
On a machine where int is 32 bits, the second constant *ought* to be
treated
Philip pointed out awhile back that it does not work to load a 7.0.*
dump into current sources if the dumped database contains any
procedural language definitions. The dumped handler-function
definitions will look like
CREATE FUNCTION "plpgsql_call_handler" ( ) RETURNS opaque AS
'/opt/postgres/l
> > Results: 5000 transactions took ~60 sec in 7.1, ~550 sec in
> > 7.0.2 with fsync and ~60 sec without fsync.
> >
> > So, seems that WAL added not just complexity to system -:)
>
> Wow, this sounds fantastic :-)
> I see my concerns where not justified.
Let's see first how justified are my h
> > The macro AbsoluteTimeIsReal does not work somehow.
>
> Hm. That expands to
>
> (((int) time) < ((int) 0x7FFC) && \
>((int) time) > ((int) 0x8001))
There is a special case in nabstime.h for AIX, which imho
got swapped. The normal case for me would be INT_MIN
and not
It appears that something is messed up with regard to Perl
support on my system. Two things are happening, which may
or may not be related.
1) There is a complaint during make that
*
* Cannot build PL/Perl because libperl is not a shared library.
* Skipped.
*
I'm running a pretty vanil
Kevin O'Gorman wrote:
> It appears that something is messed up with regard to Perl
> support on my system. Two things are happening, which may
> or may not be related.
They are not related.
> 1) There is a complaint during make that
> *
> * Cannot build PL/Perl because libperl is not a sha
On Sun, Nov 05, 2000 at 03:48:13PM +0200, Hannu Krosing wrote:
> 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 f
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> I don't really have a better idea, but consider if you installed 7.1 into
> /opt/postgres71: then this dump will load the old version of plpgsql.sl.
True, but absolute paths in a dump file are a different (and
long-standing) issue.
> Assuming tha
> There is a special case in nabstime.h for AIX, which imho
> got swapped. The normal case for me would be INT_MIN
> and not the 0x8001.
> There is a comment that I don't understand at all given the below
> source code:
>
> /*
> * AIX considers 2147483648 == -2147483648 (since they have
>
Zeugswetter Andreas SB <[EMAIL PROTECTED]> writes:
>> But that is unfortunately not the problem. Looks like yet
>> another broken compiler to me :-(
> Ok, the comparison ((int) time) > ((int) 0x8001) is the problem.
> Reading the comment again and again, I have come to the conclusion,
> that
I suspect this is just a NOT updated out file:
(UnixWare 7.1.1/UDK FS (7.1.1b) cc/Multibyte/current sources).
*** ./expected/horology-solaris-1947.outSun Oct 22 17:15:13 2000
--- ./results/horology.out Fri Nov 10 15:39:00 2000
***
*** 109,116
| epoch
Just a BIG *THANK YOU* to tom for making the inet/cidr stuff
work as one would expect.
Larry
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 (voice) Internet: [EMAIL PROTECTED]
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I suspect this is just a NOT updated out file:
Yup. Patch applied, thanks!
regards, tom lane
Peter Eisentraut wrote:
>
> Kevin O'Gorman writes:
>
> > 2) Because _something_ was made for Perl, the 'make install'
> > has to be root. Okay. But this is leaving some stuff behind
> > that is owned by root. When I attempt a subsequent
> > 'make clean; make' I get into permissions trouble, a
On Friday 10 November 2000 11:39, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > When we implement schemas, then all objects belonging to the
> > DEFINITION_SCHEMA will not be dumped, all other objects will be. At
> > least I imagine that this might be something to work with.
> > Can you tell me how to use CHECKPOINT please?
>
> You shouldn't normally use it - postmaster will start backend
> each 3-5 minutes to do this automatically.
Oh, I see.
> > > > Is this the same as a SAVEPOINT?
> > >
> > > No. Checkpoints are to speedup after crash recovery and
> > > to remo
* Tatsuo Ishii <[EMAIL PROTECTED]> [001110 18:42] wrote:
> >
> > Yes, though we can change this. We also can implement now
> > feature that Bruce wanted so long and so much -:) -
> > fsync log not on each commit but each ~ 5sec, if
> > losing some recent commits is acceptable.
>
> Sounds great.
At 11:39 10/11/00 -0500, Tom Lane wrote:
>
>To bring this back from future nice solutions to the reality of what
>to do today, do people like the "template0" solution for now (7.1)?
>I can work on it if so.
>
Being able to create a vanilla DB is essential to make pg_dump work with
customized temp
At 01:21 10/11/00 -0500, Tom Lane wrote:
>
>You're right, it's *a* solution, but it'd involve a lot of tedious work.
>It's not just adding a column to all the system tables. If I interpret
>correctly what Mark and Gene are concerned about, it'd also mean
>changing the code so that any update to a
Mark Hollomon wrote:
> Correct. I don't know why anyone would want to change the definition of
> (say) int48eq, but if we are going to allow them to do so, we should be
> careful to allow them to backup and restore such a change.
Yes, and it is also important that if such weirdos exist, they are
> * Tatsuo Ishii <[EMAIL PROTECTED]> [001110 18:42] wrote:
> > >
> > > Yes, though we can change this. We also can implement now
> > > feature that Bruce wanted so long and so much -:) -
> > > fsync log not on each commit but each ~ 5sec, if
> > > losing some recent commits is acceptable.
> >
>
Did someone read bout this?
http://www.angelfire.com/nv/aldev/pgsql/GreatBridge.html
Saludos... :-)
--
"And I'm happy, because you make me feel good, about me." - Melvin Udall
-
Martín Marqués email: [EMAIL PROTE
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> When we implement schemas, then all objects belonging to the
> DEFINITION_SCHEMA will not be dumped, all other objects will be. At least
> I imagine that this might be something to work with.
That's a thought, although it still doesn't cope with the
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> More to the point, 'rpath' is currently undefined on HPUX because HPUX
> uses 'ld' to link shared libraries, but the shared library link uses
> $(rpath), so it would break. Perhaps to start with, is there a way to use
> the compiler driver to link sh
So new-style C functions are language "newC"?
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I don't really have a better idea, but consider if you installed 7.1 into
> > /opt/postgres71: then this dump will load the old version of plpgsql.sl.
>
> True, but absolute paths in a dump file
Tom Lane writes:
> Philip pointed out awhile back that it does not work to load a 7.0.*
> dump into current sources if the dumped database contains any
> procedural language definitions. The dumped handler-function
> definitions will look like
>
> CREATE FUNCTION "plpgsql_call_handler" ( ) RETU
37 matches
Mail list logo
