Hi list,
pgsql version 7.4.2
linux version 2.4.20
distro redhat 9
We appear to have some kind of problem on one of our internal production
systems and I can't think were first to look.
What follows is some selects. Note the OID. The column 'id' is primary
key. The production system makes selects
> The following bug has been logged online:
>
> Bug reference: 1462
> Logged by: Vladimir
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8
> Operating system: Windows2k sp4
> Description:install bug
> Details:
>
> when installing PostgreSQL 8 and choose fol
> The following bug has been logged online:
>
> Bug reference: 1466
> Logged by: Joe Brown
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0.0.0
> Operating system: Windows XP
> Description:#maintenace_work_mem = 16384
> Details:
>
> I was attempting to re
> The following bug has been logged online:
>
> Bug reference: 1463
> Logged by: Vojtech Rysanek
> Email address: [EMAIL PROTECTED]
> PostgreSQL version: 8.0
> Operating system: Windows
> Description:Borland C++ problem
> Details:
>
> Hello,
> the compiling Borland C
To summarise:
I believe there to be one row stored, which is the reason why the
constraints on the primary key (id) were met, and that for reasons as
yet unknown a select returns three rows.
An addendum:
To attempt to discover the database wide implications of this, I have
done a pg_dump into a
Anthony COMMUNIER wrote:
> The statement : EXEC SQL DELETE FROM WHERE CURRENT OF
> (describe in SQL 99) isn't recognize by ecpg
PostgreSQL does not implement the entire SQL standard by any means.
Please refer to the documentation about what you can expect to work and
how.
--
On Tue, 8 Feb 2005, rob wrote:
> We appear to have some kind of problem on one of our internal production
> systems and I can't think were first to look.
>
> What follows is some selects. Note the OID. The column 'id' is primary
> key. The production system makes selects based on status. As you ca
> Hmm, could you run the above including the system-columns ctid, xmin,
> cmin, xmax, cmax?
processing=# select oid, ctid, xmin, cmin, xmax, cmax, id, aid, status
from q_certs where oid = 15282219 ;
oid| ctid | xmin| cmin| xmax| cmax| id
| aid | status
"Joe Brown" <[EMAIL PROTECTED]> writes:
> Uncommenting
> maintenace_work_mem = 16384
> caused the server immediately stop after start.
You apparently managed to change the spelling while uncommenting;
the actual line in the sample file is
#maintenance_work_mem = 16384 # min 1024, size in K
"Niklas Andersson" <[EMAIL PROTECTED]> writes:
> Had a curious problem with postgresql 7.0.3.
7.0.3? You do realize that that's prehistoric?
> Could create a DB if I run
> kernel 2.4 but not in 2.6. Had a look in
> /src/backend/commands/dbcommands.c and finaly found out that you use an
> erroro
rob <[EMAIL PROTECTED]> writes:
> processing=# select oid, ctid, xmin, cmin, xmax, cmax from q_certs
> where oid = 15282219 ;
>oid| ctid | xmin| cmin| xmax| cmax
> --+---+---+---+---+---
> 15282219 | (3,5) | 174011432 |
rob <[EMAIL PROTECTED]> writes:
> I believe there to be one row stored, which is the reason why the
> constraints on the primary key (id) were met, and that for reasons as
> yet unknown a select returns three rows.
Just for the record: you do have three physical rows. The reason a
select on the p
This looks to me like malfeasance of a VACUUM FULL: the reason there
are multiple copies is that VACUUM FULL was trying to move the row
around, and somehow you ended up with all three copies marked "good",
when there should have been only one "good" copy at any instant.
So: (1) have you had any s
robf <[EMAIL PROTECTED]> writes:
> Can I now remove these two errant records or do you think there is
> anything to gain from continuing with this investigation ?
If you have the time, it would be interesting to dump out the rows with
pg_filedump (see http://sources.redhat.com/rhdb/). I usually
Joe Brown <[EMAIL PROTECTED]> writes:
> I checked all logs I could think of (event and pg_logs) and found no
> information. I suppose if I tried starting postmaster by hand I would
> have spotted the issue.
Hmm. I see at least part of the problem: the poweron default for
log_destination is "st
If you copy the extact error strings perhaps we can fix it.
---
Vojtech Rysanek wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1464
> Logged by: Vojtech Rysanek
> Email address:
w/egg on face, DOH
I did try to make sure I didn't submit a bogus report, but didn't try
hard enough.
I checked all logs I could think of (event and pg_logs) and found no
information. I suppose if I tried starting postmaster by hand I would
have spotted the issue.
This didn't help me diagnose
ecpg on 8.0.x crashes while compiling "create table as" statements. For
example,
#include
int main(){
EXEC SQL create table a as select 1;
exit(0);
}
Here's a patch attached.
--
TANIDA Yutaka <[EMAIL PROTECTED]>
ecpg_createas.patch
Description: Binary data
-
18 matches
Mail list logo
