Re: [BUGS] BUG #2042: Installation failed
Please don't remove the list from the recipients. Added back. > This was on my Windows XP. I never installed Postgresql > before on this computer. I do not know which account it was, since > > > >> Internal account lookup failure: No mapping between > > accound names and > > >> security IDs was done. > > was all it said. With this, I assume it used the account "postgres", because that's the default. The question that remains is did this account exist before you started, or not? //Magnus ---(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] VERIFIED FIXED: Huge query stalls at PARSE/BIND stage
Patch applied to version 8.1. Large query now runs in seconds. Thanks Tom. Regards, Matt Carter
Re: [BUGS] BUG #2052: Federal Agency Tech Hub Refuses to Accept
Tom Lane wrote: "Ferindo Middleton" <[EMAIL PROTECTED]> writes: This bug report involves more than one proposed bug. I work at a federal government agency. The information technology division at this agency refuses to allow the database version 8.0.4 on their network because of several security vulnerabilities they noticed when testing the software application. They obviously haven't "tested" anything --- they are merely reading the CVE reports for old Postgres versions. All known CVE problems are resolved in 8.0.4. (If they were actually serious about security, they wouldn't be letting you run Windows 2000 inside their network, but I digress.) regards, tom lane Thanks for your support with this. I had presented the IT support team at this agency with the information you all provided that these CVEs/bugs were resolved in previous versions to 8.0.4 and they suddenly argued that it wasn’t the CVE’s that were the problem (without admitting that they never really tested 8.0.4 in the first place)… I’m sorry if I wasted anybody’s time or irritated anyone by assuming that these bugs were actually valid in 8.0.4… I’m starting to get tied up in a bunch of bureaucratic tape dealing with these people. I think their just scared of having to deal with the support overhead they think they'll have to assume if they introduce another DBMS on their network… Thank you, Ferindo Middleton ---(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 #2063: Unsupported frontend protocol
The following bug has been logged online: Bug reference: 2063 Logged by: neeraj chaudhari Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0.4 Operating system: Red Hat linux 9.0 Description:Unsupported frontend protocol Details: Hi, i have recently installed postgresql 8.0.4 on my red hat linux 9.0 box, i have configured, make & installed successfully. The application server which i use is jboss-3.2.6. Now whenever i start my database server (postgresql 8.0.4) and then my application server, i receive the following messages on my database server:- [EMAIL PROTECTED] pgsql]$ ./setenv [EMAIL PROTECTED] pgsql]$ postmaster -D /usr/pgsql/data/ LOG: database system was shut down at 2005-11-22 11:39:34 IST LOG: checkpoint record is at 0/D9CF8C LOG: redo record is at 0/D9CF8C; undo record is at 0/0; shutdown TRUE LOG: next transaction id: 30928; next oid: 19697 LOG: database system is ready FATAL: unsupported frontend protocol FATAL: unsupported frontend protocol FATAL: unsupported frontend protocol FATAL: unsupported frontend protocol FATAL: unsupported frontend protocol Then to i am able to connect to the database & access & modify the records. regards, Neeraj ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2051: CREATE TEMP TABLE AS SELECT doesn't play nice
TODO has:
o Add ON COMMIT capability to CREATE TABLE AS ... SELECT
---
David Fetter wrote:
> On Thu, Nov 17, 2005 at 05:32:43PM -0500, Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > > On Thu, Nov 17, 2005 at 04:37:14PM -0500, Tom Lane wrote:
> > >> CREATE TEMP TABLE foo ... ON COMMIT DROP;
> >
> > > It's that first little elipsis mark that's the problem. Is there
> > > something really clever I've been missing on how to do a dynamic
> > > table creation?
> >
> > Oh, you're worried about what to do if you don't know the output
> > column set of the query? OK, that is a bit harder, but I think it's
> > still a corner case. How much are you really going to get done with
> > the table if you don't know what columns it has?
>
> My use case is when I have a system of audit tables that look like
> this:
>
> CREATE TABLE foo (
> ...
> );
>
> CREATE TABLE foo_audit (
> foo_audit_id BIGSERIAL PRIMARY KEY,
> foo_actor TEXT,
> foo_timestamp TIMESTAMP,
> foo_action char(1) CHECK foo_action IN('D','I','U'),
> old_foo foo,
> new_foo foo
> );
>
> with appropriate TRIGGERs, etc. to make that happen. It nice feature
> of being partitionable via constraint exclusion.
>
> This is in aid of a system for making it possible to ALTER foo while
> preserving the data in foo_audit.
>
> Cheers,
> D
> --
> David Fetter [EMAIL PROTECTED] http://fetter.org/
> phone: +1 510 893 6100 mobile: +1 415 235 3778
>
> Remember to vote!
>
> ---(end of broadcast)---
> TIP 3: Have you checked our extensive FAQ?
>
>http://www.postgresql.org/docs/faq
>
--
Bruce Momjian| http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [BUGS] BUG #2051: CREATE TEMP TABLE AS SELECT doesn't play nice with ON COMMIT DROP
On Tue, Nov 22, 2005 at 06:20:37PM -0500, Bruce Momjian wrote: > > TODO has: > > o Add ON COMMIT capability to CREATE TABLE AS ... SELECT Great :) Cheers, D -- David Fetter [EMAIL PROTECTED] http://fetter.org/ phone: +1 415 235 3778 Remember to vote! ---(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
Re: [BUGS] strange disappearence of postgres file
"Harald Armin Massa" <[EMAIL PROTECTED]> wrote > > 2005-11-21 09:45:50 ERROR: could not open relation 1663/17253/43471: No > such > file or directory > > My checking showed that... within directory data/base/17253 there is > indeed > no file named 43471; but ones named 43470,43472,43473 . > This may be not a direct step to solve the problem, but let's get some feelings first: Is 43471 a temp table? To find out this: "select relname, nspname from pg_class, pg_namespace where pg_namespace.oid=pg_class.relnamespace and relfilenode = 43471;" Regards, Qingqing ---(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
Re: [BUGS] BUG #2063: Unsupported frontend protocol
""neeraj chaudhari"" <[EMAIL PROTECTED]> wrote > > FATAL: unsupported frontend protocol > FATAL: unsupported frontend protocol > FATAL: unsupported frontend protocol > > Then to i am able to connect to the database & access & modify the > records. > It looks like your client guesses out the right frontend protocol version after several tries, then stick to this version and continue. But the strange thing is that you are using 8.0.4, why the fatal message is not with this format: "FATAL: unsupported frontend protocol %u.%u: server supports %u.0 to %u.%u" Regards, Qingqing ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] Patch to allow contrib/pgbench files to have blank lines
Folks,
Having blank lines in -f scripts was causing silent failures. This
fixes it, for some value of "fixes." If it's OK, please apply to 8.1
CURRENT and CVS TIP :)
Cheers,
D
--
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778
Remember to vote!
Index: contrib/pgbench/pgbench.c
===
RCS file: /projects/cvsroot/pgsql/contrib/pgbench/pgbench.c,v
retrieving revision 1.46
diff -c -r1.46 pgbench.c
*** contrib/pgbench/pgbench.c 22 Nov 2005 18:17:04 - 1.46
--- contrib/pgbench/pgbench.c 23 Nov 2005 02:41:42 -
***
*** 886,896
{
Command*commands;
! commands = process_commands(buf);
! if (commands == NULL)
! {
! fclose(fd);
! return false;
}
my_commands[lineno] = commands;
--- 886,902
{
Command*commands;
!
! if (strncmp(buf, "\n", 1) != 0) {
! commands = process_commands(buf);
! if (commands == NULL)
! {
! fclose(fd);
! return false;
! }
! } else {
! lineno++;
! continue;
}
my_commands[lineno] = commands;
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
[BUGS] BUG #2066: installer error: code 2755.
The following bug has been logged online: Bug reference: 2066 Logged by: apco Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: Windows XP with sp2 Description:installer error: code 2755. Details: Postgresql MUI wrapper: can't find specified device or file. error code 2755 ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] BUG #2065: Problem with language conversion in pg_dump
The following bug has been logged online: Bug reference: 2065 Logged by: Wim Audenaert Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.0.2 Operating system: Windows XP Description:Problem with language conversion in pg_dump Details: I have a database created with encoding UTF8 while I used SQL_ASCII for the installation of Postgres 8.1.0. When I try to do a pg_dump of my database, I get the following error message: pg_dump: SQL command failed pg_dump: Error message from server: ERROR: cache lookup failed for function 170 39 pg_dump: The command was: SELECT tableoid, oid, adnum, pg_catalog.pg_get_expr(ad bin, adrelid) AS adsrc FROM pg_catalog.pg_attrdef WHERE adrelid = '23268'::pg_ca talog.oid I looked for the function 17039 in the pg_proc table, and this function doesn't exist. It does exists in an older version of the database (8.0). I tried to use the encoding parameter in pg_dump, but without success. What can I do resolve this problem? ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[BUGS] BUG #2064: retrieving more the 6 columns from a table via c#
The following bug has been logged online: Bug reference: 2064 Logged by: tr Email address: [EMAIL PROTECTED] PostgreSQL version: 1.2.1 Operating system: windows Description:retrieving more the 6 columns from a table via c# Details: I'm trying to run a simple select * quary on a table which contains more then 6 columns. if i try this quary from the postgresql quary tool i have no problems but when i activate this quary from C# DataAdapter.Fill i only get the value of the first 6 columns and the others are null. i tried a quary with listting the columns names. i tried a quary with different columns order. the DataRow that i get as a result from the fill methode with that quary contains the actual number of columns but all the columns from the seven'th one has null as a value. ---(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 #2065: Problem with language conversion in pg_dump
"Wim Audenaert" <[EMAIL PROTECTED]> writes: > When I try to do a pg_dump of my database, I get the following error > message: > pg_dump: SQL command failed > pg_dump: Error message from server: ERROR: cache lookup failed for function > 17039 I'm not sure how you managed that, but I'm sure that it's entirely unrelated to the database's encoding. Do you still have the dump file that you used to move from 8.0 to 8.1? If so, what does it show as the declaration for this table? 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 #2065: Problem with language conversion in pg_dump
"Wim Audenaert" <[EMAIL PROTECTED]> writes: > When I create a new database, this function (oid 17039 and used for utf8 > translation) is not defined in the pg_proc table. I tried to create a new > database. The pg_proc table contains several functions, but not this one. Hmm, I see that utf8_to_tcvn() doesn't seem to be there anymore, but whether that's a bug in itself is for someone else to answer (Tatsuo?). What I'm wondering about is how a reference to a nonexistent function OID got into your new database. There is no case in which pg_dump should reference a function by OID. 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
[BUGS] Incorrect column identifer using AS in SELECT statement on a VIEW.
If I create a normal table and a normal view that queries that table I get incorrect results when I query the view using the AS alias in the select statement. For example, if I create the following objects: CREATE TABLE Test1( col1 VARCHAR(200) ); CREATE VIEW Test2 AS SELECT col1 FROM Test1 ORDER BY col1; then I do a SELECT col1 AS something FROM Test2; The column identifier comes back as "col1" instead of "something".
Re: [BUGS] strange disappearence of postgres file
Quingqing, no, it is definitely NOT a temp table. I know which table it is, because: that "could not open relation ..." error message was exactly provokable with "select * from repofeld", which is one of my tables in that database. (And that was the way it was passed on to me: my application put that error on screen) Harald -- GHUM Harald Massapersuasion python postgresqlHarald Armin MassaReinsburgstraße 202b70197 Stuttgart0173/9409607
Re: [BUGS] Incorrect column identifer using AS in SELECT statement on a VIEW.
Also forgot to mention that this only started occuring in PostgreSQL 8.1. Here is my SELECT version() output: version --- PostgreSQL 8.1.0 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.0.1 20050727 (Red Hat 4.0.1-5) On 11/23/05, Hayden James <[EMAIL PROTECTED]> wrote: If I create a normal table and a normal view that queries that table I get incorrect results when I query the view using the AS alias in the select statement. For example, if I create the following objects: CREATE TABLE Test1( col1 VARCHAR(200) ); CREATE VIEW Test2 AS SELECT col1 FROM Test1 ORDER BY col1; then I do a SELECT col1 AS something FROM Test2; The column identifier comes back as "col1" instead of "something".
