Here's a better backtrace:
(gdb) bt
#0 slot_deform_tuple (slot=0xc325b8, natts=21) at heaptuple.c:1130
#1 0x004535f0 in slot_getsomeattrs (slot=0xc325b8, attnum=21)
at heaptuple.c:1340
#2 0x00543cc6 in ExecProject (projInfo=0xc44c98,
isDone=0x7fffe33f30a4) at execQual.c:5164
#3
I ran "select * from" on both tables. All rows were returned
successfully, no error logs were produced during the selects.
However there are usually many 23505 errors in indices, like:
Dec 13 10:02:13 goldbolt postgres[21949]: [26-1]
user=randirw,db=lovehunter ERROR: 23505: duplicate key value vi
2009/12/13 Nagy Daniel :
> I ran "select * from" on both tables. All rows were returned
> successfully, no error logs were produced during the selects.
>
> However there are usually many 23505 errors in indices, like:
> Dec 13 10:02:13 goldbolt postgres[21949]: [26-1]
> user=randirw,db=lovehunter E
Nagy Daniel writes:
> I ran "select * from" on both tables. All rows were returned
> successfully, no error logs were produced during the selects.
Well, that would seem to eliminate the initial theory of on-disk
corruption, except that these *other* symptoms that you just mentioned
for the first
[ just a note for the archives ]
I wrote:
> Andrew Gierth writes:
>> I don't think it's particularly closely related to #4907.
> Yeah. I think the real problem is that set_subqueryscan_references
> is overly optimistic about how much work it has to do:
On further review it doesn't seem that fi
The following bug has been logged online:
Bug reference: 5242
Logged by: Gerhard Lutz
Email address: gerhard.l...@mbtech-group.com
PostgreSQL version: 8.4.1
Operating system: Windows XP
Description:ODBC driver v8.4.1 crashed
Details:
Hello,
in my application the Pos
