<informalexample>
<programlisting>
play=# vacuum;
-NOTICE: Some databases have not been vacuumed in 1613770184 transactions.
+WARNING: Some databases have not been vacuumed in 1613770184 transactions.
Better vacuum them within 533713463 transactions,
or you may have a wraparound failure.
VACUUM
<programlisting>
regression=# EXPLAIN SELECT * FROM tenk1;
-NOTICE: QUERY PLAN:
+INFO: QUERY PLAN:
Seq Scan on tenk1 (cost=0.00..333.00 rows=10000 width=148)
</programlisting>
<programlisting>
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 1000;
-NOTICE: QUERY PLAN:
+INFO: QUERY PLAN:
Seq Scan on tenk1 (cost=0.00..358.00 rows=1007 width=148)
</programlisting>
<programlisting>
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 50;
-NOTICE: QUERY PLAN:
+INFO: QUERY PLAN:
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..181.09 rows=49 width=148)
</programlisting>
<programlisting>
regression=# EXPLAIN SELECT * FROM tenk1 WHERE unique1 < 50 AND
regression-# stringu1 = 'xxx';
-NOTICE: QUERY PLAN:
+INFO: QUERY PLAN:
Index Scan using tenk1_unique1 on tenk1 (cost=0.00..181.22 rows=1 width=148)
</programlisting>
<programlisting>
regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
regression-# AND t1.unique2 = t2.unique2;
-NOTICE: QUERY PLAN:
+INFO: QUERY PLAN:
Nested Loop (cost=0.00..330.41 rows=49 width=296)
-> Index Scan using tenk1_unique1 on tenk1 t1
SET VARIABLE
regression=# EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.unique1 < 50
regression-# AND t1.unique2 = t2.unique2;
-NOTICE: QUERY PLAN:
+INFO: QUERY PLAN:
Hash Join (cost=181.22..564.83 rows=49 width=296)
-> Seq Scan on tenk2 t2
regression=# EXPLAIN ANALYZE
regression-# SELECT * FROM tenk1 t1, tenk2 t2
regression-# WHERE t1.unique1 < 50 AND t1.unique2 = t2.unique2;
-NOTICE: QUERY PLAN:
+INFO: QUERY PLAN:
Nested Loop (cost=0.00..330.41 rows=49 width=296) (actual time=1.31..28.90 rows=50 loops=1)
-> Index Scan using tenk1_unique1 on tenk1 t1
One surprise you might encounter while running <command>initdb</command> is
a notice similar to this one:
<screen>
-NOTICE: Initializing database with en_US collation order.
+WARNING: Initializing database with en_US collation order.
This locale setting will prevent use of index optimization for
LIKE and regexp searches. If you are concerned about speed of
such queries, you may wish to set LC_COLLATE to "C" and
re-initdb. For more information see the Administrator's Guide.
</screen>
- This notice is intended to warn you that the currently selected locale
+ This is intended to warn you that the currently selected locale
will cause indexes to be sorted in an order that prevents them from
being used for LIKE and regular-expression searches. If you need
good performance of such searches, you should set your current locale
default is <literal>NOTICE</>. Valid values are <literal>DEBUG5</>,
<literal>DEBUG4</>, <literal>DEBUG3</>, <literal>DEBUG2</>,
<literal>DEBUG1</>, <literal>INFO</>, <literal>NOTICE</>,
- <literal>ERROR</>, <literal>LOG</>, <literal>FATAL</>,
- <literal>PANIC</>. Later values send less detail to the logs.
- <literal>LOG</> has a different precedence here than in
- <literal>CLIENT_MIN_MESSAGES</>.
+ <literal>WARNING</>, <literal>ERROR</>, <literal>LOG</>,
+ <literal>FATAL</>, and <literal>PANIC</>. Later values send less
+ detail to the logs. <literal>LOG</> has a different precedence
+ here than in <literal>CLIENT_MIN_MESSAGES</>.
</para>
</listitem>
</varlistentry>
<listitem>
<para>
This controls how much detail is written to the client. The
- default is <literal>INFO</>. Valid values are
+ default is <literal>NOTICE</>. Valid values are
<literal>DEBUG5</>, <literal>DEBUG4</>, <literal>DEBUG3</>,
<literal>DEBUG2</>, <literal>DEBUG1</>, <literal>LOG</>,
- <literal>INFO</>, <literal>NOTICE</>, <literal>ERROR</>,
- <literal>FATAL</>, <literal>PANIC</>. Later values send less
- information to the user. literal>LOG</> has a different
- precedence here than in <literal>SERVER_MIN_MESSAGES</>.
+ <literal>NOTICE</>, <literal>WARNING</>, and <literal>ERROR</>.
+ Later values send less information to the user. <literal>LOG</>
+ has a different precedence here than in
+ <literal>SERVER_MIN_MESSAGES</>.
</para>
</listitem>
</varlistentry>
proc = SPI_processed;
/*
* If this is SELECT and some tuple(s) fetched -
- * returns tuples to the caller via elog (NOTICE).
+ * returns tuples to the caller via elog (INFO).
*/
if ( ret == SPI_OK_SELECT && SPI_processed > 0 )
{
sprintf(buf + strlen (buf), " %s%s",
SPI_getvalue(tuple, tupdesc, i),
(i == tupdesc->natts) ? " " : " |");
- elog (NOTICE, "EXECQ: %s", buf);
+ elog (INFO, "EXECQ: %s", buf);
}
}
vac=> INSERT INTO a VALUES (execq('INSERT INTO a VALUES (0)',0));
INSERT 167631 1
vac=> SELECT execq('SELECT * FROM a',0);
-NOTICE:EXECQ: 0 <<< inserted by execq
+INFO: EXECQ: 0 <<< inserted by execq
-NOTICE:EXECQ: 1 <<< value returned by execq and inserted by upper INSERT
+INFO: EXECQ: 1 <<< value returned by execq and inserted by upper INSERT
execq
-----
(1 row)
vac=> SELECT execq('SELECT * FROM a', 10);
-NOTICE:EXECQ: 0
+INFO: EXECQ: 0
-NOTICE:EXECQ: 1
+INFO: EXECQ: 1
-NOTICE:EXECQ: 2 <<< 0 + 2, only one tuple inserted - as specified
+INFO: EXECQ: 2 <<< 0 + 2, only one tuple inserted - as specified
execq
-----
(1 row)
vac=> INSERT INTO a VALUES (execq('SELECT * FROM a', 0) + 1);
-NOTICE:EXECQ: 0
+INFO: EXECQ: 0
INSERT 167713 1
vac=> SELECT * FROM a;
x
-- This demonstrates data changes visibility rule:
vac=> INSERT INTO a SELECT execq('SELECT * FROM a', 0) * x FROM a;
-NOTICE:EXECQ: 1
-NOTICE:EXECQ: 2
-NOTICE:EXECQ: 1
-NOTICE:EXECQ: 2
-NOTICE:EXECQ: 2
+INFO: EXECQ: 1
+INFO: EXECQ: 2
+INFO: EXECQ: 1
+INFO: EXECQ: 2
+INFO: EXECQ: 2
INSERT 0 2
vac=> SELECT * FROM a;
x
/* Connect to SPI manager */
if ((ret = SPI_connect()) < 0)
- elog(NOTICE, "trigf (fired %s): SPI_connect returned %d", when, ret);
+ elog(INFO, "trigf (fired %s): SPI_connect returned %d", when, ret);
/* Get number of tuples in relation */
ret = SPI_exec("SELECT count(*) FROM ttest", 0);
FOR EACH ROW EXECUTE PROCEDURE trigf();
CREATE
vac=> INSERT INTO ttest VALUES (NULL);
-NOTICE:trigf (fired before): there are 0 tuples in ttest
+WARNING: trigf (fired before): there are 0 tuples in ttest
INSERT 0 0
-- Insertion skipped and AFTER trigger is not fired
(0 rows)
vac=> INSERT INTO ttest VALUES (1);
-NOTICE:trigf (fired before): there are 0 tuples in ttest
-NOTICE:trigf (fired after ): there are 1 tuples in ttest
+INFO: trigf (fired before): there are 0 tuples in ttest
+INFO: trigf (fired after ): there are 1 tuples in ttest
^^^^^^^^
remember what we said about visibility.
INSERT 167793 1
(1 row)
vac=> INSERT INTO ttest SELECT x * 2 FROM ttest;
-NOTICE:trigf (fired before): there are 1 tuples in ttest
-NOTICE:trigf (fired after ): there are 2 tuples in ttest
+INFO: trigf (fired before): there are 1 tuples in ttest
+INFO: trigf (fired after ): there are 2 tuples in ttest
^^^^^^^^
remember what we said about visibility.
INSERT 167794 1
(2 rows)
vac=> UPDATE ttest SET x = null WHERE x = 2;
-NOTICE:trigf (fired before): there are 2 tuples in ttest
+INFO: trigf (fired before): there are 2 tuples in ttest
UPDATE 0
vac=> UPDATE ttest SET x = 4 WHERE x = 2;
-NOTICE:trigf (fired before): there are 2 tuples in ttest
-NOTICE:trigf (fired after ): there are 2 tuples in ttest
+INFO: trigf (fired before): there are 2 tuples in ttest
+INFO: trigf (fired after ): there are 2 tuples in ttest
UPDATE 1
vac=> SELECT * FROM ttest;
x
(2 rows)
vac=> DELETE FROM ttest;
-NOTICE:trigf (fired before): there are 2 tuples in ttest
-NOTICE:trigf (fired after ): there are 1 tuples in ttest
-NOTICE:trigf (fired before): there are 1 tuples in ttest
-NOTICE:trigf (fired after ): there are 0 tuples in ttest
+INFO: trigf (fired before): there are 2 tuples in ttest
+INFO: trigf (fired after ): there are 1 tuples in ttest
+INFO: trigf (fired before): there are 1 tuples in ttest
+INFO: trigf (fired after ): there are 0 tuples in ttest
^^^^^^^^
remember what we said about visibility.
DELETE 2
projects / users / bernd / postgres.git / commitdiff