Re: [BUGS] Error on createuser
On Sun, Jun 18, 2006 at 07:38:13PM +0530, vinayak Desai wrote: > [EMAIL PROTECTED] ~]# createuser -a -d -e antonio > createuser: could not connect to database template1: FATAL: user "root" > does not exist This is not a bug. It's just that root is not a known database user. Typically there is an user postgres with full admin rights, so as root, do su - postgres and then try crateuser, etc. HTH -- toms signature.asc Description: Digital signature
Re: [BUGS] BUG #2489: Metadata dosen't match tables
James A Cole wrote: > mkeB_reports=# \d arrivals > Did not find any relation named "arrivals". > > mkeB_reports=# select * from arrivals where ontime>'2006-6-21'; > [data] > There are many other databases on this server. Most > do not have this problem. Ah, so this is the only one that has suffered transaction id wraparound. If you don't want to restore from backup, you may want to search the archives for old threads. Use keywords "transaction id wraparound" or maybe "xid wraparound". Next time you really want to make sure you vacuum the whole database, often. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] BUG #2487: Immutable functions results
"Pedro J. Romero" <[EMAIL PROTECTED]> writes: > Sorry if this not a bug, but I think so: This report is useless, since you have not shown us either function. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2489: Metadata dosen't match tables
"James A Cole" <[EMAIL PROTECTED]> writes: > mkeB_reports=# \d arrivals > Did not find any relation named "arrivals". > mkeB_reports=# select * from arrivals where ontime>'2006-6-21'; > [ works ] Looks like XID wraparound in the system catalogs. You can probably get out of it with a database-wide VACUUM, but there is some risk that you've lost data. Please read the administrator's guide part of the manual concerning routine vacuuming requirements. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] BUG #2490: '||' and type casting for user defined types
The following bug has been logged online:
Bug reference: 2490
Logged by: Nikolay Samokhvalov
Email address: [EMAIL PROTECTED]
PostgreSQL version: CVS
Operating system: fedora core 5
Description:'||' and type casting for user defined types
Details:
Assume that we are creating foolish type 'aaa', which works like
varchar(3),
or is simply 'string, which length is not more than 3'.
In/out functions for this type:
Datum
aaa_in(PG_FUNCTION_ARGS)
{
char*s = PG_GETARG_CSTRING(0);
int len = strlen(s);
VarChar *result;
if (len > 3)
ereport(ERROR,
(errcode(ERRCODE_EXTERNAL_ROUTINE_EXCEPTION),
errmsg("too much chars: length=\"%d\"",
len)));
result = (VarChar *) palloc(len + VARHDRSZ);
VARATT_SIZEP(result) = len + VARHDRSZ;
memcpy(VARDATA(result), s, len);
PG_RETURN_VARCHAR_P(result);
}
Datum
aaa_out(PG_FUNCTION_ARGS)
{
VarChar *s = PG_GETARG_VARCHAR_P(0);
char*result;
int32 len;
/* copy and add null term */
len = VARSIZE(s) - VARHDRSZ;
result = palloc(len + 1);
memcpy(result, VARDATA(s), len);
result[len] = '\0';
PG_RETURN_CSTRING(result);
}
SQL code:
CREATE FUNCTION aaa_in(cstring)
RETURNS aaa
AS 'MODULE_PATHNAME'
LANGUAGE C RETURNS NULL ON NULL INPUT;
CREATE FUNCTION aaa_out(aaa)
RETURNS cstring
AS 'MODULE_PATHNAME'
LANGUAGE C RETURNS NULL ON NULL INPUT;
CREATE TYPE aaa (
INTERNALLENGTH = -1,
INPUT = aaa_in,
OUTPUT = aaa_out,
STORAGE = extended
);
CREATE CAST (aaa AS text) WITHOUT FUNCTION
AS IMPLICIT;
CREATE CAST (text AS aaa) WITHOUT FUNCTION
AS IMPLICIT;
Well, let's do some tests. After applying sql code in the database 'trash':
trash=# select 'asd'::aaa;
aaa
-
asd
(1 row)
trash=# select 'asdf'::aaa;
ERROR: too much chars: length="4"
trash=# select ('as' || 'df')::aaa;
aaa
--
asdf
(1 row)
In the last case, function aaa_in() wasn't invoked at all and we obtained
the sting of type aaa with length > 3...
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [BUGS] Error on createuser
On Sun, Jun 18, 2006 at 07:38:13PM +0530, vinayak Desai wrote: > [EMAIL PROTECTED] ~]# createuser -a -d -e antonio > createuser: could not connect to database template1: FATAL: user "root" > does not exist > [EMAIL PROTECTED] ~]# > > i logged in as root.. > I tried to create a new user i am getting this error message... > Kindly look in to this matter. > root is not automatically permitted to do so. you might want to read up the permission part of the manual. try as the user owning the cluster (on my system that is postmaster) su postmaster -- createuser regs, klaus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2490: '||' and type casting for user defined types
"Nikolay Samokhvalov" <[EMAIL PROTECTED]> writes:
> CREATE CAST (aaa AS text) WITHOUT FUNCTION
> AS IMPLICIT;
> CREATE CAST (text AS aaa) WITHOUT FUNCTION
> AS IMPLICIT;
> trash=# select ('as' || 'df')::aaa;
> aaa
> --
> asdf
> (1 row)
> In the last case, function aaa_in() wasn't invoked at all and we obtained
> the sting of type aaa with length > 3...
Well, sure. You declared the text to aaa cast as WITHOUT FUNCTION; that
says the system can relabel any legal text value as an aaa. If you want
to enforce a length limit on the cast result, you need to write a cast
function that does it.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [BUGS] BUG #2488: backup history file is archived doubly
"Masao Fujii" <[EMAIL PROTECTED]> writes: > The cause of the problem is that pg_stop_backup creates two *.ready files. > One file is created by pg_stop_backup > RemoveOldBackupHistory > > XLogArchiveIsDone > XLogArchiveNotify. > Another is created by pg_stop_backup > XLogArchiveNotify. Oooh, good catch. The cleanest solution would be to modify RemoveOldBackupHistory so that it explicitly skips the current entry. But I'm strongly tempted to just remove the code in pg_stop_backup, and document that RemoveOldBackupHistory gets the job done (perhaps renaming it). regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2486: PANIC when CTRL-C on vacuum full analyze
"Ronald" <[EMAIL PROTECTED]> writes: > Description:PANIC when CTRL-C on vacuum full analyze I think we've seen this reported once before. You'd need to hit the window where VACUUM FULL has committed its transaction but is still busy cleaning indexes. Having moved a whole lot of rows would contribute to making that window wider ... I haven't looked into a fix but I imagine the best thing would be to start a real second transaction for the cleanup phase. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
