Re: [HACKERS] Problem linking libecpg.5.3.dylib on OS X

"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > I'm seeing the following on cuckoo: > -L/opt/local/lib -lpgtypes -lpq -lm -o libecpg.5.3.dylib > ld: Undefined symbols: > _ecpg_internal_regression_mode > /usr/bin/libtool: internal link edit command failed It looks like Joachim's last patch thinks it'

[HACKERS] Problem linking libecpg.5.3.dylib on OS X

I'm seeing the following on cuckoo: gcc -pipe -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -dynamiclib -install_name /Users/buildfarm/buildfarm/HEAD/inst/lib/libecpg.5.dylib -compatibility_version 5 -

Re: [HACKERS] Problem with windows installer

On Fri, Jan 05, 2007 at 08:30:58AM +, Dave Page wrote: > Magnus Hagander wrote: > >> I discussed this briefly with Robert on IM yesterday - he told me the > >> account was installer created. Without a PC at the time I couldn't look > >> into it further :-( > > > > The faq still applies as the

Re: [HACKERS] Problem with windows installer

Magnus Hagander wrote: >> I discussed this briefly with Robert on IM yesterday - he told me the >> account was installer created. Without a PC at the time I couldn't look >> into it further :-( > > The faq still applies as the most likely reason. It can certainly happen > with the installer creat

Re: [HACKERS] Problem with windows installer

> >> Hello all, > >> > >> a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a > >> Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x > >> version and we even tried to install 8.2 and it did not work. > >> > >> Ok, the problem is: after installing all the files t

Re: [HACKERS] Problem with windows installer

On Thu, 04 Jan 2007 22:55:52 + Dave Page <[EMAIL PROTECTED]> wrote: > Magnus Hagander wrote: > > > See the FAQ at http://www.postgresql.org/docs/faqs.FAQ_windows.html#3.3 > > (question 3.3). > > I discussed this briefly with Robert on IM yesterday - he told me the > account was installer cre

Re: [HACKERS] Problem with windows installer

Magnus Hagander wrote: > Andreas 'ads' Scherbaum wrote: >> Hello all, >> >> a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a >> Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x >> version and we even tried to install 8.2 and it did not work. >> >> Ok, the pr

Re: [HACKERS] Problem with windows installer

Andreas 'ads' Scherbaum wrote: > Hello all, > > a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a > Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x > version and we even tried to install 8.2 and it did not work. > > Ok, the problem is: after installing all

[HACKERS] Problem with windows installer

Hello all, a friend of mine ran into a problem installing PostgreSQL 8.0.9 on a Windows XP Pro machine. Before anyone is asking: it has to be a 8.0.x version and we even tried to install 8.2 and it did not work. Ok, the problem is: after installing all the files the installer wants to init the d

[HACKERS] problem with web interface for mailing lists?

Hello, I see las actualisation from 18. december regards Pavel Stehule _ Chcete sdilet sve obrazky a hudbu s prateli? http://messenger.msn.cz/ ---(end of broadcast)--- TIP 5: don't

Re: [HACKERS] Problem in buidind Postgres with mingw

[EMAIL PROTECTED] wrote: Hello we've some trouble with buildinq postgreSQL (8.1.4.tar.gz) from code with Mingw on a windows xp home machine. My experience is that XP-Pro is a better platform for building postgres than XP-HE. We've installed mingw 5.0.3 and msys 1.0.10. >From the msys c

[HACKERS] Problem in buidind Postgres with mingw

Hello we've some trouble with buildinq postgreSQL (8.1.4.tar.gz) from code with Mingw on a windows xp home machine. We've installed mingw 5.0.3 and msys 1.0.10. From the msys console we've typed the following command: $ LDFLAGS=-lstdc++ configure --without-zlib and that's seems ok. then we do: $m

[HACKERS] problem with using O_DIRECT

I tried to use O_DIRECT on Linux (SuSe) Kernel 2.6, but failed to make it run. For example, if I added the option in the "open" of BasicOpenFile(), I got the following error after typing "psql -l", psql: could not connect to server: Connection refused Is the server running locally and acce

Re: [HACKERS] problem with volatile functions in subselects ?

Bruce Momjian <[EMAIL PROTECTED]> writes: >> If we do it, basically the response to anyone who complains about loss >> of performance should be "fix your function to be marked stable or >> immutable, as appropriate". > Agreed. Are we doing this, or is it a TODO? It's done: http://archives.postgr

Re: [HACKERS] problem with volatile functions in subselects ?

Tom Lane wrote: > "Jaime Casanova" <[EMAIL PROTECTED]> writes: > >>> There's been some talk about prohibiting flattening if there are any > >>> volatile functions in the subselect's targetlist, but nothing's been > >>> done about that. > > > BTW, can you think in a good name for a GUC for this? >

Re: [HACKERS] Problem with mailing list?

On Wed, Aug 23, 2006 at 08:47:03 +0200, Zdenek Kotala <[EMAIL PROTECTED]> wrote: > Is everything ok with postgres mail server? I have problem to send mail > to hackers list and pgadmin-hacker as well. If somebody is on cc, he > receives mail correctly, but it does not appear in the list. Any su

Re: [HACKERS] Problem with mailing list?

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 23 August 2006 08:56 > To: Dave Page > Cc: pgsql-hackers@postgresql.org; [EMAIL PROTECTED] > Subject: Re: [HACKERS] Problem with mailing list? > > > I had similar prob

Re: [HACKERS] Problem with mailing list?

Dave Page wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zdenek Kotala Sent: 23 August 2006 08:07 To: Josh Berkus; Bruce Momjian; pgsql-hackers@postgresql.org; [EMAIL PROTECTED] Subject: [HACKERS] Problem with mailing list? Is everything

Re: [HACKERS] Problem with mailing list?

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Zdenek Kotala > Sent: 23 August 2006 08:07 > To: Josh Berkus; Bruce Momjian; pgsql-hackers@postgresql.org; > [EMAIL PROTECTED] > Subject: [HACKERS] Problem with mailing list?

[HACKERS] Problem with mailing list?

Is everything ok with postgres mail server? I have problem to send mail to hackers list and pgadmin-hacker as well. If somebody is on cc, he receives mail correctly, but it does not appear in the list. Any suggestion? This problem first occurred when I sign into pgadmin-hacker list.

[HACKERS] Problem with mailing list?

Is everything ok with postgres mail server? I have problem to send mail to hackers list and pgadmin-hacker as well. If somebody is on cc, he receives mail correctly, but it does not appear in the list. Any suggestion? Zdenek ---(end of broadcast)---

Re: [HACKERS] problem with volatile functions in subselects ?

Based on how small this patch is and the demonstrated desire for this behavior, can we consider putting this in 8.2, even though we're past the deadline? On Sun, Aug 13, 2006 at 10:03:30PM -0500, Jaime Casanova wrote: > On 8/13/06, Tom Lane <[EMAIL PROTECTED]> wrote: > >"Jaime Casanova" <[EMAIL PR

Re: [HACKERS] problem with volatile functions in subselects ?

On 8/13/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Jaime Casanova" <[EMAIL PROTECTED]> writes: >>> There's been some talk about prohibiting flattening if there are any >>> volatile functions in the subselect's targetlist, but nothing's been >>> done about that. > BTW, can you think in a good name

Re: [HACKERS] problem with volatile functions in subselects ?

"Jaime Casanova" <[EMAIL PROTECTED]> writes: >>> There's been some talk about prohibiting flattening if there are any >>> volatile functions in the subselect's targetlist, but nothing's been >>> done about that. > BTW, can you think in a good name for a GUC for this? I'm not in favor of a GUC for

Re: [HACKERS] problem with volatile functions in subselects ?

> There's been some talk about prohibiting flattening if there are any > volatile functions in the subselect's targetlist, but nothing's been > done about that. Disabling flattening is a sufficiently big hit to > the planner's optimization ability that it shouldn't be done lightly. > >

Re: [HACKERS] problem with volatile functions in subselects ?

On 7/30/06, Tom Lane <[EMAIL PROTECTED]> wrote: "Sergey E. Koposov" <[EMAIL PROTECTED]> writes: > I see the very strange behaviour with the following set of queries: > wsdb=# select na,nb, na::double precision as da, nb::double precision as db from ( select random()::numeric as na,random()::nu

Re: [HACKERS] problem with volatile functions in subselects ?

"Sergey E. Koposov" <[EMAIL PROTECTED]> writes: > I see the very strange behaviour with the following set of queries: > wsdb=# select na,nb, na::double precision as da, nb::double precision as db > from ( select random()::numeric as na,random()::numeric as nb from > generate_series(1,2)) as xx;

[HACKERS] problem with volatile functions in subselects ?

Hello Hackers, I see the very strange behaviour with the following set of queries: wsdb=# select na,nb, na::double precision as da, nb::double precision as db from ( select random()::numeric as na,random()::numeric as nb from generate_series(1,2)) as xx; na |nb

Re: [HACKERS] Problem to "current-status information in shared memory" patch

"Qingqing Zhou" <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> wrote >> "postgres --single" works for me. Maybe you need a "make >> distclean"/rebuild? > Sorry, because I forget to say that you need to turn "stats_command_string" > on. Ah. OK, fixed. regar

Re: [HACKERS] Problem to "current-status information in shared memory" patch

"Tom Lane" <[EMAIL PROTECTED]> wrote > > "postgres --single" works for me. Maybe you need a "make > distclean"/rebuild? > Sorry, because I forget to say that you need to turn "stats_command_string" on. When it is off, pgstat_report_activity() will return immediately so nothing wrong could be obs

Re: [HACKERS] Problem to "current-status information in shared memory" patch

"Qingqing Zhou" <[EMAIL PROTECTED]> writes: > Ooops, guess we forget to handle the single user mode in "current-status > information in shared memory" patch ... "postgres --single" works for me. Maybe you need a "make distclean"/rebuild? regards, tom lane ---

[HACKERS] Problem to "current-status information in shared memory" patch

On CVS tip: $ postgres --single -Ddata postgres PostgreSQL stand-alone backend 8.2devel Segmentation fault (core dumped) $ gdb -c core.18119 (gdb) bt #0 pgstat_report_activity (cmd_str=0x67d25e "") at pgstat.c:1484 1484beentry->st_changecount++; (gdb) bt #0 pgstat_report_activity (

Re: [HACKERS] problem with PQsendQuery/PQgetResult and COPY FROM statement

"Massimiliano Poletto" <[EMAIL PROTECTED]> writes: >> If you call it exactly once, it'll say that exactly once. If you keep >> calling it "millions of times", it'll keep saying that. > OK. I wonder, though, why at some point it does in fact return 0. Probably because you ran out of memory to cr

Re: [HACKERS] problem with PQsendQuery/PQgetResult and COPY FROM statement

If you call it exactly once, it'll say that exactly once. If you keep calling it "millions of times", it'll keep saying that. OK. I wonder, though, why at some point it does in fact return 0. Indeed. You forgot to "complete the COPY sequence" before returning to the PQgetResult loop. As lo

Re: [HACKERS] problem with PQsendQuery/PQgetResult and COPY FROM statement

[EMAIL PROTECTED] writes: > I do not expect PQgetResult to return millions of non-null PGresult > objects after a PQsendQuery("COPY test FROM STDIN"). I expect exactly > one non-null result, with a result status of PGRES_COPY_IN. If you call it exactly once, it'll say that exactly once. If you k

Re: [HACKERS] problem with PQsendQuery/PQgetResult and COPY FROM statement

Thanks for all your replies, but I must clarify some things. First, note that what I posted is just a small example that reproduces behavior that appears incorrect. The real code is a C++ wrapper around libpq that supports non-blocking queries and reuses open connections. Volkan and Martijn: I k

Re: [HACKERS] problem with PQsendQuery/PQgetResult and COPY FROM statement

On Fri, May 19, 2006 at 11:51:00AM -0700, [EMAIL PROTECTED] wrote: > I attempt to execute a "COPY test FROM STDIN" using PQsendQuery. > Subsequently, after the appropriate poll()/PQconsumeInput/PQisBusy > calls, PQgetResult returns tens of millions of (invalid?) non-null > PGresults. This behavior

Re: [HACKERS] problem with PQsendQuery/PQgetResult and COPY FROM statement

[EMAIL PROTECTED] writes: > I attempt to execute a "COPY test FROM STDIN" using PQsendQuery. > Subsequently, after the appropriate poll()/PQconsumeInput/PQisBusy > calls, PQgetResult returns tens of millions of (invalid?) non-null > PGresults. You should fix your code to pay some attention to what

Re: [HACKERS] problem with PQsendQuery/PQgetResult and COPY FROM statement

On May 19 11:51, [EMAIL PROTECTED] wrote: > if (PQsendQuery(conn, "COPY test FROM STDIN") > 0) { > retrieve(conn, 20); Shouldn't you be send()'ing instead of retrieve()'ing? COPY tbl FROM stdin, requests data from client to COPY FROM stdin TO tbl. Regards. ---(end

[HACKERS] problem with PQsendQuery/PQgetResult and COPY FROM statement

I attempt to execute a "COPY test FROM STDIN" using PQsendQuery. Subsequently, after the appropriate poll()/PQconsumeInput/PQisBusy calls, PQgetResult returns tens of millions of (invalid?) non-null PGresults. This behavior seems incorrect, and sometimes causes my application to exhaust memory and

[HACKERS] Problem compiling from cvs, mingw

I get the following error:   gcc -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -fno-strict-aliasing -I. -I../../../src/include -I./src/include/port/win32 -DEXEC_BACKEND  "-I../../../src/include/port/win32" -DBUILDING_DLL  -c -o bootparse.o bootparse.cbootparse.y:101:10: "b4_file_name" i

Re: [HACKERS] Problem compiling with mingw

"Juan Manuel Diaz Lara" <[EMAIL PROTECTED]> wrote > > bootparse.y:101:10: "b4_file_name" is not a valid filename > > bison-2.1.exe --> d:\gnuwin32 > Maybe it is bison's problem. I always use 1.875 since it has been there long enough && powerful enough ... Regards, Qingqing --

[HACKERS] Problem compiling with mingw

I run configure (no complains about bison o flex), after a few seconds I receive the next errors:   make[4]: Leaving directory `/pgsql/src/backend/access/nbtree'make -C transam SUBSYS.omake[4]: Entering directory `/pgsql/src/backend/access/transam'make[4]: `SUBSYS.o' is up to date.make[4]: Leavin

Re: [HACKERS] problem with large maintenance_work_mem settings and

Tom Lane wrote: > I wrote: > >>Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> >>>samples %symbol name >>>350318533 98.8618 mergepreread >>>9718220.2743 tuplesort_gettuple_common >>>4136740.1167 tuplesort_heap_siftup > > >>I don't have enough memory to really reproduce th

Re: [HACKERS] problem with large maintenance_work_mem settings and

I wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> samples %symbol name >> 350318533 98.8618 mergepreread >> 9718220.2743 tuplesort_gettuple_common >> 4136740.1167 tuplesort_heap_siftup > I don't have enough memory to really reproduce this, but I've come close > eno

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > samples %symbol name > 350318533 98.8618 mergepreread > 9718220.2743 tuplesort_gettuple_common > 4136740.1167 tuplesort_heap_siftup I don't have enough memory to really reproduce this, but I've come close enough that I believe

Re: [HACKERS] problem with large maintenance_work_mem settings and

"Zeugswetter Andreas DCP SD" <[EMAIL PROTECTED]> writes: >>> I'll look into it, but I was already wondering if we shouldn't bound >>> the number of tapes somehow. It's a bit hard to believe that 28000 >>> tapes is a sane setting. >> >> Well, since they are not actually tapes, why not? > I wonde

Re: [HACKERS] problem with large maintenance_work_mem settings and

> > I'll look into it, but I was already wondering if we shouldn't bound > > the number of tapes somehow. It's a bit hard to believe that 28000 > > tapes is a sane setting. > > Well, since they are not actually tapes, why not? I wonder what the OS does when we repeatedly open and close those

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > samples %symbol name > 350318533 98.8618 mergepreread > 9718220.2743 tuplesort_gettuple_common > 4136740.1167 tuplesort_heap_siftup I'm not immediately seeing why mergepreread would have such a problem with lots of tapes. Coul

Re: [HACKERS] problem with large maintenance_work_mem settings and

Simon Riggs <[EMAIL PROTECTED]> writes: > On Fri, 2006-03-10 at 09:31 -0500, Tom Lane wrote: >> I'll look into it, but I was already wondering if we shouldn't bound the >> number of tapes somehow. It's a bit hard to believe that 28000 tapes is >> a sane setting. > I thought you had changed the me

Re: [HACKERS] problem with large maintenance_work_mem settings and

On Fri, 2006-03-10 at 09:31 -0500, Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > > LOG: begin index sort: unique = f, workMem = 8024000, randomAccess = f > > LOG: switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec > > elapsed 32.43 sec > > LOG: finished wri

Re: [HACKERS] problem with large maintenance_work_mem settings and

Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>LOG: begin index sort: unique = f, workMem = 8024000, randomAccess = f >>LOG: switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec >>elapsed 32.43 sec >>LOG: finished writing run 1 to tape 0: CPU 173.56s/3425.8

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > LOG: begin index sort: unique = f, workMem = 8024000, randomAccess = f > LOG: switching to external sort with 28658 tapes: CPU 4.18s/13.96u sec > elapsed 32.43 sec > LOG: finished writing run 1 to tape 0: CPU 173.56s/3425.85u sec elapsed > 381

Re: [HACKERS] problem with large maintenance_work_mem settings and

Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>samples %symbol name >>103520432 47.9018 inlineApplySortFunction >>33382738 15.4471 comparetup_index >>25296438 11.7054 tuplesort_heap_siftup >>10089122 4.6685 btint4cmp >>8395676 3.8849 LogicalTapeRead >>28735

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > samples %symbol name > 103520432 47.9018 inlineApplySortFunction > 33382738 15.4471 comparetup_index > 25296438 11.7054 tuplesort_heap_siftup > 10089122 4.6685 btint4cmp > 8395676 3.8849 LogicalTapeRead > 2873556 1.3297 tuplesor

Re: [HACKERS] problem with large maintenance_work_mem settings and

Simon Riggs wrote: On Wed, 2006-03-08 at 10:45 -0500, Tom Lane wrote: Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: CREATE INDEX on a 1,8B row table (5 int columns - index created on the first row about 300M distinct values): before: 11h 51min after: 3h 11min(!) Cool. Does it seem to

Re: [HACKERS] problem with large maintenance_work_mem settings and

Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>CREATE INDEX on a 1,8B row table (5 int columns - index created on the >>first row about 300M distinct values): > > >>before: 11h 51min >>after: 3h 11min(!) > > > Cool. Does it seem to be I/O bound now? Would you be will

Re: [HACKERS] problem with large maintenance_work_mem settings and

On Wed, 2006-03-08 at 10:45 -0500, Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > > CREATE INDEX on a 1,8B row table (5 int columns - index created on the > > first row about 300M distinct values): > > > before: 11h 51min > > after: 3h 11min(!) > > Cool. Does it seem to be

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > CREATE INDEX on a 1,8B row table (5 int columns - index created on the > first row about 300M distinct values): > before: 11h 51min > after: 3h 11min(!) Cool. Does it seem to be I/O bound now? Would you be willing to do it over with oprofile t

Re: [HACKERS] problem with large maintenance_work_mem settings and

Tom Lane wrote: I wrote: Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: samples %symbol name 24915704 96.2170 ltsReleaseBlock We probably need to tweak things so this doesn't get called during the "final merge" pass. Looking at it now. I've committed a fix for this into CV

Re: [HACKERS] problem with large maintenance_work_mem settings and

I wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> samples %symbol name >> 24915704 96.2170 ltsReleaseBlock > We probably need to tweak things so this doesn't get called during the > "final merge" pass. Looking at it now. I've committed a fix for this into CVS HEAD --- plea

Re: [HACKERS] problem with large maintenance_work_mem settings and

On Sun, 2006-03-05 at 15:15 -0500, Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > > samples %symbol name > > 24915704 96.2170 ltsReleaseBlock > > 3872651.4955 LogicalTapeRead > > 1687250.6516 inlineApplySortFunction > > Hmm ... the comment in ltsReleaseBlo

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > samples %symbol name > 24915704 96.2170 ltsReleaseBlock > 3872651.4955 LogicalTapeRead > 1687250.6516 inlineApplySortFunction Hmm ... the comment in ltsReleaseBlock sez /* * Insert blocknum into array, preserving decr

Re: [HACKERS] problem with large maintenance_work_mem settings and

Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > forgot to mention that this is 8.1.3 compiled from source. >>> >>>See the discussion starting here: >>>http://archives.postgresql.org/pgsql-hackers/2006-02/msg00590.php > > >>I was following this thread - and it was partly

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >>> forgot to mention that this is 8.1.3 compiled from source. >> >> See the discussion starting here: >> http://archives.postgresql.org/pgsql-hackers/2006-02/msg00590.php > I was following this thread - and it was partly a reason why I'm playing >

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The sorting code probably needs a defense to keep it from trying to >> exceed MaxAllocSize for the SortObject array; AFAIR there is no such >> consideration there now, but it's easily added. I'm not sure where your >> VACUUM fai

Re: [HACKERS] problem with large maintenance_work_mem settings and

Tom Lane wrote: > Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: > >>>not that I think it is related to the problem at all. It looks like I'm >>>hitting the MaxAllocSize Limit in src/include/utils/memutils.h. > > >>just tried to increase this limit to 4GB (from the default 1GB) and this >>seem

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: >> not that I think it is related to the problem at all. It looks like I'm >> hitting the MaxAllocSize Limit in src/include/utils/memutils.h. > just tried to increase this limit to 4GB (from the default 1GB) and this > seems to help a fair bit. s/h

Re: [HACKERS] problem with large maintenance_work_mem settings and

Michael Paesold wrote: > Stefan Kaltenbrunner wrote: > >> hubert depesz lubaczewski wrote: >> >>> On 3/4/06, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote: >>> forgot to mention that this is 8.1.3 compiled from source. Further testing shows that not only CREATE INDEX has some issue with

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner wrote: foo=# set maintenance_work_mem to 200; SET foo=# VACUUM ANALYZE verbose; INFO: vacuuming "information_schema.sql_features" ERROR: invalid memory alloc request size 204798 Just an FYI, I reported a similar problem on my 8.0.0 database a few weeks ago. I up

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner wrote: > hubert depesz lubaczewski wrote: > >>On 3/4/06, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote: >> >> >>>forgot to mention that this is 8.1.3 compiled from source. Further >>>testing shows that not only CREATE INDEX has some issue with large >>>maintenance_work_mem se

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner wrote: hubert depesz lubaczewski wrote: On 3/4/06, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote: forgot to mention that this is 8.1.3 compiled from source. Further testing shows that not only CREATE INDEX has some issue with large maintenance_work_mem settings : what d

Re: [HACKERS] problem with large maintenance_work_mem settings and

hubert depesz lubaczewski wrote: > On 3/4/06, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote: > >>forgot to mention that this is 8.1.3 compiled from source. Further >>testing shows that not only CREATE INDEX has some issue with large >>maintenance_work_mem settings : > > > what does it show: > c

Re: [HACKERS] problem with large maintenance_work_mem settings and

On 3/4/06, Stefan Kaltenbrunner <[EMAIL PROTECTED]> wrote: > forgot to mention that this is 8.1.3 compiled from source. Further > testing shows that not only CREATE INDEX has some issue with large > maintenance_work_mem settings : what does it show: cat /proc/sys/kernel/shmmax ? depesz -

Re: [HACKERS] problem with large maintenance_work_mem settings and

Stefan Kaltenbrunner wrote: > Hi all! > > while playing on a new box i noticed that postgresql does not seem to be > able to cope with very large settings for maintenance_work_mem. > > For a test I created a single table with 5 integer columns containing > about 1,8B rows 8(about 300M distinct va

[HACKERS] problem with large maintenance_work_mem settings and CREATE INDEX

Hi all! while playing on a new box i noticed that postgresql does not seem to be able to cope with very large settings for maintenance_work_mem. For a test I created a single table with 5 integer columns containing about 1,8B rows 8(about 300M distinct values in the column I want to index): foo

Re: [HACKERS] Problem with the Planner

On Mon, 16 Jan 2006, Anjan Kumar. A. wrote: > > > > Please observe the following queries. Why PostgreSQL is favouring MergeJoin > eventhough, it leading to higher execution times than NestedLoopJoin. Any > suggestions to fix this problem. > > > bench=# EXPLAIN ANALYZE SELECT * FROM tenk1 t1, ten

[HACKERS] Problem with the Planner

Please observe the following queries. Why PostgreSQL is favouring MergeJoin eventhough, it leading to higher execution times than NestedLoopJoin. Any suggestions to fix this problem. bench=# EXPLAIN ANALYZE SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2;

Re: [HACKERS] problem with nasty latin2 sorting

Anna Domachowska <[EMAIL PROTECTED]> writes: > I've got a problem with sorting polish words in postgresql 7.4.2 > ... > I belive that postgres was compiled with "--enable-locale", and the > right locale is set. How sure are you of that? This sure sounds like a wrong-locale problem to me. Try "s

Re: [HACKERS] problem with nasty latin2 sorting

Anna Domachowska <[EMAIL PROTECTED]> writes: > So "¯arnów" is placed in wrong place, because it should be found after letter > "Z" ?? > > What's wrong? Is there any patch to fix this? Does anybody had similar > problem? > I belive that postgres was compiled with "--enable-locale", and the right

[HACKERS] problem with nasty latin2 sorting

Hello, I've got a problem with sorting polish words in postgresql 7.4.2 For example, I've got couple of polish cities in my table 'x', results of sorting are: (select city from x order by city asc) Bydgoszcz Gdańsk Iława Łódź Żarnów Malbork Warszawa So "Żarnów" is placed in wrong place, becau

Re: [HACKERS] Problem with COPY CSV

Christopher Kings-Lynne wrote: Attached is a small test extract from the USDA nutrient database. The problem is that the script won't load the COPY data correctly. This is with CVS HEAD (and 8.1). It is the 4th column in the table that gives the problem (nutr_no integer). Each of the 3

[HACKERS] Problem with COPY CSV

Attached is a small test extract from the USDA nutrient database. The problem is that the script won't load the COPY data correctly. This is with CVS HEAD (and 8.1). It is the 4th column in the table that gives the problem (nutr_no integer). Each of the 3 COPY rows has a different way of sp

Re: [HACKERS] problem with custom Gist for custom type

Ok, I got it, google is my friend ;) ... > Can I use valgrind to find out the root of problem. If so, how should I > invoke it with postgres. Postgres it self was configured with: ... -- GJ Binary system, you're either 1 or 0... dead or alive ;) ---(end of broadcast)

Re: [HACKERS] problem with custom Gist for custom type

On Wednesday 26 October 2005 18:34, Oleg Bartunov wrote: > btw, if you could read russian, we have GiST programming tutorial > http://www.sai.msu.su/~megera/postgres/talks/gist_tutorial.html I did try, but last time I did Russian lessons was around 10 years ago, so ... babel fish could help btw, bu

Re: [HACKERS] problem with custom Gist for custom type

btw, if you could read russian, we have GiST programming tutorial http://www.sai.msu.su/~megera/postgres/talks/gist_tutorial.html Oleg On Wed, 26 Oct 2005, Tom Lane wrote: Grzegorz Jaskiewicz <[EMAIL PROTECTED]> writes: I created custom type, and attempt to create gist indexing for it,

Re: [HACKERS] problem with custom Gist for custom type

On Wednesday 26 October 2005 17:48, Tom Lane wrote: > Looks like you're scribbling on memory that doesn't belong to you. > Check for miscomputed palloc request sizes, etc. Thanks very much for the tip. I thogut perhaps I am not filling out some parts of structures, or something. Can I use valgrind

Re: [HACKERS] problem with custom Gist for custom type

Grzegorz Jaskiewicz <[EMAIL PROTECTED]> writes: > I created custom type, and attempt to create gist indexing for it, to > make search wind quick. > on select from * where something << 'something'; I get: > WARNING: problem in alloc set GiST temporary context: detected write > past chunk end i

[HACKERS] problem with custom Gist for custom type

Hi there folks I created custom type, and attempt to create gist indexing for it, to make search wind quick. on select from * where something << 'something'; I get: WARNING: problem in alloc set GiST temporary context: detected write past chunk end in block 0x843e6e0, chunk 0x843e994 Can

Re: [HACKERS] Problem in ExecEvalExpr function

Sandeep, You seem to be having a lot of trouble understanding the evaluation code which isn't that complex.  Are you still trying to do that case-insensitive comparison?  If so, I seriously recommend that you just look at the citext project on gborg and stop messing around in the backend, it's jus

Re: [HACKERS] Problem in ExecEvalExpr function

On Tue, Oct 18, 2005 at 02:38:39PM +0530, sandeep satpal wrote: > > Hi, > > I have some doubts related to ExecEvalExpr functions which is used to > executing the expression. Since they are operators, they go through ExecEvalOper. However, after the first call they go through ExecMakeFunctionRes

[HACKERS] Problem in ExecEvalExpr function

Hi, I have some doubts related to ExecEvalExpr functions which is used to executing the expression. Here we are finding the subexpression recursively. But I am not able to find it out that where exactly the comparison taking place. For eg. relation A id name age relation B name age stat

Re: [HACKERS] problem for o/p

On Sat, Sep 10, 2005 at 12:11:52PM +0100, rajinder ruprai wrote: > i'am getting different o/p for the same program code as well as > the data base is the same .twice the output is being printed on > some machines whereas correct o/p on some.the program code is [...] > raise notice ' 'emp name %' ',

[HACKERS] problem for o/p

sir, i'am getting different o/p for the same program code as well as the data base is the same .twice the output is being printed on some machines whereas correct o/p on some.the program code is create or replace function f() return int4 as' c1 cursor for select empname from emp; e1 emp.ename%type;

Re: [HACKERS] problem with PQExecParams

On Wed, Aug 31, 2005 at 12:08:10PM -, prasanna mavinakuli wrote: > We need to insert binary data to tables and retrieve the > Same-(data type is bytea). > We are using PQExecParams for inserting and retrieving > Data. This doesn't belong on pgsql-hackers, which is for discussing development o

[HACKERS] problem with PQExecParams

  Hi, Problem Description:   We need to insert binary data to tables and retrieve the Same-(data type is bytea). We are using PQExecParams for inserting and retrieving Data. Table contains other than binary data also. When we tried to fetch the integer data (type-int2) We are not able to get

Re: [HACKERS] problem with coalesce

Oleg, > ERROR:  column "query.query" must appear in the GROUP BY clause or be > used in an aggregate function Apparently the parser thinks you have an aggregate function in there. Do you? -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadc

[HACKERS] problem with coalesce

Hi there, I don't understand why this select doesn't works: regression=# select coalesce( tp_rewrite_substitute(ARRAY[query, test.target, test.sample]), query) from test,to_tsquery('new2 & york2 & hotel') as query where query @ te

[HACKERS] problem building 7.3 on FreeBSD 6

Hi! Can someone with a FreeBSD 6.x installation confirm the build error referred here: I maintain the postgresql ports for FreeBSD, but I have no version 6 installed yet. Thanks, Palle ---

Re: [HACKERS] Problem with dblink regression test - FIXED

Patch applied. Thanks. --- Jim C. Nasby wrote: > On Tue, Jun 28, 2005 at 02:28:11PM -0400, Andrew Dunstan wrote: > > > > > > Jim C. Nasby wrote: > > > > >All the logs for the most recent run against HEAD are now at > >

<    2   3   4   5   6   7   8   9   10   11   >