Sergey Burladyan writes:
> postgres=# select xpath('count(//)', ''::xml);
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
Hmm. Looking at the libxml2 source code makes it clear that at le
I am install libxml2-dbg 2.7.3.dfsg-1 package, this is backtrace with it:
Program received signal SIGABRT, Aborted.
0xb7f17424 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f17424 in __kernel_vsyscall ()
#1 0xb7be0640 in *__GI_raise (sig=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#2 0xb7be200
This is CVS HEAD 8.3, Debian package 8.3.7 also affected.
libxml2: 2.7.3.dfsg-1 current version in debian testing.
postgres=# select version();
version
---
PostgreSQL 8.3.7 on i
"Daniele Bortoluzzi" writes:
> I created a multicolumn GIN index with btree_gin functionality (fulltext
> column + timestamp). After creating the index the db segfaulted:
> LOG: server process (PID 14195) was terminated by signal 11: Segmentation
> fault
I cannot replicate this problem based on
On Sunday 31 May 2009 20:00:44 Tom Lane wrote:
> Itagaki Takahiro writes:
> > Here is a patch to fix the bug. I added a parameter 'encode' to
> > map_sql_value_to_xml_value() and pass false for xml attributes.
>
> One thing I was wondering about, which is sort of highlighted by your
> patch, is wh
On Thursday 28 May 2009 13:31:16 Itagaki Takahiro wrote:
> Here is a patch to fix the bug. I added a parameter 'encode' to
> map_sql_value_to_xml_value() and pass false for xml attributes.
I have committed your patch with minor editing. Thanks.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@po
Jeff Davis writes:
> On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
>> I don't know what you mean by "frozen" exactly, but the start point of a
>> synchronized scan is stored in shared memory; otherwise, it wouldn't
>> know where to stop.
> Correction: I didn't actually mean _shared_ memory
On Tue, Jun 9, 2009 at 1:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> This seems like the only option that will produce correct answers, so
>> it gets my vote. How much is the performance penalty for
>> materializing the tuplestore? I'm inclined to think that whatever it
>> is, you just have
On Tue, Jun 9, 2009 at 1:00 PM, Kevin
Grittner wrote:
>
> the same paragraph: "The default is to allow scrolling in some cases;
"in some cases"... like in "but not all"... ?
this doesn't sound like a vow to me. if the user really wants
SCROLLing ability he should have been specified that way...
i
On Tue, Jun 9, 2009 at 12:07 PM, Tom Lane wrote:
> The technically best solution is probably similar to what Materialize
> nodes do, ie, read the query only once and be careful to stash rows
> aside into a tuplestore as they are read. This would fix both issues
> with one patch. The problem with
Tom Lane wrote:
> Robert Haas writes:
>> This seems like the only option that will produce correct answers,
>> so it gets my vote. How much is the performance penalty for
>> materializing the tuplestore? I'm inclined to think that whatever
>> it is, you just have to pay it if you ask for a WIT
On Tue, 2009-06-09 at 10:51 -0700, Jeff Davis wrote:
> On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
> > We could probably fix this specific issue by refactoring things in such
> > a way that the seqscan start point is frozen on the first read and
> > re-used after rewinds.
>
> I don't know w
On Tue, 2009-06-09 at 12:07 -0400, Tom Lane wrote:
> We could probably fix this specific issue by refactoring things in such
> a way that the seqscan start point is frozen on the first read and
> re-used after rewinds.
I don't know what you mean by "frozen" exactly, but the start point of a
synchr
Robert Haas writes:
> This seems like the only option that will produce correct answers, so
> it gets my vote. How much is the performance penalty for
> materializing the tuplestore? I'm inclined to think that whatever it
> is, you just have to pay it if you ask for a WITH HOLD cursor.
I don't
Robert Haas escribió:
> I suppose in theory you could try to figure out whether
> materialization is really necessary (let's see... no seqscans here and
> no volatile functions... ok, so we can cheat...) but that seems
> likely to lead to future bugs as the rules for which things are safe
> chang
Mark Kirkwood writes:
> A construction of the form
> DECLARE cur CURSOR WITH HOLD FOR SELECT * FROM obj
> loop
> FETCH 1000 FROM cur
> process 'em
> COMMIT
> results in some of the same rows being emitted more than once, altho the
> final rowcount is correct (i.e some rows end up b
WarrenDLC wrote:
>
> I've been running the installation and when it comes to initialize the
> first database cluster, initdb freezes and closes. the install continues
> with a "non fatal" error, but the installation does not work correctly.
> I have removed old users using net user delete
> I
"Andreas Nolte" writes:
> ... CEST ERROR: syntax error at or near "@" at character 33
> ... CEST STATEMENT: ALTER FUNCTION public.sp_pp_set(@ppnr integer, @JobID
> character varying) OWNER TO sa;
Hmm, looks like it's forgetting to double-quote function argument names
when needed. Thanks for the
Hello,
I'm testing now for almost a day, and I'm pretty sure now that this is a bug.
I tried to collect as much information for you as possible.
following behaviour:
I have a UTF8 encoded database (with name MANZPartCarrier), running on
WindowsXP. Dump/Restore work fine with PostgreSQL 8
19 matches
Mail list logo
