nyuuzyou/wikis huggingface dataset:
Hibernate XML Type

This Java class can be used to enable Hibernate to store and retrieve PostgreSQL "xml" typed fields as String objects. It's trivially adapted to parse the XML into a DOM and store from a DOM or whatever your preferred XML representation instead.
To tell Hibernate to use this UserType for a given mapped field, specify a Type annotation on the property, like:
@org.hibernate.annotations.Type(type="foo.bar.SQLXMLType")
private String markup;
If you're using Hibernate's XML mapping, add a "type" attribute to the "property" mapping, and specify the fully-qualified name of the type in the value. See, eg, this article.
Here's the source to the UserType. Feel free to adapt it as necessary. Be aware, though, that if you change the Java type in use to something that's mutable (ie where you can change the state of an instance) you must significantly adapt the implementation below according to the API documentation here.
Without using a UserType like this, you'll be able to retrieve xml columns fine, but on storing changes you'll receive a PostgreSQL error like:
ERROR: column "markup" is of type xml but expression is of type character varying at character 122
package foo.bar;
import java.io.Serializable;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
import java.sql.Types;
import org.hibernate.HibernateException;
/**
 * Store and retrieve a PostgreSQL "xml" column as a Java string.
 */
public class SQLXMLType implements org.hibernate.usertype.UserType {
 private final int[] sqlTypesSupported = new int[] { Types.VARCHAR };
 @Override
 public int[] sqlTypes() {
 return sqlTypesSupported;
 }
 @Override
 public Class returnedClass() {
 return String.class;
 }
 @Override
 public boolean equals(Object x, Object y) throws HibernateException {
 if (x == null) {
 return y == null;
 } else {
 return x.equals(y);
 }
 }
 @Override
 public int hashCode(Object x) throws HibernateException {
 return x == null ? null : x.hashCode();
 }
 @Override
 public Object nullSafeGet(ResultSet rs, String[] names, Object owner) throws HibernateException, SQLException {
 assert(names.length == 1);
 String xmldoc = rs.getString( names[0] );
 return rs.wasNull() ? null : xmldoc;
 }
 @Override
 public void nullSafeSet(PreparedStatement st, Object value, int index) throws HibernateException, SQLException {
 if (value == null) {
 st.setNull(index, Types.OTHER);
 } else {
 st.setObject(index, value, Types.OTHER);
 }
 }
 @Override
 public Object deepCopy(Object value) throws HibernateException {
 if (value == null)
 return null;
 return new String( (String)value );
 }
 @Override
 public boolean isMutable() {
 return false;
 }
 @Override
 public Serializable disassemble(Object value) throws HibernateException {
 return (String) value;
 }
 @Override
 public Object assemble(Serializable cached, Object owner) throws HibernateException {
 return (String) cached;
 }
 @Override
 public Object replace(Object original, Object target, Object owner) throws HibernateException {
 return original;
 }
}
High Availability

= Manifesto =
We need a canonical source of information with step-by-step instructions for creating a HA configuration for Postgres. 
== Best Practices ==
Please add links to demos, slide decks or blog posts that demonstrate an HA setup.
== Tools ==
* Pgpool-II
* HA-Proxy
* There are server-oriented tools for doing "high availability" on servers which may be used to make a "high availability" Postgres instance
** DRBD (for Linux)
** IBM HACMP aka PowerHA Afilias has run HA Postgres clusters where HACMP, running atop AIX, was used to provide high availability
== Existing Pages ==
All these pages had some reference to "high availability" in them:
* Distributing_PostgreSQL
* Replication,_Clustering,_and_Connection_Pooling
* Shared_Storage
* Tungsten
* Postgres-XC
* Warm_Standby
Category:Clustering
Hint Bits/ja

PostgreSQLのMVCC機構は多くの有用な機能を提供しますが、いくつかのこの実装の副作用があります。
その１つは、読み取っただけであるにも関わらずデータベーステーブルに大量に書き込まれることになる、ヒントビット処理の巡回です。
ヒントビットは、コミットまたはアボートされたことがわかったトランザクションにより作成、削除またはその両方の処理をされたタプルに印付けするために使用されます。
これらのビット集合なしでタプルの可視性を決定するためには、pg_clogとおそらくpg_subtransを参照しなければならなくなります。
これは高価な検査です。
一方で、タプルがビット集合を持てば、その状態が分かります。
（または、最悪の場合でも、pg_clogを検索することなく、現在のスナップショットから簡単に計算できます。）
以下の4つのヒントビットがあります。
*XMIN_COMMITTED -- コミットされたことが既知の作成トランザクション
*XMIN_ABORTED -- アボートされたことが既知の作成トランザクション
*XMAX_COMMITTED -- 同上。ただし削除トランザクション用
*XMAX_ABORTED -- 同上
XMINビットのいずれも設定されいない場合は以下のいずれかです。
* 作成トランザクションが実行中である場合。これは共有メモリ内で実行中のトランザクションを確認することで検査できます。
* 終了した後に最初に検査した場合。この場合pg_clogを参照し、トランザクションの状態を確認しなければなりません。また、最終状態がわかったらヒントビットを更新することができます。
タプルが削除と印付けされていた場合、同様の記録がXMAXビットに付けられます。
バキュームまたは任意の通常のDML操作のいずれかによるタプルの確認はすべて、その確認時にこのヒントビットを挿入/削除トランザクションのコミット/アボート状態に一致するように更新します。
テーブル全体に対する通常のSELECT、count(*)、VACUUMは可視性に関してすべてのタプルを検査し、ヒントビットを設定します。
他にもヒントビットがタプル単位で検査、設定されるということにも注意してください。
単純な走査ではページ上の全タプルにアクセスし、そのヒントビットを一度に更新しますが、ばらばらのアクセス（インデックススキャンを介した単一タプルの取り出しなど）では、各種ヒントビットを更新するために同一ページに多く書き込みする可能性があり、時間がかかります。
==コミットログ==
ここに記載したものの一部はsrc/backend/access/transam/READMEにあります。
* "pg_clogはXIDを代入された各トランザクションのコミット状態を記録します。"
* トランザクションと副トランザクションでは、最初にこれを必要とする何か（通常はタプルの挿入・更新・削除ですが、他にもいくつかXIDの代入が必要になる箇所があります）を行った際に永続XIDが代入されます。
pg_clogは副トランザクション、主トランザクションの終了時にのみ更新されます。
トランザクションIDが代入される時、すでに存在するか、存在しなければ初期化されているかどうかを確認するためにトランザクションIDが含まれるclogページが検査されます。
pg_clogには8kB単位のページが割り当てられます。
各トランザクションは2ビット必要ですので、1つの8kBページには4トランザクション/バイト * 8k バイト = 32k トランザクション分の領域があります。
割り当て時、ページはゼロで初期化されます。
このビットパターンは「トランザクションは進行中」を表します。
このためトランザクションが起動する時、その状態を含むpg_clogページが割り当てられているかどうかのみを確認する必要がありますが、何も書き込む必要はありません。
8.3以降では、トランザクションの起動時にこれは起こりません。Xidの割り当て時（つまりトランザクションが最初に読み取り・書き込みコマンドを呼び出した時）に起こります。
過去のバージョンでは、最初にスナップショットが取られた時、非常に少ない例外がありますが通常は、種類を問わない最初のコマンドを実行した時に起こります。
これは、32Kのトランザクションを書き込む度にトランザクションは、そのXIDを割り当てる時に余計な作業、つまりpg_clogの次のページを作成しゼロで初期化する作業をしなければならないことを意味します。
これは問題のトランザクションを遅くするだけではありません。
次にXIDが必要となった時にゼロで初期化中であれば、待機しなければなりません。
これがおそらく報告された、トランザクションの実行時間が予想しないほど長くなる動作の説明です。
CLOGページは内部CLOGバッファがいっぱいになるまでディスクへ書き出しません。
ここにはもっとも使用時期が古いバッファが永続ストレージに吐き出されます。
CLOG pages don't make their way out to disk until the internal CLOG 
buffers are filled, at which point the least recently used buffer there is evicted to permanent storage.
元原稿:
* http://archives.postgresql.org/pgsql-patches/2005-07/msg00390.php
* http://archives.postgresql.org/pgsql-performance/2008-05/msg00182.php
Category:Performance
Category:Japanese
Homebrew

Homebrew is a package manager for Mac OS X that builds software from its source code. It includes a version of PostgreSQL packaged by what it refers to as a formula. This type of installation might be preferred by people who are comfortable using the command line to install programs, such as software developers. For installing elsewise in OS X see here.
Typical installation of server looks like
$ brew install postgresql
This installs the command line console (psql) as well as a PostgreSQL server locally, so you can create your own databases locally if desired.
If you want just the command line console (psql) to access remote databases, see here.
It will give you instructions on creating an initial database. When you do it will be "owned" by your username and create the `postgres` and `template1` databases.
Run the following to start the server.
$ brew services start postgresql # or "brew services run postgresql" to have it not restart at boot time
# or the pg_ctl command it mentions
And to connect/use it, as your user:
$ psql postgres
You can see what other versions are available for install by running 
$ brew search postgres
==> Formulae
check_postgres postgresql ✔ postgresql@10 postgresql@11 ...
You can see which version the current latest is/will be by installing it and inferring it from the directory, running `brew info postgresql` or looking at the formula `brew edit postgresql`
Notes on Homebrew:
* Install PostgreSQL on Mac OS X via Brew
* Brew Install Postgresql on OS X Lion - Resolving conflicts with the built-in PostgreSQL libraries shipping with OS X 10.7 'Lion'
* Discussion comparing Homebrew and EDB OS X installers
* petere/postgresql tap for installing multiple PostgreSQL versions in parallel
Category:Tool
HowToBooth

== PreShow ==
=== Get Help ===
* Email to -general, -advocacy for volunteers
* Email to local pug for Volunteers
* Check with pg.us|pg.eu or similar support groups for booth materials/swag
=== Advertise ===
* Update the pg wiki at http://wiki.postgresql.org/wiki/Events
* Send email to pgsql-announce
* Add your event to the PostgreSQL website
* Notify any local PUG groups
* Blogs / Twitter / Foursquare?
==Booth Setup==
===Load-In===
Most conferences provide an opportunity to "load in" and set up the booth the day or evening before the conference. This is highly recommended: you might need more setup time than you expect, you might have forgotten critical items, parking is often available during load-in (and not day of), and doing it the day before means that you might be able to recruit some volunteers who aren't available at other times.
Generally for load-in you're going to need a car or truck, at least two other volunteers, and a folding dolly is advisable. Try to consolidate all your stuff down to as few boxes and bags as possible; it's easier to carry one large box than 4 small ones. 
You and another volunteer should drop off the gear, the vol should watch the gear while you park. Then the two of you and any other volunteers should shuttle gear to the show floor, leaving one vol to watch any gear on the curb until the last trip.
During load-in, you want to accomplish the following things:
* Set up the booth display, table, banners, literature, and swag display.
* Test your demo or any other A/V for the booth.
* Sort and arrange t-shirts.
* Do an inventory check to see if you forgot anything.
* Set up power (and internet, if possible)
* Sort and stash extra literature, swag and gear out of sight.
* Check on other projects near your booth you might want to team up with.
===Booth Layout===
* Usually the table will be draped from the front - this makes an excellent storage area for additional inventory of small items (buttons, etc)
* Make sure there's room for the booth staff to walk behind the booth: keep volunteer's packs/bags, 
the boxes of t-shirts, etc. corralled.
===Table Layout===
* Leave space on the table for people to set papers etc if they need to take notes.
* Make sure you have price signs up for any items that are not free.
==Running The Booth==
===Busy Busy Booth===
===Answering Questions===
===Soliciting Donations===
===Your Fellow Booth Staff===
* Introduce yourself to your fellow booth volunteers if you don't know them.
===Security===
* Keep the cash box out of sight.
===Lunch===
* Make sure everyone gets lunch and a break to walk around the conference.
* It's better to avoid eating in the booth if you can.
===Packing Up===
* Basically, reverse the load-in procedure.
Category:Advocacy
How to sponsor a feature

== How to sponsor a feature ==
=== Propose the Feature ===
* Write a detailed proposal. Here is a proposal template
* Send it to the pgsql-hackers list.
* Ask for feedback, and pay attention both to what comes back and to silence.
* Lather, rinse, repeat.
* Avoid sending such proposals during a CommitFest.
=== Create A Specification ===
You can:
* Create this on your own.
* Solicit community help.
* Hire people to create the specification.
=== Gather Consensus on the Specification ===
* Send the specification back to pgsql-hackers and make sure you get affirmative agreement before proceeding further.
=== Submitting Patches ===
* Review Submitting a Patch prior to submitting your patch.
* During development, make sure you send patches early and often. Giant patch dumps are a great way to get your patch rejected and/or ignored.
* Send patches to the pgsql-hackers list along with a reminder of what has gone before. Pointers into the archives are good if some time has elapsed.
Category:Community
Category:Getting a patch accepted
HowToUseYourPostgreSQLMailAccount

== Logging In/Account Creation ==
Email accounts under @postgresql.org are not generally available, and are only
for specific use cases or for for a number of people who are "grandfathered" in.
== How to Access Your PostgreSQL.org Address ==
The postgresql.org mail system is accessible through various different interfaces, depending on how you want to use it you can choose between:
Webinterface: Go to postgresql.org webmail system and log in. This gets you into
RoundCube, a fairly simple webmail interface. It is even multi-lingual.
POP3/IMAP4: You can access imap.postgresql.org via POP3 or IMAP4 using the hostname imap.postgresql.org. Connections need to use TLS encryption, either directly or using STARTTLS. At least TLS 1.2 is required.
SMTP: we provide an authenticated-only SMTP relay service using the hostname smtp.postgresql.org. Connections need to use TLS encryption, either through smtps or STARTTLS.
HPUX XOpen sockets

Test results of compiling PostgreSQL and a small test program that uses libpq with different combinations of X/Open socket related options.
configure command-line used to compile PostgreSQL:
 ./configure --enable-cassert --enable-debug --with-perl --without-readline --with-libs=/opt/packages/zlib-1.2.5/inst/lib/hpux64:/opt/packages/libxslt-1.1.26/inst/lib/hpux64 --with-includes=/opt/packages/zlib-1.2.5/inst/include:/opt/packages/libxslt-1.1.26/inst/include --with-libxml --with-libxslt --prefix=/home/heikki/xopentest/inst CC=cc CFLAGS=+DD64
Base command-line used to compile test program:
 cc -Ae +DD64 xopentest.c -o xopentest -I /home/heikki/xopentest/inst/include -L /home/heikki/xopentest/inst/lib -lpq
PostgreSQL build	Additional options to test program build 	Result
unpatched 	<none> 	fail: Connection to database failed: could not get socket error status: Invalid argument
unpatched 	-lxnet -D_XOPEN_SOURCE_EXTENDED 	success
unpatched 	-lxnet -D_XOPEN_SOURCE_EXTENDED -D_HPUX_ALT_XOPEN_SOCKET_API	success
patched 	<none> 	success
patched 	-lxnet -D_XOPEN_SOURCE_EXTENDED 	success
patched 	-lxnet -D_XOPEN_SOURCE_EXTENDED -D_HPUX_ALT_XOPEN_SOCKET_API	success
Category:MOVE TO USERPAGE
Idempotent Deployment

= DDL for Idempotent Operations =
 	CREATE OR REPLACE	CREATE IF NOT EXISTS	DROP IF EXISTS
AGGREGATE 	Y (12) 	N 	Y
CAST 	N 	N 	Y
COLLATION 	N 	Y 	Y
CONVERSION 	N 	N 	Y
DATABASE 	N 	N 	Y
DOMAIN 	N 	N 	Y
EVENT TRIGGER 	N 	N 	Y
EXTENSION 	N 	Y 	Y
FOREIGN DATA WRAPPER 	N 	N 	Y
FOREIGN TABLE 	N 	Y 	Y
FUNCTION 	Y (7.2) 	N 	Y
GROUP 	N 	N 	Y
INDEX 	N 	Y (9.5) 	Y
LANGUAGE 	Y 	N 	Y
MATERIALIZED VIEW 	N 	Y (9.5) 	Y
OPERATOR 	N 	N 	Y
OPERATOR CLASS 	N 	N 	Y
OPERATOR FAMILY 	N 	N 	Y
PROCEDURE 	Y (11) 	N 	Y (11)
ROLE 	N 	N 	Y
RULE 	Y 	N 	Y
SCHEMA 	N 	Y 	Y
SEQUENCE 	N 	Y (9.5) 	Y
SERVER 	N 	Y (10) 	Y
STATISTICS 	N 	Y (10) 	Y
TABLE 	N 	Y 	Y
TABLE AS 	N 	Y 	N/A
TABLESPACE 	N 	N 	Y
TEXT SEARCH CONFIGURATION	N 	N 	Y
TEXT SEARCH DICTIONARY 	N 	N 	Y
TEXT SEARCH PARSER 	N 	N 	Y
TEXT SEARCH TEMPLATE 	N 	N 	Y
TRANSFORM 	Y (9.6) 	N 	Y (9.6)
TRIGGER 	Y (14) 	N 	Y
TYPE 	N 	N 	Y
USER 	N 	N 	Y
USER MAPPING 	N 	Y (10) 	Y
VIEW 	Y 	N 	Y
Identity Guidelines

= Identity Guidelines =
== Name==
The official name of the project is : PostgreSQL
The first letter and the last 3 letters ( SQL ) should be capitalized, and all letters should be in the same colour, to avoid accidentally emphasising an incorrect name, such as "Postgre".
Postgres is also accepted as an alternative name.
All other names are incorrect, especially Postgre
== Tagline ==
The world's most advanced open source relational database
Only the first letter is capitalized.
== Logo ==
The primary logo is an elephant head (known as Slonik)
Multiple version of the Logo are available :
* 3 colors : The head is blue, the inner border is white, the outer border is black.
* 1 color : Preferred colors are blue ( on lighter backgrounds) or white (on sufficiently dark backgrounds)
Image:PostgreSQL logo.3colors.120x120.png| 3 colors
Image:PostgreSQL_logo.1color_blue.300x300.png‎| 1 color blue
Image:PostgreSQL_logo.1color_white.120x120.png‎| 1 color white
In Japan, a turtle logo is used in place of the elephant due to domestic terrorist symbolism.
Use of the logo is subject to our Trademark Policy.
== Font ==
The font is called Strait and is available here.
Category:Advocacy
Incrementally Updated Backups

== Incrementally Updated Backups ==
In a standby configuration, it is possible to offload the expense of taking periodic base backups from the primary server; instead base backups can be made by backing up a standby server's files. This concept is generally known as incrementally updated backups, log change accumulation, or more simply, change accumulation.
=== Stopping the standby server ===
If we take a valid file system backup of the standby server's data directory, we will be able to use that new backup to create a new standby, or for continuous archive recovery of the master. We then no longer need to keep WAL files from before the new backup. If recovery is needed, it will be faster to recover from the incrementally updated backup than from the original base backup.
The easiest way to take a valid file system backup of the standby server is to completely stop the standby server (with, for example, pg_ctl stop, verifying that it did in fact stop), take a cold file-system backup of it and the WAL archive directory, and restart the standby.
To check if the server really stopped one could do:
 pg_controldata /path/to/data | grep "Database cluster state: *shut down" >/dev/null
 if [ $? -ne 0 ]; then
 # do some error handling
 fi
=== Without stopping the standby server ===
If stopping the standby is undesirable (for example, because it is a hot standby, or because it would then take too long to fail over should the primary fail), it is possible to take a file system backup while it is still processing logs shipped from the primary. However, this procedure is quite complicated and it must be followed carefully or the backup will not be valid. The steps are:
1. Perform pg_start_backup() on the master, noting the WAL filename and offset reported.
2. Copy the backup_label file from the primary's data directory to a temporary location:
 cp /path/to/master/backup_label /tmp
3. Run pg_controldata on the standby and wait for "Latest checkpoint's REDO location" to equal or exceed the WAL information reported by pg_start_backup(). You might need to call pg_switch_xlog() on the master to force the required WAL file to be sent to the standby.
4. Perform a file system backup of the standby's data directory.
5. Perform pg_stop_backup() on the master.
6. Move the saved backup_label file to the new backup directory:
 mv /tmp/backup_label /path/to/new_backup
== Existing implementation ==
[https://github.com/omniti-labs/omnipitr
 OmniPITR] set of tools for WAL replication does backups on slave server using similar technique, but without running any queries on master server. Instead it gets necessary information using pg_controldata calls on slave, and it builds backup_label (and backup "segment") files on its own.
Category:Backup
Indexable Operators

__NOTOC__
== Finding the operators usable with an index ==
When working with GiST or GIN indexes, it might not be immediately obvious which types of queries can use a particular index.
Typically, an indexable query has a WHERE clause of the form "indexed_column indexable_operator constant". For regular
btree and hash indexes, the indexable operators are just =, <, <=, >, >=. For a GiST or GIN index the indexable operators might be something else entirely. Here are queries that let you find out what operators can be used with any particular existing index.
This works with Postgres 8.3 and up:
SELECT
 pg_get_indexdef(ss.indexrelid, (ss.iopc).n, true) AS index_col,
 amop.amopopr::regoperator AS indexable_operator
FROM pg_opclass opc, pg_amop amop,
 (SELECT indexrelid, information_schema._pg_expandarray(indclass) AS iopc
 FROM pg_index
 WHERE indexrelid = 'INDEXNAME'::regclass) ss
WHERE amop.amopfamily = opc.opcfamily and opc.oid = (ss.iopc).x
ORDER BY (ss.iopc).n, indexable_operator;
(Replace INDEXNAME with the name of the index you're interested in.)
This works with Postgres 8.1 and 8.2:
SELECT
 pg_get_indexdef(ss.indexrelid, (ss.iopc).n, true) AS index_col,
 amop.amopopr::regoperator AS indexable_operator
FROM pg_amop amop,
 (SELECT indexrelid, information_schema._pg_expandarray(indclass) AS iopc
 FROM pg_index
 WHERE indexrelid = 'INDEXNAME'::regclass) ss
WHERE amop.amopclaid = (ss.iopc).x
ORDER BY (ss.iopc).n, indexable_operator;
== Sample Output ==
Given
create table t1 (f1 polygon);
create index i1 on t1 using gist(f1);
the output for index i1 would look like
 index_col | indexable_operator 
-----------+----------------------
 f1 | <<(polygon,polygon)
 f1 | &<(polygon,polygon)
 f1 | &>(polygon,polygon)
 f1 | >>(polygon,polygon)
 f1 | <@(polygon,polygon)
 f1 | @>(polygon,polygon)
 f1 | ~=(polygon,polygon)
 f1 | &&(polygon,polygon)
 f1 | <<|(polygon,polygon)
 f1 | &<|(polygon,polygon)
 f1 | |&>(polygon,polygon)
 f1 | |>>(polygon,polygon)
 f1 | @(polygon,polygon)
 f1 | ~(polygon,polygon)
(14 rows)
Category:SQL
Category:Indexes
Index Progress

== INDEX / REINDEX Progress in PostgreSQL 12+ ==
In PostgreSQL 12 and newer, there is pg_stat_progress_create_index that can help see the progress of INDEX or REINDEX:
select
 now(),
 query_start as started_at,
 now() - query_start as query_duration,
 format('[%s] %s', a.pid, a.query) as pid_and_query,
 index_relid::regclass as index_name,
 relid::regclass as table_name,
 (pg_size_pretty(pg_relation_size(relid))) as table_size,
 phase,
 nullif(wait_event_type, ) || ': ' || wait_event as wait_type_and_event,
 current_locker_pid,
 (select nullif(left(query, 150), ) || '...' from pg_stat_activity a where a.pid = current_locker_pid) as current_locker_query,
 format(
 '%s (%s of %s)',
 coalesce((round(100 * lockers_done::numeric / nullif(lockers_total, 0), 2))::text || '%', 'N/A'),
 coalesce(lockers_done::text, '?'),
 coalesce(lockers_total::text, '?')
 ) as lockers_progress,
 format(
 '%s (%s of %s)',
 coalesce((round(100 * blocks_done::numeric / nullif(blocks_total, 0), 2))::text || '%', 'N/A'),
 coalesce(blocks_done::text, '?'),
 coalesce(blocks_total::text, '?')
 ) as blocks_progress,
 format(
 '%s (%s of %s)',
 coalesce((round(100 * tuples_done::numeric / nullif(tuples_total, 0), 2))::text || '%', 'N/A'),
 coalesce(tuples_done::text, '?'),
 coalesce(tuples_total::text, '?')
 ) as tuples_progress,
 format(
 '%s (%s of %s)',
 coalesce((round(100 * partitions_done::numeric / nullif(partitions_total, 0), 2))::text || '%', 'N/A'),
 coalesce(partitions_done::text, '?'),
 coalesce(partitions_total::text, '?')
 ) as partitions_progress
from pg_stat_progress_create_index p
left join pg_stat_activity a on a.pid = p.pid
; -- in psql, use "\watch 5" instead of semicolon to run in loop
Información de Desarrollo

__NOTOC__
Esta área incluye la documentación de desarrollo orientada sobre los aspectos de desarrollo de PostgreSQL. Por favor, visite developer areael área de desarrollo del sitio web de PostgreSQL para obtener más información sobre el desarrollo de PostgreSQL. Usted puede encontrar la mayoría de los desarrolladores en #postgresql en Libera. Una lista de nicks de IRC con sus respectivos nombres del mundo real se puede encontrar aquí.
==PostgreSQL 9.1 - Desarrollo Activo==
* PostgreSQL 9.1 Plan de Desarrollo
* PostgreSQL 9.1 Open Items
==PostgreSQL 9.0 - Release Preparation==
* PostgreSQL 9.0 Open Items
* 9.0 Alpha Release Feature List
==Proceso de Desarrollo==
* Todo list
* Unofficial Todo Detail
* Submitting a Patch
* Reviewing a Patch
* Round-robin Patch Review
* Running a CommitFest
* Committing with Git
== Recursos para Desarrolladores ==
* FAQ Desarrolladores
* Regression test authoring
* HOWTO Alpha and Beta Test PostgreSQL
* Trabajando con Git
* Trabajando con CVS (obsoleto)
* Trabajando con Eclipse (usando CVS)
* Trabajando con Visual Studio Code
* Fixing shift/reduce conflicts in Bison
* Procedural Language Matrix
* Feature Matrix
* PostgreSQL Coding
* Development docs (updated every 5 minutes)
== Planes y Projectos? ==
* Open CommitFest - New patch submissions for 9.1
* CommitFest
* PostgreSQL 8.4
* PgCon 2009 Developer Meeting
* PgCon 2008 Developer Meeting
* Development projects - links to individual projects
Category:CommitFest