Hello
this is known bug - you have to drop modified table and create it
again. I believe so this should be fixed early - in this summer.
regards
Pavel Stehule
2009/7/10 Sergey Burladyan :
> Alvaro Herrera writes:
>
>> Michael Tenenbaum wrote:
>>
>> > If I have a stored procedure that returns a
Sergey Burladyan writes:
> Alvaro Herrera writes:
>
> > Michael Tenenbaum wrote:
> >
> > > If I have a stored procedure that returns a set of records of a table, I
> > > get
> > > an error message that the procedure's record is the wrong type after I
> > > change some columns in the table.
>
Alvaro Herrera writes:
> Michael Tenenbaum wrote:
>
> > If I have a stored procedure that returns a set of records of a table, I get
> > an error message that the procedure's record is the wrong type after I
> > change some columns in the table.
> >
> > Deleting the procedure then rewriting the
Bruce Momjian wrote:
>
> That is an installer error so you will have to report it to MoteView or
> Crossbow.
But in any case, if you are getting something as old as 8.0.0-rc1, you
are being scammed.
> ---
>
> Ahren Reed w
"Ahren Reed" writes:
> PostgreSQL version: 8.0.0
> Operating system: Windows XP
> Description:installation failure: Failure to set permissions on the
> installed files
> I am using the Crossbow install package called "MoteViewSetup_1.2.B.exe"
> that came on my Crossbow System Support C
Dan Boeriu wrote:
> I tried several times to build Postgres 8.4 with the ossp uuid both from
> source and from yum/rpm.
> I do have installed on the server uuid 1.6
> Now in 8.3.7 I installed a uuid package from postgres yum and run a script:
> /usr/share/pgsql/contrib/uuid-ossp.sql
> which I can
That is an installer error so you will have to report it to MoteView or
Crossbow.
---
Ahren Reed wrote:
>
> The following bug has been logged online:
>
> Bug reference: 4915
> Logged by: Ahren Reed
> Email a
The following bug has been logged online:
Bug reference: 4915
Logged by: Ahren Reed
Email address: aar...@nps.edu
PostgreSQL version: 8.0.0
Operating system: Windows XP
Description:installation failure: Failure to set permissions on the
installed files
Details:
I a
The following bug has been logged online:
Bug reference: 4914
Logged by: Dan Boeriu
Email address: dan.boe...@roost.com
PostgreSQL version: 8.4
Operating system: Red Hat 5.3
Description:uuid_generate_v4 not present in either source or yum/rpm
Details:
I tried severa
> "Tom" == Tom Lane writes:
>> The system was recently dump/restored from a different box. The
>> failing rows are all new inserts since the restore.
Tom> So the table has been insert-only so far? I was just thinking
Tom> that HOT bugs seemed like a probable explanation, but that idea
Mathieu De Zutter wrote:
> I have a table log_event with a primary key on an integer 'id', called
> log_event_pkey.
>
> The tables contains a duplicate for id = 15723018. The duplicate (note that
> besides the id, all data differs) doesn't seem to be known by the index at
> all.
What do the INSE
Andrew Gierth writes:
> Tom> One thing that seems odd is that the xids are kinda small. Did
> Tom> the system just recently have a wraparound event?
> The system was recently dump/restored from a different box. The
> failing rows are all new inserts since the restore.
So the table has been in
> "Tom" == Tom Lane writes:
>> Notice that the two rows seem entirely independent (different
>> xmin). The OP stated that his app generally does single-row
>> inserts (with some exceptions not relevent here); however, we
>> found a nearby row which shares the xmin:
Tom> How is the time
Andrew Gierth wrote:
> > "Mathieu" == "Mathieu De Zutter" writes:
>
> Mathieu> I have a table log_event with a primary key on an integer
> Mathieu> 'id', called log_event_pkey.
>
> Mathieu> The tables contains a duplicate for id = 15723018. The
> Mathieu> duplicate (note that besides the
Andrew Gierth writes:
> This was first reported on IRC and I spent a little time working with
> the OP trying to dig up info to suggest a cause; here is the relevent
> data (all provided by the OP at my request). I have not been able to
> suggest a possible cause based on this.
> shs=# select cti
"Tom Bowden" writes:
> I found that when using xslt_process(), either with two parameters, or with
> an empty/null third parameter -- that I get a 'server restarted' message.
Hm, I don't.
regression=# select xslt_process('','');
xslt_process
--
(1 row)
regression=# select xslt
> "Mathieu" == "Mathieu De Zutter" writes:
Mathieu> I have a table log_event with a primary key on an integer
Mathieu> 'id', called log_event_pkey.
Mathieu> The tables contains a duplicate for id = 15723018. The
Mathieu> duplicate (note that besides the id, all data differs)
Mathieu> do
The following bug has been logged online:
Bug reference: 4913
Logged by: Mathieu De Zutter
Email address: math...@dezutter.org
PostgreSQL version: 8.3.7
Operating system: Debian Lenny
Description:Row missing from primary key index
Details:
I have a table log_event w
The following bug has been logged online:
Bug reference: 4912
Logged by: Tom Bowden
Email address: tom.bow...@fis-cal.com
PostgreSQL version: 8.4rc2
Operating system: Linux 2.6.22.5-31-bigsmp
Description:server core dumps on xslt_process with empty param
string
Detail
The following bug has been logged online:
Bug reference: 4911
Logged by: Brian Ceccarelli
Email address: cecca...@talussoftware.com
PostgreSQL version: 8.4
Operating system: Windows, Linux
Description:Cannot assign a value to a member of a nested composite
type.
Detai
> The function body contains
> return '\';
>
> and that string literal causes a syntax error when we come to parse the
> RETURN statement.
Thanks for the explanation - very clear.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://
"Eugen Kraynovych" writes:
> PANIC: XX000: bad buffer id: 2049
> CONTEXT: COPY attach_data, line 207: "164
> \\320\\317\\021\\340\\241\\261\\032\\341\\000\\000\\000\\000\\000\\000\\000\
> \000\\000\\000\\000\..."
Huh, that's interesting. This is repeatable from a fresh initdb?
Could you m
The following bug has been logged online:
Bug reference: 4910
Logged by: Eugen Kraynovych
Email address: y.kraynov...@web.de
PostgreSQL version: 8.3.7
Operating system: Gentoo 2.6.14 hardened
Description:pg_restore fails on linux but success on win, buffer
dirty
Detai
Looks very good by now.
I'll test the version for a few days in my regular work and will
post more feedback here.
On 8 Lip, 17:37, dp...@pgadmin.org (Dave Page) wrote:
> On Wed, Jul 8, 2009 at 2:03 PM, Tsutomu Yamada wrote:
> > In the past, there was the thread about this problem,
> > and it
24 matches
Mail list logo
