Re: [BUGS] Huge number of disk writes after migration to 8.1
> Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Maybe the fact that the stat file is completely rewritten > every 500 ms > > should be reconsidered, if in the future someone chooses to rewrite > > the stat system. We can reconsider this part then, as well. > > Yeah, it's becoming pretty obvious that that design does not > scale very well. I don't immediately have any ideas about a > better way though. > > I am working on some marginal hacks like not writing more of > the backend activity strings than is needed, but it'd be > nicer to think of a different solution. In most cases you're going to see extremely few reads compared to writes on pg_stats, right? So why not have the backends connect to the stats process (or perhaps use UDP, or use the pipe, or whatever) and fetch the data when needed. So when nobody fetches any data, there is no overhead (except for the stats process adding up values, of course). Then you could also push down some filtering to the stats process - for example, when you are reading from pg_stat_activity there is no need to send over the row level stats. IIRC, today you have to read (and write) the whole stats file anyways. //Magnus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] Huge number of disk writes after migration to 8.1
On Jan 19, 2006, at 06:51, Magnus Hagander wrote: In most cases you're going to see extremely few reads compared to writes on pg_stats, right? So why not have the backends connect to the stats process (or perhaps use UDP, or use the pipe, or whatever) and fetch the data when needed. So when nobody fetches any data, there is no overhead (except for the stats process adding up values, of course). Do the stats need to persist across postmaster restarts (or crashes)? If so, then they need to be written to disk at some point, so we can't get rid of the stats file and the frequent writes to it. Or maybe there could be a GUC setting for persisting stats -- if it's enabled, it works as implemented today (flushed to disk every 500ms). If it's disabled, the stats are only stored in-memory and never written to a file; the postmaster could automatically do an "ANALYZE" on startup to fill the in-memory stats. We could move the stat file writes to happen only at a checkpoint. Backends would get up-to-date info directly from the stats process as you described, but it would always be persisted at a checkpoint. Those *should* be less-frequent than every half a second. :) - Chris smime.p7s Description: S/MIME cryptographic signature
Re: [BUGS] Huge number of disk writes after migration to 8.1
Chris Campbell wrote: > On Jan 19, 2006, at 06:51, Magnus Hagander wrote: > > >In most cases you're going to see extremely few reads compared to > >writes > >on pg_stats, right? So why not have the backends connect to the stats > >process (or perhaps use UDP, or use the pipe, or whatever) and > >fetch the > >data when needed. So when nobody fetches any data, there is no > >overhead > >(except for the stats process adding up values, of course). > > Do the stats need to persist across postmaster restarts (or crashes)? After a crash we forcibly _delete_ the stat file. OTOH, on clean shutdown it would be quite possible to write it (which would be the only time at which the file is written). -- Alvaro Herrerahttp://www.advogato.org/person/alvherre Licensee shall have no right to use the Licensed Software for productive or commercial use. (Licencia de StarOffice 6.0 beta) ---(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] Huge number of disk writes after migration to 8.1
"Magnus Hagander" <[EMAIL PROTECTED]> writes: > In most cases you're going to see extremely few reads compared to writes > on pg_stats, right? So why not have the backends connect to the stats > process (or perhaps use UDP, or use the pipe, or whatever) and fetch the > data when needed. So when nobody fetches any data, there is no overhead > (except for the stats process adding up values, of course). That's a thought. You'd still want the stats file to preserve the data across shutdowns, but the update rate could be far slower, maybe once every few minutes. The other nice thing is that when you do want the stats, you could get current values, not half-a-second-behind values. > Then you could also push down some filtering to the stats process - for > example, when you are reading from pg_stat_activity there is no need to > send over the row level stats. IIRC, today you have to read (and write) > the whole stats file anyways. No; the current behavior of grabbing a snapshot of the whole stats dataset is a feature, not a bug. It lets you sit there and correlate the data using multiple queries, without worrying that the numbers are changing under you. We'd lose this ability if the data had to be re-fetched for each query because we didn't grab it all. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] Execution of stored procedures
Sundaramoorthy, Annapoorani (Cognizant) wrote: Microsoft OLE DB Provider for ODBC Drivers (0x80004005) Error while executing the query; ERROR: SELECT query has no destination for result data HINT: If you want to discard the results, use PERFORM instead. This error is associated with the execution of stored procedure. Select ; Is the way in which I am trying to execute the procedure in pgadmin and also this is the way in which I am using it in the asp file. If it gives you the same error from pgadmin then it's clearly not an ODBC error. The error message suggests to me that the problem is in the function itself where you may be executing a SELECT without putting its results into a variable. You would probably get more answers on the plpgsql-general list. This mailing list is for bugs in the PostgreSQL server itself. See you there! -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] Huge number of disk writes after migration to 8.1
> > In most cases you're going to see extremely few reads compared to > > writes on pg_stats, right? So why not have the backends > connect to the > > stats process (or perhaps use UDP, or use the pipe, or > whatever) and > > fetch the data when needed. So when nobody fetches any > data, there is > > no overhead (except for the stats process adding up values, > of course). > > That's a thought. You'd still want the stats file to > preserve the data across shutdowns, but the update rate could > be far slower, maybe once every few minutes. The other nice > thing is that when you do want the stats, you could get > current values, not half-a-second-behind values. Exactly. For those who care a lot about their stats data, we could offer a config parameter for how often to write out the stats file. > > Then you could also push down some filtering to the stats process - > > for example, when you are reading from pg_stat_activity there is no > > need to send over the row level stats. IIRC, today you have to read > > (and write) the whole stats file anyways. > > No; the current behavior of grabbing a snapshot of the whole > stats dataset is a feature, not a bug. It lets you sit there > and correlate the data using multiple queries, without > worrying that the numbers are changing under you. We'd lose > this ability if the data had to be re-fetched for each query > because we didn't grab it all. Oh. Good point. Didn't even know we had that feature, but now that I do I see it's a good one :-) //Magnus ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Huge number of disk writes after migration to 8.1
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Chris Campbell wrote: >> Do the stats need to persist across postmaster restarts (or crashes)? > After a crash we forcibly _delete_ the stat file. I'm not sure why, though --- the writing technique seems fairly safe, and in any case the reader checks what it's reading. Maybe we shouldn't throw away the old stats. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2176: Pgadmin III not honoring DATESTYLE
The following bug has been logged online: Bug reference: 2176 Logged by: Francisco Leovey Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2 Operating system: Linux Description:Pgadmin III not honoring DATESTYLE Details: By default in postgresql.conf the DATESTYLE is set to "SQL,European" and it works OK except for Pgadmin III. When you ask for "view data" in Pgadmin III a date field shows -mm-dd instead of dd/mm/ Please tell me how to fix this Thank you ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2178: NOT IN command don't work
The following bug has been logged online: Bug reference: 2178 Logged by: Daniel Afonso Heisler Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.X Operating system: Linux Description:NOT IN command don't work Details: When i run the following query, postgreSQL return TRUE. # SELECT true WHERE 1 NOT IN (2,3); But, when i run the next query, it don't return TRUE # SELECT true WHERE 1 NOT IN (2,NULL,3); In theory, that is not correctly. The operator IN work with normally. See the next example: # SELECT true WHERE 1 IN (1,2,NULL,3); ---(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 #2168: 45.000.000 records too much?
Some additional info. We repeated the test on different hardware with unfortunately the same result. This is the output of the postgresql logfile of that experiment: LOG: background writer process (PID 8208) was terminated by signal 9 LOG: terminating any other active server processes LOG: statistics collector process (PID 8209) was terminated by signal 9 LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2006-01-18 11:25:34 CET LOG: checkpoint record is at 3/AE5CF484 LOG: redo record is at 3/AE5CB388; undo record is at 0/0; shutdown FALSE LOG: next transaction ID: 10061; next OID: 25648 LOG: database system was not properly shut down; automatic recovery in progress LOG: redo starts at 3/AE5CB388 LOG: record with zero length at 3/AE5E7314 LOG: redo done at 3/AE5E72D0 LOG: database system is ready This time we tested with postgresql 8.0.3 on a 2.6.12 linux kernel. (Previously i tested with postgresql 7.4.9 on a 2.6.15 kernel.) I think you will be able to repeat the experiment with this information. Regards, Steven ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2183: Cannot enter Paragraph Type data
The following bug has been logged online: Bug reference: 2183 Logged by: varun bhasin Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows Xp SP-1 Description:Cannot enter Paragraph Type data Details: I am trying to input a Resume in the database. I have tried using text,varchar datatypes but it shows the whole resume as a single word. I am using JDBC to retreive the data and display using JSP. Kindly help as soon as possible. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2168: 45.000.000 records too much?
Tom Lane wrote: "Steven Mooij" <[EMAIL PROTECTED]> writes: testsearch=> insert into t_documentword2 (SELECT document_id, t_word2.id, frequency from t_documentword, t_word2 where t_documentword.word = t_word2.word); server closed the connection unexpectedly There's not enough information here to guess what the problem is. (But it's not table size; people routinely manipulate tables much bigger than that in Postgres.) A stack trace from the core dump would be really helpful, or even better a self-contained test case that other people could replicate the failure with. See the bug reporting guidelines at http://www.postgresql.org/docs/8.1/static/bug-reporting.html I created a self-contained test case, here's a script that produces a similar error: CREATETABLE t_test1 ( xbigint, ybigint, PRIMARY KEY(x) ) WITHOUT OIDS; CREATETABLE t_test2 ( xbigint, zbigint, PRIMARY KEY (x), FOREIGN KEY (x) REFERENCES t_test1(x) ) WITHOUT OIDS; INSERT INTO t_test1 VALUES (1, 2); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test1 (SELECT x + (SELECT count(*) FROM t_test1), y + (SELECT count(*) FROM t_test1) FROM t_test1); INSERT INTO t_test2 (SELECT x, x * 2 FROM t_test1); The first block of inserts completes flawlessly and fills t_test1 with over 64.000.000 records. It's the last statement copying (no join involved this time) from t_test1 to t_test2 that results in: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. I am not 100% sure, but i think this is the relevant part of the logfile that goes with it: LOG: database system was interrupted at 2006-01-18 00:07:48 CET LOG: checkpoint record is at B/A2857768 LOG: redo record is at B/A28535B0; undo record is at 0/0; shutdown FALSE LOG: next transaction ID: 2724; next OID: 75506450 LOG: database system was not properly shut down; automatic recovery in progressLOG: incomplete startup packet LOG: red
[BUGS] BUG #2177: (minor:) pgsql: Trailing semicolon on \d treated as argument
The following bug has been logged online: Bug reference: 2177 Logged by: Giles Morant Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.1 Operating system: Linux (Gentoo) Description:(minor:) pgsql: Trailing semicolon on \d treated as argument Details: When describing tables/view/indexes using \d, a semi-colon is optional: e.g. \d users; or: \d users Both give the same (correct) results. However, if there is a space between "users" and the semi-colon, the semi-colon is then treated as an argument and this occurs: \d users ; \d: extra argument ";" ignored The semi-colon should be ignored silently, in my view- "SELECT 1+2 ;" for example doesn't raise an alert. I searched the mailing lists to find a previous report of this very minor bug; the closest I found was some discussion in 2001 of stripping semi-colons from the end of such strings but the discussion seemed to stop with no resolution. http://archives.postgresql.org/pgsql-patches/2001-09/msg00285.php Fri, 28 Sep 2001 15:56:07 -0400 (EDT) Thanks, Giles Morant. ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2180: log_statement=mod does not work
The following bug has been logged online: Bug reference: 2180 Logged by: Gilles Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.0 Operating system: Linux RedHat ES3 Description:log_statement=mod does not work Details: When I configure in the file postgresql.conf: log_statement=mod I don't have the update, delete, insert queries logged like it says in the documentation : http://www.postgresql.org/docs/8.1/interactive/runtime-config-logging.html Could you tell me, what I need to do to get these queries logged? Thanks Gilles ---(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] BUG #2179: psql can't show chinese
The following bug has been logged online: Bug reference: 2179 Logged by: stephanie Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2 Operating system: windows2000professional Description:psql can't show chinese Details: The database encoding is EUC_CN. The query tool pgadmin provide can show Chinese. psql can't show chinese whether I use set client_encoding='unicode'. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[BUGS] contrib/adddepend failed 8.1.2
Hi.
I was trying to upgrade PostgreSQL from 7.2.8 to 8.1.2.
Dump and restore work well. But adddepend was failed.
To fix it, this regexp
$seq =~ s|^nextval\(["']+([^'"\)]+)["']+.*\)$|$1|g;
need to change
$seq =~ s|^nextval\(\(["']+([^'"\)]+)["']+.*\)$|$1|g;
or
$seq =~ s|^nextval\(\(?["']+([^'"\)]+)["']+.*\)$|$1|g;
[EMAIL PROTECTED] adddepend]$ ./adddepend -Y -d ishida
Upgrade the Unique Constraint style via:
DROP INDEX t_i_key RESTRICT;
ALTER TABLE t ADD CONSTRAINT t_i_key UNIQUE (i);
NOTICE: ALTER TABLE / ADD UNIQUE will create implicit index "t_i_key"
for table "t"
Do you wish to upgrade Sequence 'nextval(('"t_i_seq"'::text)::regclass)'
to SERIAL?
Found on column t.i
DBD::Pg::st execute failed: ERROR: syntax error at or near ""t_i_seq""
at character 790 at ./adddepend line 539.
logfile
ERROR: syntax error at or near ""t_i_seq"" at character 790
STATEMENT:
INSERT INTO pg_catalog.pg_depend
( classid
, objid
, objsubid
, refclassid
, refobjid
, refobjsubid
, deptype
) VALUES ( (SELECT c.oid--
classid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
WHERE n.nspname = 'pg_catalog'
AND c.relname = 'pg_class')
, (SELECT c.oid-- objid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
WHERE n.nspname = 'public'
AND c.relname =
'nextval(('"t_i_seq"'::text)::regclass)')
, 0--
objsubid
, (SELECT c.oid--
refclassid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
WHERE n.nspname = 'pg_catalog'
AND c.relname = 'pg_class')
, (SELECT c.oid--
refobjid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
WHERE n.nspname = 'public'
AND c.relname = 't')
, (SELECT a.attnum --
refobjsubid
FROM pg_class as c
JOIN pg_namespace as n
ON (n.oid =
c.relnamespace)
JOIN pg_attribute as a
ON (a.attrelid = c.oid)
WHERE n.nspname = 'public'
AND c.relname = 't'
AND a.attname = 'i')
, 'i' --
deptype
);
--
ISHIDA Akio <[EMAIL PROTECTED] / [EMAIL PROTECTED]>
*** ./contrib/adddepend/adddepend.orig 2003-11-30 07:39:16.0 +0900
--- ./contrib/adddepend/adddepend 2006-01-18 00:46:32.0 +0900
***
*** 469,475
my $seq = $row->{'adsrc'};
# Extract the sequence name from the default
! $seq =~ s|^nextval\(["']+([^'"\)]+)["']+.*\)$|$1|g;
# Does the user want to upgrade this sequence?
print <{'adsrc'};
# Extract the sequence name from the default
! $seq =~ s|^nextval\(\(["']+([^'"\)]+)["']+.*\)$|$1|g;
# Does the user want to upgrade this sequence?
print <
---(end of broadcast)--
[BUGS] BUG #2185: function compilation error with "Create [TEMP] table?
The following bug has been logged online: Bug reference: 2185 Logged by: marc mamin Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: DB Server: Linux Client: windows XP Description:function compilation error with "Create [TEMP] table? Details: within a function, when I: - use create temp table , - do anyting with this table - drop that table, The first call to that function works, but further calls fail. Rebuilding the function before each call fix the issue. I guess that the function is not yet compiled at the first call, and that further calls use a compiled version Cheers, Marc Here the steps to repeat the bug: - CREATE OR REPLACE FUNCTION bugtest() RETURNS int AS $BODY$ BEGIN create temp table bugt(i int); insert into bugt values(1); drop table bugt; RETURN 0; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; select bugtest(); -->0 select bugtest(); -->ERROR: relation with OID 52284 does not exist -->CONTEXT: SQL statement "insert into bugt values(1)" -->PL/pgSQL function "bugtest" line 9 at SQL statement ---(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 #2184: Insertion problem
The following bug has been logged online: Bug reference: 2184 Logged by: Surya Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: Windows-2003 Server Description:Insertion problem Details: There is a problem when inserting a single quote in the database. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[BUGS] BUG #2181: Bug in SQLNumResultCols
The following bug has been logged online: Bug reference: 2181 Logged by: Thomas Goerner Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1 Operating system: WinXP Description:Bug in SQLNumResultCols Details: calling SQLNumResultCols on a hstmt that has been executed previously and then closed using SQLFreeStmt(m_hstmt, SQL_CLOSE) (MFC's CRecordset::Requery() does this) re-executes the statement. ODBC driver version is 8.01.01.02. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[BUGS] BUG #2182: Internal account lookup failure:
The following bug has been logged online: Bug reference: 2182 Logged by: Anantha Prasad Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2-1 Operating system: Win2000 Prof Description:Internal account lookup failure: Details: I had not installed PostGreSQL on this computer before. When I use the installer, it gives the foll. message and rolls back the installation. "Internal account lookup failure: No mapping between account names and security IDs was done." Tried with other user names etc. but cannot proceed. ---(end of broadcast)--- TIP 6: explain analyze is your friend
[BUGS] BUG #2186: syntax error in postgresql.conf
The following bug has been logged online: Bug reference: 2186 Logged by: Alexander Yeliseyev Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1.2 Operating system: SuSe Linux 9.2 Description:syntax error in postgresql.conf Details: [EMAIL PROTECTED]:~> ./pgSQL.boot [EMAIL PROTECTED]:~> cat server.log FATAL: syntax error in file "/Data/postgresql.conf" line 48, near token "," [EMAIL PROTECTED]:~> the line 48 in postgresql.conf is: listen_addresses = 'eth0','localhost' # what IP address(es) to listen on; # comma-separated list of addresses; # defaults to 'localhost', '*' = all I can not understand, and it is not clear written in documentation, what is the right syntax to configure PgSQL to listen connections from 192.168.15.0/24 network only. It always returns error and does not starts up, just only writes this FATAL error in *.log file. And I have configured it to listen from 'eth0' and just have added 'localhost' after comma, I have received this error again. ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2186: syntax error in postgresql.conf
Alexander Yeliseyev wrote: > > The following bug has been logged online: > > Bug reference: 2186 > Logged by: Alexander Yeliseyev > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.2 > Operating system: SuSe Linux 9.2 > Description:syntax error in postgresql.conf > Details: > > [EMAIL PROTECTED]:~> ./pgSQL.boot > [EMAIL PROTECTED]:~> cat server.log > FATAL: syntax error in file "/Data/postgresql.conf" line 48, near token > "," > [EMAIL PROTECTED]:~> > > the line 48 in postgresql.conf is: > listen_addresses = 'eth0','localhost' > # what IP address(es) to listen on; > # comma-separated list of > addresses; > # defaults to 'localhost', '*' = > all > > I can not understand, and it is not clear written in documentation, what is > the right syntax to configure PgSQL to listen connections from > 192.168.15.0/24 network only. It always returns error and does not starts > up, just only writes this FATAL error in *.log file. And I have configured > it to listen from 'eth0' and just have added 'localhost' after comma, I have > received this error again. Use 'eth0, localhost', meaning put the comma inside the quotes. -- 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 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 #2182: Internal account lookup failure:
Anantha Prasad wrote: > > The following bug has been logged online: > > Bug reference: 2182 > Logged by: Anantha Prasad > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.2-1 > Operating system: Win2000 Prof > Description:Internal account lookup failure: > Details: > > I had not installed PostGreSQL on this computer before. When I use the > installer, it gives the foll. message and rolls back the installation. > > "Internal account lookup failure: No mapping between account names and > security IDs was done." > > Tried with other user names etc. but cannot proceed. No idea --- that isn't our error message. -- 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 #2177: (minor:) pgsql: Trailing semicolon on \d treated
We can't just throw away semicolons, e.g.: \test=> \f ; Field separator is ";". The current behavior seems pretty good. It doesn't seem worth improving. --- Giles Morant wrote: > > The following bug has been logged online: > > Bug reference: 2177 > Logged by: Giles Morant > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.1 > Operating system: Linux (Gentoo) > Description:(minor:) pgsql: Trailing semicolon on \d treated as > argument > Details: > > When describing tables/view/indexes using \d, a semi-colon is optional: > e.g. \d users; > or: \d users > Both give the same (correct) results. > > However, if there is a space between "users" and the semi-colon, the > semi-colon is then treated as an argument and this occurs: >\d users ; > >\d: extra argument ";" ignored > > The semi-colon should be ignored silently, in my view- "SELECT 1+2 ;" for > example doesn't raise an alert. > > I searched the mailing lists to find a previous report of this very minor > bug; the closest I found was some discussion in 2001 of stripping > semi-colons from the end of such strings but the discussion seemed to stop > with no resolution. > > http://archives.postgresql.org/pgsql-patches/2001-09/msg00285.php > Fri, 28 Sep 2001 15:56:07 -0400 (EDT) > > Thanks, > Giles Morant. > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend > -- 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 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 #2180: log_statement=mod does not work
On Wed, Jan 18, 2006 at 03:38:17PM +, Gilles wrote: > When I configure in the file postgresql.conf: > log_statement=mod > I don't have the update, delete, insert queries logged like it says in the > documentation : > http://www.postgresql.org/docs/8.1/interactive/runtime-config-logging.html > > Could you tell me, what I need to do to get these queries logged? Works here. Did you restart or reload the server after making the change? Are you sure you changed the right postgresql.conf (this can be a problem if you have multiple versions of PostgreSQL installed)? What does "SHOW log_statement" show? Are you sure you're looking in the right log file? Do you see other log entries? -- Michael Fuhr ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2183: Cannot enter Paragraph Type data
varun bhasin wrote: > > The following bug has been logged online: > > Bug reference: 2183 > Logged by: varun bhasin > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: Windows Xp SP-1 > Description:Cannot enter Paragraph Type data > Details: > > I am trying to input a Resume in the database. I have tried using > text,varchar datatypes but it shows the whole resume as a single word. > > I am using JDBC to retreive the data and display using JSP. I think you need to ask the jdbc email list about this. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2178: NOT IN command don't work
On Tue, 17 Jan 2006, Daniel Afonso Heisler wrote: > > The following bug has been logged online: > > Bug reference: 2178 > Logged by: Daniel Afonso Heisler > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1.X > Operating system: Linux > Description:NOT IN command don't work > Details: > > When i run the following query, postgreSQL return TRUE. > # SELECT true WHERE 1 NOT IN (2,3); > > But, when i run the next query, it don't return TRUE > # SELECT true WHERE 1 NOT IN (2,NULL,3); This is not a bug, and the above is correct by spec. select 1 in (NULL,2,3) is null; - t select 1 not in (NULL,2,3) is null - t IIRC, the short form is: a NOT IN b => NOT (a IN b) => NOT (a = ANY b) a = ANY b returns true if a=b returns true for any value in b a = ANY b returns false if a=b returns false for every value in b a = ANY b returns NULL otherwise 1 = 2 returns false 1 = NULL returns NULL 1 = 3 returns false 1 IN (2, NULL, 3) = NULL NOT (1 IN (2,NULL,3)) = NULL 1 NOT IN (2,NULL,3) = NULL ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2185: function compilation error with "Create [TEMP] table?
On 1/19/06, marc mamin <[EMAIL PROTECTED]> wrote: > > The following bug has been logged online: > > Bug reference: 2185 > Logged by: marc mamin > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1 > Operating system: DB Server: Linux Client: windows XP > Description:function compilation error with "Create [TEMP] table? > Details: > > within a function, when I: > - use create temp table , > - do anyting with this table > - drop that table, > > The first call to that function works, but further calls fail. Rebuilding > the function before each call fix the issue. > I guess that the function is not yet compiled at the first call, and that > further calls use a compiled version > > Cheers, Marc > > Here the steps to repeat the bug: > - > > CREATE OR REPLACE FUNCTION bugtest() > RETURNS int AS > $BODY$ > > > BEGIN > > > create temp table bugt(i int); > insert into bugt values(1); > drop table bugt; > > > RETURN 0; > > > END; > $BODY$ > LANGUAGE 'plpgsql' VOLATILE; > > > select bugtest(); > -->0 > select bugtest(); > -->ERROR: relation with OID 52284 does not exist > -->CONTEXT: SQL statement "insert into bugt values(1)" > -->PL/pgSQL function "bugtest" line 9 at SQL statement > that is a known issue, do it this way CREATE OR REPLACE FUNCTION bugtest() RETURNS int AS $BODY$ BEGIN execute 'create temp table bugt(i int)'; execute 'insert into bugt values(1)'; execute 'drop table bugt'; RETURN 0; END; $BODY$ LANGUAGE 'plpgsql' VOLATILE; -- regards, Jaime Casanova (DBA: DataBase Aniquilator ;) ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] BUG #2184: Insertion problem
Surya wrote: > > The following bug has been logged online: > > Bug reference: 2184 > Logged by: Surya > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.0 > Operating system: Windows-2003 Server > Description:Insertion problem > Details: > > There is a problem when inserting a single quote in the database. Use two single-quotes to insert a single-quote: 'I took it''s money' -- 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 2: Don't 'kill -9' the postmaster
Re: [BUGS] BUG #2180: log_statement=mod does not work
"Gilles" <[EMAIL PROTECTED]> writes: > When I configure in the file postgresql.conf: > log_statement=mod > I don't have the update, delete, insert queries logged like it says in the > documentation : > http://www.postgresql.org/docs/8.1/interactive/runtime-config-logging.html Did you remember to do "pg_ctl reload" (or kill -HUP the postmaster) after changing the config file? Perhaps you neglected to remove the # comment marker from that line in the file? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2178: NOT IN command don't work
On Tue, Jan 17, 2006 at 10:00:28PM +, Daniel Afonso Heisler wrote: > When i run the following query, postgreSQL return TRUE. > # SELECT true WHERE 1 NOT IN (2,3); > > But, when i run the next query, it don't return TRUE > # SELECT true WHERE 1 NOT IN (2,NULL,3); The expression "1 NOT IN (2,NULL,3)" evaluates to NULL because NULL means "unknown." This comes up occasionally; see the archives for past discussion. http://archives.postgresql.org/pgsql-sql/2005-12/msg00219.php http://archives.postgresql.org/pgsql-sql/2005-10/msg00227.php -- Michael Fuhr ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2000: psql does not prompt for password
Duncan, do you have answers to any of these questions? --- Magnus Hagander wrote: > Wow, that's really weird :-) > > Do you have any pgpass.conf anywhere? Either on the local disk or on the > network drive in question? Please do a search for it. > > If not, can you also check if you by any chance have more than one > libpq.dll installed, in different location? And if sho, which versions > these are? > > And finally, is this the pginstaller installed version, or something > else? > > //Magnus > > > > -Original Message- > > From: [EMAIL PROTECTED] > > Sent: Thursday, December 22, 2005 7:14 PM > > To: pgsql-bugs@postgresql.org > > Subject: Re: [BUGS] BUG #2000: psql does not prompt for password > > > > I just installed the 8.1.1 release on Windows XP Pro and > > encountered a very strange problem that seems to be related > > to your problem. My pg_hba.conf is the default > > out-of-the-box config (i.e local IPv4 connections are > > configured as: host all all 127.0.0.1/32 md5). I tried > > running psql from different shells, cmd.exe and 4NT, as well > > as using the shortcut to cmd.exe installed by the PostgreSQL > > installer. In some cases I was prompted for a password, but > > in other cases, psql would not prompt me, even if I tried to > > force it with -W. > > After several hours of testing different login users and > > pg_hba.conf entries I stumbled upon this discovery: the shell > > doesn't matter, your current directory does (see the > > transcript below). If you are currently in a directory on a > > local hard drive such as C:, authentication always fails, but > > if you are currently on a network drive, in my case H:, > > password prompting always occurs as documented. > > Prompting also occurs correctly if the drive is local but you > > are mounting it as if it were a network drive (for reasons I > > won't go into, my D: and E: drives are "network" mounts of > > subdirectories on C:). > > Here is a sample session in cmd.exe: > > > > -- > > > > > > Microsoft Windows XP [Version 5.1.2600] > > (C) Copyright 1985-2001 Microsoft Corp. > > > > H:\>c: > > > > C:\>psql > > psql: FATAL: password authentication failed for user "dhg0417" > > > > C:\>psql -W > > psql: FATAL: password authentication failed for user "dhg0417" > > > > C:\>h: > > > > H:\>psql > > Password: > > Welcome to psql 8.1.1, the PostgreSQL interactive terminal. > > > > Type: \copyright for distribution terms > >\h for help with SQL commands > >\? for help with psql commands > >\g or terminate with semicolon to execute query > >\q to quit > > > > Warning: Console code page (437) differs from Windows code page (1252) > > 8-bit characters may not work correctly. See psql reference > > page "Notes for Windows users" for details. > > > > dhg0417=> \q > > > > H:\>d: > > > > D:\>psql > > Password: > > Welcome to psql 8.1.1, the PostgreSQL interactive terminal. > > > > Type: \copyright for distribution terms > >\h for help with SQL commands > >\? for help with psql commands > >\g or terminate with semicolon to execute query > >\q to quit > > > > Warning: Console code page (437) differs from Windows code page (1252) > > 8-bit characters may not work correctly. See psql reference > > page "Notes for Windows users" for details. > > > > dhg0417=> > > > > -- > > - > > > > My guess is that psql treats requests while logged in to a > > network drive as "network" connections, while requests from > > the C: drive seem to be treated as "local" connections. > > Should I submit this as a bug or is this known behaviour? > > > > > > Bruce Momjian wrote: > > > Mike Grant wrote: > > > > I get the same thing with 8.0.4, on Windows XP Professional. > > > > > > I am still confused. I tried 'psql -W test' in the mingw shell > > > window, and in a 'cmd.exe' window, and both prompted me for a > > > password. I even tried a command.com window. > > > > > > Are you using a Cygwin window perhaps? > > > > > > > > -- > > > - > > > > > > > > > > > > > > ~Mike > > > > > > > > Bruce Momjian wrote: > > > > > Todd wrote: > > > > > > > > > > > > The following bug has been logged online: > > > > > > > > > > > > Bug reference: 2000 > > > > > > Logged by: Todd > > > > > > Email address: [EMAIL PROTECTED] > > > > > > PostgreSQL version: 8.1 Beta 4 > > > > > > Operating system: Windows Xp home > > > > > > Description:psql does not prompt for password > > > > > > Details: > > > > > > > > > > > > psql -U p
Re: [BUGS] BUG #2168: 45.000.000 records too much?
Steven Mooij wrote: > Some additional info. We repeated the test on different hardware with > unfortunately the same result. This is the output of the postgresql > logfile of that experiment: [log messages about processes kill 9ed] > This time we tested with postgresql 8.0.3 on a 2.6.12 linux kernel. > (Previously i tested with postgresql 7.4.9 on a 2.6.15 kernel.) Does dmesg or syslog mention the OOM killer? I tried running your test case while watching memory usage and stopped the postmaster before it finished as I didn't want to risk the kernel killing it (or some random other process) the hard way. -- Seneca Cunningham [EMAIL PROTECTED] ---(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] unsubscribe
unsubscribe HI，你 用 过 网 易 相 册 批 量 上 传 工 具 吗 ？想 传 多 少 就 传 多 少 ，还 是 免 费 的！
