nyuuzyou/wikis huggingface dataset:
Japan PostgreSQL Developer Meetup 5

= Date & Time =
* 15 Nov 2017
* 12:00 - 18:00
= Location =
* New Shinbashi Coworking (ニュー新橋コワーキング: 新橋駅前)
** New Shinbashi Building, 3rd floor room 305C
** http://www.nscow.com/
= RSVPs =
== Developers (alphabetical order) ==
* Amit Langote
* Aya Iwata
* Ayumi Ishii
* Daisuke Higuchi
* Dang Minh Huong
* Eiji Seki
* Etsuro Fujita
* Kohei Kaigai
* Kyotaro Horiguchi
* Masahiko Sawada
* Masanori Oyama
* Masao Fujii
* Michael Paquier
* Minoru Nakamura
* Moon Insung
* Ryoji Kawamichi
* Taiki Kondo
* Takayuki Tsunakawa
* Takeshi Ideriha
* Tatsuo Ishii
* Tatsuro Yamada
* Vinayak Pokale
* Yoshifumi Masunaga
* Yugo Nagata
* Yusuke Egashira
* Yuto Hayamizu
* Yuzuko Hosoya
 Unfortunately the date does not meet everyone's availability:
 we tried it, but we couldn't. To whom cannot make it, 
 we are very sorry, and hope you come if your schedule changes.
 残念ながら皆さま全員のスケジュールに合わせることができませんでした。
 現時点で参加が難しい方も、もし予定が変わった時は是非ご参加ください。
== Staff ==
* Hitoshi HEMMI
* Mark HISADA
* Kaori Inaba
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 17:30：Unconference style discussion
* 17:30 - 18:00：Cleanup
* 18:00 - ：Hang out ( to be arranged … )
== Note ==
* We will start the meetup with lunch.
* Please bring 1,000 yen for lunch and coffee.
* ランチをしながらスタートいたします。
* 申し訳ありませんが昼食・コーヒー代で1,000円をお持ちください。
* ランチはスタッフが準備しておきます。
* 持ち込み可ですので、お好みのものがあればどうぞお持ちください。
== Facilities ==
* WiFi
* Projector
* Whiteboard 
* Kitchen
= Agenda =
* COBOL on PostgreSQL (Tabata, Hitachi)
* PostgreSQL scale out (Tsunakawa "MauMau", Fujitsu)
* Weakness of PG through TDE project (Kondo and Dan, NEC Sol.)
* FDW clusters (Katayama, Toshiba)
* Temporal table implementation using logical decoding (Yamada, NTT)
* KaiGai's recent projects (Kaigai, HeteroDB)
* PostgreSQL 11 features (Michael, Vmware)
* Optimizer (Kawamichi, U-Tokyo)
= Meeting notes =
back to Japan PostgreSQL Developer
Japan PostgreSQL Developer Meetup 6

= Date & Time =
* 23 Feb 2018
* 12:00 - 18:00
= Location =
* Minorasu real estate agency, 2F Seminar room (6min walk from Kamata Station)
** 7-36-7 Nishi-Kamata, Ota-ku, Tokyo
** http://www.minorasu.co.jp/corporate/minorasu_hd/
= RSVPs =
== Developers ==
* Tatsuo Ishii
* Yugo Nagata
* Masao Fujii
* Ayumi Ishii
* Michael Paquier
* Vinayak Pokale
* Kohei Kaigai
* Taiki Kondo
* Dang Minh Huong
* Etsuro Fujita
* Kyotaro Horiguchi
* Tatsuro Yamada
* Amit Langote
* Masahiko Sawada
* Moon Insung
* Masanori Oyama
* Yuzuko Hosoya
* Yoshifumi Masunaga
* Takayuki Tsunakawa
* Yusuke Egashira
* Daisuke Higuchi
* Eiji Seki
* Aya Iwata
* Takeshi Ideriha
* Kirk Jamison
* Ryoji Kawamichi
* Yuto Hayamizu
* Minoru Nakamura
* Yoshiyuki Tabata
* Taiga Katayama
== Staff ==
* Hara Norihiro
* Kaori Inaba
* Masaki Hisada
* Hitoshi Hemmi
 Unfortunately the date does not meet everyone's availability:
 we tried it, but we couldn't. To whom cannot make it, 
 we are very sorry, and hope you come if your schedule changes.
 残念ながら皆さま全員のスケジュールに合わせることができませんでした。
 現時点で参加が難しい方も、もし予定が変わった時は是非ご参加ください。
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 17:30：Unconference style discussion
* 17:30 - 18:00：Cleanup
* 18:00 - ：Hang out ( to be arranged … )
== Note ==
* We will start the meetup with lunch.
* Please bring 1,000 yen for lunch and coffee.
* ランチをしながらスタートいたします。
* 申し訳ありませんが昼食・コーヒー代で1,000円をお持ちください。
* ランチはスタッフが準備しておきます。
* 持ち込み可ですので、お好みのものがあればどうぞお持ちください。
== Facilities ==
* WiFi
* Projector
* Whiteboard 
* Kitchen
= Agenda =
* Applying PMDK to PostgreSQL (Menjo, NTT)
* VACUUM (Sawada, NTT)
* Multithread (Hirose, Toshiba)
* FDW and Partitioning (Hirose, Toshiba)
* Task and Question in using FDW (Fujii, Mitsubishi Electric)
* Hitachi's Efforts Part 2 (Inagaki, Hitachi)
= Meeting notes =
back to Japan PostgreSQL Developer
Japan PostgreSQL Developer Meetup 7

= Date & Time =
* 21 May 2018
* 12:00 - 17:30
= Location =
* Rental kitchen space Patia Ikebukuro
** 5-2-12 Nishi-Ikebukuro, Toshima-ku, Tokyo
** https://www.patia.tokyo/ikebukuro/access
= RSVPs =
== Developers ==
* Tatsuo Ishii
* Yugo Nagata
* Masao Fujii
* Ayumi Ishii
* Michael Paquier
* Vinayak Pokale
* Kohei Kaigai
* Taiki Kondo
* Dang Minh Huong
* Etsuro Fujita
* Kyotaro Horiguchi
* Tatsuro Yamada
* Amit Langote
* Masahiko Sawada
* Moon, Insung
* Yuzuko Hosoya
* Yoshifumi Masunaga
* Takayuki Tsunakawa
* Yusuke Egashira
* Daisuke Higuchi
* Eiji Seki
* Aya Iwata
* Takeshi Ideriha
* Kirk Jamison
* Ryoji Kawamichi
* Yuto Hayamizu
* Minoru Nakamura
* Yoshiyuki Tabata
* Taiga Katayama
* Tsuyoshi Inagaki
* Takashi Menjo
* Yuki Fujii
* Imai, Yoshikazu
* Yamaji, Ryo
* Yotsunaga, Naoki
== Staff ==
* Kaori Inaba
* Masaki Hisada
* Hitoshi Hemmi
 Unfortunately the date does not meet everyone's availability:
 we tried it, but we couldn't. To whom cannot make it, 
 we are very sorry, and hope you come if your schedule changes.
 残念ながら皆さま全員のスケジュールに合わせることができませんでした。
 現時点で参加が難しい方も、もし予定が変わった時は是非ご参加ください。
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 17:30：Unconference style discussion
* 17:30 - 18:00：Cleanup
* 18:00 - ：Hang out ( to be arranged … )
== Note ==
* We will start the meetup with lunch.
* Please bring 1,000 yen for lunch and coffee.
* ランチをしながらスタートいたします。
* 申し訳ありませんが昼食・コーヒー代で1,000円をお持ちください。
* ランチはスタッフが準備しておきます。
* 持ち込み可ですので、お好みのものがあればどうぞお持ちください。
== Facilities ==
* Projector
* Whiteboard 
* Kitchen
= Agenda =
* PostgreSQL VIETNAM ( DANG, NEC Solution Innovators )
* Sharing to System and Relation Cache ( Ideriha, FUJITSU )
* Partitioning Advisor ( Hosoya, NTT )
* Introduce GridDB-FDW ( Katayama, TOSHIBA )
* TDE/KMS ( Moon, NTT )
* Plan Advisor ( Yamada, NTT )
* Vacuum ( Sawada, NTT )
= Meeting notes =
back to Japan PostgreSQL Developer
Japan PostgreSQL Developer Meetup 8

= Date & Time =
* 16 Nov 2018
* 12:00 - 17:30
= Location =
* ミノラス不動産株式会社 本社2Fセミナールーム
** 7-36-7 Nishi-Kamata, Ota-ku, Tokyo
** (蒲田駅から徒歩6分)
** Minorasu real estate agency, 2F Seminar room (6min walk from Kamata Station)
** http://www.minorasu.co.jp/corporate/minorasu_hd/
= RSVPs =
TBD
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 17:30：Unconference style discussion
* 17:30 - 18:00：Cleanup
* 18:00 - ：Hang out ( to be arranged … )
== Note ==
* We will start the meetup with lunch.
* Please bring 1,000 yen for lunch and coffee.
* ランチをしながらスタートいたします。
* 申し訳ありませんが昼食・コーヒー代で1,000円をお持ちください。
* ランチはスタッフが準備しておきます。
* 持ち込み可ですので、お好みのものがあればどうぞお持ちください。
== Facilities ==
* WiFi
* Projector
* Whiteboard 
* Kitchen
= Agenda =
* Incremental view maintenance	(Yogo Nagata)
* Influx FDW			(Shohei Mochizuki)
* Global meta cache		(Takeshi Ideriha)
* Partitioning Performance	(Amit Langote)
* Auto explain analyze		(Taiki Kondo)
* CF				(Michael Paquier)
* Time Series benchmark		(Yuto Hayamizu / Ryoji Kawamichi)
* Atomic commit API		(Masahiko Sawada)
* Auto plan tuning by feedback	(Tatsuro Yamada)
= Meeting notes =
back to Japan PostgreSQL Developer
Japan PostgreSQL Developer Meetup 9

= Date & Time =
* 7 Mar 2019
* 12:00 - 17:30
= Location =
* グランパークタワー (田町/三田) 34F
** 3-4-1 Shibaura, Minato-ku, Tokyo
** (JR田町駅から徒歩5分)
* Granpark tower (Tamachi/Mita) 34F 
** 5min walk from JR Tamachi Station
* https://www.granpark.jp/access/
= RSVPs =
TBD
= Time table =
* 12:00 - 12:30：Registration & Lunch Start
* 12:30 - 17:30：Unconference style discussion
* 17:30 - 18:00：Cleanup
* 18:00 - ：Hang out ( to be arranged … )
== Note ==
* We will start the meetup with lunch.
* Please bring 1,000 yen for lunch and coffee.
* ランチをしながらスタートいたします。
* 申し訳ありませんが昼食・コーヒー代で1,000円をお持ちください。
* ランチはスタッフが準備しておきます。
* 持ち込み可ですので、お好みのものがあればどうぞお持ちください。
== Facilities ==
* Projector
* Whiteboard
= Agenda =
* Transparent Data Encryption ( Masahiko Sawada / Moon, Insung )
* Multiple Query Optimization ( Yuya Watari )
* Pgpool-II / Shared REL cache ( Takuma Hoshiai / Tatsuo Ishii )
* Postgres and our feature ( Takayuki Tsunakawa )
* Catalog cache hard limit ( Takeshi Ideriha )
* Calculating parallel-degree on joining ( Taiki Kondo )
* Small talk about postgres securiting ( Dang Minh Huong )
= Meeting notes =
back to Japan_PostgreSQL_Developer_Meetup
Java

== Java Drivers as of Aug 2018 ==
The canonical JDBC driver pgjdbc
JDBC Driver based on NIO pgjdbc-ng
A number of async and or reactive drivers are in various states
Reactive client reactive-pg-client 
Reactive client https://github.com/r2dbc/r2dbc-client r2dbc]
Async client pgnio
Async client postgres-async-driver
Async client vertx-postgresql-client
Scala client postgresql-async
Scala Async client postgres.async
JDBC-BinaryTransfer

=== JDBC Binary Transfer ===
The idea of the binary transfer patch to the JDBC driver is to transfer all binary types from the PostgreSQL server to the JDBC driver in their binary form.
This eliminates the need to convert, for example, a number from their text representation to their binary representation.
This patch will therefore provide a speedup of the JDBC performance.
== Configuration ==
The binary transfer is enabled by default, but is controlled by the
 binaryTransfer=boolean
flag on the connection url.
An example:
 jdbc:postgresql://localhost:5432:mydatabase?binaryTransfer=true
Furthermore you are able to force binary transfer using the
 -Dorg.postgresql.forcebinary=boolean
JVM argument.
An example:
 java -Dorg.postgresql.forcebinary=true -classpath myjar.jar MyApp
If the compatible version is less that 8.0 then values of type TIME, TIMETZ, TIMESTAMP and TIMESTAMPTZ are never transferred in binary format.
If the compatible version is less that 8.3 then values of type INT2_ARRAY, INT4_ARRAY, INT8_ARRAY, FLOAT4_ARRAY, FLOAT8_ARRAY, VARCHAR_ARRAY and TEXT_ARRAY are never transferred in binary format.
== Development ==
The patch was developed by Mikko, with modifications by Kris and minor updates by Jesper.
== Testing ==
* Jignesh: Postgres 8.4 Testing with new JDBC Drivers
== Versions ==
=== v13 ===
* Sync with CVS HEAD (2009/06/23)
=== v12 ===
* Sync with CVS HEAD (2009/06/02)
=== v11 ===
* Fixed Statement::executeQuery(String) in regards to ResultSet 
* Added binary transfer to the test suite
* Added simple Statement ResultSet test
=== v10 ===
* Sync with CVS HEAD
* build.xml - cleanups regarding def_pgport
* build.properties - cleanups regarding def_pgport
* QueryExecutor - corrected the constant value
* QueryExecutorImpl - removed unneeded code paths
=== v9 and older ===
* Mikko's site
== Patches ==
* BinaryTransfer-v13 (part1)
* BinaryTransfer-v13 (part2)
* BinaryTransfer-v12 (part1)
* BinaryTransfer-v12 (part2)
* BinaryTransfer-v11 (part1)
* BinaryTransfer-v11 (part2)
Category:Performance
JDBC Driver for PostgreSQL by CData

== About ==
The JDBC Driver for PostgreSQL by CData offers the most natural way to connect to PostgreSQL data from Java-based applications and developer technologies. The driver wraps the complexity of accessing PostgreSQL data in an easy-to-integrate, 100%-Java JDBC driver. 
The driver hides the complexity of accessing data and provides additional powerful security features, smart caching, batching, socket management, and more.
Category:Tool
JDBC-Findbugs

=== JDBC Findbugs ===
The goal of this project is to eliminate all the findbugs warnings in the JDBC driver.
== Versions ==
=== v1 (2009/06/30) ===
* Use .valueOf() method for numbers
* Fix AbstractJdbc3Connection::prepareStatement condition
== Patches ==
* Findbugs-v1
Category:JDBC
JSON compact

In some cases you may want to remove all unnecessary noise from a JSON document, in particular if you plan to store it in your DB. This snippet does exactly this task.
CREATE OR REPLACE FUNCTION public.json_compact(p_json JSON,
 p_step INTEGER DEFAULT 0)
RETURNS JSON
AS $$
DECLARE
 v_type TEXT;
 v_text TEXT := ;
 v_indent INTEGER;
 v_key TEXT;
 v_object JSON;
 v_count INTEGER;
BEGIN
 p_step := coalesce(p_step, 0);
 -- Object or array?
 v_type := json_typeof(p_json);
 
 IF v_type = 'object' THEN
 -- Start object
 v_text := '{';
 SELECT count(*) - 1 INTO v_count
 FROM json_object_keys(p_json);
 -- go through keys, add them and recurse over value
 FOR v_key IN (SELECT json_object_keys(p_json))
 LOOP
 v_text := v_text || to_json(v_key)::TEXT || ':' || public.json_compact(p_json->v_key, p_step + 1);
 IF v_count > 0 THEN
 v_text := v_text || ',';
 v_count := v_count - 1;
 END IF;
 --v_text := v_text || E'\n';
 END LOOP;
 -- Close object
 v_text := v_text || '}';
 ELSIF v_type = 'array' THEN
 -- Start array
 v_text := '[';
 v_count := json_array_length(p_json) - 1;
 -- go through elements and add them through recursion
 FOR v_object IN (SELECT json_array_elements(p_json))
 LOOP
 v_text := v_text || public.json_compact(v_object, p_step + 1);
 IF v_count > 0 THEN
 v_text := v_text || ',';
 v_count := v_count - 1;
 END IF;
 --v_text := v_text || E'\n';
 END LOOP;
 -- Close array
 v_text := v_text || ']';
 ELSE -- A simple value
 v_text := v_text || p_json::TEXT;
 END IF;
 IF p_step > 0 THEN RETURN v_text;
 ELSE RETURN v_text::JSON;
 END IF;
END;
$$ LANGUAGE plpgsql;
COMMENT ON FUNCTION public.json_compact(p_json JSON,
 p_step INTEGER)
IS $$Return a JSON document in a compact JSON suitable for storing in the DB.
Parameters:
* p_json: The JSON document to be compacted.
* p_step: Optional: This parameter is used for recursion in the document structure. You are not supposed to use it.$$;
Libpq API Weaknesses

In case somebody has time to address some of these... 
* PQconsumeInput() does not return whether any data input (or output in case of nonblocking connections) has been consumed. That means that more complex state machines need to be built around it.
* Whether libpq currently is is waiting for writes or reads is not exposed. There's PostgresPollingStatusType, which is returned by PQconnectPoll()/PQresetPoll(), but we don't conveniently expose it during normal operation. That's especially problematic for PQsend*, where it's entirely unclear whether reading or writing is needed. One can approximate it it by calling PQflush().
* The query result format can only be set on a per-query basis, not on a per-column/per type basis, even though the protocol supports the former. That's annoying because users need to add support for every type possibly used to benefit from the binary protocol, even though even just supporting a handful (bytea in particular) reaps most of the benefit.
* no pipelined query support
* Lots of old deprecated functions
List of drivers

= Drivers =
The list below are PostgreSQL drivers (also referred to as "client libraries") that developers can use to interface with PostgreSQL from various programming languages. The list is alphabetized by programming language, and also indicates if the driver is based on libpq and whether or not it supports the SCRAM-SHA-256 authentication protocol that was added in PostgreSQL 10.
NOTE: The drivers listed below are in various states of development. Some of them have been stable for many years and have been proven in various environments, whereas others are in early development. This listed is strictly informational: it is up to you to select the driver that is best for your environment.
If you would like to add additional drivers to the list, please add them in alphabetical order based on the programming language for the driver.
== Open Source ==
Driver 	Language 	License 	Uses libpq?	Supports SCRAM?
libpq 	C 	PostgreSQL 	Yes 	Yes
ODBC 	C 	LGPLv2 	Yes 	Yes
libpqxx 	C++ 	BSD 3-Clause 	Yes 	Yes
QPSQL 	C++ (Qt) 	LGPLv3 	Yes 	Yes
pgfe 	C++ 	zlib 	Yes 	Yes
OZO 	C++ 	PostgreSQL 	Yes 	Yes
taoPQ 	C++ 	BSL-1.0 	Yes 	Yes
npgsql 	C# 	PostgreSQL 	No 	Yes, since 3.2.7
Postmodern 	Common Lisp 	zlib and PostgreSQL	No 	Yes, since 1.30
crystal-pg 	Crystal 	BSD 3-Clause 	No 	Yes, since 0.18.0
Postgrex 	Elixir 	Apache 2 	No 	Yes, since 0.14.0
emacs-libpq 	Emacs Lisp 	GPLv3 	Yes 	Yes
epgsql 	Erlang 	BSD 3-Clause 	No 	Yes
pgo 	Erlang 	Apache 2.0 	No 	Yes
github.com/lib/pq	Go 	MIT 	No 	Yes, since 1.1.0
pgx 	Go 	MIT 	No 	Yes , since 3.4.0
go-pg 	Go 	BSD 2-Clause 	No 	Yes, since 6.15
HDBC 	Haskell 	BSD 3-Clause 	Yes 	Yes
postgresql-simple	Haskell 	BSD 3-Clause 	Yes 	Yes
JDBC 	Java 	BSD 2-Clause 	No 	Yes, since 42.2.0.
R2DBC 	Java 	Apache 2.0 	No 	Yes
node-postgres 	JavaScript 	MIT 	Optional 	Yes , since 7.9.0
postgres.js 	JavaScript 	The Unlicense 	No 	Yes
pgmoon 	Lua 	MIT 	No 	Yes, since 1.13.0
DBD::Pg 	Perl 	Artistic 	Yes 	Yes
php-pgsql 	PHP 	PHPv3.0.1 	Yes 	Yes
PDO_PGSQL 	PHP 	PHPv3.0.1 	Yes 	Yes
ext-pq 	PHP 	BSD 2-Clause 	Yes 	Yes
Pomm 	PHP 	MIT 	Yes 	Yes
Psycopg 3 	Python 	LGPLv3 	Yes 	Yes
psycopg2 	Python (CPython only)	LGPLv3 	Yes 	Yes
asyncpg 	Python 	Apache 2 	No 	Yes, since 0.19.0
pg8000 	Python 	BSD 3-Clause 	No 	Yes
psycopg2cffi 	Python, PyPy 	LGPLv3 	Yes 	Yes
RPostgreSQL 	R 	GPLv2 	Yes 	Yes
ruby-pg 	Ruby 	BSD 2-Clause 	Yes 	Yes
rust-postgres 	Rust 	MIT 	No 	Yes
PostgresClientKit	Swift 	Apache 2 	No 	Yes , since 1.3.0
PostgresNIO 	Swift 	MIT 	No 	Yes
Pgtcl 	Tcl 	BSD 3-Clause 	Yes 	Yes
pgtclng 	Tcl 	PostgreSQL 	Yes 	Yes
postgresql-client	TypeScript 	MIT 	No 	Yes
== Proprietary ==
There is a list of proprietary (and open source) drivers listed out on the PostgreSQL website:
https://www.postgresql.org/download/products/2-drivers-and-interfaces/
The PostgreSQL Global Development Group do not endorse or recommend any products listed in the above URL, and cannot vouch for the quality or reliability of any of them.
== Unsupported Drivers ==
Below is a list of drivers that are no longer maintained.
Driver 	Language
CLSQL 	Common Lisp
pgsql 	Erlang
erlang-psql-driver	Erlang
PgPP 	Perl
= See Also =
* Software catalog list
!
Lock database

== LOCK DATABASE ==
LOCK DATABASE is a database-level lock mechanism.
This functionality is not implemented in PostgreSQL, and is not planned to be yet.
=== Synopsis ===
LOCK DATABASE db_name [IN dblockmode MODE] [NOWAIT];
UNLOCK DATABASE db_name;
dblockmode having the following options:
SHARE | EXCLUSIVE
EXCLUSIVE excludes all SQL query to be run on the database. No connection is allowed from external applications.
SHARE authorizes SELECT queries and connections to the database. DDL and DML are blocked.
=== Characteristics ===
LOCK DATABASE is a database-level lock, waiting for any locks to be released before taking it.
For example, if lock is taken on a table of this database, LOCK DATABASE waits until it is released.
When waiting for locking, new table locks of this database cannot be taken.
It is also possible to set NOWAIT what makes LOCK DATABASE to return an error if lock cannot be taken immediately.
mechanism to ensure that no transaction can be run on this database or no user can access to this database when lock is taken.
Lock can be released with command UNLOCK DATABASE or when session that used this database is disconnected.
PostgreSQL always takes the least level of lock when using such mechanism.
LOCK DATABASE can be used if database administrator or superuser needs more restrictive lock mechanism.
=== Usage ===
* Server maintenance:
instead of taking multiple locks on tables of a database.
* Cluster of nodes:
PostgreSQL does not ensure a DROP DATABASE query if done on multiple nodes at the same time as query is autocommit.
DROP DATABASE can easily fail on a node if an application keeps a connection alive on it.
However DROP succeeds if no session are alive on this node of the cluster.
In this case LOCK DATABASE can be used as a 2PC like mechanism to ensure database drop in a cluster of nodes.
Category:Feature request
Logging Brainstorm

During the Sept. 2009 commitfest, at least two patches have come in to modify logging. After some discussion, both were rejected with the suggestion that this whole idea needs more discussion before it needs more coding.
== Wishlist ==
This list includes things we might like to be able to do and currently can't.
; Log actions in different databases to different files
: syslog is the best destination for error logging, but the performance is bad when we writes a lot of logs. It would be better to split query and performance logs into text logs. Syslog-based filtering is not a solution because performance bottleneck is in the communication of syslog.
; Log differently based on source database
: i.e. make log_line_prefix, log_min_messages, etc. database-specific
; Do either of the above with some criterion other than just database
: e.g. different users' actions end up logged in different places
; Provide logs that are both machine-readable and human-readable.
: We've got csvlog, which sucks for humans to read, and other logs, which suck for machines to read. One possible solution is to allow logging to two files -- one in CSV and another in "plain text".
; Add option to fix the latest log filename
: Machine-monitoring will be easier if we could fix the latest log filename. The latest message is always at the tail of the same file. If the file size shrinks, monitoring middleware reopens the same filename. The log will be renamed on log rotation; timestamp for formatting is retrieved from creation time of the file.
; Use unique server log encoding for databases with different encoding
: We merge logs in different encoding into a file for now. The encoding of server log should be specified independent from database encoding. UTF-8 might be only reasonable encoding though.
; Different localization in server logs and client messages
: We use one lc_messages for both server logs and client messages, but it would be better to have different encoding in them. DBA and user could want different localization.
; Additional fields to report object names in error message
: The name and schema name of the relevant object can be pulled out of the message by programs without having to parse the message text.
: 
== Implementation Idea ==
; Use executor hooks for query logging
: Query logging could be implemented in external modules and we could avoid including it in the core feature. We have ExecutorStart_hook in 8.4, but need additional ProcessUtility_hook to filter also DDL commands.
; Logging hook (rejected)
: Adding send_message_to_server_log_hook in elog and do all operations listed on the wishlist in user-defined modules. But having such critical behavior dependent on a loadable module is a bad idea .
Category:Development
Logging Checkpoints

Checkpoints are very disrupting to your database performance and can cause connections to stall for up to a few seconds while they occur. Starting in PostgreSQL 8.3, you can get verbose logging of the checkpoint process by turning on log_checkpoints. In earlier versions, you can't get much information, but it is possible to get a log message for every checkpoint by setting checkpoint_warning to a higher value, like its maximum of 3600 (seconds). This will produce a warning in the log every time a checkpoint is done. If you have connection backed up behind the checkpoint, they should complete in a bunch just after the checkpoint does. See Checkpoints and the Background Writer for information about reducing the scale of this problem.
Category:AdministrationCategory:Performance
Logging Checkpoints/ja

チェックポイントはデータベースの性能を大きく妨害し、これが発生する数秒の間完了するまで接続できなくなることもあり得ます。
PostgreSQL 8.3からlog_checkpointsを有効にすることによりチェックポイント処理の詳細なログを記録させることができます。
以前のバージョンでは多くの情報を記録させることはできませんが、checkpoint_warningをより大きく、例えば最大値である3600（秒）設定することにより、各チェックポイントについてログメッセージを記録させることができます。
これによりチェックポイントが完了する度にログに警告が記録されます。
もしチェックポイントの背後に待機している接続があるようならば、そのチェックポイントの完了直後に一斉に完了するはずです。この問題の影響を少なくするための情報についてはCheckpoints and the Background Writerを参照してください。
Category:AdministrationCategory:PerformanceCategory:Japanese
Logging Checkpoints/ru

Контрольные точки могут оказывать значительное влияние на производительность базы данных и приводить к задержкам до нескольких секунд.
Начиная с PostgreSQL 8.3 можно получить подробности по контрольным точкам с помощью настройки log_checkpoints. В более ранних версиях невозможно получить подробную информацию, однако, можно включить логгирование фактов возникновения точек, установив checkpoint_warning в более высокое значение, но не превышающее 3600 (секунд). Предупреждения будут генерироваться по завершению контрольных точек.
Если подключения не разрываются после завершения контрольных точек, стоит обратиться к Checkpoints and the Background Writer для снижения этого эффекта.
Category:Administration
Category:Performance
Category:Russian