Tom Lane wrote:
> Joe Conway <[EMAIL PROTECTED]> writes:
>
>> If not, prepare an array of C strings representing the attribute
>> values of your return tuple, and call: FUNC_BUILD_SLOT(values,
>> funcctx);
>
> I think that's a poor choice of abstraction, as it forces the user
> into the le
On Friday 24 May 2002 03:15 pm, Ulrich Drepper wrote:
> This is getting silly.
Yes, Ulrich, it is. Very silly. And Red Hat's stance is one of the silliest,
IMHO.
>You'll see that the glibc in RHL7.3 contains a lot of the
> code from the glibc 2.3 branch. It's not named 2.2.90 because major
>
On Mon, 27 May 2002 21:00:43 -0400 (EDT)
"Bruce Momjian" <[EMAIL PROTECTED]> wrote:
> TODO updated:
>
> Add BSD-licensed qsort() for 32-bit Solaris
Is this necessary? Didn't someone say that Sun had acknowledged the
performance problem and were going to be releasing a patch for it?
If tha
Jan Wieck wrote:
> Tom Lane wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> > >> Hmm. So your vision of PREPARE would allow the backend to reply
> > >> with a list of parameter types. How would you envision that working
> > >> exactly?
> >
> > > I guess there's some sort of statement ide
> Oh. Hmm, if that's what you want then I do not think an indexscan is
> the way to go about it. The indexscan will only visit leaf pages
> (and not, for example, internal nodes of a btree). Also the
> free-space-counting code you're using seems pretty unworkable since the
> indexscan is unlike
TODO updated:
Add BSD-licensed qsort() for 32-bit Solaris
---
Andrew Sullivan wrote:
> On Tue, Apr 30, 2002 at 03:28:13PM -0400, Tom Lane wrote:
>
> > Do you need to profile it? It seemed that the 32-bit behavio
NunoACHenriques <[EMAIL PROTECTED]> writes:
> I've issued a query like the one below and the server timed out after
> 180min (+/-). The query "construct_warehouse()" can last well above the
> 180min because it fills a table with millions of tuples...
>
> -
On Thu, 23 May 2002 18:36:17 +0100 (WEST)
"NunoACHenriques" <[EMAIL PROTECTED]> wrote:
> Is there any server timeout that is undocumented?
Looks more like a backend crash to me. Can you look for a core file in
$PGDATA/base/xxx/ (where xxx is the OID of your database)? If you
don't have debu
Peter Eisentraut wrote:
> We need a function like this in the main line. The "show all" variety
> isn't top priority, but we need something that gets you the "show" result
> as a query output. The original idea was to make SHOW return a query
> result directly, but a function is fine with me too
On Thu, 23 May 2002 18:36:17 +0100 (WEST), NunoACHenriques
<[EMAIL PROTECTED]> wrote:
>server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
>The connection to the server was lost. Attempting reset: Fa
Teodor Sigaev <[EMAIL PROTECTED]> writes:
>> Yeah, but the update case is inserting more entries into the index.
>> I'm wondering if that causes the index scan's state to get corrupted
>> so that it misses scanning some entries.
> Thank you, Tom. You give me a direction for looking. Attached patc
Olivier PRENANT wrote:
> Hi every one.
>
> I just moved (at last!) to 7.2.1. Works like a charm...
> I'm suprised though by the number of WAL files.
>
> I have 8 files where postgresql.conf says WAL_FILES=4.
>
> What did I miss ? (I have no outstanding transaction)
>
> FWIW, t's on UW711.
No,
Please,
I saw some articles about de implementation off some security rules like
NO CREATE TABLE and the possibility of the implementation in version 7.2
of PostgreSQL.
Could you confirm this information? Is there this implementation in 7.2?
If not, what coul I do to create a user without the pri
NunoACHenriques <[EMAIL PROTECTED]> writes:
> Is there any server timeout that is undocumented?
No.
> spid=> vacuum full analyze ; select construct_warehouse() ; vacuum analyze ;
> NOTICE: Skipping "pg_group" --- only table or database owner can VACUUM it
> NOTICE: Skipping "pg_database"
Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> > could anyone please enlighten me about the status of replication? I do
> > expect lots of questions about this, and I'm not really sure if I can
> > promise it for 7.3. :-)
>
> Unless 7.3 slips drastically from our current intended
Joe Conway wrote:
> Tom Lane wrote:
>>
>> Now that I think about it, it's possible that ExecFunctionReScan is
>> correct now, at least given the simplistic always-materialize policy
>> that we've implemented so far. But it hasn't gotten much testing.
>
> OK -- the attached (stand alone) test scr
Joe Conway <[EMAIL PROTECTED]> writes:
> I'm thinking about next steps for SRFs and looking for input. ... At
> this point I know of several things which need to be done (or at least I
> think they are desirable):
> 1. Documentation -- it wasn't clear if Joel Burton was going to have
> time to
Tom Lane wrote:
>>3. PL/pgSQL support for returning sets -- this seems to me like an
>>important item if SRFs are to be useful to the masses. Any pointers on
>>how to approach this would be appreciated.
>
> Does Oracle's pl/sql support this? If so what does it look like?
I *think* Oracle pl/s
On Fri, 2002-05-24 at 12:03, Peter Eisentraut wrote:
> > Or does the -34 mean more than just the RedHat version number? The
> > Debian version is correctly named 2.2.5-6 where the -6 means that this
> > is the 6th release of glibc 2.2.5 for Debian,
>
> Just for general amusement: I run SuSE's g
Joe Conway writes:
> Here is a revised patch for a sample C function returning setof
> composite. (Same comments as last time -- It is a clone of SHOW ALL as
> an SRF. For the moment, the function is implemented as contrib/showguc,
> although a few minor changes to guc.c and guc.h were required t
Hi!
I have sended the message below to pgadmin-support but receive no
answers... I hope you can help me on this...
Is there any server timeout that is undocumented?
I've issued a query like the one below and the server timed out after
180min (+/-). The query "co
On Thu, 2002-05-23 at 07:20, Michael Meskes wrote:
> The glibc version in the soon to be released Woody
> release is 2.2.5.
The version in RHL7.3 is 2.2.5-34. This is not what Debian uses. Maybe
you should read the changelog for the version.
--
---. ,-.
Joe Conway <[EMAIL PROTECTED]> writes:
> If not, prepare an array of C strings representing the
> attribute values of your return tuple, and call:
> FUNC_BUILD_SLOT(values, funcctx);
I think that's a poor choice of abstraction, as it forces the user into
the least-efficient-possible way of b
>
>
>
>Unless 7.3 slips drastically from our current intended schedule
>(beta in late August), I think it's pretty safe to say there will
>be no replication in 7.3, beyond what's already available (rserv
>and so forth).
>
I can't speak for any of the other replication projects, but
pgreplication
Manfred Koizar <[EMAIL PROTECTED]> writes:
> On leaf pages order index tuples by heap item pointer, if otherwise
> equal. In IndexScanDescData remember the whole index tuple (including
> the heap item pointer) instead of ItemPointerData. Then depending on
> scan direction _bt_next() would look f
Dear Tom,
I have just been talking to Hans-Juergen Schoening from the hackers-list
on the telephone. I found out, that I was really using postgres 7.2-1.72,
(I took this as 7.2.1 :(( ) - so I updated the server, and the webserver
that's connecting to the database to the latest current rpm-releas
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Sure. In my understanding, unlike tables "free/reusable space" is
> actually not reused in index. pgstatindex would be usefull to judge if
> REINDEX is needed by showing the growth of physical length and
> "free/reusable space".
Oh. Hmm, if that's what
"Henrik Steffen" <[EMAIL PROTECTED]> writes:
> Does anyone know what the message "invalid length of startup packet"
> in /var/log/messages means?
Something is connecting to your postmaster and sending invalid data.
> It says it's "fatal" - so what is the reason
> for this message, what does it m
Michael Meskes <[EMAIL PROTECTED]> writes:
> could anyone please enlighten me about the status of replication? I do
> expect lots of questions about this, and I'm not really sure if I can
> promise it for 7.3. :-)
Unless 7.3 slips drastically from our current intended schedule
(beta in late Augus
Hello hackers!
Does anyone know what the message "invalid length of startup packet"
in /var/log/messages means? It says it's "fatal" - so what is the reason
for this message, what does it mean and what can I do against it?
I use the latest postgresql-release on a heavily loaded dedicated pentiu
Hi,
could anyone please enlighten me about the status of replication? I do
expect lots of questions about this, and I'm not really sure if I can
promise it for 7.3. :-)
Yes, I know it's marked urgent in the TODO list, but no one seems to be
listed as tackling this topic.
Thanks a lot.
Michael
Hi,
could anyone please enlighten me about the status of replication? I do
expect lots of questions about this, and I'm not really sure if I can
promise it for 7.3. :-)
Yes, I know it#s marked urgent in the TODO list, but no one seems to be
listed as tackling this topic.
Thanks a lot.
Michael
Hi,
we ( me and Teodor) are looking for some postgresql, Web short-time contracts.
If somebody have some offering, please contact for details.
I estimate we'll have financial problem till autumn.
Our experience:
1. Search engines - small and medium scale for dynamic sites
(customized OpenFTS
On Sat, 25 May 2002 14:21:52 -0400, Tom Lane <[EMAIL PROTECTED]>
wrote:
>I'm somewhat concerned that the more stringent locking will slow down
>VACUUM a good deal when there's lots of concurrent activity, but I don't
>see another answer. Ideas anyone?
Ideas? Always! :-) Don't know if this one
Sorry, forgot a patch...
Teodor Sigaev wrote:
>
>
> Oleg Bartunov wrote:
>
>> Just tested with 7.2.1. It works. We have one more patch (for rtree_gist)
>> to submit before 7.2.2 release.
>>
>
> Attached patch fix a bug with creating index. Bug was reported by Chris
> Hodgson <[EMAIL PROTECTE
Oleg Bartunov wrote:
> Just tested with 7.2.1. It works. We have one more patch (for rtree_gist)
> to submit before 7.2.2 release.
>
Attached patch fix a bug with creating index. Bug was reported by Chris Hodgson
<[EMAIL PROTECTED]>. Please, apply it for 7.2.2 and current CVS.
--
Teodor Si
Tested it with current CVS. It works.
Oleg Bartunov wrote:
> Just tested with 7.2.1. It works. We have one more patch (for rtree_gist)
> to submit before 7.2.2 release.
>
> Oleg
>
> On Sun, 26 May 2002, Teodor Sigaev wrote:
>
>
>>>Yeah, but the update case is inserting more entries into
37 matches
Mail list logo
