Hi,
When i am tring to change the column type from
character/Varchar to "int" i am getting error like,
ERROR: column "fname" cannot be cast to type
"int4"
I can able to change the column type to "int " if
the old datatype is double etc.
Even a "int" datatype also i can able to conver t
On Mon, Nov 14, 2005 at 06:19:16PM -0600, Kevin Grittner wrote:
> the moment aren't sure. The current machines are "transitional",
> and it may not be too late to set the permanent servers up with ECC
> memory. Is it something I should fight for?
Yes. Always.
A
--
Andrew Sullivan | [EMAIL P
On Tue, Nov 15, 2005 at 01:53:27PM +0800, ITS ONT Alcazar, Jose Aguedo C wrote:
> Thanks Tom! I think we did it. Below are the thing's i've inputed. Also, i
> have change the attributes and ownership of the xlog file as to the same
> with the previous file. Probably, they (sysadmins) have restored
"sandhya" <[EMAIL PROTECTED]> writes:
> When i am tring to change the column type from character/Varchar to =
> "int" i am getting error like,
> ERROR: column "fname" cannot be cast to type "int4"
If this is a pre-8.0 PG version, try casting to text and then int4.
If 8.0 or later, it should work
It appears that the log file is not being written -- I'll start a
separate thread on that issue.
I reran the query. Same error, same relation, different block.
dtr=> UPDATE
dtr-> "DbTranRepository"
dtr-> SET "userId" = UPPER("userId")
dtr-> WHERE (
dtr(> ("userId" <> UPPER("userId")) AND
http://www.postgresql.org/support/professional_support is an even better
place to start, since it lists all companies who've registered as
providing support. :)
On Mon, Nov 14, 2005 at 09:06:20PM -0800, Aaron Glenn wrote:
> On 11/14/05, ITS ONT Alcazar, Jose Aguedo C
> <[EMAIL PROTECTED]> wrote:
>
CREATE TABLE mytable (
id serial not null primary key,
myvalue varchar(50),
create_dt timestamp not null default now()
);
INSERT INTO mytable (myvalue) VALUES ('When was this record inserted ?');
SELECT * FROM mytable;
"Si" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECT
Could my issue be the same problem as this thread?:
http://archives.postgresql.org/pgsql-bugs/2005-11/msg00114.php
The references to "Invalid Argument" caught my eye. That thread
did start from a very different point, though.
-Kevin
>>> "Kevin Grittner" <[EMAIL PROTECTED]> >>>
It appears tha
On 11/15/05, Kevin Grittner <[EMAIL PROTECTED]> wrote:
Could my issue be the same problem as this thread?:http://archives.postgresql.org/pgsql-bugs/2005-11/msg00114.phpThe references to "Invalid Argument" caught my eye. That thread
did start from a very different point, though.-Kevin
It's possible
I am looking for advice on how best to configure logging from PostgreSQL
when it is run as a Windows service. Under Linux we allow it to log to
'stderr' and we use the pg_ctl -l switch to direct that to a file. This
doesn't seem to be supported under Windows, so I'm looking for "best
practices" a
I am having an extremely difficult time restoring the backup.gz I have
on my Desktop.
I just completed my installation of PG 8 on my Windows XP Home
notebook. I tried using PGAdminIII to do the Restore, but for some
reason it doesn't want to work.
So, I tried using PSQL, but I'm still not h
> I am looking for advice on how best to configure logging from
> PostgreSQL when it is run as a Windows service. Under Linux
> we allow it to log to 'stderr' and we use the pg_ctl -l
> switch to direct that to a file. This doesn't seem to be
> supported under Windows, so I'm looking for "bes
On Tue, 2005-11-15 at 12:16, [EMAIL PROTECTED] wrote:
> I am having an extremely difficult time restoring the backup.gz I have
> on my Desktop.
>
> I just completed my installation of PG 8 on my Windows XP Home
> notebook. I tried using PGAdminIII to do the Restore, but for some
> reason it do
>
> I reran the query. Same error, same relation, different block.
>
> dtr=> UPDATE
> dtr-> "DbTranRepository"
> dtr-> SET "userId" = UPPER("userId")
> dtr-> WHERE (
> dtr(> ("userId" <> UPPER("userId")) AND
> dtr(> ("timestampValue" BETWEEN '2005-10-28' AND '2005-11-15'));
> ERROR
The table has about 23.3 million rows, of which about 200,000 will
be affected by this update. Run time is about an hour. During the
first run, the table was the target of about 45,000 inserts. This rerun
was done as the only task. A third run (also by itself) gave this:
ERROR: could not read
Correction:
dtr=> select count(*) from "DbTranRepository"
dtr-> WHERE (
dtr(> ("userId" <> UPPER("userId")) AND
dtr(> ("timestampValue" BETWEEN '2005-10-28' AND '2005-11-15'));
count
611255
(1 row)
I'm becoming more convinced that this happens as the UPDATE
runs into rows inser
I got the error log working on Windows (with redirect_stderr). I had
to stop and restart postgres to do so. I ran the query (for the fourth
time), and it completed successfully.
I'm not inclined to believe that changing the redirect_stderr setting
would change this behavior, so I guess that eit
Hello all,
I was just wondering if anyone is using Steeleyes LifeKeeper for linux,
and if you had any feedback for my on its performance.
Thank you
Joshua O'Brien
---(end of broadcast)---
TIP 4: Have you searched our list archives?
If I have followed the chain correctly, I saw that you were trying to
run an update statement on a large number of records in a large table
right? I have changed my strategy in the past for this type of problem.
I don't know if it would have fixed this problem or not, but I have seen
with Postg
On Tue, 15 Nov 2005, Kevin Grittner wrote:
> I got the error log working on Windows (with redirect_stderr). I had
> to stop and restart postgres to do so. I ran the query (for the fourth
> time), and it completed successfully.
Strange - the phyiscal read for the 2nd, 3rd, 4th time should be t
"Kevin Grittner" <[EMAIL PROTECTED]> writes:
> ERROR: could not read block 1482762 of relation 1663/16385/16483:
> Invalid argument
> So the block number is increasing each time. I'm inclined to think
> that this is the result of the scan passing over rows added by itself.
It's just about impos
21 matches
Mail list logo
