https://wiki.postgresql.org/api.php?action=feedcontributions&user=Ishii&feedformat=atomPostgreSQL wiki - User contributions [en]2024-03-19T03:59:07ZUser contributionsMediaWiki 1.35.13https://wiki.postgresql.org/index.php?title=PgCon_2023_Developer_Meeting&diff=37688PgCon 2023 Developer Meeting2023-03-24T02:55:13Z<p>Ishii: /* RSVPs */</p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Tuesday 30 May, 2023 at the University of Ottawa, prior to pgCon 2023. In order to keep the numbers manageable, this meeting is by '''invitation only'''.<br />
Any questions regarding the invitations to this event should be directed to the team of individuals tasked with coming up with the list of people to invite:<br />
<br />
* Andres Freund<br />
* Stephen Frost<br />
* Dave Page<br />
<br />
An Unconference will be held on Friday for in-depth discussion of technical topics.<br />
<br />
This is a PostgreSQL Community event.<br />
<br />
== Meeting Goals ==<br />
<br />
* Define the schedule for the upcoming releases<br />
* Address any proposed timing, policy, or procedure issues<br />
* Receive updates from project sub-teams on their activities and discuss any resulting issues or concerns.<br />
* Address any proposed [http://en.wikipedia.org/wiki/Wicked_problem Wicked problems]<br />
<br />
== Time & Location ==<br />
<br />
The meeting will (probably) be:<br />
<br />
* 9:00AM to 12PM<br />
* DMS 3105 - Desmarais Hall, 55 Laurier Avenue East<br />
* University of Ottawa.<br />
<br />
Lunch will be served during the meeting.<br />
<br />
== COVID-19 ==<br />
<br />
The University of Ottawa's COVID-19 guidance can be found at https://www.uottawa.ca/en/covid-19. Wearing of masks at the Developer Meeting will be optional, however we do ask that people do not attend if they have COVID symptoms or have tested positive.<br />
<br />
== RSVPs ==<br />
<br />
The following people have RSVPed to the meeting (in alphabetical order, by surname). Note that we can accommodate a '''maximum of 30'''!<br />
<br />
# Joe Conway<br />
# Jeff Davis<br />
# Andres Freund<br />
# Stephen Frost<br />
# Etsuro Fujita<br />
# Jonathan Katz<br />
# Alexander Korotkov<br />
# Tom Lane<br />
# Noah Misch<br />
# Thomas Munro<br />
# Dave Page<br />
# Michael Paquier<br />
# Melanie Plageman<br />
<br />
The following people will not be in Ottawa, and do not plan to attend:<br />
<br />
# Tatsuo Ishii<br />
<br />
== Agenda Items ==<br />
<br />
* 16.0 release and commitfest schedule (Dave)<br />
* ''Please add suggestions for agenda items here. (with your name)''<br />
<br />
==Agenda==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:10<br />
|Welcome and introductions<br />
|Dave Page<br />
<br />
|- <br />
|09:10 - 09:20<br />
|Release and commitfest schedules<br />
|Dave Page<br />
<br />
|- <br />
|??:?? - ??:??<br />
|TBD<br />
|TBD<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<br />
|Coffee break<br />
|All<br />
<br />
|- <br />
|??:?? - ??:??<br />
|TBD<br />
|TBD<br />
<br />
|- <br />
|11:50 - 12:00<br />
|Any other business<br />
|Dave Page<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:00<br />
|Lunch<br />
|<br />
<br />
|}<br />
<br />
Note: This timetable is a rough guide only. Items will start as soon as the previous discussion is complete (breaks will not move materially however). Any remaining time before lunch may be used for Commitfest item triage or other activities.<br />
<br />
[[Category:Developer Meeting]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Incremental_View_Maintenance&diff=34134Incremental View Maintenance2019-10-01T05:19:01Z<p>Ishii: /* Restrictions on view definition */</p>
<hr />
<div>This page describes Incremental View Maintenance (IVM) proposed in pgsql-hackers. <br />
<br />
= Overview =<br />
<br />
PostgreSQL has supported materialized views since 9.3. This feature is used to speed up query evaluation by storing the results of specified queries. One problem of materialized view is its maintenance. Materialized views have to be brought up to date when the underling base relations are updated. <br />
<br />
Incremental View Maintenance (IVM) is a technique to maintain materialized views which computes and applies only the incremental changes to the materialized views rather than recomputing the contents as the current REFRESH command does. This feature is not implemented on PostgreSQL yet. Implementing this into PostgreSQL core was proposed firstly at [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews|PgCon 2013 Developer Meeting]] and [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com][https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com]. There were also other discussions on IVM [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost] [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com]. The first patch was submitted in 2019[https://www.postgresql.org/message-id/20190514154648.63fea174748c18ed7f7dcb16%40sraoss.co.jp].<br />
<br />
= Basic Theory of IVM =<br />
<br />
IVM computes and applies only the incremental changes to the materialized views. Suppose that view V is defined by query Q over a state of base relations D. When D changes D' = D + dD, we can get the new view state V' by calculating from D' and Q, and this is re-computation performed by REFRESH MATERIALIZED VIEW command. On the other hand, IVM calculates the delta for view (dV) from the base tables delta (dD) and view definition (Q), and applies this to get the new view state, V' = V + dV.<br />
<br />
In theory, the view definition is described in a relational algebra (or bag algebra) form. For example, a (inner) join view of table R and S is defined as V = R ⨝ S. <br />
<br />
When table R is changed in a transaction, this can be described as R ← R - ∇R + ΔR, where ∇R and ΔR denote tuples deleted from and inserted into R, respectively. (To be accurate, instead of - and +, ∸ and ⨄ are used by tradition in bag algebra.) In this condition, the deltas of the view are calculated as ∇V = ∇R ⨝ S and ΔV = ΔR ⨝ S, then the view can be updated as V ← V - ∇V + ΔV.<br />
<br />
= How to extract changes on base tables =<br />
<br />
There are at least two approaches. One is using AFTER triggers and Transition Tables, which is a feature of AFTER trigger introduced from PostgreSQL 10. This was implemented originally aiming to support IVM, and in fact the proposed patch uses this. This enables collect row sets that include all of the rows inserted, deleted, or modified by the current SQL statement. These row sets can be referred as tables of specified name. OLD TABLE contains the before-images of all rows updated or deleted by the statement. Similarly, NEW TABLE contains the after-images of all rows updated or inserted by the statement. These two tables correspond ∇R and ΔR, respectively.<br />
<br />
Another candidate is using logical decoding of WAL.<br />
<br />
= How to calculate the delta to be applied to materialized views =<br />
<br />
This is basically based on relational algebra or bag algebra. In theory, we can handle various view definition. Views can be defined using several operations: selection, projection, join, aggregation, union, difference, intersection, etc. If we can prepare a module for each operation, there is possibility of extensive implementation of IVM.<br />
<br />
However, we started from a simple view definition. The proposed patch currently supports selection-projection-join and some aggregations.<br />
<br />
= When to maintain materialized views =<br />
<br />
There are two approaches, immediate maintenance and deferred maintenance. <br />
<br />
== Immediate View Maintenance ==<br />
<br />
In immediate maintenance, views are updated in the same transaction where the base table is updated. <br />
<br />
The proposed patch implements a kind of immediate maintenance, that is, materialized views are updated immediately in AFTER triggers when a base table is modified. SQL statement modify only one base table and the changes can be extracted by using Transition Tables mentioned above.<br />
<br />
In addition, there could be another implementation of Immediate Maintenance, in which materialized views are updated at the end of a transaction that modified base table, rather than in AFTER trigger. Oracle supports this type of IVM. To implement this, we will need a mechanism to maintain change logs on base tables as well as Deferred maintenance as said bellow.<br />
<br />
== Deferred View Maintenance ==<br />
<br />
In deferred maintenance, views are updated after the transaction is committed, for example, when the view is accessed, as a response to user command like REFRESH, or updated periodically, and so on.<br />
<br />
In order to implement "deferred", it is need to implement a mechanism to maintain logs for recording changes of base tables. An algorithm to compute the delta to be applied to views are also to be considered because more than one tables could be modified a lot of times before a view is updated.<br />
<br />
= How to handle views with tuple duplicates or DISTINCT clause =<br />
<br />
We need some considerations to support materialized views including duplicate tuples or DISTINCT clause in its definition query. <br />
<br />
For example, if there are two same tuples in a view and we would like to delete only one tuple rather than both of two. In this situation, we can not use DELETE statement simply, because this will delete both of tow tuples. <br />
<br />
As another example, suppose a materialized view is defined with DISTINCT and there are duplicate tuples in its base table. The duplicates in the base table are eliminated due to DISTINCT. Then, when we would like to apply delta tables to this view, how we should update the view? When deleting tuples from the base table, a tuple in the view should be deleted if and only if the duplicity of the tuple becomes zero. Else, the tuple must remain in the view. Moreover, as for tuple insertion, we can insert a tuple into the view only if the same tuple doesn't exist in the view. If there is already the same one, additional tuple must not be inserted since duplicate is not allowed.<br />
<br />
== counting algorithm ==<br />
<br />
Counting algorithm is an algorithm for handling tuple duplicates or DISTINCT clause in IVM. In this algorithm, the number of same tuples is counted and stored in the materialized views as duplicity of each tuple. When tuples are to be inserted into the view, the count is increased if there is already the same one. Otherwize, if the same tuple doesn't exist, a new tuple is inserted. Similarly, when tuples are to be deleted from the view, the count is decreased. If the count becomes zero, this tuple is deleted from the view.<br />
<br />
= How to identify rows to be modified in materialized views =<br />
<br />
When applying the delta to materialized views, we have to identify which tuple in materialized views is corresponding to a tuple in the delta. A naive method is matching by using all columns in a tuple, but clearly this is inefficient. If a materialized view has unique index, we can use this. Any way, for efficient IVM, appropriate index will be necessary on the materialized view. Maybe, REPLICA IDENTITY (or something similar) is useful.<br />
<br />
= Implementation details =<br />
<br />
This section describes details of the proposed patch's implementation<br />
<br />
This patch implements a kind of Immediate Maintenance of materialized views. If a materialized view created with IVM option, the contents of this view is updated automatically and incrementally after base tables are updated. <br />
<br />
== Creating Materialized Views ==<br />
<br />
Materialized view with IVM option created by CRATE INCREMENTAL MATERIALIZED VIEW command. Noted this syntax is just tentative, so it may be changed.<br />
<br />
When a materialized view is created, AFTER triggers are internally created on its all base tables. When the base tables is modified (INSERT, DELETE,<br />
UPDATE), this view is updated incrementally in the trigger function.<br />
<br />
Before populating the materialized view, GROUP BY and count(*) are added to the view definition query for counting duplicity of tuples in the view. The result of count is stored in the view as a special column named "__ivm_count__". <br />
<br />
== Maintenance of Materialized View ==<br />
<br />
When base tables are modified, the change set of the table can be referred as Ephemeral Named Relations (ENRs) thanks to Transition Table. We can calculate the diff set of the view by replacing the base table in the view definition query with the ENR (at least if it is Selection-Projection -Join view). As well as view definition time, GROUP BY and count(*) is added in order to count the duplicity of tuples in the diff set. As a result, two diff sets (to be deleted from and to be inserted into the view) are calculated, and the results are stored into temporary tables respectively.<br />
<br />
The view is updated by merging these change sets. Instead of executing DELETE or INSERT simply, the values of __ivm_count__ column in the view is decreased or increased. When the values becomes zero, the corresponding tuple is deleted from the view.<br />
<br />
== Aggregation support ==<br />
<br />
Currently, count sum, min, max and avg are supported.<br />
<br />
As a restriction, expressions specified in GROUP BY must appear in the target list of views because tuples to be updated in materialized views are identified by using this group keys. When creating a materialized view, more than one hidden columns for each aggregation are added to the target list. The name of these hidden column is like __ivm_count_sum__, for example.<br />
<br />
In the case of views without aggregate functions, only the number of tuple duplicates (__ivm_count__) are updated at incremental maintenance. On the other <br />
hand, in the case of vies with aggregations, the aggregated values and related hidden columns are also updated. The way of update depends the kind of aggregate function. Specifically, sum and count are updated by adding or subtracting delta values. avg is updated by using values of sum and count stored in views as hidden columns and deltas of them.<br />
<br />
In the case of sum and avg (or any aggregation functions except to count), NULL in input values is ignored, and this returns a null value when no rows are selected. To support this specification, the number of not-NULL input values is counted and stored in views as a hidden column. In the case of count, this returns zero when no rows are selected, and count(*) doesn't ignore NULL input. These specification are also supported.<br />
<br />
Tuples to be updated in materialized views are identified by using keys specified by GROUP BY clause. However, in the case of aggregation without GROUP BY, there is only one tuple in the view, so keys are not uses to identify tuples.<br />
<br />
== Access to Materialized Views ==<br />
<br />
When SELECT is issued for materialized views with IVM support defined with DISTINCT, all columns except to __ivm_count__ of each tuple are returned. This is correct because duplicity of tuples are eliminated by GROUP BY.<br />
<br />
When DISTINCT is not used, the query returns each tuple __ivm_count__ times. Currently, this is implemented by rewriting the SELECT<br />
query to replace the view RTE with a subquery which joins the view and generate_series function as bellow. <br />
<br />
SELECT mv.* FROM mv, generate_series(1, mv.__ivm_count__);<br />
<br />
__ivm_count__ column is invisible for users when "SELECT * FROM ..." is issued, but users can see the value by specifying in target list explicitly.<br />
<br />
<br />
== Restrictions on view definition ==<br />
<br />
The current implementation supports views including selection, projection, inner join with or without DISTINCT, and some aggregations (count, sum, min, max, agv) and GROUP BY (HAVING is not supported).<br />
Self-join is also supported.<br />
Subquery support and outer join support are on our plan. CTE and window functions are not supported.<br />
<br />
Incremental materialized view on view, materialized view or incremental materialized view are not supported.<br />
<br />
== Timing of view maintenance ==<br />
<br />
This patch implements only a kind of Immediate Maintenance. For implementing Deferred Maintenance, we need a infrastructure to maintain these logs. For example, which logs are necessary and which logs can be discarded, etc.<br />
<br />
== Counting algorithm implementation ==<br />
<br />
The proposed patch treats "__ivm_count__" as a special column name in a somewhat ad hoc way. This is used when maintaining and accessing materialized views. When "SELECT * FROM ..." is issued to views, __ivm_count__ column is invisible for users. Note that users can not use this name as a user column in materialized views with IVM support. As for how to make internal columns invisible to SELECT *, there have been other discussions about doing that using a new flag in pg_attribute[https://www.postgresql.org/message-id/flat/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com].<br />
<br />
When a materialized view with duplicate tuples is accessed, this is replaced with a subquery which uses generate_series function. It does not have to be generate_series, and we can make a new set returning function for this. Anyway, this internal behaviour is visible in EXPLAIN results as below. <br />
<br />
postgres=# EXPLAIN SELECT * FROM m1;<br />
QUERY PLAN <br />
------------------------------------------------------------------------------<br />
Nested Loop (cost=0.00..61.03 rows=3000 width=2)<br />
-> Seq Scan on m1 mv (cost=0.00..1.03 rows=3 width=10)<br />
-> Function Scan on generate_series (cost=0.00..10.00 rows=1000 width=0)<br />
(3 rows)<br />
<br />
Also, there would be performance impact because estimated rows number by optimizer is wrong, and what is worse, the cost of join is not small when the size of view is large. Therefore, we might have to add a new plan node for selecting from materialized views with IVM support rather than using a special set returning function.<br />
<br />
== Concurrent Transactions ==<br />
<br />
When a view is defined on two tables and each table is modified in different concurrent transactions respectively, if a change in one transaction was not considered in another transaction in READ COMMITTED level, an anormal update of the materialized view would be possible. To prevent this, a lock on the materialized view is taken in early stage of view maintenance to wait for concurrent transactions which are updating the same view to end. Also, the latest snapshot is taken before computing delta tables to make any changes which occurs in other transaction during lock waiting visible.<br />
<br />
In REPEATABLE READ or SERIALIZABLE level, don't wait a lock, and raise an error immediately to prevent anormal update because table changes occurred in other transactions must not be visible, and views can not be maintained correctly in AFTER triggers.<br />
<br />
These solutions might be ugly, but something to prevent anormal update is anyway necessary. There may be better way. One idea to resolve this is performing view maintenance in two phases. Firstly, views are updated using only table changes visible in this transaction. Then, just after this transaction is committed, views have to be updated additionally using changes happened in other transactions to keep consistency. This is a just idea, but to implement this idea, we will need keep to keep and maintain change logs.<br />
<br />
= Links =<br />
<br />
== CommitFest ==<br />
<br />
* [https://commitfest.postgresql.org/23/2138/ Incremental Materialized View Maintenance]<br />
<br />
== Talks ==<br />
<br />
* [https://www.pgcon.org/2019/schedule/events/1316.en.html Towards Implementing Incremental View Maintenance on PostgreSQL (PGCon 2019) ]<br />
* [https://www.postgresql.eu/events/pgconfeu2018/schedule/session/2195-implementing-incremental-view-maintenance-on-postgresql/ Implementing Incremental View Maintenance on PostgreSQL (PGConf.EU 2018) ]<br />
* [https://wiki.postgresql.org/images/8/85/Materialised_Views_-_FOSDEM.pdf Materialised views now and the future (PGDay FOSDEM 2014)]<br />
<br />
== Wiki==<br />
* [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews]]<br />
* [[Materialized Views]]<br />
<br />
== pgsql-hackers ==<br />
* [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com counting algorithm for incremental matview maintenance]<br />
* [https://www.postgresql.org/message-id/1368557513.95389.YahooMailNeo%40web162903.mail.bf1.yahoo.com Differential (transactional) REFRESH]<br />
* [https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com matview incremental maintenance]<br />
* [https://www.postgresql.org/message-id/flat/1371225929.28496.YahooMailNeo%40web162905.mail.bf1.yahoo.com refresh materialized view concurrently]<br />
* [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost Alternative MATERIALIZED VIEW design and implementation with history table and other features]<br />
* [https://www.postgresql.org/message-id/1402790204.65037.YahooMailNeo@web122301.mail.ne1.yahoo.com delta relations in AFTER triggers]<br />
* [https://www.postgresql.org/message-id/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com "SELECT *" vs hidden columns and logical column order]<br />
* [https://www.postgresql.org/message-id/flat/20141209174146.GP1768@alvh.no-ip.org logical column ordering]<br />
<br />
* [https://www.postgresql.org/message-id/154a391d341.1176179cb4319.144192970510819074%40zohocorp.com Incremental refresh of materialized view - Patch]<br />
* [https://www.postgresql.org/message-id/20170123233819.GD1838%40localhost Contrib: alternative MATERIALIZED VIEWs]<br />
* [https://www.postgresql.org/message-id/flat/CAKLmikMjJqVJbKijOxivhb9%3DA5PfoZcit2QowbJ4rFszzr4Zhw%40mail.gmail.com#b7829393acf1cfcbc507b137f5ebaeab Implementing Incremental View Maintenance]<br />
<br />
==pgsql-general ==<br />
* [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com Incrementally refreshed materialized view ]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Incremental_View_Maintenance&diff=34131Incremental View Maintenance2019-10-01T04:33:18Z<p>Ishii: /* Restrictions on view definition */</p>
<hr />
<div>This page describes Incremental View Maintenance (IVM) proposed in pgsql-hackers. <br />
<br />
= Overview =<br />
<br />
PostgreSQL has supported materialized views since 9.3. This feature is used to speed up query evaluation by storing the results of specified queries. One problem of materialized view is its maintenance. Materialized views have to be brought up to date when the underling base relations are updated. <br />
<br />
Incremental View Maintenance (IVM) is a technique to maintain materialized views which computes and applies only the incremental changes to the materialized views rather than recomputing the contents as the current REFRESH command does. This feature is not implemented on PostgreSQL yet. Implementing this into PostgreSQL core was proposed firstly at [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews|PgCon 2013 Developer Meeting]] and [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com][https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com]. There were also other discussions on IVM [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost] [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com]. The first patch was submitted in 2019[https://www.postgresql.org/message-id/20190514154648.63fea174748c18ed7f7dcb16%40sraoss.co.jp].<br />
<br />
= Basic Theory of IVM =<br />
<br />
IVM computes and applies only the incremental changes to the materialized views. Suppose that view V is defined by query Q over a state of base relations D. When D changes D' = D + dD, we can get the new view state V' by calculating from D' and Q, and this is re-computation performed by REFRESH MATERIALIZED VIEW command. On the other hand, IVM calculates the delta for view (dV) from the base tables delta (dD) and view definition (Q), and applies this to get the new view state, V' = V + dV.<br />
<br />
In theory, the view definition is described in a relational algebra (or bag algebra) form. For example, a (inner) join view of table R and S is defined as V = R ⨝ S. <br />
<br />
When table R is changed in a transaction, this can be described as R ← R - ∇R + ΔR, where ∇R and ΔR denote tuples deleted from and inserted into R, respectively. (To be accurate, instead of - and +, ∸ and ⨄ are used by tradition in bag algebra.) In this condition, the deltas of the view are calculated as ∇V = ∇R ⨝ S and ΔV = ΔR ⨝ S, then the view can be updated as V ← V - ∇V + ΔV.<br />
<br />
= How to extract changes on base tables =<br />
<br />
There are at least two approaches. One is using AFTER triggers and Transition Tables, which is a feature of AFTER trigger introduced from PostgreSQL 10. This was implemented originally aiming to support IVM, and in fact the proposed patch uses this. This enables collect row sets that include all of the rows inserted, deleted, or modified by the current SQL statement. These row sets can be referred as tables of specified name. OLD TABLE contains the before-images of all rows updated or deleted by the statement. Similarly, NEW TABLE contains the after-images of all rows updated or inserted by the statement. These two tables correspond ∇R and ΔR, respectively.<br />
<br />
Another candidate is using logical decoding of WAL.<br />
<br />
= How to calculate the delta to be applied to materialized views =<br />
<br />
This is basically based on relational algebra or bag algebra. In theory, we can handle various view definition. Views can be defined using several operations: selection, projection, join, aggregation, union, difference, intersection, etc. If we can prepare a module for each operation, there is possibility of extensive implementation of IVM.<br />
<br />
However, we started from a simple view definition. The proposed patch currently supports selection-projection-join and some aggregations.<br />
<br />
= When to maintain materialized views =<br />
<br />
There are two approaches, immediate maintenance and deferred maintenance. <br />
<br />
== Immediate View Maintenance ==<br />
<br />
In immediate maintenance, views are updated in the same transaction where the base table is updated. <br />
<br />
The proposed patch implements a kind of immediate maintenance, that is, materialized views are updated immediately in AFTER triggers when a base table is modified. SQL statement modify only one base table and the changes can be extracted by using Transition Tables mentioned above.<br />
<br />
In addition, there could be another implementation of Immediate Maintenance, in which materialized views are updated at the end of a transaction that modified base table, rather than in AFTER trigger. Oracle supports this type of IVM. To implement this, we will need a mechanism to maintain change logs on base tables as well as Deferred maintenance as said bellow.<br />
<br />
== Deferred View Maintenance ==<br />
<br />
In deferred maintenance, views are updated after the transaction is committed, for example, when the view is accessed, as a response to user command like REFRESH, or updated periodically, and so on.<br />
<br />
In order to implement "deferred", it is need to implement a mechanism to maintain logs for recording changes of base tables. An algorithm to compute the delta to be applied to views are also to be considered because more than one tables could be modified a lot of times before a view is updated.<br />
<br />
= How to handle views with tuple duplicates or DISTINCT clause =<br />
<br />
We need some considerations to support materialized views including duplicate tuples or DISTINCT clause in its definition query. <br />
<br />
For example, if there are two same tuples in a view and we would like to delete only one tuple rather than both of two. In this situation, we can not use DELETE statement simply, because this will delete both of tow tuples. <br />
<br />
As another example, suppose a materialized view is defined with DISTINCT and there are duplicate tuples in its base table. The duplicates in the base table are eliminated due to DISTINCT. Then, when we would like to apply delta tables to this view, how we should update the view? When deleting tuples from the base table, a tuple in the view should be deleted if and only if the duplicity of the tuple becomes zero. Else, the tuple must remain in the view. Moreover, as for tuple insertion, we can insert a tuple into the view only if the same tuple doesn't exist in the view. If there is already the same one, additional tuple must not be inserted since duplicate is not allowed.<br />
<br />
== counting algorithm ==<br />
<br />
Counting algorithm is an algorithm for handling tuple duplicates or DISTINCT clause in IVM. In this algorithm, the number of same tuples is counted and stored in the materialized views as duplicity of each tuple. When tuples are to be inserted into the view, the count is increased if there is already the same one. Otherwize, if the same tuple doesn't exist, a new tuple is inserted. Similarly, when tuples are to be deleted from the view, the count is decreased. If the count becomes zero, this tuple is deleted from the view.<br />
<br />
= How to identify rows to be modified in materialized views =<br />
<br />
When applying the delta to materialized views, we have to identify which tuple in materialized views is corresponding to a tuple in the delta. A naive method is matching by using all columns in a tuple, but clearly this is inefficient. If a materialized view has unique index, we can use this. Any way, for efficient IVM, appropriate index will be necessary on the materialized view. Maybe, REPLICA IDENTITY (or something similar) is useful.<br />
<br />
= Implementation details =<br />
<br />
This section describes details of the proposed patch's implementation<br />
<br />
This patch implements a kind of Immediate Maintenance of materialized views. If a materialized view created with IVM option, the contents of this view is updated automatically and incrementally after base tables are updated. <br />
<br />
== Creating Materialized Views ==<br />
<br />
Materialized view with IVM option created by CRATE INCREMENTAL MATERIALIZED VIEW command. Noted this syntax is just tentative, so it may be changed.<br />
<br />
When a materialized view is created, AFTER triggers are internally created on its all base tables. When the base tables is modified (INSERT, DELETE,<br />
UPDATE), this view is updated incrementally in the trigger function.<br />
<br />
Before populating the materialized view, GROUP BY and count(*) are added to the view definition query for counting duplicity of tuples in the view. The result of count is stored in the view as a special column named "__ivm_count__". <br />
<br />
== Maintenance of Materialized View ==<br />
<br />
When base tables are modified, the change set of the table can be referred as Ephemeral Named Relations (ENRs) thanks to Transition Table. We can calculate the diff set of the view by replacing the base table in the view definition query with the ENR (at least if it is Selection-Projection -Join view). As well as view definition time, GROUP BY and count(*) is added in order to count the duplicity of tuples in the diff set. As a result, two diff sets (to be deleted from and to be inserted into the view) are calculated, and the results are stored into temporary tables respectively.<br />
<br />
The view is updated by merging these change sets. Instead of executing DELETE or INSERT simply, the values of __ivm_count__ column in the view is decreased or increased. When the values becomes zero, the corresponding tuple is deleted from the view.<br />
<br />
== Aggregation support ==<br />
<br />
Currently, count sum, min, max and avg are supported.<br />
<br />
As a restriction, expressions specified in GROUP BY must appear in the target list of views because tuples to be updated in materialized views are identified by using this group keys. When creating a materialized view, more than one hidden columns for each aggregation are added to the target list. The name of these hidden column is like __ivm_count_sum__, for example.<br />
<br />
In the case of views without aggregate functions, only the number of tuple duplicates (__ivm_count__) are updated at incremental maintenance. On the other <br />
hand, in the case of vies with aggregations, the aggregated values and related hidden columns are also updated. The way of update depends the kind of aggregate function. Specifically, sum and count are updated by adding or subtracting delta values. avg is updated by using values of sum and count stored in views as hidden columns and deltas of them.<br />
<br />
In the case of sum and avg (or any aggregation functions except to count), NULL in input values is ignored, and this returns a null value when no rows are selected. To support this specification, the number of not-NULL input values is counted and stored in views as a hidden column. In the case of count, this returns zero when no rows are selected, and count(*) doesn't ignore NULL input. These specification are also supported.<br />
<br />
Tuples to be updated in materialized views are identified by using keys specified by GROUP BY clause. However, in the case of aggregation without GROUP BY, there is only one tuple in the view, so keys are not uses to identify tuples.<br />
<br />
== Access to Materialized Views ==<br />
<br />
When SELECT is issued for materialized views with IVM support defined with DISTINCT, all columns except to __ivm_count__ of each tuple are returned. This is correct because duplicity of tuples are eliminated by GROUP BY.<br />
<br />
When DISTINCT is not used, the query returns each tuple __ivm_count__ times. Currently, this is implemented by rewriting the SELECT<br />
query to replace the view RTE with a subquery which joins the view and generate_series function as bellow. <br />
<br />
SELECT mv.* FROM mv, generate_series(1, mv.__ivm_count__);<br />
<br />
__ivm_count__ column is invisible for users when "SELECT * FROM ..." is issued, but users can see the value by specifying in target list explicitly.<br />
<br />
<br />
== Restrictions on view definition ==<br />
<br />
The current implementation supports views including selection, projection, inner join with or without DISTINCT, and some aggregations (count, sum, min, max, agv) and GROUP BY (HAVING is not supported).<br />
Self-join is also supported.<br />
Subquery support and outer join support are on our plan. CTE and window functions are not supported.<br />
<br />
Incremental materialized view on view, materialized view or incremental materialized view are not supported as well.<br />
<br />
== Timing of view maintenance ==<br />
<br />
This patch implements only a kind of Immediate Maintenance. For implementing Deferred Maintenance, we need a infrastructure to maintain these logs. For example, which logs are necessary and which logs can be discarded, etc.<br />
<br />
== Counting algorithm implementation ==<br />
<br />
The proposed patch treats "__ivm_count__" as a special column name in a somewhat ad hoc way. This is used when maintaining and accessing materialized views. When "SELECT * FROM ..." is issued to views, __ivm_count__ column is invisible for users. Note that users can not use this name as a user column in materialized views with IVM support. As for how to make internal columns invisible to SELECT *, there have been other discussions about doing that using a new flag in pg_attribute[https://www.postgresql.org/message-id/flat/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com].<br />
<br />
When a materialized view with duplicate tuples is accessed, this is replaced with a subquery which uses generate_series function. It does not have to be generate_series, and we can make a new set returning function for this. Anyway, this internal behaviour is visible in EXPLAIN results as below. <br />
<br />
postgres=# EXPLAIN SELECT * FROM m1;<br />
QUERY PLAN <br />
------------------------------------------------------------------------------<br />
Nested Loop (cost=0.00..61.03 rows=3000 width=2)<br />
-> Seq Scan on m1 mv (cost=0.00..1.03 rows=3 width=10)<br />
-> Function Scan on generate_series (cost=0.00..10.00 rows=1000 width=0)<br />
(3 rows)<br />
<br />
Also, there would be performance impact because estimated rows number by optimizer is wrong, and what is worse, the cost of join is not small when the size of view is large. Therefore, we might have to add a new plan node for selecting from materialized views with IVM support rather than using a special set returning function.<br />
<br />
== Concurrent Transactions ==<br />
<br />
When a view is defined on two tables and each table is modified in different concurrent transactions respectively, if a change in one transaction was not considered in another transaction in READ COMMITTED level, an anormal update of the materialized view would be possible. To prevent this, a lock on the materialized view is taken in early stage of view maintenance to wait for concurrent transactions which are updating the same view to end. Also, the latest snapshot is taken before computing delta tables to make any changes which occurs in other transaction during lock waiting visible.<br />
<br />
In REPEATABLE READ or SERIALIZABLE level, don't wait a lock, and raise an error immediately to prevent anormal update because table changes occurred in other transactions must not be visible, and views can not be maintained correctly in AFTER triggers.<br />
<br />
These solutions might be ugly, but something to prevent anormal update is anyway necessary. There may be better way. One idea to resolve this is performing view maintenance in two phases. Firstly, views are updated using only table changes visible in this transaction. Then, just after this transaction is committed, views have to be updated additionally using changes happened in other transactions to keep consistency. This is a just idea, but to implement this idea, we will need keep to keep and maintain change logs.<br />
<br />
= Links =<br />
<br />
== CommitFest ==<br />
<br />
* [https://commitfest.postgresql.org/23/2138/ Incremental Materialized View Maintenance]<br />
<br />
== Talks ==<br />
<br />
* [https://www.pgcon.org/2019/schedule/events/1316.en.html Towards Implementing Incremental View Maintenance on PostgreSQL (PGCon 2019) ]<br />
* [https://www.postgresql.eu/events/pgconfeu2018/schedule/session/2195-implementing-incremental-view-maintenance-on-postgresql/ Implementing Incremental View Maintenance on PostgreSQL (PGConf.EU 2018) ]<br />
* [https://wiki.postgresql.org/images/8/85/Materialised_Views_-_FOSDEM.pdf Materialised views now and the future (PGDay FOSDEM 2014)]<br />
<br />
== Wiki==<br />
* [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews]]<br />
* [[Materialized Views]]<br />
<br />
== pgsql-hackers ==<br />
* [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com counting algorithm for incremental matview maintenance]<br />
* [https://www.postgresql.org/message-id/1368557513.95389.YahooMailNeo%40web162903.mail.bf1.yahoo.com Differential (transactional) REFRESH]<br />
* [https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com matview incremental maintenance]<br />
* [https://www.postgresql.org/message-id/flat/1371225929.28496.YahooMailNeo%40web162905.mail.bf1.yahoo.com refresh materialized view concurrently]<br />
* [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost Alternative MATERIALIZED VIEW design and implementation with history table and other features]<br />
* [https://www.postgresql.org/message-id/1402790204.65037.YahooMailNeo@web122301.mail.ne1.yahoo.com delta relations in AFTER triggers]<br />
* [https://www.postgresql.org/message-id/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com "SELECT *" vs hidden columns and logical column order]<br />
* [https://www.postgresql.org/message-id/flat/20141209174146.GP1768@alvh.no-ip.org logical column ordering]<br />
<br />
* [https://www.postgresql.org/message-id/154a391d341.1176179cb4319.144192970510819074%40zohocorp.com Incremental refresh of materialized view - Patch]<br />
* [https://www.postgresql.org/message-id/20170123233819.GD1838%40localhost Contrib: alternative MATERIALIZED VIEWs]<br />
* [https://www.postgresql.org/message-id/flat/CAKLmikMjJqVJbKijOxivhb9%3DA5PfoZcit2QowbJ4rFszzr4Zhw%40mail.gmail.com#b7829393acf1cfcbc507b137f5ebaeab Implementing Incremental View Maintenance]<br />
<br />
==pgsql-general ==<br />
* [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com Incrementally refreshed materialized view ]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Incremental_View_Maintenance&diff=34129Incremental View Maintenance2019-10-01T03:56:03Z<p>Ishii: /* Restrictions on view definition */</p>
<hr />
<div>This page describes Incremental View Maintenance (IVM) proposed in pgsql-hackers. <br />
<br />
= Overview =<br />
<br />
PostgreSQL has supported materialized views since 9.3. This feature is used to speed up query evaluation by storing the results of specified queries. One problem of materialized view is its maintenance. Materialized views have to be brought up to date when the underling base relations are updated. <br />
<br />
Incremental View Maintenance (IVM) is a technique to maintain materialized views which computes and applies only the incremental changes to the materialized views rather than recomputing the contents as the current REFRESH command does. This feature is not implemented on PostgreSQL yet. Implementing this into PostgreSQL core was proposed firstly at [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews|PgCon 2013 Developer Meeting]] and [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com][https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com]. There were also other discussions on IVM [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost] [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com]. The first patch was submitted in 2019[https://www.postgresql.org/message-id/20190514154648.63fea174748c18ed7f7dcb16%40sraoss.co.jp].<br />
<br />
= Basic Theory of IVM =<br />
<br />
IVM computes and applies only the incremental changes to the materialized views. Suppose that view V is defined by query Q over a state of base relations D. When D changes D' = D + dD, we can get the new view state V' by calculating from D' and Q, and this is re-computation performed by REFRESH MATERIALIZED VIEW command. On the other hand, IVM calculates the delta for view (dV) from the base tables delta (dD) and view definition (Q), and applies this to get the new view state, V' = V + dV.<br />
<br />
In theory, the view definition is described in a relational algebra (or bag algebra) form. For example, a (inner) join view of table R and S is defined as V = R ⨝ S. <br />
<br />
When table R is changed in a transaction, this can be described as R ← R - ∇R + ΔR, where ∇R and ΔR denote tuples deleted from and inserted into R, respectively. (To be accurate, instead of - and +, ∸ and ⨄ are used by tradition in bag algebra.) In this condition, the deltas of the view are calculated as ∇V = ∇R ⨝ S and ΔV = ΔR ⨝ S, then the view can be updated as V ← V - ∇V + ΔV.<br />
<br />
= How to extract changes on base tables =<br />
<br />
There are at least two approaches. One is using AFTER triggers and Transition Tables, which is a feature of AFTER trigger introduced from PostgreSQL 10. This was implemented originally aiming to support IVM, and in fact the proposed patch uses this. This enables collect row sets that include all of the rows inserted, deleted, or modified by the current SQL statement. These row sets can be referred as tables of specified name. OLD TABLE contains the before-images of all rows updated or deleted by the statement. Similarly, NEW TABLE contains the after-images of all rows updated or inserted by the statement. These two tables correspond ∇R and ΔR, respectively.<br />
<br />
Another candidate is using logical decoding of WAL.<br />
<br />
= How to calculate the delta to be applied to materialized views =<br />
<br />
This is basically based on relational algebra or bag algebra. In theory, we can handle various view definition. Views can be defined using several operations: selection, projection, join, aggregation, union, difference, intersection, etc. If we can prepare a module for each operation, there is possibility of extensive implementation of IVM.<br />
<br />
However, we started from a simple view definition. The proposed patch currently supports selection-projection-join and some aggregations.<br />
<br />
= When to maintain materialized views =<br />
<br />
There are two approaches, immediate maintenance and deferred maintenance. <br />
<br />
== Immediate View Maintenance ==<br />
<br />
In immediate maintenance, views are updated in the same transaction where the base table is updated. <br />
<br />
The proposed patch implements a kind of immediate maintenance, that is, materialized views are updated immediately in AFTER triggers when a base table is modified. SQL statement modify only one base table and the changes can be extracted by using Transition Tables mentioned above.<br />
<br />
In addition, there could be another implementation of Immediate Maintenance, in which materialized views are updated at the end of a transaction that modified base table, rather than in AFTER trigger. Oracle supports this type of IVM. To implement this, we will need a mechanism to maintain change logs on base tables as well as Deferred maintenance as said bellow.<br />
<br />
== Deferred View Maintenance ==<br />
<br />
In deferred maintenance, views are updated after the transaction is committed, for example, when the view is accessed, as a response to user command like REFRESH, or updated periodically, and so on.<br />
<br />
In order to implement "deferred", it is need to implement a mechanism to maintain logs for recording changes of base tables. An algorithm to compute the delta to be applied to views are also to be considered because more than one tables could be modified a lot of times before a view is updated.<br />
<br />
= How to handle views with tuple duplicates or DISTINCT clause =<br />
<br />
We need some considerations to support materialized views including duplicate tuples or DISTINCT clause in its definition query. <br />
<br />
For example, if there are two same tuples in a view and we would like to delete only one tuple rather than both of two. In this situation, we can not use DELETE statement simply, because this will delete both of tow tuples. <br />
<br />
As another example, suppose a materialized view is defined with DISTINCT and there are duplicate tuples in its base table. The duplicates in the base table are eliminated due to DISTINCT. Then, when we would like to apply delta tables to this view, how we should update the view? When deleting tuples from the base table, a tuple in the view should be deleted if and only if the duplicity of the tuple becomes zero. Else, the tuple must remain in the view. Moreover, as for tuple insertion, we can insert a tuple into the view only if the same tuple doesn't exist in the view. If there is already the same one, additional tuple must not be inserted since duplicate is not allowed.<br />
<br />
== counting algorithm ==<br />
<br />
Counting algorithm is an algorithm for handling tuple duplicates or DISTINCT clause in IVM. In this algorithm, the number of same tuples is counted and stored in the materialized views as duplicity of each tuple. When tuples are to be inserted into the view, the count is increased if there is already the same one. Otherwize, if the same tuple doesn't exist, a new tuple is inserted. Similarly, when tuples are to be deleted from the view, the count is decreased. If the count becomes zero, this tuple is deleted from the view.<br />
<br />
= How to identify rows to be modified in materialized views =<br />
<br />
When applying the delta to materialized views, we have to identify which tuple in materialized views is corresponding to a tuple in the delta. A naive method is matching by using all columns in a tuple, but clearly this is inefficient. If a materialized view has unique index, we can use this. Any way, for efficient IVM, appropriate index will be necessary on the materialized view. Maybe, REPLICA IDENTITY (or something similar) is useful.<br />
<br />
= Implementation details =<br />
<br />
This section describes details of the proposed patch's implementation<br />
<br />
This patch implements a kind of Immediate Maintenance of materialized views. If a materialized view created with IVM option, the contents of this view is updated automatically and incrementally after base tables are updated. <br />
<br />
== Creating Materialized Views ==<br />
<br />
Materialized view with IVM option created by CRATE INCREMENTAL MATERIALIZED VIEW command. Noted this syntax is just tentative, so it may be changed.<br />
<br />
When a materialized view is created, AFTER triggers are internally created on its all base tables. When the base tables is modified (INSERT, DELETE,<br />
UPDATE), this view is updated incrementally in the trigger function.<br />
<br />
Before populating the materialized view, GROUP BY and count(*) are added to the view definition query for counting duplicity of tuples in the view. The result of count is stored in the view as a special column named "__ivm_count__". <br />
<br />
== Maintenance of Materialized View ==<br />
<br />
When base tables are modified, the change set of the table can be referred as Ephemeral Named Relations (ENRs) thanks to Transition Table. We can calculate the diff set of the view by replacing the base table in the view definition query with the ENR (at least if it is Selection-Projection -Join view). As well as view definition time, GROUP BY and count(*) is added in order to count the duplicity of tuples in the diff set. As a result, two diff sets (to be deleted from and to be inserted into the view) are calculated, and the results are stored into temporary tables respectively.<br />
<br />
The view is updated by merging these change sets. Instead of executing DELETE or INSERT simply, the values of __ivm_count__ column in the view is decreased or increased. When the values becomes zero, the corresponding tuple is deleted from the view.<br />
<br />
== Aggregation support ==<br />
<br />
Currently, count sum, min, max and avg are supported.<br />
<br />
As a restriction, expressions specified in GROUP BY must appear in the target list of views because tuples to be updated in materialized views are identified by using this group keys. When creating a materialized view, more than one hidden columns for each aggregation are added to the target list. The name of these hidden column is like __ivm_count_sum__, for example.<br />
<br />
In the case of views without aggregate functions, only the number of tuple duplicates (__ivm_count__) are updated at incremental maintenance. On the other <br />
hand, in the case of vies with aggregations, the aggregated values and related hidden columns are also updated. The way of update depends the kind of aggregate function. Specifically, sum and count are updated by adding or subtracting delta values. avg is updated by using values of sum and count stored in views as hidden columns and deltas of them.<br />
<br />
In the case of sum and avg (or any aggregation functions except to count), NULL in input values is ignored, and this returns a null value when no rows are selected. To support this specification, the number of not-NULL input values is counted and stored in views as a hidden column. In the case of count, this returns zero when no rows are selected, and count(*) doesn't ignore NULL input. These specification are also supported.<br />
<br />
Tuples to be updated in materialized views are identified by using keys specified by GROUP BY clause. However, in the case of aggregation without GROUP BY, there is only one tuple in the view, so keys are not uses to identify tuples.<br />
<br />
== Access to Materialized Views ==<br />
<br />
When SELECT is issued for materialized views with IVM support defined with DISTINCT, all columns except to __ivm_count__ of each tuple are returned. This is correct because duplicity of tuples are eliminated by GROUP BY.<br />
<br />
When DISTINCT is not used, the query returns each tuple __ivm_count__ times. Currently, this is implemented by rewriting the SELECT<br />
query to replace the view RTE with a subquery which joins the view and generate_series function as bellow. <br />
<br />
SELECT mv.* FROM mv, generate_series(1, mv.__ivm_count__);<br />
<br />
__ivm_count__ column is invisible for users when "SELECT * FROM ..." is issued, but users can see the value by specifying in target list explicitly.<br />
<br />
<br />
== Restrictions on view definition ==<br />
<br />
The current implementation supports views including selection, projection, inner join with or without DISTINCT, and some aggregations (count, sum, min, max, agv) and GROUP BY (HAVING is not supported).<br />
Self-join is also supported.<br />
Subquery support and outer join support are on our plan. CTE and window functions are not supported.<br />
<br />
== Timing of view maintenance ==<br />
<br />
This patch implements only a kind of Immediate Maintenance. For implementing Deferred Maintenance, we need a infrastructure to maintain these logs. For example, which logs are necessary and which logs can be discarded, etc.<br />
<br />
== Counting algorithm implementation ==<br />
<br />
The proposed patch treats "__ivm_count__" as a special column name in a somewhat ad hoc way. This is used when maintaining and accessing materialized views. When "SELECT * FROM ..." is issued to views, __ivm_count__ column is invisible for users. Note that users can not use this name as a user column in materialized views with IVM support. As for how to make internal columns invisible to SELECT *, there have been other discussions about doing that using a new flag in pg_attribute[https://www.postgresql.org/message-id/flat/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com].<br />
<br />
When a materialized view with duplicate tuples is accessed, this is replaced with a subquery which uses generate_series function. It does not have to be generate_series, and we can make a new set returning function for this. Anyway, this internal behaviour is visible in EXPLAIN results as below. <br />
<br />
postgres=# EXPLAIN SELECT * FROM m1;<br />
QUERY PLAN <br />
------------------------------------------------------------------------------<br />
Nested Loop (cost=0.00..61.03 rows=3000 width=2)<br />
-> Seq Scan on m1 mv (cost=0.00..1.03 rows=3 width=10)<br />
-> Function Scan on generate_series (cost=0.00..10.00 rows=1000 width=0)<br />
(3 rows)<br />
<br />
Also, there would be performance impact because estimated rows number by optimizer is wrong, and what is worse, the cost of join is not small when the size of view is large. Therefore, we might have to add a new plan node for selecting from materialized views with IVM support rather than using a special set returning function.<br />
<br />
== Concurrent Transactions ==<br />
<br />
When a view is defined on two tables and each table is modified in different concurrent transactions respectively, if a change in one transaction was not considered in another transaction in READ COMMITTED level, an anormal update of the materialized view would be possible. To prevent this, a lock on the materialized view is taken in early stage of view maintenance to wait for concurrent transactions which are updating the same view to end. Also, the latest snapshot is taken before computing delta tables to make any changes which occurs in other transaction during lock waiting visible.<br />
<br />
In REPEATABLE READ or SERIALIZABLE level, don't wait a lock, and raise an error immediately to prevent anormal update because table changes occurred in other transactions must not be visible, and views can not be maintained correctly in AFTER triggers.<br />
<br />
These solutions might be ugly, but something to prevent anormal update is anyway necessary. There may be better way. One idea to resolve this is performing view maintenance in two phases. Firstly, views are updated using only table changes visible in this transaction. Then, just after this transaction is committed, views have to be updated additionally using changes happened in other transactions to keep consistency. This is a just idea, but to implement this idea, we will need keep to keep and maintain change logs.<br />
<br />
= Links =<br />
<br />
== CommitFest ==<br />
<br />
* [https://commitfest.postgresql.org/23/2138/ Incremental Materialized View Maintenance]<br />
<br />
== Talks ==<br />
<br />
* [https://www.pgcon.org/2019/schedule/events/1316.en.html Towards Implementing Incremental View Maintenance on PostgreSQL (PGCon 2019) ]<br />
* [https://www.postgresql.eu/events/pgconfeu2018/schedule/session/2195-implementing-incremental-view-maintenance-on-postgresql/ Implementing Incremental View Maintenance on PostgreSQL (PGConf.EU 2018) ]<br />
* [https://wiki.postgresql.org/images/8/85/Materialised_Views_-_FOSDEM.pdf Materialised views now and the future (PGDay FOSDEM 2014)]<br />
<br />
== Wiki==<br />
* [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews]]<br />
* [[Materialized Views]]<br />
<br />
== pgsql-hackers ==<br />
* [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com counting algorithm for incremental matview maintenance]<br />
* [https://www.postgresql.org/message-id/1368557513.95389.YahooMailNeo%40web162903.mail.bf1.yahoo.com Differential (transactional) REFRESH]<br />
* [https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com matview incremental maintenance]<br />
* [https://www.postgresql.org/message-id/flat/1371225929.28496.YahooMailNeo%40web162905.mail.bf1.yahoo.com refresh materialized view concurrently]<br />
* [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost Alternative MATERIALIZED VIEW design and implementation with history table and other features]<br />
* [https://www.postgresql.org/message-id/1402790204.65037.YahooMailNeo@web122301.mail.ne1.yahoo.com delta relations in AFTER triggers]<br />
* [https://www.postgresql.org/message-id/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com "SELECT *" vs hidden columns and logical column order]<br />
* [https://www.postgresql.org/message-id/flat/20141209174146.GP1768@alvh.no-ip.org logical column ordering]<br />
<br />
* [https://www.postgresql.org/message-id/154a391d341.1176179cb4319.144192970510819074%40zohocorp.com Incremental refresh of materialized view - Patch]<br />
* [https://www.postgresql.org/message-id/20170123233819.GD1838%40localhost Contrib: alternative MATERIALIZED VIEWs]<br />
* [https://www.postgresql.org/message-id/flat/CAKLmikMjJqVJbKijOxivhb9%3DA5PfoZcit2QowbJ4rFszzr4Zhw%40mail.gmail.com#b7829393acf1cfcbc507b137f5ebaeab Implementing Incremental View Maintenance]<br />
<br />
==pgsql-general ==<br />
* [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com Incrementally refreshed materialized view ]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Incremental_View_Maintenance&diff=33861Incremental View Maintenance2019-08-02T08:36:59Z<p>Ishii: /* Restrictions on view definition */</p>
<hr />
<div>This page describes Incremental View Maintenance (IVM) proposed in pgsql-hackers. <br />
<br />
= Overview =<br />
<br />
PostgreSQL has supported materialized views since 9.3. This feature is used to speed up query evaluation by storing the results of specified queries. One problem of materialized view is its maintenance. Materialized views have to be brought up to date when the underling base relations are updated. <br />
<br />
Incremental View Maintenance (IVM) is a technique to maintain materialized views which computes and applies only the incremental changes to the materialized views rather than recomputing the contents as the current REFRESH command does. This feature is not implemented on PostgreSQL yet. Implementing this into PostgreSQL core was proposed firstly at [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews|PgCon 2013 Developer Meeting]] and [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com][https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com]. There were also other discussions on IVM [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost] [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com]. The first patch was submitted in 2019[https://www.postgresql.org/message-id/20190514154648.63fea174748c18ed7f7dcb16%40sraoss.co.jp].<br />
<br />
= Basic Theory of IVM =<br />
<br />
IVM computes and applies only the incremental changes to the materialized views. Suppose that view V is defined by query Q over a state of base relations D. When D changes D' = D + dD, we can get the new view state V' by calculating from D' and Q, and this is re-computation performed by REFRESH MATERIALIZED VIEW command. On the other hand, IVM calculates the delta for view (dV) from the base tables delta (dD) and view definition (Q), and applies this to get the new view state, V' = V + dV.<br />
<br />
In theory, the view definition is described in a relational algebra (or bag algebra) form. For example, a (inner) join view of table R and S is defined as V = R ⨝ S. <br />
<br />
When table R is changed in a transaction, this can be described as R ← R - ∇R + ΔR, where ∇R and ΔR denote tuples deleted from and inserted into R, respectively. (To be accurate, instead of - and +, ∸ and ⨄ are used by tradition in bag algebra.) In this condition, the deltas of the view are calculated as ∇V = ∇R ⨝ S and ΔV = ΔR ⨝ S, then the view can be updated as V ← V - ∇V + ΔV.<br />
<br />
= How to extract changes on base tables =<br />
<br />
There are at least two approaches. One is using AFTER triggers and Transition Tables, which is a feature of AFTER trigger introduced from PostgreSQL 10. This was implemented originally aiming to support IVM, and in fact the proposed patch uses this. This enables collect row sets that include all of the rows inserted, deleted, or modified by the current SQL statement. These row sets can be referred as tables of specified name. OLD TABLE contains the before-images of all rows updated or deleted by the statement. Similarly, NEW TABLE contains the after-images of all rows updated or inserted by the statement. These two tables correspond ∇R and ΔR, respectively.<br />
<br />
Another candidate is using logical decoding of WAL.<br />
<br />
= How to calculate the delta to be applied to materialized views =<br />
<br />
This is basically based on relational algebra or bag algebra. In theory, we can handle various view definition. Views can be defined using several operations: selection, projection, join, aggregation, union, difference, intersection, etc. If we can prepare a module for each operation, there is possibility of extensive implementation of IVM.<br />
<br />
However, we started from a simple view definition. The proposed patch currently supports selection-projection-join and some aggregations.<br />
<br />
= When to maintain materialized views =<br />
<br />
There are two approaches, immediate maintenance and deferred maintenance. <br />
<br />
== Immediate View Maintenance ==<br />
<br />
In immediate maintenance, views are updated in the same transaction where the base table is updated. <br />
<br />
The proposed patch implements a kind of immediate maintenance, that is, materialized views are updated immediately in AFTER triggers when a base table is modified. SQL statement modify only one base table and the changes can be extracted by using Transition Tables mentioned above.<br />
<br />
In addition, there could be another implementation of Immediate Maintenance, in which materialized views are updated at the end of a transaction that modified base table, rather than in AFTER trigger. Oracle supports this type of IVM. To implement this, we will need a mechanism to maintain change logs on base tables as well as Deferred maintenance as said bellow.<br />
<br />
== Deferred View Maintenance ==<br />
<br />
In deferred maintenance, views are updated after the transaction is committed, for example, when the view is accessed, as a response to user command like REFRESH, or updated periodically, and so on.<br />
<br />
In order to implement "deferred", it is need to implement a mechanism to maintain logs for recording changes of base tables. An algorithm to compute the delta to be applied to views are also to be considered because more than one tables could be modified a lot of times before a view is updated.<br />
<br />
= How to handle views with tuple duplicates or DISTINCT clause =<br />
<br />
We need some considerations to support materialized views including duplicate tuples or DISTINCT clause in its definition query. <br />
<br />
For example, if there are two same tuples in a view and we would like to delete only one tuple rather than both of two. In this situation, we can not use DELETE statement simply, because this will delete both of tow tuples. <br />
<br />
As another example, suppose a materialized view is defined with DISTINCT and there are duplicate tuples in its base table. The duplicates in the base table are eliminated due to DISTINCT. Then, when we would like to apply delta tables to this view, how we should update the view? When deleting tuples from the base table, a tuple in the view should be deleted if and only if the duplicity of the tuple becomes zero. Else, the tuple must remain in the view. Moreover, as for tuple insertion, we can insert a tuple into the view only if the same tuple doesn't exist in the view. If there is already the same one, additional tuple must not be inserted since duplicate is not allowed.<br />
<br />
== counting algorithm ==<br />
<br />
Counting algorithm is an algorithm for handling tuple duplicates or DISTINCT clause in IVM. In this algorithm, the number of same tuples is counted and stored in the materialized views as duplicity of each tuple. When tuples are to be inserted into the view, the count is increased if there is already the same one. Otherwize, if the same tuple doesn't exist, a new tuple is inserted. Similarly, when tuples are to be deleted from the view, the count is decreased. If the count becomes zero, this tuple is deleted from the view.<br />
<br />
= How to identify rows to be modified in materialized views =<br />
<br />
When applying the delta to materialized views, we have to identify which tuple in materialized views is corresponding to a tuple in the delta. A naive method is matching by using all columns in a tuple, but clearly this is inefficient. If a materialized view has unique index, we can use this. Any way, for efficient IVM, appropriate index will be necessary on the materialized view. Maybe, REPLICA IDENTITY (or something similar) is useful.<br />
<br />
= Implementation details =<br />
<br />
This section describes details of the proposed patch's implementation<br />
<br />
This patch implements a kind of Immediate Maintenance of materialized views. If a materialized view created with IVM option, the contents of this view is updated automatically and incrementally after base tables are updated. <br />
<br />
== Creating Materialized Views ==<br />
<br />
Materialized view with IVM option created by CRATE INCREMENTAL MATERIALIZED VIEW command. Noted this syntax is just tentative, so it may be changed.<br />
<br />
When a materialized view is created, AFTER triggers are internally created on its all base tables. When the base tables is modified (INSERT, DELETE,<br />
UPDATE), this view is updated incrementally in the trigger function.<br />
<br />
Before populating the materialized view, GROUP BY and count(*) are added to the view definition query for counting duplicity of tuples in the view. The result of count is stored in the view as a special column named "__ivm_count__". <br />
<br />
== Maintenance of Materialized View ==<br />
<br />
When base tables are modified, the change set of the table can be referred as Ephemeral Named Relations (ENRs) thanks to Transition Table. We can calculate the diff set of the view by replacing the base table in the view definition query with the ENR (at least if it is Selection-Projection -Join view). As well as view definition time, GROUP BY and count(*) is added in order to count the duplicity of tuples in the diff set. As a result, two diff sets (to be deleted from and to be inserted into the view) are calculated, and the results are stored into temporary tables respectively.<br />
<br />
The view is updated by merging these change sets. Instead of executing DELETE or INSERT simply, the values of __ivm_count__ column in the view is decreased or increased. When the values becomes zero, the corresponding tuple is deleted from the view.<br />
<br />
== Aggregation support ==<br />
<br />
Currently, count sum, min, max and avg are supported.<br />
<br />
As a restriction, expressions specified in GROUP BY must appear in the target list of views because tuples to be updated in materialized views are identified by using this group keys. When creating a materialized view, more than one hidden columns for each aggregation are added to the target list. The name of these hidden column is like __ivm_count_sum__, for example.<br />
<br />
In the case of views without aggregate functions, only the number of tuple duplicates (__ivm_count__) are updated at incremental maintenance. On the other <br />
hand, in the case of vies with aggregations, the aggregated values and related hidden columns are also updated. The way of update depends the kind of aggregate function. Specifically, sum and count are updated by adding or subtracting delta values. avg is updated by using values of sum and count stored in views as hidden columns and deltas of them.<br />
<br />
In the case of sum and avg (or any aggregation functions except to count), NULL in input values is ignored, and this returns a null value when no rows are selected. To support this specification, the number of not-NULL input values is counted and stored in views as a hidden column. In the case of count, this returns zero when no rows are selected, and count(*) doesn't ignore NULL input. These specification are also supported.<br />
<br />
Tuples to be updated in materialized views are identified by using keys specified by GROUP BY clause. However, in the case of aggregation without GROUP BY, there is only one tuple in the view, so keys are not uses to identify tuples.<br />
<br />
== Access to Materialized Views ==<br />
<br />
When SELECT is issued for materialized views with IVM support defined with DISTINCT, all columns except to __ivm_count__ of each tuple are returned. This is correct because duplicity of tuples are eliminated by GROUP BY.<br />
<br />
When DISTINCT is not used, the query returns each tuple __ivm_count__ times. Currently, this is implemented by rewriting the SELECT<br />
query to replace the view RTE with a subquery which joins the view and generate_series function as bellow. <br />
<br />
SELECT mv.* FROM mv, generate_series(1, mv.__ivm_count__);<br />
<br />
__ivm_count__ column is invisible for users when "SELECT * FROM ..." is issued, but users can see the value by specifying in target list explicitly.<br />
<br />
<br />
== Restrictions on view definition ==<br />
<br />
The current implementation supports views including selection, projection, inner join with or without DISTINCT, and some aggregations (count, sum, min, max, agv) and GROUP BY.<br />
<br />
Self-join and outer join are not supported, but now investigated. Subqueries, CTE, window functions are not considered well.<br />
<br />
== Timing of view maintenance ==<br />
<br />
This patch implements only a kind of Immediate Maintenance. For implementing Deferred Maintenance, we need a infrastructure to maintain these logs. For example, which logs are necessary and which logs can be discarded, etc.<br />
<br />
== Counting algorithm implementation ==<br />
<br />
The proposed patch treats "__ivm_count__" as a special column name in a somewhat ad hoc way. This is used when maintaining and accessing materialized views. When "SELECT * FROM ..." is issued to views, __ivm_count__ column is invisible for users. Note that users can not use this name as a user column in materialized views with IVM support. As for how to make internal columns invisible to SELECT *, there have been other discussions about doing that using a new flag in pg_attribute[https://www.postgresql.org/message-id/flat/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com].<br />
<br />
When a materialized view with duplicate tuples is accessed, this is replaced with a subquery which uses generate_series function. It does not have to be generate_series, and we can make a new set returning function for this. Anyway, this internal behaviour is visible in EXPLAIN results as below. <br />
<br />
postgres=# EXPLAIN SELECT * FROM m1;<br />
QUERY PLAN <br />
------------------------------------------------------------------------------<br />
Nested Loop (cost=0.00..61.03 rows=3000 width=2)<br />
-> Seq Scan on m1 mv (cost=0.00..1.03 rows=3 width=10)<br />
-> Function Scan on generate_series (cost=0.00..10.00 rows=1000 width=0)<br />
(3 rows)<br />
<br />
Also, there would be performance impact because estimated rows number by optimizer is wrong, and what is worse, the cost of join is not small when the size of view is large. Therefore, we might have to add a new plan node for selecting from materialized views with IVM support rather than using a special set returning function.<br />
<br />
== Concurrent Transactions ==<br />
<br />
When a view is defined on two tables and each table is modified in different concurrent transactions respectively, if a change in one transaction was not considered in another transaction in READ COMMITTED level, an anormal update of the materialized view would be possible. To prevent this, a lock on the materialized view is taken in early stage of view maintenance to wait for concurrent transactions which are updating the same view to end. Also, the latest snapshot is taken before computing delta tables to make any changes which occurs in other transaction during lock waiting visible.<br />
<br />
In REPEATABLE READ or SERIALIZABLE level, don't wait a lock, and raise an error immediately to prevent anormal update because table changes occurred in other transactions must not be visible, and views can not be maintained correctly in AFTER triggers.<br />
<br />
These solutions might be ugly, but something to prevent anormal update is anyway necessary. There may be better way. One idea to resolve this is performing view maintenance in two phases. Firstly, views are updated using only table changes visible in this transaction. Then, just after this transaction is committed, views have to be updated additionally using changes happened in other transactions to keep consistency. This is a just idea, but to implement this idea, we will need keep to keep and maintain change logs.<br />
<br />
= Links =<br />
<br />
== CommitFest ==<br />
<br />
* [https://commitfest.postgresql.org/23/2138/ Incremental Materialized View Maintenance]<br />
<br />
== Talks ==<br />
<br />
* [https://www.pgcon.org/2019/schedule/events/1316.en.html Towards Implementing Incremental View Maintenance on PostgreSQL (PGCon 2019) ]<br />
* [https://www.postgresql.eu/events/pgconfeu2018/schedule/session/2195-implementing-incremental-view-maintenance-on-postgresql/ Implementing Incremental View Maintenance on PostgreSQL (PGConf.EU 2018) ]<br />
* [https://wiki.postgresql.org/images/8/85/Materialised_Views_-_FOSDEM.pdf Materialised views now and the future (PGDay FOSDEM 2014)]<br />
<br />
== Wiki==<br />
* [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews]]<br />
* [[Materialized Views]]<br />
<br />
== pgsql-hackers ==<br />
* [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com counting algorithm for incremental matview maintenance]<br />
* [https://www.postgresql.org/message-id/1368557513.95389.YahooMailNeo%40web162903.mail.bf1.yahoo.com Differential (transactional) REFRESH]<br />
* [https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com matview incremental maintenance]<br />
* [https://www.postgresql.org/message-id/flat/1371225929.28496.YahooMailNeo%40web162905.mail.bf1.yahoo.com refresh materialized view concurrently]<br />
* [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost Alternative MATERIALIZED VIEW design and implementation with history table and other features]<br />
* [https://www.postgresql.org/message-id/1402790204.65037.YahooMailNeo@web122301.mail.ne1.yahoo.com delta relations in AFTER triggers]<br />
* [https://www.postgresql.org/message-id/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com "SELECT *" vs hidden columns and logical column order]<br />
* [https://www.postgresql.org/message-id/flat/20141209174146.GP1768@alvh.no-ip.org logical column ordering]<br />
<br />
* [https://www.postgresql.org/message-id/154a391d341.1176179cb4319.144192970510819074%40zohocorp.com Incremental refresh of materialized view - Patch]<br />
* [https://www.postgresql.org/message-id/20170123233819.GD1838%40localhost Contrib: alternative MATERIALIZED VIEWs]<br />
* [https://www.postgresql.org/message-id/flat/CAKLmikMjJqVJbKijOxivhb9%3DA5PfoZcit2QowbJ4rFszzr4Zhw%40mail.gmail.com#b7829393acf1cfcbc507b137f5ebaeab Implementing Incremental View Maintenance]<br />
<br />
==pgsql-general ==<br />
* [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com Incrementally refreshed materialized view ]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Incremental_View_Maintenance&diff=33860Incremental View Maintenance2019-08-02T08:36:40Z<p>Ishii: /* Restrictions on view definition */</p>
<hr />
<div>This page describes Incremental View Maintenance (IVM) proposed in pgsql-hackers. <br />
<br />
= Overview =<br />
<br />
PostgreSQL has supported materialized views since 9.3. This feature is used to speed up query evaluation by storing the results of specified queries. One problem of materialized view is its maintenance. Materialized views have to be brought up to date when the underling base relations are updated. <br />
<br />
Incremental View Maintenance (IVM) is a technique to maintain materialized views which computes and applies only the incremental changes to the materialized views rather than recomputing the contents as the current REFRESH command does. This feature is not implemented on PostgreSQL yet. Implementing this into PostgreSQL core was proposed firstly at [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews|PgCon 2013 Developer Meeting]] and [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com][https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com]. There were also other discussions on IVM [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost] [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com]. The first patch was submitted in 2019[https://www.postgresql.org/message-id/20190514154648.63fea174748c18ed7f7dcb16%40sraoss.co.jp].<br />
<br />
= Basic Theory of IVM =<br />
<br />
IVM computes and applies only the incremental changes to the materialized views. Suppose that view V is defined by query Q over a state of base relations D. When D changes D' = D + dD, we can get the new view state V' by calculating from D' and Q, and this is re-computation performed by REFRESH MATERIALIZED VIEW command. On the other hand, IVM calculates the delta for view (dV) from the base tables delta (dD) and view definition (Q), and applies this to get the new view state, V' = V + dV.<br />
<br />
In theory, the view definition is described in a relational algebra (or bag algebra) form. For example, a (inner) join view of table R and S is defined as V = R ⨝ S. <br />
<br />
When table R is changed in a transaction, this can be described as R ← R - ∇R + ΔR, where ∇R and ΔR denote tuples deleted from and inserted into R, respectively. (To be accurate, instead of - and +, ∸ and ⨄ are used by tradition in bag algebra.) In this condition, the deltas of the view are calculated as ∇V = ∇R ⨝ S and ΔV = ΔR ⨝ S, then the view can be updated as V ← V - ∇V + ΔV.<br />
<br />
= How to extract changes on base tables =<br />
<br />
There are at least two approaches. One is using AFTER triggers and Transition Tables, which is a feature of AFTER trigger introduced from PostgreSQL 10. This was implemented originally aiming to support IVM, and in fact the proposed patch uses this. This enables collect row sets that include all of the rows inserted, deleted, or modified by the current SQL statement. These row sets can be referred as tables of specified name. OLD TABLE contains the before-images of all rows updated or deleted by the statement. Similarly, NEW TABLE contains the after-images of all rows updated or inserted by the statement. These two tables correspond ∇R and ΔR, respectively.<br />
<br />
Another candidate is using logical decoding of WAL.<br />
<br />
= How to calculate the delta to be applied to materialized views =<br />
<br />
This is basically based on relational algebra or bag algebra. In theory, we can handle various view definition. Views can be defined using several operations: selection, projection, join, aggregation, union, difference, intersection, etc. If we can prepare a module for each operation, there is possibility of extensive implementation of IVM.<br />
<br />
However, we started from a simple view definition. The proposed patch currently supports selection-projection-join and some aggregations.<br />
<br />
= When to maintain materialized views =<br />
<br />
There are two approaches, immediate maintenance and deferred maintenance. <br />
<br />
== Immediate View Maintenance ==<br />
<br />
In immediate maintenance, views are updated in the same transaction where the base table is updated. <br />
<br />
The proposed patch implements a kind of immediate maintenance, that is, materialized views are updated immediately in AFTER triggers when a base table is modified. SQL statement modify only one base table and the changes can be extracted by using Transition Tables mentioned above.<br />
<br />
In addition, there could be another implementation of Immediate Maintenance, in which materialized views are updated at the end of a transaction that modified base table, rather than in AFTER trigger. Oracle supports this type of IVM. To implement this, we will need a mechanism to maintain change logs on base tables as well as Deferred maintenance as said bellow.<br />
<br />
== Deferred View Maintenance ==<br />
<br />
In deferred maintenance, views are updated after the transaction is committed, for example, when the view is accessed, as a response to user command like REFRESH, or updated periodically, and so on.<br />
<br />
In order to implement "deferred", it is need to implement a mechanism to maintain logs for recording changes of base tables. An algorithm to compute the delta to be applied to views are also to be considered because more than one tables could be modified a lot of times before a view is updated.<br />
<br />
= How to handle views with tuple duplicates or DISTINCT clause =<br />
<br />
We need some considerations to support materialized views including duplicate tuples or DISTINCT clause in its definition query. <br />
<br />
For example, if there are two same tuples in a view and we would like to delete only one tuple rather than both of two. In this situation, we can not use DELETE statement simply, because this will delete both of tow tuples. <br />
<br />
As another example, suppose a materialized view is defined with DISTINCT and there are duplicate tuples in its base table. The duplicates in the base table are eliminated due to DISTINCT. Then, when we would like to apply delta tables to this view, how we should update the view? When deleting tuples from the base table, a tuple in the view should be deleted if and only if the duplicity of the tuple becomes zero. Else, the tuple must remain in the view. Moreover, as for tuple insertion, we can insert a tuple into the view only if the same tuple doesn't exist in the view. If there is already the same one, additional tuple must not be inserted since duplicate is not allowed.<br />
<br />
== counting algorithm ==<br />
<br />
Counting algorithm is an algorithm for handling tuple duplicates or DISTINCT clause in IVM. In this algorithm, the number of same tuples is counted and stored in the materialized views as duplicity of each tuple. When tuples are to be inserted into the view, the count is increased if there is already the same one. Otherwize, if the same tuple doesn't exist, a new tuple is inserted. Similarly, when tuples are to be deleted from the view, the count is decreased. If the count becomes zero, this tuple is deleted from the view.<br />
<br />
= How to identify rows to be modified in materialized views =<br />
<br />
When applying the delta to materialized views, we have to identify which tuple in materialized views is corresponding to a tuple in the delta. A naive method is matching by using all columns in a tuple, but clearly this is inefficient. If a materialized view has unique index, we can use this. Any way, for efficient IVM, appropriate index will be necessary on the materialized view. Maybe, REPLICA IDENTITY (or something similar) is useful.<br />
<br />
= Implementation details =<br />
<br />
This section describes details of the proposed patch's implementation<br />
<br />
This patch implements a kind of Immediate Maintenance of materialized views. If a materialized view created with IVM option, the contents of this view is updated automatically and incrementally after base tables are updated. <br />
<br />
== Creating Materialized Views ==<br />
<br />
Materialized view with IVM option created by CRATE INCREMENTAL MATERIALIZED VIEW command. Noted this syntax is just tentative, so it may be changed.<br />
<br />
When a materialized view is created, AFTER triggers are internally created on its all base tables. When the base tables is modified (INSERT, DELETE,<br />
UPDATE), this view is updated incrementally in the trigger function.<br />
<br />
Before populating the materialized view, GROUP BY and count(*) are added to the view definition query for counting duplicity of tuples in the view. The result of count is stored in the view as a special column named "__ivm_count__". <br />
<br />
== Maintenance of Materialized View ==<br />
<br />
When base tables are modified, the change set of the table can be referred as Ephemeral Named Relations (ENRs) thanks to Transition Table. We can calculate the diff set of the view by replacing the base table in the view definition query with the ENR (at least if it is Selection-Projection -Join view). As well as view definition time, GROUP BY and count(*) is added in order to count the duplicity of tuples in the diff set. As a result, two diff sets (to be deleted from and to be inserted into the view) are calculated, and the results are stored into temporary tables respectively.<br />
<br />
The view is updated by merging these change sets. Instead of executing DELETE or INSERT simply, the values of __ivm_count__ column in the view is decreased or increased. When the values becomes zero, the corresponding tuple is deleted from the view.<br />
<br />
== Aggregation support ==<br />
<br />
Currently, count sum, min, max and avg are supported.<br />
<br />
As a restriction, expressions specified in GROUP BY must appear in the target list of views because tuples to be updated in materialized views are identified by using this group keys. When creating a materialized view, more than one hidden columns for each aggregation are added to the target list. The name of these hidden column is like __ivm_count_sum__, for example.<br />
<br />
In the case of views without aggregate functions, only the number of tuple duplicates (__ivm_count__) are updated at incremental maintenance. On the other <br />
hand, in the case of vies with aggregations, the aggregated values and related hidden columns are also updated. The way of update depends the kind of aggregate function. Specifically, sum and count are updated by adding or subtracting delta values. avg is updated by using values of sum and count stored in views as hidden columns and deltas of them.<br />
<br />
In the case of sum and avg (or any aggregation functions except to count), NULL in input values is ignored, and this returns a null value when no rows are selected. To support this specification, the number of not-NULL input values is counted and stored in views as a hidden column. In the case of count, this returns zero when no rows are selected, and count(*) doesn't ignore NULL input. These specification are also supported.<br />
<br />
Tuples to be updated in materialized views are identified by using keys specified by GROUP BY clause. However, in the case of aggregation without GROUP BY, there is only one tuple in the view, so keys are not uses to identify tuples.<br />
<br />
== Access to Materialized Views ==<br />
<br />
When SELECT is issued for materialized views with IVM support defined with DISTINCT, all columns except to __ivm_count__ of each tuple are returned. This is correct because duplicity of tuples are eliminated by GROUP BY.<br />
<br />
When DISTINCT is not used, the query returns each tuple __ivm_count__ times. Currently, this is implemented by rewriting the SELECT<br />
query to replace the view RTE with a subquery which joins the view and generate_series function as bellow. <br />
<br />
SELECT mv.* FROM mv, generate_series(1, mv.__ivm_count__);<br />
<br />
__ivm_count__ column is invisible for users when "SELECT * FROM ..." is issued, but users can see the value by specifying in target list explicitly.<br />
<br />
<br />
== Restrictions on view definition ==<br />
<br />
The current implementation supports views including selection, projection, inner join with or without DISTINCT, and some aggregations (count, sum, min. max, agv) and GROUP BY.<br />
<br />
Self-join and outer join are not supported, but now investigated. Subqueries, CTE, window functions are not considered well.<br />
<br />
== Timing of view maintenance ==<br />
<br />
This patch implements only a kind of Immediate Maintenance. For implementing Deferred Maintenance, we need a infrastructure to maintain these logs. For example, which logs are necessary and which logs can be discarded, etc.<br />
<br />
== Counting algorithm implementation ==<br />
<br />
The proposed patch treats "__ivm_count__" as a special column name in a somewhat ad hoc way. This is used when maintaining and accessing materialized views. When "SELECT * FROM ..." is issued to views, __ivm_count__ column is invisible for users. Note that users can not use this name as a user column in materialized views with IVM support. As for how to make internal columns invisible to SELECT *, there have been other discussions about doing that using a new flag in pg_attribute[https://www.postgresql.org/message-id/flat/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com].<br />
<br />
When a materialized view with duplicate tuples is accessed, this is replaced with a subquery which uses generate_series function. It does not have to be generate_series, and we can make a new set returning function for this. Anyway, this internal behaviour is visible in EXPLAIN results as below. <br />
<br />
postgres=# EXPLAIN SELECT * FROM m1;<br />
QUERY PLAN <br />
------------------------------------------------------------------------------<br />
Nested Loop (cost=0.00..61.03 rows=3000 width=2)<br />
-> Seq Scan on m1 mv (cost=0.00..1.03 rows=3 width=10)<br />
-> Function Scan on generate_series (cost=0.00..10.00 rows=1000 width=0)<br />
(3 rows)<br />
<br />
Also, there would be performance impact because estimated rows number by optimizer is wrong, and what is worse, the cost of join is not small when the size of view is large. Therefore, we might have to add a new plan node for selecting from materialized views with IVM support rather than using a special set returning function.<br />
<br />
== Concurrent Transactions ==<br />
<br />
When a view is defined on two tables and each table is modified in different concurrent transactions respectively, if a change in one transaction was not considered in another transaction in READ COMMITTED level, an anormal update of the materialized view would be possible. To prevent this, a lock on the materialized view is taken in early stage of view maintenance to wait for concurrent transactions which are updating the same view to end. Also, the latest snapshot is taken before computing delta tables to make any changes which occurs in other transaction during lock waiting visible.<br />
<br />
In REPEATABLE READ or SERIALIZABLE level, don't wait a lock, and raise an error immediately to prevent anormal update because table changes occurred in other transactions must not be visible, and views can not be maintained correctly in AFTER triggers.<br />
<br />
These solutions might be ugly, but something to prevent anormal update is anyway necessary. There may be better way. One idea to resolve this is performing view maintenance in two phases. Firstly, views are updated using only table changes visible in this transaction. Then, just after this transaction is committed, views have to be updated additionally using changes happened in other transactions to keep consistency. This is a just idea, but to implement this idea, we will need keep to keep and maintain change logs.<br />
<br />
= Links =<br />
<br />
== CommitFest ==<br />
<br />
* [https://commitfest.postgresql.org/23/2138/ Incremental Materialized View Maintenance]<br />
<br />
== Talks ==<br />
<br />
* [https://www.pgcon.org/2019/schedule/events/1316.en.html Towards Implementing Incremental View Maintenance on PostgreSQL (PGCon 2019) ]<br />
* [https://www.postgresql.eu/events/pgconfeu2018/schedule/session/2195-implementing-incremental-view-maintenance-on-postgresql/ Implementing Incremental View Maintenance on PostgreSQL (PGConf.EU 2018) ]<br />
* [https://wiki.postgresql.org/images/8/85/Materialised_Views_-_FOSDEM.pdf Materialised views now and the future (PGDay FOSDEM 2014)]<br />
<br />
== Wiki==<br />
* [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews]]<br />
* [[Materialized Views]]<br />
<br />
== pgsql-hackers ==<br />
* [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com counting algorithm for incremental matview maintenance]<br />
* [https://www.postgresql.org/message-id/1368557513.95389.YahooMailNeo%40web162903.mail.bf1.yahoo.com Differential (transactional) REFRESH]<br />
* [https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com matview incremental maintenance]<br />
* [https://www.postgresql.org/message-id/flat/1371225929.28496.YahooMailNeo%40web162905.mail.bf1.yahoo.com refresh materialized view concurrently]<br />
* [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost Alternative MATERIALIZED VIEW design and implementation with history table and other features]<br />
* [https://www.postgresql.org/message-id/1402790204.65037.YahooMailNeo@web122301.mail.ne1.yahoo.com delta relations in AFTER triggers]<br />
* [https://www.postgresql.org/message-id/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com "SELECT *" vs hidden columns and logical column order]<br />
* [https://www.postgresql.org/message-id/flat/20141209174146.GP1768@alvh.no-ip.org logical column ordering]<br />
<br />
* [https://www.postgresql.org/message-id/154a391d341.1176179cb4319.144192970510819074%40zohocorp.com Incremental refresh of materialized view - Patch]<br />
* [https://www.postgresql.org/message-id/20170123233819.GD1838%40localhost Contrib: alternative MATERIALIZED VIEWs]<br />
* [https://www.postgresql.org/message-id/flat/CAKLmikMjJqVJbKijOxivhb9%3DA5PfoZcit2QowbJ4rFszzr4Zhw%40mail.gmail.com#b7829393acf1cfcbc507b137f5ebaeab Implementing Incremental View Maintenance]<br />
<br />
==pgsql-general ==<br />
* [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com Incrementally refreshed materialized view ]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Incremental_View_Maintenance&diff=33859Incremental View Maintenance2019-08-02T08:34:50Z<p>Ishii: /* Aggregation support */</p>
<hr />
<div>This page describes Incremental View Maintenance (IVM) proposed in pgsql-hackers. <br />
<br />
= Overview =<br />
<br />
PostgreSQL has supported materialized views since 9.3. This feature is used to speed up query evaluation by storing the results of specified queries. One problem of materialized view is its maintenance. Materialized views have to be brought up to date when the underling base relations are updated. <br />
<br />
Incremental View Maintenance (IVM) is a technique to maintain materialized views which computes and applies only the incremental changes to the materialized views rather than recomputing the contents as the current REFRESH command does. This feature is not implemented on PostgreSQL yet. Implementing this into PostgreSQL core was proposed firstly at [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews|PgCon 2013 Developer Meeting]] and [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com][https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com]. There were also other discussions on IVM [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost] [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com]. The first patch was submitted in 2019[https://www.postgresql.org/message-id/20190514154648.63fea174748c18ed7f7dcb16%40sraoss.co.jp].<br />
<br />
= Basic Theory of IVM =<br />
<br />
IVM computes and applies only the incremental changes to the materialized views. Suppose that view V is defined by query Q over a state of base relations D. When D changes D' = D + dD, we can get the new view state V' by calculating from D' and Q, and this is re-computation performed by REFRESH MATERIALIZED VIEW command. On the other hand, IVM calculates the delta for view (dV) from the base tables delta (dD) and view definition (Q), and applies this to get the new view state, V' = V + dV.<br />
<br />
In theory, the view definition is described in a relational algebra (or bag algebra) form. For example, a (inner) join view of table R and S is defined as V = R ⨝ S. <br />
<br />
When table R is changed in a transaction, this can be described as R ← R - ∇R + ΔR, where ∇R and ΔR denote tuples deleted from and inserted into R, respectively. (To be accurate, instead of - and +, ∸ and ⨄ are used by tradition in bag algebra.) In this condition, the deltas of the view are calculated as ∇V = ∇R ⨝ S and ΔV = ΔR ⨝ S, then the view can be updated as V ← V - ∇V + ΔV.<br />
<br />
= How to extract changes on base tables =<br />
<br />
There are at least two approaches. One is using AFTER triggers and Transition Tables, which is a feature of AFTER trigger introduced from PostgreSQL 10. This was implemented originally aiming to support IVM, and in fact the proposed patch uses this. This enables collect row sets that include all of the rows inserted, deleted, or modified by the current SQL statement. These row sets can be referred as tables of specified name. OLD TABLE contains the before-images of all rows updated or deleted by the statement. Similarly, NEW TABLE contains the after-images of all rows updated or inserted by the statement. These two tables correspond ∇R and ΔR, respectively.<br />
<br />
Another candidate is using logical decoding of WAL.<br />
<br />
= How to calculate the delta to be applied to materialized views =<br />
<br />
This is basically based on relational algebra or bag algebra. In theory, we can handle various view definition. Views can be defined using several operations: selection, projection, join, aggregation, union, difference, intersection, etc. If we can prepare a module for each operation, there is possibility of extensive implementation of IVM.<br />
<br />
However, we started from a simple view definition. The proposed patch currently supports selection-projection-join and some aggregations.<br />
<br />
= When to maintain materialized views =<br />
<br />
There are two approaches, immediate maintenance and deferred maintenance. <br />
<br />
== Immediate View Maintenance ==<br />
<br />
In immediate maintenance, views are updated in the same transaction where the base table is updated. <br />
<br />
The proposed patch implements a kind of immediate maintenance, that is, materialized views are updated immediately in AFTER triggers when a base table is modified. SQL statement modify only one base table and the changes can be extracted by using Transition Tables mentioned above.<br />
<br />
In addition, there could be another implementation of Immediate Maintenance, in which materialized views are updated at the end of a transaction that modified base table, rather than in AFTER trigger. Oracle supports this type of IVM. To implement this, we will need a mechanism to maintain change logs on base tables as well as Deferred maintenance as said bellow.<br />
<br />
== Deferred View Maintenance ==<br />
<br />
In deferred maintenance, views are updated after the transaction is committed, for example, when the view is accessed, as a response to user command like REFRESH, or updated periodically, and so on.<br />
<br />
In order to implement "deferred", it is need to implement a mechanism to maintain logs for recording changes of base tables. An algorithm to compute the delta to be applied to views are also to be considered because more than one tables could be modified a lot of times before a view is updated.<br />
<br />
= How to handle views with tuple duplicates or DISTINCT clause =<br />
<br />
We need some considerations to support materialized views including duplicate tuples or DISTINCT clause in its definition query. <br />
<br />
For example, if there are two same tuples in a view and we would like to delete only one tuple rather than both of two. In this situation, we can not use DELETE statement simply, because this will delete both of tow tuples. <br />
<br />
As another example, suppose a materialized view is defined with DISTINCT and there are duplicate tuples in its base table. The duplicates in the base table are eliminated due to DISTINCT. Then, when we would like to apply delta tables to this view, how we should update the view? When deleting tuples from the base table, a tuple in the view should be deleted if and only if the duplicity of the tuple becomes zero. Else, the tuple must remain in the view. Moreover, as for tuple insertion, we can insert a tuple into the view only if the same tuple doesn't exist in the view. If there is already the same one, additional tuple must not be inserted since duplicate is not allowed.<br />
<br />
== counting algorithm ==<br />
<br />
Counting algorithm is an algorithm for handling tuple duplicates or DISTINCT clause in IVM. In this algorithm, the number of same tuples is counted and stored in the materialized views as duplicity of each tuple. When tuples are to be inserted into the view, the count is increased if there is already the same one. Otherwize, if the same tuple doesn't exist, a new tuple is inserted. Similarly, when tuples are to be deleted from the view, the count is decreased. If the count becomes zero, this tuple is deleted from the view.<br />
<br />
= How to identify rows to be modified in materialized views =<br />
<br />
When applying the delta to materialized views, we have to identify which tuple in materialized views is corresponding to a tuple in the delta. A naive method is matching by using all columns in a tuple, but clearly this is inefficient. If a materialized view has unique index, we can use this. Any way, for efficient IVM, appropriate index will be necessary on the materialized view. Maybe, REPLICA IDENTITY (or something similar) is useful.<br />
<br />
= Implementation details =<br />
<br />
This section describes details of the proposed patch's implementation<br />
<br />
This patch implements a kind of Immediate Maintenance of materialized views. If a materialized view created with IVM option, the contents of this view is updated automatically and incrementally after base tables are updated. <br />
<br />
== Creating Materialized Views ==<br />
<br />
Materialized view with IVM option created by CRATE INCREMENTAL MATERIALIZED VIEW command. Noted this syntax is just tentative, so it may be changed.<br />
<br />
When a materialized view is created, AFTER triggers are internally created on its all base tables. When the base tables is modified (INSERT, DELETE,<br />
UPDATE), this view is updated incrementally in the trigger function.<br />
<br />
Before populating the materialized view, GROUP BY and count(*) are added to the view definition query for counting duplicity of tuples in the view. The result of count is stored in the view as a special column named "__ivm_count__". <br />
<br />
== Maintenance of Materialized View ==<br />
<br />
When base tables are modified, the change set of the table can be referred as Ephemeral Named Relations (ENRs) thanks to Transition Table. We can calculate the diff set of the view by replacing the base table in the view definition query with the ENR (at least if it is Selection-Projection -Join view). As well as view definition time, GROUP BY and count(*) is added in order to count the duplicity of tuples in the diff set. As a result, two diff sets (to be deleted from and to be inserted into the view) are calculated, and the results are stored into temporary tables respectively.<br />
<br />
The view is updated by merging these change sets. Instead of executing DELETE or INSERT simply, the values of __ivm_count__ column in the view is decreased or increased. When the values becomes zero, the corresponding tuple is deleted from the view.<br />
<br />
== Aggregation support ==<br />
<br />
Currently, count sum, min, max and avg are supported.<br />
<br />
As a restriction, expressions specified in GROUP BY must appear in the target list of views because tuples to be updated in materialized views are identified by using this group keys. When creating a materialized view, more than one hidden columns for each aggregation are added to the target list. The name of these hidden column is like __ivm_count_sum__, for example.<br />
<br />
In the case of views without aggregate functions, only the number of tuple duplicates (__ivm_count__) are updated at incremental maintenance. On the other <br />
hand, in the case of vies with aggregations, the aggregated values and related hidden columns are also updated. The way of update depends the kind of aggregate function. Specifically, sum and count are updated by adding or subtracting delta values. avg is updated by using values of sum and count stored in views as hidden columns and deltas of them.<br />
<br />
In the case of sum and avg (or any aggregation functions except to count), NULL in input values is ignored, and this returns a null value when no rows are selected. To support this specification, the number of not-NULL input values is counted and stored in views as a hidden column. In the case of count, this returns zero when no rows are selected, and count(*) doesn't ignore NULL input. These specification are also supported.<br />
<br />
Tuples to be updated in materialized views are identified by using keys specified by GROUP BY clause. However, in the case of aggregation without GROUP BY, there is only one tuple in the view, so keys are not uses to identify tuples.<br />
<br />
== Access to Materialized Views ==<br />
<br />
When SELECT is issued for materialized views with IVM support defined with DISTINCT, all columns except to __ivm_count__ of each tuple are returned. This is correct because duplicity of tuples are eliminated by GROUP BY.<br />
<br />
When DISTINCT is not used, the query returns each tuple __ivm_count__ times. Currently, this is implemented by rewriting the SELECT<br />
query to replace the view RTE with a subquery which joins the view and generate_series function as bellow. <br />
<br />
SELECT mv.* FROM mv, generate_series(1, mv.__ivm_count__);<br />
<br />
__ivm_count__ column is invisible for users when "SELECT * FROM ..." is issued, but users can see the value by specifying in target list explicitly.<br />
<br />
<br />
== Restrictions on view definition ==<br />
<br />
The current implementation supports views including selection, projection, inner join with or without DISTINCT, and some aggregations (count, sum, agv) and GROUP BY. We are now working on min/max.<br />
<br />
Self-join and outer join are not supported, but now investigated. Subqueries, CTE, window functions are not considered well.<br />
<br />
== Timing of view maintenance ==<br />
<br />
This patch implements only a kind of Immediate Maintenance. For implementing Deferred Maintenance, we need a infrastructure to maintain these logs. For example, which logs are necessary and which logs can be discarded, etc.<br />
<br />
== Counting algorithm implementation ==<br />
<br />
The proposed patch treats "__ivm_count__" as a special column name in a somewhat ad hoc way. This is used when maintaining and accessing materialized views. When "SELECT * FROM ..." is issued to views, __ivm_count__ column is invisible for users. Note that users can not use this name as a user column in materialized views with IVM support. As for how to make internal columns invisible to SELECT *, there have been other discussions about doing that using a new flag in pg_attribute[https://www.postgresql.org/message-id/flat/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com].<br />
<br />
When a materialized view with duplicate tuples is accessed, this is replaced with a subquery which uses generate_series function. It does not have to be generate_series, and we can make a new set returning function for this. Anyway, this internal behaviour is visible in EXPLAIN results as below. <br />
<br />
postgres=# EXPLAIN SELECT * FROM m1;<br />
QUERY PLAN <br />
------------------------------------------------------------------------------<br />
Nested Loop (cost=0.00..61.03 rows=3000 width=2)<br />
-> Seq Scan on m1 mv (cost=0.00..1.03 rows=3 width=10)<br />
-> Function Scan on generate_series (cost=0.00..10.00 rows=1000 width=0)<br />
(3 rows)<br />
<br />
Also, there would be performance impact because estimated rows number by optimizer is wrong, and what is worse, the cost of join is not small when the size of view is large. Therefore, we might have to add a new plan node for selecting from materialized views with IVM support rather than using a special set returning function.<br />
<br />
== Concurrent Transactions ==<br />
<br />
When a view is defined on two tables and each table is modified in different concurrent transactions respectively, if a change in one transaction was not considered in another transaction in READ COMMITTED level, an anormal update of the materialized view would be possible. To prevent this, a lock on the materialized view is taken in early stage of view maintenance to wait for concurrent transactions which are updating the same view to end. Also, the latest snapshot is taken before computing delta tables to make any changes which occurs in other transaction during lock waiting visible.<br />
<br />
In REPEATABLE READ or SERIALIZABLE level, don't wait a lock, and raise an error immediately to prevent anormal update because table changes occurred in other transactions must not be visible, and views can not be maintained correctly in AFTER triggers.<br />
<br />
These solutions might be ugly, but something to prevent anormal update is anyway necessary. There may be better way. One idea to resolve this is performing view maintenance in two phases. Firstly, views are updated using only table changes visible in this transaction. Then, just after this transaction is committed, views have to be updated additionally using changes happened in other transactions to keep consistency. This is a just idea, but to implement this idea, we will need keep to keep and maintain change logs.<br />
<br />
= Links =<br />
<br />
== CommitFest ==<br />
<br />
* [https://commitfest.postgresql.org/23/2138/ Incremental Materialized View Maintenance]<br />
<br />
== Talks ==<br />
<br />
* [https://www.pgcon.org/2019/schedule/events/1316.en.html Towards Implementing Incremental View Maintenance on PostgreSQL (PGCon 2019) ]<br />
* [https://www.postgresql.eu/events/pgconfeu2018/schedule/session/2195-implementing-incremental-view-maintenance-on-postgresql/ Implementing Incremental View Maintenance on PostgreSQL (PGConf.EU 2018) ]<br />
* [https://wiki.postgresql.org/images/8/85/Materialised_Views_-_FOSDEM.pdf Materialised views now and the future (PGDay FOSDEM 2014)]<br />
<br />
== Wiki==<br />
* [[PgCon_2013_Developer_Meeting#Incremental_Maintenance_of_Matviews]]<br />
* [[Materialized Views]]<br />
<br />
== pgsql-hackers ==<br />
* [https://www.postgresql.org/message-id/1368561126.64093.YahooMailNeo%40web162904.mail.bf1.yahoo.com counting algorithm for incremental matview maintenance]<br />
* [https://www.postgresql.org/message-id/1368557513.95389.YahooMailNeo%40web162903.mail.bf1.yahoo.com Differential (transactional) REFRESH]<br />
* [https://www.postgresql.org/message-id/1371480075.55528.YahooMailNeo@web162901.mail.bf1.yahoo.com matview incremental maintenance]<br />
* [https://www.postgresql.org/message-id/flat/1371225929.28496.YahooMailNeo%40web162905.mail.bf1.yahoo.com refresh materialized view concurrently]<br />
* [https://www.postgresql.org/message-id/20161123031126.GQ32683%40localhost Alternative MATERIALIZED VIEW design and implementation with history table and other features]<br />
* [https://www.postgresql.org/message-id/1402790204.65037.YahooMailNeo@web122301.mail.ne1.yahoo.com delta relations in AFTER triggers]<br />
* [https://www.postgresql.org/message-id/CAEepm%3D3ZHh%3Dp0nEEnVbs1Dig_UShPzHUcMNAqvDQUgYgcDo-pA%40mail.gmail.com "SELECT *" vs hidden columns and logical column order]<br />
* [https://www.postgresql.org/message-id/flat/20141209174146.GP1768@alvh.no-ip.org logical column ordering]<br />
<br />
* [https://www.postgresql.org/message-id/154a391d341.1176179cb4319.144192970510819074%40zohocorp.com Incremental refresh of materialized view - Patch]<br />
* [https://www.postgresql.org/message-id/20170123233819.GD1838%40localhost Contrib: alternative MATERIALIZED VIEWs]<br />
* [https://www.postgresql.org/message-id/flat/CAKLmikMjJqVJbKijOxivhb9%3DA5PfoZcit2QowbJ4rFszzr4Zhw%40mail.gmail.com#b7829393acf1cfcbc507b137f5ebaeab Implementing Incremental View Maintenance]<br />
<br />
==pgsql-general ==<br />
* [https://www.postgresql.org/message-id/CAMjNa7eKJAetBMxfLzPreqxGHSeciRi3MuPXWOXMOsqe8CmpPg%40mail.gmail.com Incrementally refreshed materialized view ]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Connection_pooling&diff=31892Ecosystem:PostgreSQL only:Connection pooling2018-04-26T05:39:20Z<p>Ishii: /* Pgpool-II */</p>
<hr />
<div>== Pgpool-II ==<br />
<br />
* Provider -- Pgpool-II Global Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs, session level connection pooling, in memory query cache and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.<br />
* Additional info -- [[Ecosystem:Pgpool-II|click here]]<br />
<br />
[[Category:Ecosystem]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Clustering&diff=31891Ecosystem:PostgreSQL only:Clustering2018-04-26T05:37:00Z<p>Ishii: </p>
<hr />
<div>== EDB Postgres Failover Manager ==<br />
<br />
* Provider -- EnterpriseDB Corporation<br />
* Website -- https://www.enterprisedb.com/products/edb-postgres-platform/edb-postgres-failover-manager<br />
* License -- proprietary<br />
* Interoperability level -- explicitly supports PostgreSQL 9.5 or higher<br />
* Verified PostgreSQL versions -- See: https://www.enterprisedb.com/services/edb-supported-products-and-platforms#EFM<br />
* Last update (YYYY-MM-DD) -- 2017-6-7<br />
* Description -- Failover Manager creates highly available fault tolerant clusters minimizing database downtime with health monitoring, failure detection/notification, and automatic failover required in stringent 9s based high availability solutions. A simple and lightweight architecture without a single point of failure protects against a variety of failure scenarios that can be customized to specific application needs.<br />
* Additional info -- [[Ecosystem:EDB Postgres Failover Manager|click here]]<br />
<br />
== Postgres-BDR ==<br />
<br />
* Provider -- 2ndQuadrant<br />
* Website -- https://www.2ndquadrant.com/<br />
* License -- Proprietary<br />
* Interoperability level -- explicitly supports PostgreSQL 9.4 or higher<br />
* Verified PostgreSQL versions -- https://www.2ndquadrant.com/en/resources/bdr/<br />
* Last update (YYYY-MM-DD) -- 2018-03-16<br />
* Description --Postgres-BDR (Bi-Directional Replication for PostgreSQL) is a ground-breaking multi-master replication tool for PostgreSQL databases that has been in full production status since 2014. In the complex environment of replication, BDR achieves efficiency and accuracy, ensuring very high availability of all nodes in a geographically distributed cluster.<br />
* Additional info -- [[Ecosystem:Postgres-BDR|click here]]<br />
<br />
== repmgr ==<br />
<br />
* Provider -- 2ndQuadrant<br />
* Website -- https://www.2ndquadrant.com/<br />
* License -- GPL v3<br />
* Interoperability level -- explicitly supports PostgreSQL 9.1 or higher<br />
* Verified PostgreSQL versions -- https://www.2ndquadrant.com/en/resources/repmgr/<br />
* Last update (YYYY-MM-DD) -- 2018-03-09<br />
* Description -- repmgr helps DBAs and System Administrators manage a cluster of PostgreSQL databases. It simplifies administration and daily management, enhances productivity and reduces the overall costs of a PostgreSQL cluster.<br />
* Additional info -- [[Ecosystem:repmgr|click here]]<br />
<br />
== Pgpool-II ==<br />
<br />
* Provider -- Pgpool-II Global Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs, session level connection pooling, in memory query cache and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.<br />
* Additional info -- [[Ecosystem:Pgpool-II|click here]]<br />
<br />
[[Category:Ecosystem]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Clustering&diff=31890Ecosystem:PostgreSQL only:Clustering2018-04-26T05:35:41Z<p>Ishii: /* Pgpool-II */</p>
<hr />
<div>== EDB Postgres Failover Manager ==<br />
<br />
* Provider -- EnterpriseDB Corporation<br />
* Website -- https://www.enterprisedb.com/products/edb-postgres-platform/edb-postgres-failover-manager<br />
* License -- proprietary<br />
* Interoperability level -- explicitly supports PostgreSQL 9.5 or higher<br />
* Verified PostgreSQL versions -- See: https://www.enterprisedb.com/services/edb-supported-products-and-platforms#EFM<br />
* Last update (YYYY-MM-DD) -- 2017-6-7<br />
* Description -- Failover Manager creates highly available fault tolerant clusters minimizing database downtime with health monitoring, failure detection/notification, and automatic failover required in stringent 9s based high availability solutions. A simple and lightweight architecture without a single point of failure protects against a variety of failure scenarios that can be customized to specific application needs.<br />
* Additional info -- [[Ecosystem:EDB Postgres Failover Manager|click here]]<br />
<br />
== Postgres-BDR ==<br />
<br />
* Provider -- 2ndQuadrant<br />
* Website -- https://www.2ndquadrant.com/<br />
* License -- Proprietary<br />
* Interoperability level -- explicitly supports PostgreSQL 9.4 or higher<br />
* Verified PostgreSQL versions -- https://www.2ndquadrant.com/en/resources/bdr/<br />
* Last update (YYYY-MM-DD) -- 2018-03-16<br />
* Description --Postgres-BDR (Bi-Directional Replication for PostgreSQL) is a ground-breaking multi-master replication tool for PostgreSQL databases that has been in full production status since 2014. In the complex environment of replication, BDR achieves efficiency and accuracy, ensuring very high availability of all nodes in a geographically distributed cluster.<br />
* Additional info -- [[Ecosystem:Postgres-BDR|click here]]<br />
<br />
== repmgr ==<br />
<br />
* Provider -- 2ndQuadrant<br />
* Website -- https://www.2ndquadrant.com/<br />
* License -- GPL v3<br />
* Interoperability level -- explicitly supports PostgreSQL 9.1 or higher<br />
* Verified PostgreSQL versions -- https://www.2ndquadrant.com/en/resources/repmgr/<br />
* Last update (YYYY-MM-DD) -- 2018-03-09<br />
* Description -- repmgr helps DBAs and System Administrators manage a cluster of PostgreSQL databases. It simplifies administration and daily management, enhances productivity and reduces the overall costs of a PostgreSQL cluster.<br />
* Additional info -- [[Ecosystem:repmgr|click here]]<br />
<br />
=== Pgpool-II ===<br />
<br />
* Provider -- Pgpool-II Global Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs, session level connection pooling, in memory query cache and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.<br />
* Additional info -- [[Ecosystem:Pgpool-II|click here]]<br />
<br />
[[Category:Ecosystem]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Clustering&diff=31889Ecosystem:PostgreSQL only:Clustering2018-04-26T05:33:29Z<p>Ishii: /* repmgr */</p>
<hr />
<div>== EDB Postgres Failover Manager ==<br />
<br />
* Provider -- EnterpriseDB Corporation<br />
* Website -- https://www.enterprisedb.com/products/edb-postgres-platform/edb-postgres-failover-manager<br />
* License -- proprietary<br />
* Interoperability level -- explicitly supports PostgreSQL 9.5 or higher<br />
* Verified PostgreSQL versions -- See: https://www.enterprisedb.com/services/edb-supported-products-and-platforms#EFM<br />
* Last update (YYYY-MM-DD) -- 2017-6-7<br />
* Description -- Failover Manager creates highly available fault tolerant clusters minimizing database downtime with health monitoring, failure detection/notification, and automatic failover required in stringent 9s based high availability solutions. A simple and lightweight architecture without a single point of failure protects against a variety of failure scenarios that can be customized to specific application needs.<br />
* Additional info -- [[Ecosystem:EDB Postgres Failover Manager|click here]]<br />
<br />
== Postgres-BDR ==<br />
<br />
* Provider -- 2ndQuadrant<br />
* Website -- https://www.2ndquadrant.com/<br />
* License -- Proprietary<br />
* Interoperability level -- explicitly supports PostgreSQL 9.4 or higher<br />
* Verified PostgreSQL versions -- https://www.2ndquadrant.com/en/resources/bdr/<br />
* Last update (YYYY-MM-DD) -- 2018-03-16<br />
* Description --Postgres-BDR (Bi-Directional Replication for PostgreSQL) is a ground-breaking multi-master replication tool for PostgreSQL databases that has been in full production status since 2014. In the complex environment of replication, BDR achieves efficiency and accuracy, ensuring very high availability of all nodes in a geographically distributed cluster.<br />
* Additional info -- [[Ecosystem:Postgres-BDR|click here]]<br />
<br />
== repmgr ==<br />
<br />
* Provider -- 2ndQuadrant<br />
* Website -- https://www.2ndquadrant.com/<br />
* License -- GPL v3<br />
* Interoperability level -- explicitly supports PostgreSQL 9.1 or higher<br />
* Verified PostgreSQL versions -- https://www.2ndquadrant.com/en/resources/repmgr/<br />
* Last update (YYYY-MM-DD) -- 2018-03-09<br />
* Description -- repmgr helps DBAs and System Administrators manage a cluster of PostgreSQL databases. It simplifies administration and daily management, enhances productivity and reduces the overall costs of a PostgreSQL cluster.<br />
* Additional info -- [[Ecosystem:repmgr|click here]]<br />
<br />
=== Pgpool-II ===<br />
<br />
* Provider -- Pgpool-II Global Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs, session level connection pooling, in memory query cache and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.<br />
<br />
[[Category:Ecosystem]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Clustering&diff=31888Ecosystem:PostgreSQL only:Clustering2018-04-26T05:32:43Z<p>Ishii: </p>
<hr />
<div>== EDB Postgres Failover Manager ==<br />
<br />
* Provider -- EnterpriseDB Corporation<br />
* Website -- https://www.enterprisedb.com/products/edb-postgres-platform/edb-postgres-failover-manager<br />
* License -- proprietary<br />
* Interoperability level -- explicitly supports PostgreSQL 9.5 or higher<br />
* Verified PostgreSQL versions -- See: https://www.enterprisedb.com/services/edb-supported-products-and-platforms#EFM<br />
* Last update (YYYY-MM-DD) -- 2017-6-7<br />
* Description -- Failover Manager creates highly available fault tolerant clusters minimizing database downtime with health monitoring, failure detection/notification, and automatic failover required in stringent 9s based high availability solutions. A simple and lightweight architecture without a single point of failure protects against a variety of failure scenarios that can be customized to specific application needs.<br />
* Additional info -- [[Ecosystem:EDB Postgres Failover Manager|click here]]<br />
<br />
== Postgres-BDR ==<br />
<br />
* Provider -- 2ndQuadrant<br />
* Website -- https://www.2ndquadrant.com/<br />
* License -- Proprietary<br />
* Interoperability level -- explicitly supports PostgreSQL 9.4 or higher<br />
* Verified PostgreSQL versions -- https://www.2ndquadrant.com/en/resources/bdr/<br />
* Last update (YYYY-MM-DD) -- 2018-03-16<br />
* Description --Postgres-BDR (Bi-Directional Replication for PostgreSQL) is a ground-breaking multi-master replication tool for PostgreSQL databases that has been in full production status since 2014. In the complex environment of replication, BDR achieves efficiency and accuracy, ensuring very high availability of all nodes in a geographically distributed cluster.<br />
* Additional info -- [[Ecosystem:Postgres-BDR|click here]]<br />
<br />
== repmgr ==<br />
<br />
* Provider -- 2ndQuadrant<br />
* Website -- https://www.2ndquadrant.com/<br />
* License -- GPL v3<br />
* Interoperability level -- explicitly supports PostgreSQL 9.1 or higher<br />
* Verified PostgreSQL versions -- https://www.2ndquadrant.com/en/resources/repmgr/<br />
* Last update (YYYY-MM-DD) -- 2018-03-09<br />
* Description -- repmgr helps DBAs and System Administrators manage a cluster of PostgreSQL databases. It simplifies administration and daily management, enhances productivity and reduces the overall costs of a PostgreSQL cluster.<br />
* Additional info -- [[Ecosystem:repmgr|click here]]<br />
<br />
* Provider -- Pgpool-II Global Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs, session level connection pooling, in memory query cache and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.<br />
<br />
[[Category:Ecosystem]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Connection_pooling&diff=31887Ecosystem:PostgreSQL only:Connection pooling2018-04-26T05:26:47Z<p>Ishii: /* Pgpool-II */</p>
<hr />
<div>== Pgpool-II ==<br />
<br />
* Provider -- Pgpool-II Global Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs, session level connection pooling, in memory query cache and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Connection_pooling&diff=31886Ecosystem:PostgreSQL only:Connection pooling2018-04-26T05:26:30Z<p>Ishii: /* Pgpool-II */</p>
<hr />
<div>== Pgpool-II ==<br />
<br />
* Provider -- Pgpool-II Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs, session level connection pooling, in memory query cache and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Connection_pooling&diff=31885Ecosystem:PostgreSQL only:Connection pooling2018-04-26T05:26:11Z<p>Ishii: /* Pgpool-II */</p>
<hr />
<div>== Pgpool-II ==<br />
<br />
* Provider -- Pgpool-II Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs, session level connection pooling, query cache and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.</div>Ishiihttps://wiki.postgresql.org/index.php?title=Ecosystem:PostgreSQL_only:Connection_pooling&diff=31884Ecosystem:PostgreSQL only:Connection pooling2018-04-26T05:24:55Z<p>Ishii: Created page with "== Pgpool-II == * Provider -- Pgpool-II Development Group * Website -- https://pgpool.net * License -- PostgreSQL License * Interoperability level -- PostgreSQL 7.3 or higher..."</p>
<hr />
<div>== Pgpool-II ==<br />
<br />
* Provider -- Pgpool-II Development Group<br />
* Website -- https://pgpool.net<br />
* License -- PostgreSQL License<br />
* Interoperability level -- PostgreSQL 7.3 or higher<br />
* Verified PostgreSQL versions -- PostgreSQL 7.3 or higher<br />
* Last update (YYYY-MM-DD) -- 2018-04-26<br />
* Description -- Pgpool-II is a cluster management tool for PostgreSQL. It provides features currently lacking in PostgreSQL: automatic failover, automatic query dispatching to master (primary) server and slave (standby) servers, load balancing for SELECTs and more. Pgpool-II is mostly transparent to non-cluster-aware PostgreSQL applications. Also Pgpool-II provides built-in High Availability feature to protect Pgpool-II itself.</div>Ishiihttps://wiki.postgresql.org/index.php?title=Todo&diff=31535Todo2018-02-28T04:32:33Z<p>Ishii: /* psql */</p>
<hr />
<div><div style="margin: 1ex 1em; float: right;"><br />
__TOC__<br />
</div><br />
<br />
This list contains some known PostgreSQL bugs, some feature requests, and some things we are not even sure we want. Many of these items are hard, and some are perhaps impossible. If you would like to work on an item, please read the [[Developer FAQ]] first. There is also a [[Development_information|development information page]].<br />
<br />
* {{TodoPending}} - marks ordinary, incomplete items<br />
* {{TodoEasy}} - marks items that are easier to implement<br />
* {{TodoDone}} - marks changes that are done, and will appear in the PostgreSQL 11 release.<br />
<br />
For help on editing this list, please see [[Talk:Todo]]. <b>Please do not add items here without discussion on the [[Mailing_Lists|mailing list]].</b><br />
<br />
== Development Process ==<br />
<br />
<b>WARNING for Developers:</b> Unfortunately this list does not contain all the information necessary for someone to start coding a feature. Some of these items might have become unnecessary since they were added --- others might be desirable but the implementation might be unclear. When selecting items listed below, be prepared to first discuss the value of the feature. '''Do not assume that you can select one, code it and then expect it to be committed.''' Always discuss design on Hackers list before starting to code. The flow should be:<br />
<br />
Desirability -> Design -> Implement -> Test -> Review -> Commit<br />
<br />
== Administration ==<br />
<br />
{{TodoItem<br />
|Allow administrators to cancel long-lived prepared transactions<br />
* [http://www.postgresql.org/message-id/20961.1403630269@sss.pgh.pa.us Re: idle_in_transaction_timeout]<br />
}}<br />
<br />
{{TodoItem<br />
|Check for unreferenced table files created by transactions that were in-progress when the server terminated abruptly<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00096.php <nowiki>Removing unreferenced files</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow log_min_messages to be specified on a per-module basis<br />
|This would allow administrators to see more detailed information from specific sections of the backend, e.g. checkpoints, autovacuum, etc. Another idea is to allow separate configuration files for each module, or allow arbitrary SET commands to be passed to them. See also [[Logging Brainstorm]].}}<br />
<br />
{{TodoItem<br />
|Allow custom variables to appear in pg_settings()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00850.php <nowiki>Re: count(*) performance improvement ideas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have custom variables be transaction-safe<br />
* {{MessageLink|4B577E9F.8000505@dunslane.net|Custom GUCs still a bit broken}}<br />
* {{MessageLink|alpine.DEB.2.20.1701081007440.10378@lancre|proposal: session server side variables}}<br />
}}<br />
<br />
{{TodoItem<br />
|Implement the SQL-standard mechanism whereby REVOKE ROLE revokes only the privilege granted by the invoking role, and not those granted by other roles<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-05/msg00010.php <nowiki>Re: Grantor name gets lost when grantor role dropped</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent query cancel packets from being replayed by an attacker, especially when using SSL<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00345.php <nowiki>Replay attack of query cancel</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve logging of prepared transactions recovered during startup<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg00092.php <nowiki>&quot;recovering prepared transaction&quot; after server restart message</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider supporting incremental base backups<br />
* http://www.postgresql.org/message-id/543D5AA7.9@2ndquadrant.it<br />
}}<br />
<br />
=== Configuration files ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Consider normalizing fractions in postgresql.conf, perhaps using '%'<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php <nowiki>Fractions in GUC variables</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add external tool to auto-tune some postgresql.conf parameters<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00000.php <nowiki>Re: Overhauling GUCS</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00033.php <nowiki>Simple postgresql.conf wizard</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow pg_hba.conf to process include files<br />
* [http://www.postgresql.org/message-id/86fvnm5t44.fsf@jerry.enova.com HBA files w/include support]<br />
}}<br />
<br />
{{TodoItem<br />
|Create utility to compute accurate random_page_cost value<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00162.php<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00362.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow synchronous_standby_names to be disabled after communication failure with all synchronous standby servers exceeds some timeout<br />
|This also requires successful execution of a synchronous notification command.<br />
* http://archives.postgresql.org/pgsql-hackers/2012-07/msg00409.php<br />
* [http://www.postgresql.org/message-id/BF2827DCCE55594C8D7A8F7FFD3AB7713DD9A622@SZXEML508-MBX.china.huawei.com Standalone synchronous master]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-12/msg01224.php<br />
}}<br />
<br />
{{TodoItem<br />
|Fix log_line_prefix to display the transaction id (%x) for statements not in a transaction block<br />
* Currently it displays zero.<br />
}}<br />
<br />
{{TodoItem<br />
|Adjust rounding behavior for numeric GUC values<br />
* http://www.postgresql.org/message-id/53BE3815.4010203@po.ntts.co.jp<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Tablespaces ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow a database in tablespace t1 with tables created in tablespace t2 to be used as a template for a new database created with default tablespace t2<br />
|Currently all objects in the default database tablespace must have default tablespace specifications. This is because new databases are created by copying directories. If you mix default tablespace tables and tablespace-specified tables in the same directory, creating a new database from such a mixed directory would create a new database with tables that had incorrect explicit tablespaces. To fix this would require modifying pg_class in the newly copied database, which we don't currently do.}}<br />
<br />
{{TodoItem<br />
|Allow reporting of which objects are in which tablespaces<br />
|This item is difficult because a tablespace can contain objects from multiple databases. There is a server-side function that returns the databases which use a specific tablespace, so this requires a tool that will call that function and connect to each database to find the objects in each database for that tablespace.}}<br />
<br />
{{TodoItem<br />
|Allow WAL replay of CREATE TABLESPACE to work when the directory structure on the recovery computer is different from the original<br />
* [https://www.postgresql.org/message-id/20180214042443.GB1993%40paquier.xyz Remarks about the difficulty of the item]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow per-tablespace quotas}}<br />
<br />
{{TodoItem<br />
|Allow tablespaces on RAM-based partitions for unlogged tables<br />
* http://archives.postgresql.org/pgsql-advocacy/2011-05/msg00033.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow tablespaces on RAM-based partitions for temporary objects<br />
* [https://www.postgresql.org/message-id/20170529185308.GB28209@momjian.us Use of non-restart-safe storage by temp_tablespaces]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow toast tables to be moved to a different tablespace<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-05/msg00980.php moving toast table to its own tablespace]<br />
* {{messageLink|CAFEQCbH756DyyAPQ1ykh3+b+kE1-EhWRww1WO_x5v38C-uLnUg@mail.gmail.com|patch : Allow toast tables to be moved to a different tablespace}}<br />
}}<br />
<br />
{{TodoItem<br />
|Close race in DROP TABLESPACE on Windows<br />
* http://www.postgresql.org/message-id/20141108050423.GA642055@tornado.leadboat.com<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Statistics Collector ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Testing pgstat via pg_regress is tricky and inefficient. Consider making a dedicated pgstat test-suite.<br />
* [http://www.postgresql.org/message-id/20141216142937.GX1768@alvh.no-ip.org <nowiki>Re: REVIEW: Track TRUNCATE via pgstat</nowiki>]<br />
}}<br />
{{TodoItem<br />
|Track number of WAL files ready to be archived in pg_stat_archiver <br />
* [http://www.postgresql.org/message-id/CAB7nPqSCrcZGGy_SmpT7ubSzVGNMtphYU1JJZYyapHuN46E-Tw@mail.gmail.com <nowiki>pg_stat_archiver missing feature</nowiki>]<br />
* [http://www.postgresql.org/message-id/53F5AB0A.5060502@dalibo.com Track number of files ready to be archived in pg_stat_archiver]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== SSL ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
| Allow automatic selection of SSL client certificates from a certificate store<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg00406.php <nowiki>Allow multiple certificates or keys in the postgresql.crt/.key files</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Send the full certificate server chain to the client<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-12/msg00145.php BUG #5245: Full Server Certificate Chain Not Sent to client]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Point-In-Time Recovery (PITR) ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow archive_mode to be changed without server restart?<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01655.php <nowiki>Enabling archive_mode without restart</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Standby server mode ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
| Allow pg_xlogfile_name() to be used in recovery mode<br />
* [http://archives.postgresql.org/message-id/3f0b79eb1001190135vd9f62f1sa7868abc1ea61d12@mail.gmail.com <nowiki>Streaming replication and pg_xlogfile_name()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Prevent variables inherited from the server environment from being used for making streaming replication connections<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01011.php <nowiki>Re: Parameter name standby_mode</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Change walsender so that it applies per-role settings<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00642.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure configuration parameters for standby mode<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg01820.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Data Types ==<br />
<br />
{{TodoItem<br />
|Fix data types where equality comparison is not intuitive, e.g. box<br />
* http://archives.postgresql.org/pgsql-hackers/2011-10/msg01643.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for public SYNONYMs<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00519.php <nowiki>Proposal for SYNONYMS</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg02043.php<br />
* http://archives.postgresql.org/pgsql-general/2010-12/msg00139.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for SQL-standard GENERATED columns<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-07/msg00543.php <nowiki>Re: Three weeks left until feature freeze</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00038.php <nowiki>GENERATED ... AS IDENTITY, Was: Re: Feature Freeze</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00344.php <nowiki>Behavior of GENERATED columns per SQL2003</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00076.php <nowiki>Re: [HACKERS] Behavior of GENERATED columns per SQL2003</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00604.php <nowiki>IDENTITY/GENERATED patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a special data type for regular expressions<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg01067.php <nowiki>Why is there a tsquery data type?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow deleting enumerated values from an existing enumerated data type<br />
* [http://www.postgresql.org/message-id/CAO%3D2mx6uvgPaPDf-rHqG8%3D1MZnGyVDMQeh8zS4euRyyg4D35OQ@mail.gmail.com Alter or rename enum value]<br />
}}<br />
<br />
{{TodoItem<br />
|Add overlaps geometric operators that ignore point overlaps<br />
* http://archives.postgresql.org/pgsql-hackers/2010-03/msg00861.php<br />
}}<br />
<br />
{{TodoItem<br />
| Add IMMUTABLE column attribute<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00623.php<br />
}}<br />
<br />
=== Domains ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow functions defined as casts to domains to be called during casting<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-05/msg00072.php <nowiki>bug? non working casts for domain</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-09/msg01681.php <nowiki>TODO: Fix CREATE CAST on DOMAINs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow values to be cast to domain types<br />
* [http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php <nowiki>Domain casting still doesn't work right</nowiki>] <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php <nowiki>domain casting?</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg00812.php<br />
}}<br />
<br />
{{TodoItem<br />
|Make domains work better with polymorphic functions<br />
* [http://archives.postgresql.org/message-id/4887.1228700773@sss.pgh.pa.us Polymorphic types vs. domains]<br />
* [http://archives.postgresql.org/message-id/15535.1238774571@sss.pgh.pa.us some difficulties with fixing it]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Dates and Times ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow infinite intervals just like infinite timestamps<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg00076.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow TIMESTAMP WITH TIME ZONE to store the original timezone information, either zone name or offset from UTC<br />
|If the TIMESTAMP value is stored with a time zone name, interval computations should adjust based on the time zone rules. <br />
* [http://archives.postgresql.org/pgsql-hackers/2004-10/msg00705.php <nowiki>timestamp with time zone a la sql99</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have timestamp subtraction not call justify_hours()?<br />
* [http://archives.postgresql.org/pgsql-sql/2006-10/msg00059.php <nowiki>timestamp subtraction (was Re: formatting intervals with to_char)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow a comma to denote fractional seconds in ISO-8601-compliant times (and timestamps)<br />
* http://www.postgresql.org/message-id/7D5AC9AB-238D-4FE7-8857-18D98190A4D9@justatheory.com<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Arrays ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow single-byte header storage for array elements}}<br />
<br />
{{TodoItem<br />
|Add function to detect if an array is empty<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00475.php <nowiki>Re: array_length()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of NULLs in arrays<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-11/msg00009.php <nowiki>BUG #4509: array_cat's null behaviour is inconsistent</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01040.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== MONEY Data Type ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add locale-aware MONEY type, and support multiple currencies<br />
* [http://archives.postgresql.org/pgsql-general/2005-08/msg01432.php <nowiki>A real currency type</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01181.php <nowiki>Money type todos?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|MONEY dumps in a locale-specific format making it difficult to restore to a system with a different locale}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Text Search ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow dictionaries to change the token that is passed on to later dictionaries<br />
* [http://archives.postgresql.org/pgsql-patches/2007-11/msg00081.php <nowiki>a tsearch2 (8.2.4) dictionary that only filters out stopwords</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a function-based API for '@@' searches<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00511.php <nowiki>Some recent advances in<br />
full-text search</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve text search error messages<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php <nowiki>Poorly designed tsearch NOTICEs</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider changing error to warning for strings larger than one megabyte<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-02/msg00190.php <nowiki>BUG #3975: tsearch2 index should not bomb out of 1Mb limit</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|tsearch and tsdicts regression tests fail in Turkish locale on glibc<br />
* [http://archives.postgresql.org/message-id/49749645.5070801@gmx.net tsearch with Turkish locale]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of dash and plus signs in email address user names, and perhaps improve URL parsing<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00772.php<br />
* [http://archives.postgresql.org/message-id/E1Ri8il-0008Ct-9p@wrigleys.postgresql.org tsearch does not recognize all valid emails]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve default parser, to more easily allow adding new tokens<br />
* http://archives.postgresql.org/message-id/23485.1297727826@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Add additional support functions<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00319.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== XML ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow XML arrays to be cast to other data types<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00981.php <nowiki>proposal casting from XML[] to int[], numeric[], text[]</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add XML Schema validation and xmlvalidate functions (SQL:2008)}}<br />
<br />
{{TodoItem<br />
|Add xmlvalidatedtd variant to support validating against a DTD?}}<br />
<br />
{{TodoItem<br />
|Relax-NG validation; libxml2 supports this already}}<br />
<br />
{{TodoItem<br />
|Allow reliable XML operation non-UTF8 server encodings (xpath(), in particular, is known to not work)<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-01/msg00135.php <nowiki>BUG #4622: xpath only work in utf-8 server encoding</nowiki>] <br />
* http://archives.postgresql.org/message-id/4110.1238973350@sss.pgh.pa.us}}<br />
<br />
{{TodoItem<br />
|Add functions from SQL:2006: XMLDOCUMENT, XMLCAST, XMLTEXT}}<br />
<br />
{{TodoItem<br />
|Add XMLNAMESPACES support in XMLELEMENT and elsewhere}}<br />
<br />
{{TodoItem<br />
|Move XSLT from contrib/xml2 to a more reasonable location<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00539.php<br />
}}<br />
<br />
{{TodoItem<br />
|Report errors returned by the XSLT library<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00562.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve the XSLT parameter passing API<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg00416.php<br />
}}<br />
<br />
{{TodoItem<br />
|XML Canonical: Convert XML documents to canonical form to compare them. libxml2 has support for this.}}<br />
<br />
{{TodoItem<br />
|Add pretty-printed XML output option<br />
|Parse a document and serialize it back in some indented form. libxml2 might support this.}}<br />
<br />
{{TodoItem<br />
|Add XMLQUERY (from the SQL/XML standard)}}<br />
<br />
{{TodoItem<br />
|Allow XML shredding<br />
|In some cases shredding could be better option (if there is no need to keep XML docs entirely, e.g. if we have already developed tools that understand only relational data. This would be a separate module that implements annotated schema decomposition technique, similar to DB2 and SQL Server functionality.}}<br />
<br />
{{TodoItem<br />
|XPath: Adding the <x> at the root causes problems [http://archives.postgresql.org/pgsql-bugs/2008-05/msg00184.php] [http://archives.postgresql.org/pgsql-bugs/2008-07/msg00054.php] [http://archives.postgresql.org/pgsql-general/2008-07/msg00613.php]}}<br />
<br />
{{TodoItem<br />
|xpath_table needs to be implemented/implementable to get rid of contrib/xml2 [http://archives.postgresql.org/pgsql-general/2008-05/msg00823.php]}}<br />
<br />
{{TodoItem<br />
|xpath_table is pretty broken anyway [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02424.php]}}<br />
<br />
{{TodoItem<br />
|better handling of XPath data types [http://archives.postgresql.org/pgsql-hackers/2008-06/msg00616.php] [http://archives.postgresql.org/message-id/004a01c90e90$4b986d90$e2c948b0$@anstett@iaas.uni-stuttgart.de]}}<br />
<br />
{{TodoItem<br />
|Improve handling of PIs and DTDs in xmlconcat() [http://archives.postgresql.org/message-id/200904211211.n3LCB09p008988@wwwmaster.postgresql.org]}}<br />
<br />
{{TodoItem<br />
|Restructure XML and /contrib/xml2 functionality<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02314.php<br />
}}<br />
<br />
{{TodoItem<br />
|Verify Xpath escaping behavior<br />
* [http://www.postgresql.org/message-id/E1VOXZv-0008Q9-0Z@wrigleys.postgresql.org Xpath behaviour unintuitive / arguably wrong]<br />
* [http://www.postgresql.org/message-id/CAAY5AM1L83y79rtOZAUJioREO6n4%3DXAFKcGu6qO3hCZE1yJytg@mail.gmail.com xpath missing entity decoding - bug or feature]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Functions ==<br />
<br />
{{TodoItem<br />
|Enforce typmod for function inputs, function results and parameters for spi_prepare'd statements called from PLs<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg01403.php <nowiki>Re: BUG #2917: spi_prepare doesn't accept typename aliases</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01160.php <nowiki>RFC for adding typmods to functions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix IS OF so it matches the ISO specification, and add documentation<br />
* [http://archives.postgresql.org/pgsql-patches/2003-08/msg00060.php <nowiki>Re: [HACKERS] IS OF</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00060.php <nowiki>ToDo: add documentation for operator IS OF</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement Boyer-Moore searching in LIKE queries<br />
* {{messageLink|27645.1220635769@sss.pgh.pa.us|TODO item: Implement Boyer-Moore searching (First time hacker)}}<br />
* [https://www.postgresql.org/message-id/CALkFZpcbipVJO%3DxVvNQMZ7uLUgHzBn65GdjtBHdeb47QV4XzLw@mail.gmail.com Implement Boyer-Moore searching in LIKE queries]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent malicious functions from being executed with the permissions of unsuspecting users<br />
|Indexed functions are safe, so VACUUM and ANALYZE are safe too. Triggers, CHECK and DEFAULT expressions, and rules are still vulnerable. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00268.php <nowiki>Some notes about the index-functions security vulnerability</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce memory usage of aggregates in set returning functions<br />
* [http://archives.postgresql.org/pgsql-performance/2008-01/msg00031.php <nowiki>Re: Performance of aggregates over set-returning functions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix /contrib/ltree operator<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php <nowiki>BUG #3720: wrong results at using ltree</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix /contrib/btree_gist's implementation of inet indexing<br />
* [http://archives.postgresql.org/pgsql-bugs/2010-10/msg00099.php <nowiki>BUG #5705: btree_gist: Index on inet changes query result</nowiki>]<br />
}}<br />
<br />
=== Character Formatting ===<br />
<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Allow to_date() and to_timestamp() to accept localized month names}}<br />
<br />
{{TodoItem<br />
|Add missing parameter handling in to_char()<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-12/msg00948.php <nowiki>Re: to_char and i18n</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Throw an error from to_char() instead of printing a string of "#" when a number doesn't fit in the desired output format.<br />
* discussed in [http://archives.postgresql.org/message-id/37ed240d0907290836w42187222n18664dfcbcb445b1@mail.gmail.com "to_char, support for EEEE format"]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix to_number() handling for values not matching the format string<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01447.php <nowiki>Re: numeric_to_number() function skipping some digits</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Multi-Language Support ==<br />
<br />
{{TodoItem<br />
|Add NCHAR (as distinguished from ordinary varchar)<br />
* [http://www.postgresql.org/message-id/A756FAD7EDC2E24F8CAB7E2F3B5375E918B12BC0@FALEX03.au.fjanz.com UTF8 national character data type support WIP patch and list of open issues.]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a cares-about-collation column to pg_proc, so that unresolved-collation errors can be thrown at parse time<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-03/msg01520.php <nowiki>Open issues for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Integrate collations with text search configurations<br />
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Integrate collations with to_char() and related functions<br />
* [http://archives.postgresql.org/message-id/28887.1303579034@sss.pgh.pa.us <nowiki>Some TODO items for collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support collation-sensitive equality and hashing functions<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-06/msg00472.php <nowiki> contrib/citext versus collations</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a LOCALE option to CREATE DATABASE, as a shorthand<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00119.php <nowiki> Re: 8.4 open items list</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support multiple simultaneous character sets, per SQL:2008}}<br />
<br />
{{TodoItem<br />
|Improve UTF8 combined character handling?}}<br />
<br />
{{TodoItem<br />
|Add octet_length_server() and octet_length_client()}}<br />
<br />
{{TodoItem<br />
|Make octet_length_client() the same as octet_length()?}}<br />
<br />
{{TodoItem<br />
|Fix problems with wrong runtime encoding conversion for NLS message files}}<br />
<br />
{{TodoItem<br />
|Fix contrib/fuzzystrmatch to work with multibyte encodings<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00047.php <nowiki> soundex function returns UTF-16 characters</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00138.php <nowiki> dmetaphone woes</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Change memory allocation for multi-byte functions so memory is allocated inside conversion functions<br />
|Currently we preallocate memory based on worst-case usage.}}<br />
<br />
{{TodoItem<br />
|Add ability to use case-insensitive regular expressions on multi-byte characters<br />
|Currently it works for UTF-8, but not other multi-byte encodings<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00433.php <nowiki>Regexps vs. locale</nowiki>]<br />
* {{MessageLink|20091201210024.B1393753FB7@cvs.postgresql.org|A partial solution for UTF-8}}<br />
}}<br />
<br />
{{TodoItem<br />
|Improve encoding of connection startup messages sent to the client<br />
|Currently some authentication error messages are sent in the server encoding<br />
* [http://archives.postgresql.org/pgsql-general/2008-12/msg00801.php <nowiki>encoding of PostgreSQL messages</nowiki>]<br />
* [http://www.postgresql.org/message-id/20131220030725.GA1411150@tornado.leadboat.com multibyte messages are displayed incorrectly on the client]<br />
}}<br />
<br />
{{TodoItem<br />
|Windows: Cache MessageEncoding conversion for use outside transactions<br />
* http://www.postgresql.org/message-id/20150812055719.GA1945333@tornado.leadboat.com<br />
}}<br />
<br />
{{TodoItem<br />
|More sensible support for Unicode combining characters, normal forms<br />
* http://archives.postgresql.org/message-id/200904141532.44618.peter_e@gmx.net<br />
}}<br />
<br />
== Views and Rules ==<br />
<br />
{{TodoItem<br />
|Allow VIEW/RULE recompilation when the underlying tables change<br />
|This is both difficult and controversial.<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01723.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change"]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg01724.php Re: About "Allow VIEW/RULE recompilation when the underlying tables change2"]<br />
* [http://archives.postgresql.org/message-id/CACk%3DU9NFSzWrEba8G5dZ%3DTZLy3_hx3QXGyCcKVWT%3D4iA1FjMuA@mail.gmail.com VIEW still referring to old name of field]<br />
* [http://www.postgresql.org/message-id/87mwe4k46y.fsf@commandprompt.com Re-create dependent views on ALTER TABLE ALTER COLUMN ... TYPE?]<br />
}}<br />
{{TodoItem<br />
|Make it possible to use RETURNING together with conditional DO INSTEAD rules, such as for partitioning setups<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00577.php <nowiki>RETURNING and DO INSTEAD ... Intentional or not?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve ability to modify views via ALTER TABLE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00691.php <nowiki>Re: idea: storing view source in system catalogs</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg01410.php <nowiki>modifying views</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-08/msg00300.php <nowiki>Re: patch: Add columns via CREATE OR REPLACE VIEW</nowiki>]<br />
}}<br />
<br />
== SQL Commands ==<br />
<br />
{{TodoItem<br />
|Add CORRESPONDING BY to UNION/INTERSECT/EXCEPT<br />
* [http://dissipatedheat.com/2011/11/10/how-not-to-write-a-patch-for-postgresql/ How not to write this patch.]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve type determination of unknown (NULL or quoted literal) result columns for UNION/INTERSECT/EXCEPT<br />
* [http://archives.postgresql.org/message-id/9799.1302719551@sss.pgh.pa.us <nowiki>UNION construct type cast gives poor error message</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow prepared transactions with temporary tables created and dropped in the same transaction, and when an ON COMMIT DELETE ROWS temporary table is accessed<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php <nowiki>Re: &quot;could not open relation 1663/16384/16584: No such file or directory&quot; in a specific combination of transactions with temp tables</nowiki>]<br />
* [http://archives.postgresql.org/message-id/492543D5.9050904@enterprisedb.com A suggestion on how to implement this]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a GUC variable to warn about non-standard SQL usage in queries}}<br />
<br />
{{TodoItem<br />
|Add NOVICE output level for helpful messages<br />
|For example, have it warn about unjoined tables. This could also control automatic sequence/index creation messages.<br />
}}<br />
<br />
{{TodoItem<br />
|Add SQL-standard MERGE command<br />
|MERGE is typically used to merge two tables, for data warehousing type use cases. PostgreSQL has an "UPSERT" command as of version 9.5, with the addition of "ON CONFLICT DO UPDATE". SQL MERGE is independently useful, though.<br />
}}<br />
<br />
{{TodoItem<br />
|Allow NOTIFY in rules involving conditionals}}<br />
<br />
{{TodoItem<br />
|Allow LISTEN on patterns<br />
* http://www.postgresql.org/message-id/52693FC5.7070507@gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Simplify dropping roles that have objects in several databases}}<br />
<br />
{{TodoItem<br />
|Add support for WITH RECURSIVE ... CYCLE<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00291.php <nowiki>WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows</nowiki>]}}<br />
<br />
{{TodoItem<br />
|Add DEFAULT .. AS OWNER so permission checks are done as the table owner<br />
|This would be useful for SERIAL nextval() calls and CHECK constraints.}}<br />
<br />
{{TodoItem<br />
|Allow DISTINCT to work in multiple-argument aggregate calls}}<br />
<br />
{{TodoItem<br />
|Add comments on system tables/columns using the information in catalogs.sgml<br />
|Ideally the information would be pulled from the SGML file automatically.}}<br />
<br />
{{TodoItem<br />
|Prevent the specification of conflicting transaction read/write options<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00684.php <nowiki>Re: SET TRANSACTION and SQL Standard</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow DELETE and UPDATE to be used with LIMIT and ORDER BY<br />
* http://archives.postgresql.org/pgadmin-hackers/2010-04/msg00078.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg01997.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow PREPARE of cursors}}<br />
<br />
{{TodoItem<br />
|Have DISCARD PLANS discard plans cached by functions<br />
|DISCARD ALL should do the same.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00431.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid multiple-evaluation of BETWEEN and IN arguments containing volatile expressions<br />
* http://archives.postgresql.org/message-id/4D95B605.2020709@enterprisedb.com<br />
}}<br />
<br />
=== CREATE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow CREATE TABLE AS to determine column lengths for complex expressions like SELECT col1 || col2}}<br />
<br />
{{TodoItem<br />
|Have WITH CONSTRAINTS also create constraint indexes<br />
* [http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php <nowiki>Re: CREATE TABLE LIKE INCLUDING INDEXES support</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Move NOT NULL constraint information to pg_constraint<br />
|Currently NOT NULL constraints are stored in pg_attribute without any designation of their origins, e.g. primary keys. One manifest problem is that dropping a PRIMARY KEY constraint does not remove the NOT NULL constraint designation. Another issue is that we should probably force NOT NULL to be propagated from parent tables to children, just as CHECK constraints are. (But then does dropping PRIMARY KEY affect children?)<br />
* http://archives.postgresql.org/message-id/19768.1238680878@sss.pgh.pa.us<br />
* http://archives.postgresql.org/message-id/200909181005.n8IA5Ris061239@wwwmaster.postgresql.org<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg01223.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00358.php<br />
* [https://www.postgresql.org/message-id/CAB7nPqTPXgX9HiyhhtAgpW7jbA1iskMCSoqXPEEB_KYXYy1E1Q@mail.gmail.com Prevent ALTER TABLE DROP NOT NULL on child tables if parent column has it]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent concurrent CREATE TABLE from sometimes returning a cryptic error message<br />
* [http://archives.postgresql.org/pgsql-bugs/2007-10/msg00169.php <nowiki>BUG #3692: Conflicting create table statements throw unexpected error</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add CREATE SCHEMA ... LIKE that copies a schema}}<br />
<br />
{{TodoItem<br />
|Fix CREATE OR REPLACE FUNCTION to not leave objects depending on the function in inconsistent state<br />
* [http://archives.postgresql.org/pgsql-general/2008-08/msg00985.php indexes on functions and create or replace function]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow temporary tables to exist as empty by default in all sessions<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00006.php <nowiki>what is difference between LOCAL and GLOBAL TEMP TABLES in PostgreSQL</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg01329.php <nowiki>idea: global temp tables</nowiki>]<br />
* [http://archives.postgresql.org//pgsql-hackers/2009-05/msg00016.php <nowiki>Re: idea: global temp tables</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg01098.php <nowiki>global temporary tables</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2012-04/msg01148.php Temporary tables under hot standby]<br />
* [http://www.postgresql.org/message-id/CAFj8pRC2h6qhHsFbcE7b_7SagiS6o%3D5J2UvCwCb05Ka1XFv_Ng@mail.gmail.com Implementation of global temporary tables?]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the creation of "distinct" types<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01647.php <nowiki>Distinct types</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider analyzing temporary tables when they are first used in a query<br />
|Autovacuum cannot analyze or vacuum temporary tables.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-04/msg00416.php <nowiki>autovacuum and temp tables support</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== UPDATE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Research self-referential UPDATEs that see inconsistent row versions in read-committed mode<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php <nowiki>Concurrently updating an updatable view</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve performance of EvalPlanQual mechanism that rechecks already-updated rows<br />
|This is related to the previous item, which questions whether it even has the right semantics<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-09/msg00045.php <nowiki>BUG #4401: concurrent updates to a table blocks one update indefinitely</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-07/msg00302.php <nowiki>BUG #4945: Parallel update(s) gone wild</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ALTER ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Have ALTER TABLE RENAME of a SERIAL column rename the sequence<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00008.php <nowiki>Re: newbie: renaming sequences task</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CADLWmXUV4LbLhMZL8rYMhCy72aZZLB5BSARPQVgoX0BrxA0FFg@mail.gmail.com renaming implicit sequences]<br />
}}<br />
<br />
{{TodoItem<br />
|Add ALTER DOMAIN to modify the underlying data type}}<br />
<br />
{{TodoItem<br />
|Allow ALTER TABLESPACE to move the tablespace to different directories}}<br />
<br />
{{TodoItem<br />
|Allow moving system tables to other tablespaces, where possible<br />
|Currently non-global system tables must be in the default database tablespace. Global system tables can never be moved.}}<br />
<br />
{{TodoItem<br />
|Have ALTER INDEX update the name of a constraint using that index}}<br />
<br />
{{TodoItem<br />
|Allow column display reordering by recording a display, storage, and permanent id for every column?<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00782.php <nowiki>Re: column ordering, was Re: [PATCHES] Enums patch v2</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01029.php <nowiki>Column reordering in pg_dump</nowiki>]<br />
* http://archives.postgresql.org/message-id/1324412114-sup-9608@alvh.no-ip.org<br />
* [http://www.postgresql.org/message-id/CAApHDvqhnuznxd4xVMFDcGn+nHVYyUtJ-TvbRsOuR%3DPaVbbGqw@mail.gmail.com logical column order and physical column order]<br />
* [http://www.postgresql.org/message-id/20141209174146.GP1768@alvh.no-ip.org logical column ordering]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow deactivating (and reactivating) indexes via ALTER TABLE<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg01191.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add ALTER OPERATOR ... RENAME<br />
|needs to consider effects of changing operator precedence<br />
* [http://archives.postgresql.org/message-id/1322948781.26266.9.camel@vanquo.pezone.net Missing rename support]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== CLUSTER ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Automatically maintain clustering on a table<br />
|This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied hash function.<br />
* [http://archives.postgresql.org/pgsql-performance/2004-08/msg00350.php <nowiki>Equivalent praxis to CLUSTERED INDEX?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00155.php <nowiki>Re: Grouped Index Tuples</nowiki>]<br />
* http://community.enterprisedb.com/git/<br />
* [http://archives.postgresql.org/pgsql-performance/2009-10/msg00346.php <nowiki>Re: maintain_cluster_order_v5.patch</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Allow CLUSTER to be used on partial indexes<br />
* http://www.postgresql.org/message-id/CAMkU%3D1zYwoHHsqJ8wfK3GdG_t_a6t4RK-GFDSKymQ0EGP%3DtypA@mail.gmail.com<br />
}} <br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== COPY ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow COPY to report error lines and continue<br />
|This requires the use of a savepoint before each COPY line is processed, with ROLLBACK on COPY failure. <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php <nowiki>Re: VLDB Features</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY to report errors sooner<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg01169.php <nowiki>Timely reporting of COPY errors</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY FROM to create index entries in bulk<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00811.php <nowiki>Batch update of indexes on data loading</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve COPY performance<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00954.php <nowiki>Re: 8.3 / 8.2.6 restore comparison</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01882.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow a stalled COPY to exit if the backend is terminated<br />
* [http://archives.postgresql.org/pgsql-bugs/2009-04/msg00067.php <nowiki>Re: possible bug not in open items</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow COPY "text" format to output a header<br />
* [http://www.postgresql.org/message-id/CACfv+pJ31tesLvncJyP24quo8AE+M0GP6p6MEpwPv6yV8%3DsVHQ@mail.gmail.com Why doesn't COPY support the HEADER options for tab-separated output?]<br />
}}<br />
<br />
{{TodoItem<br />
|Have COPY FREEZE set PD_ALL_VISIBLE<br />
* [http://www.postgresql.org/message-id/CAMkU%3D1w3osJJ2FneELhhNRLxfZitDgp9FPHee08NT2FQFmz_pQ@mail.gmail.com items]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== GRANT/REVOKE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow dropping of a role that has connection rights<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00736.php <nowiki>DROP ROLE dependency tracking ...</nowiki>]<br />
}}<br />
{{TodoEndSubsection}}<br />
<br />
=== DECLARE CURSOR ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Prevent DROP TABLE from dropping a table referenced by its own open cursor?}}<br />
<br />
{{TodoItem<br />
|Provide some guarantees about the behavior of cursors that invoke volatile functions<br />
* [http://archives.postgresql.org/message-id/20997.1244563664@sss.pgh.pa.us Re: Cursor with hold emits the same row more than once across commits in 8.3.7]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== SHOW/SET ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add SET PERFORMANCE_TIPS option to suggest INDEX, VACUUM, VACUUM ANALYZE, and CLUSTER}}<br />
<br />
{{TodoItem<br />
|Rationalize the discrepancy between settings that use values in bytes and SHOW that returns the object count<br />
* [http://archives.postgresql.org/pgsql-docs/2008-07/msg00007.php <nowiki>Re: [ADMIN] shared_buffers and shmmax</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ANALYZE ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve how ANALYZE computes in-doubt tuples<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php <nowiki>VACUUM/ANALYZE counting of in-doubt tuples</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Remove quadratic time in statistics sender when analyzing many tables<br />
* [http://www.postgresql.org/message-id/flat/CAMkU%3D1wLjAsmJNuB6ZObZmGHqi9jLbK6n1eSgnOc5J1-AUsvUA@mail.gmail.com Thousands of schemas and ANALYZE goes out of memory]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce memory use when analyzing many tables in a single command by making catcache and syscache flushable or bounded.<br />
* [http://www.postgresql.org/message-id/flat/CAMkU%3D1yZnAYvMHENt8%3D9pgwE8q5zmX+mG%3DSXbFHiLkq_qn0B7Q@mail.gmail.com Thousands of schemas and ANALYZE goes out of memory]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== EXPLAIN ===<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE issue NOTICE messages when the estimated and actual row counts differ by a specified percentage}}<br />
<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE report rows as floating-point numbers<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-05/msg01363.php <nowiki>explain analyze rows=%.0f</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00108.php <nowiki>Re: explain analyze rows=%.0f</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have EXPLAIN ANALYZE report buckets and memory usage for HashAggregate<br />
* [https://www.postgresql.org/message-id/flat/2527f5cb-5992-ae66-f3ec-4aa2396065ec%402ndquadrant.com <nowiki>to-do item for explain analyze of hash aggregates? </nowiki>]<br />
}}<br />
<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Window Functions ===<br />
See {{messageLink|357.1230492361@sss.pgh.pa.us|TODO items for window functions}}.<br />
{{TodoSubsection}}<br />
{{TodoItem<br />
|Support creation of user-defined window functions<br />
|We have the ability to create new window functions written in C. Is it<br />
worth the effort to create an API that would let them be written in PL/pgsql, etc?}}<br />
<br />
{{TodoItem<br />
|Implement full support for window framing clauses<br />
|In addition to done clauses described in the [http://developer.postgresql.org/pgdocs/postgres/sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS latest doc], these clauses are not implemented yet.<br />
* RANGE BETWEEN ... PRECEDING/FOLLOWING<br />
* EXCLUDE<br />
}}<br />
<br />
{{TodoItem<br />
|Investigate tuplestore performance issues<br />
|The tuplestore_in_memory() thing is just a band-aid, we ought to try to solve it properly. tuplestore_advance seems like a weak spot as well.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00152.php <nowiki>tuplestore potential performance problem</nowiki>]<br />
}}<br />
<br />
{{TodoItem|Do we really need so much duplicated code between Agg and WindowAgg?}}<br />
<br />
{{TodoItem<br />
|Teach planner to evaluate multiple windows in the optimal order<br />
|Currently windows are always evaluated in the query-specified order.<br />
* http://archives.postgresql.org/message-id/3CDAD71E9D70417290FCF66F0178D1E1@amd64<br />
}}<br />
<br />
{{TodoItem<br />
|Implement DISTINCT clause in window aggregates<br />
|Some proprietary RDBMSs have implemented it already, so it helps with porting from those.}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Integrity Constraints ==<br />
=== Keys ===<br />
<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Improve deferrable unique constraints for cases with many conflicts<br />
|The current implementation fires a trigger for each potentially conflicting row. This might not scale well for an update that changes many key values at once.<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Referential Integrity ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add MATCH PARTIAL referential integrity}}<br />
<br />
{{TodoItem<br />
|Change foreign key constraint for array -&gt; element to mean element in array?<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-10/msg01814.php <nowiki>foreign keys for array/period contains relationships</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix problem when cascading referential triggers make changes on cascaded tables, seeing the tables in an intermediate state<br />
* [http://archives.postgresql.org/pgsql-hackers/2005-09/msg00174.php <nowiki>Re: [PATCHES] Work-in-progress referential action trigger timing</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Are ri_KeysEqual checks in the RI enforcement triggers still necessary?<br />
* [http://archives.postgresql.org/pgsql-performance/2005-10/msg00458.php <nowiki>Re: Effects of cascading references in foreign keys</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Check Constraints ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Run check constraints only when affected columns are changed<br />
* http://archives.postgresql.org/message-id/1326055327.15293.13.camel@vanquo.pezone.net<br />
}}<br />
<br />
{{TodoItem<br />
|Do not scan the table when a check constraint is added in the same command that adds the column<br />
* [http://www.postgresql.org/message-id/CAMkU%3D1z5vXZ8Txd9_8hvNFovtbGuP4VTitFRN59XDncEHVGtJA@mail.gmail.com skip table scan for adding column with provable check constraints]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Server-Side Languages ==<br />
<br />
{{TodoItem<br />
|Add support for polymorphic arguments and return types to languages other than PL/PgSQL}}<br />
<br />
{{TodoItem<br />
|Add support for OUT and INOUT parameters to languages other than PL/PgSQL}}<br />
<br />
{{TodoItem<br />
|Add more fine-grained specification of functions taking arbitrary data types<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg00367.php <nowiki>RfD: more powerful &quot;any&quot; types</nowiki>]<br />
}}<br />
<br />
{{TodoItemDone<br />
|Implement stored procedures<br />
|This might involve the control of transaction state and the return of multiple result sets<br />
* [http://archives.postgresql.org/pgsql-general/2008-10/msg00454.php <nowiki>PL/pgSQL stored procedure returning multiple result sets (SELECTs)?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01375.php <nowiki>Proposal: real procedures again (8.4)</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-09/msg00542.php<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-04/msg01149.php <nowiki>Gathering specs and discussion on feature (post 9.1)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow holdable cursors in SPI}}<br />
<br />
{{TodoItem<br />
|Rethink query plan caching and timing of parse analysis within SQL-language functions<br />
|They should work more like plpgsql functions do ...<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00078.php <nowiki>Re: BUG #6019: invalid cached plan on inherited table</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow regex operations in PL/Perl using UTF8 characters in non-UTF8 encoded databases}}<br />
<br />
=== PL/pgSQL ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Allow handling of %TYPE arrays, e.g. tab.col%TYPE[]}}<br />
<br />
{{TodoItem<br />
|<nowiki>Allow listing of record column names, and access to record columns via variables, e.g. columns := r.(*), tval2 := r.(colname)</nowiki><br />
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00458.php <nowiki>Re: PL/PGSQL: Dynamic Record Introspection</nowiki>]<br />
* [http://pgxn.org/dist/colnames/ <nowiki>colnames: Extension to retrieve column names from a record</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow row and record variables to be set to NULL constants, and allow NULL tests on such variables<br />
|Because a row is not scalar, do not allow assignment from NULL-valued scalars.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00070.php <nowiki>NULL and plpgsql rows</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider keeping separate cached copies when search_path changes<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01009.php <nowiki>pl/pgsql Plan Invalidation and search_path</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve handling of NULL row values vs. NULL rows<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg01758.php <nowiki>Null row vs. row of nulls in plpgsql</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg01973.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve PERFORM handling of WITH queries or document limitation<br />
* http://archives.postgresql.org/pgsql-bugs/2011-03/msg00309.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== PL/Python ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Create a new restricted execution class that will allow passing function arguments in as locals. Passing them as globals means functions cannot be called recursively.<br />
* [http://archives.postgresql.org/pgsql-hackers/2011-02/msg01468.php <nowiki>Re: pl/python do not delete function arguments</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add a DB-API compliant interface on top of the SPI interface<br />
* http://petereisentraut.blogspot.com/2011/11/plpydbapi-db-api-for-plpython.html<br />
}}<br />
<br />
{{TodoItem<br />
|For functions returning a setof record with a composite type, cache the I/O functions for the composite type<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02007.php<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Clients ==<br />
<br />
{{TodoItem<br />
|Split out pg_resetxlog output into pre- and post-sections<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg02040.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve pg_rewind<br />
* [https://www.postgresql.org/message-id/CAN-RpxDhc_8JOq%3DcT9vd6MqWQaS0ZtvSf2LFV1V+bjOoEz02ow@mail.gmail.com Proposal: pg_rewind to skip config files]<br />
}}<br />
<br />
=== psql ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Move psql backslash database information into the backend, use mnemonic commands?<br />
|This would allow non-psql clients to pull the same information out of the database as psql. <br />
* [http://archives.postgresql.org/pgsql-hackers/2004-01/msg00191.php <nowiki>Re: psql \d option list overloaded</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Make psql's \d commands distinguish default privileges from no privileges<br />
|ACL displays were visibly different for the two cases before we "improved" them by using array_to_string.<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-05/msg00082.php <nowiki>BUG #6021: There is no difference between default and empty access privileges with \dp</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consistently display privilege information for all objects in psql}}<br />
<br />
{{TodoItemDone<br />
|\s without arguments (display history) fails with libedit, doesn't use pager either<br />
* [http://archives.postgresql.org/pgsql-bugs/2011-06/msg00114.php <nowiki> psql \s not working - OS X</nowiki>]<br />
|This items has been fixed in commit 750c5e.<br />
<br/><br />
<code><br />
Fix psql \s to work with recent libedit, and add pager support.<br />
<br />
psql's \s (print command history) doesn't work at all with recent libedit<br />
versions when printing to the terminal, because libedit tries to do an<br />
fchmod() on the target file which will fail if the target is /dev/tty.<br />
(We'd already noted this in the context of the target being /dev/null.)<br />
Even before that, it didn't work pleasantly, because libedit likes to<br />
encode the command history file (to ensure successful reloading), which<br />
renders it nigh unreadable, not to mention significantly different-looking<br />
depending on exactly which libedit version you have. So let's forget using<br />
write_history() for this purpose, and instead print the data ourselves,<br />
using logic similar to that used to iterate over the history for newline<br />
encoding/decoding purposes.<br />
<br />
While we're at it, insert the ability to use the pager when \s is printing<br />
to the terminal. This has been an acknowledged shortcoming of \s for many<br />
years, so while you could argue it's not exactly a back-patchable bug fix<br />
it still seems like a good improvement. Anyone who's seriously annoyed<br />
at this can use "\s /dev/tty" or local equivalent to get the old behavior.<br />
<br />
Experimentation with this showed that the history iteration logic was<br />
actually rather broken when used with libedit. It turns out that with<br />
libedit you have to use previous_history() not next_history() to advance<br />
to more recent history entries. The easiest and most robust fix for this<br />
seems to be to make a run-time test to verify which function to call.<br />
We had not noticed this because libedit doesn't really need the newline<br />
encoding logic: its own encoding ensures that command entries containing<br />
newlines are reloaded correctly (unlike libreadline). So the effective<br />
behavior with recent libedits was that only the oldest history entry got<br />
newline-encoded or newline-decoded. However, because of yet other bugs in<br />
history_set_pos(), some old versions of libedit allowed the existing loop<br />
logic to reach entries besides the oldest, which means there may be libedit<br />
~/.psql_history files out there containing encoded newlines in more than<br />
just the oldest entry. To ensure we can reload such files, it seems<br />
appropriate to back-patch this fix, even though that will result in some<br />
incompatibility with older psql versions (ie, multiline history entries<br />
written by a psql with this fix will look corrupted to a psql without it,<br />
if its libedit is reasonably up to date).<br />
<br />
Stepan Rutz and Tom Lane<br />
</code><br />
}}<br />
<br />
{{TodoItem<br />
|Add a \set variable to control whether \s displays line numbers<br />
|Another option is to add \# which lists line numbers, and allows command execution.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php <nowiki>Re: psql possible TODO</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Include the symbolic SQLSTATE name in verbose error reports<br />
* [http://archives.postgresql.org/pgsql-general/2007-09/msg00438.php <nowiki>Re: Checking is TSearch2 query is valid</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add option to wrap column values at whitespace boundaries, rather than chopping them at a fixed width.<br />
|Currently, &quot;wrapped&quot; format chops values into fixed widths. Perhaps the word wrapping could use the same algorithm documented in the W3C specification. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00404.php <nowiki>Re: psql wrapped format default for backslash-d commands</nowiki>]<br />
* http://www.w3.org/TR/CSS21/tables.html#auto-table-layout}}<br />
<br />
{{TodoItem<br />
|Add option to print advice for people familiar with other databases<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-01/msg01845.php <nowiki>MySQL-ism help patch for psql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix FETCH_COUNT to handle SELECT ... INTO and WITH queries<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01565.php<br />
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00192.php<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent psql from sending remaining single-line multi-statement queries after reconnecting<br />
* http://archives.postgresql.org/pgsql-bugs/2010-05/msg00159.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg01283.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve line drawing characters<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00386.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider improving the continuation prompt<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01772.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve speed of tab completion by using LIKE<br />
* http://www.postgresql.org/message-id/20120821174847.GL1267@tamriel.snowman.net<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== pg_dump / pg_restore ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItemEasy<br />
|Dump security labels and comments on databases in a way that allows to load a dump into a differently named database<br />
* [http://www.postgresql.org/message-id/20150710115735.GH26521@alap3.anarazel.de security labels on databases are bad for dump & restore]<br />
|}}<br />
<br />
{{TodoItemEasy<br />
|<nowiki>Add full object name to the tag field. eg. for operators we need '=(integer, integer)', instead of just '='.</nowiki>}}<br />
<br />
{{TodoItem<br />
|Avoid using platform-dependent names for locales in pg_dumpall output<br />
|Using native locale names puts roadblocks in the way of porting a dump to another platform. One possible solution is to get<br />
CREATE DATABASE to accept some agreed-on set of locale names and fix them up to meet the platform's requirements.<br />
* http://archives.postgresql.org/message-id/21396.1241716688@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|In a selective dump, allow dumping of an object and all its dependencies}}<br />
<br />
{{TodoItem<br />
|Stop dumping CASCADE on DROP TYPE commands in clean mode}}<br />
<br />
{{TodoItem<br />
|Allow pg_restore to load different parts of the COPY data for a single table simultaneously}}<br />
<br />
{{TodoItemDone<br />
|Refactor handling of database attributes between pg_dump and pg_dumpall<br />
|Currently only pg_dumpall emits database attributes, such as ALTER DATABASE SET commands and database-level GRANTs.<br />
Many people wish that pg_dump would do that. One proposal is to let pg_dump issue such commands if the -C switch was used,<br />
but it's unclear whether that will satisfy the demand.<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01031.php <nowiki>ALTER DATABASE vs pg_dump</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-bugs/2010-05/msg00010.php summary of the issues]<br />
* [http://www.postgresql.org/message-id/flat/20150730064941.GA1582735@tornado.leadboat.com rehash five years later]<br />
* {{messageLink|21573.1475162949@sss.pgh.pa.us|sketch for division of labor between pg_dump and pg_dumpall}}<br />
}}<br />
<br />
{{TodoItem<br />
|Preserve sparse storage of large objects over dump/restore<br />
* [http://archives.postgresql.org/message-id/18789.1349750451@sss.pgh.pa.us <nowiki>TODO item: teach pg_dump about sparsely-stored large objects</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent PL/pgSQL comment from throwing an error in a non-superuser restore<br />
* [http://www.postgresql.org/message-id/E1VuYH7-0008Rz-SV@wrigleys.postgresql.org Reloading dump fails at COMMENT ON EXTENSION plpgsql]<br />
}}<br />
<br />
{{TodoItem<br />
|Delay REFRESH MATERIALIZED VIEW until dependent indexes are created<br />
* [http://www.postgresql.org/message-id/20140820021530.2534.43156@wrigleys.postgresql.org pg_restore unusable for expensive matviews]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== pg_upgrade ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Handle large object comments<br />
|This is difficult to do because the large object doesn't exist when --schema-only is loaded.<br />
}}<br />
<br />
{{TodoItem<br />
|Consider using pg_depend for checking object usage in version.c<br />
}}<br />
<br />
{{TodoItem<br />
|Migrate pg_statistic by dumping it out as a flat file, so analyze is not necessary<br />
* [http://archives.postgresql.org/message-id/CAAZKuFaWdLkK8eozSAooZBets9y_mfo2HS6urPAKXEPbd-JLCA@mail.gmail.com pg_upgrade and statistics]<br />
* [https://www.postgresql.org/message-id/20171205140135.GA25023%40momjian.us Speeding up pg_upgrade]<br />
}}<br />
<br />
{{TodoItem<br />
|Find cleaner way to start/stop dedicated servers for upgrades<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00275.php<br />
}}<br />
<br />
{{TodoItem<br />
|Desired changes that would prevent upgrades with pg_upgrade<br />
* 32-bit page checksums<br />
* Add metapage to GiST indexes<br />
* Clean up hstore's internal representation<br />
* Remove tuple infomask bit HEAP_MOVED_OFF and HEAP_MOVED_IN<br />
* [http://www.postgresql.org/message-id/CAK+WP1xdmyswEehMuetNztM4H199Z1w9KWRHVMKzyyFM+hV%3DzA@mail.gmail.com fix char() index trailing space handling]<br />
* [http://www.postgresql.org/message-id/CAPpHfdtxXMjyZxwND09ZLBBACVbWb5J9bLUf67CndR4VKFDgwg@mail.gmail.com Use non-collation-aware comparisons for GIN opclasses]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== ecpg ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Docs<br />
|Document differences between ecpg and the SQL standard and information about the Informix-compatibility module.}}<br />
<br />
{{TodoItem<br />
|Solve cardinality &gt; 1 for input descriptors / variables?}}<br />
<br />
{{TodoItem<br />
|Add a semantic check level, e.g. check if a table exists}}<br />
<br />
{{TodoItem<br />
|fix handling of DB attributes that are arrays}}<br />
<br />
{{TodoItem<br />
|Fix nested C comments}}<br />
<br />
{{TodoItemEasy<br />
|sqlwarn[6] should be 'W' if the PRECISION or SCALE value specified}}<br />
<br />
{{TodoItem<br />
|Make SET CONNECTION thread-aware, non-standard?}}<br />
<br />
{{TodoItem<br />
|Allow multidimensional arrays}}<br />
<br />
{{TodoItem<br />
|Implement COPY FROM STDIN}} <br />
<br />
{{TodoItem<br />
|Provide a way to specify size of a bytea parameter<br />
* [http://archives.postgresql.org/message-id/200906192131.n5JLVoMo044178@wwwmaster.postgresql.org <nowiki>BUG #4866: ECPG and BYTEA</nowiki>]<br />
}}<br />
<br />
{{TodoItemEasy<br />
|Fix small memory leaks in ecpg<br />
|Memory leaks in a short running application like ecpg are not really a problem, but make debugging more complicated}} <br />
<br />
{{TodoItem<br />
|Allow reuse of cursor name variables<br />
* [http://archives.postgresql.org/message-id/20100329113435.GA3430@feivel.credativ.lan <nowiki>Problems with variable cursorname in ecpg</nowiki>]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== libpq ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Prevent PQfnumber() from lowercasing unquoted column names<br />
|PQfnumber() should never have been doing lowercasing, but historically it has so we need a way to prevent it}}<br />
<br />
{{TodoItem<br />
|Consider disallowing multiple queries in PQexec() as an additional barrier to SQL injection attacks<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-01/msg00184.php <nowiki>Re: InitPostgres and flatfiles question</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add PQexecf() that allows complex parameter substitution<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01803.php <nowiki>Last minute mini-proposal (I know, know) for PQexecf()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add SQLSTATE and severity to errors generated within libpq itself<br />
* [http://archives.postgresql.org/pgsql-interfaces/2007-11/msg00015.php <nowiki>v8.1: Error severity on libpq PGconn*</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01425.php<br />
}}<br />
<br />
{{TodoItem<br />
|Add support for interface/ipaddress binding to libpq<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg01811.php <nowiki>SR/libpq - outbound interface/ipaddress binding</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|When receiving a FATAL error remember it, so that it doesn't profess ingnorance about why the session was closed<br />
* [http://www.postgresql.org/message-id/CA+TgmoZ4P1cQetjOxQoHiG072UcE7dpE7dTBV8hMOidhwhof+g@mail.gmail.com<nowiki>Idle In Transaction Session Timeout, revived</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Pipelining support for libpq async API and an array-valued PQexecPrepared that uses it<br />
* [http://www.postgresql.org/message-id/CAMsr+YHE8Rt800yWcHEL8SrgruK0ng_nBmtKV6YMZ2BAzRBZzw@mail.gmail.com Foreign table batched inserts]<br />
}}<br />
{{TodoEndSubsection}}<br />
<br />
== Triggers ==<br />
<br />
{{TodoItem<br />
|Improve storage of deferred trigger queue<br />
|Right now all deferred trigger information is stored in backend memory. This could exhaust memory for very large trigger queues. This item involves dumping large queues into files, or doing some kind of join to process all the triggers, some bulk operation, or a bitmap. <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00876.php <nowiki>Re: BUG #4204: COPY to table with FK has memory leak</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-10/msg00464.php <nowiki>Scaling up deferred unique checks and the after trigger queue</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00023.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow triggers to be disabled in only the current session.<br />
|This is currently possible by starting a multi-statement transaction, modifying the system tables, performing the desired SQL, restoring the system tables, and committing the transaction. ALTER TABLE ... TRIGGER requires a table lock so it is not ideal for this usage.}}<br />
<br />
{{TodoItem<br />
|With disabled triggers, allow pg_dump to use ALTER TABLE ADD FOREIGN KEY<br />
|If the dump is known to be valid, allow foreign keys to be added without revalidating the data.}}<br />
<br />
{{TodoItem<br />
|When statement-level triggers are defined on a parent table, have them fire only on the parent table, and fire child table triggers only where appropriate<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg01883.php <nowiki>Statement-level triggers and inheritance</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Tighten trigger permission checks<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00564.php <nowiki>Security leak with trigger functions?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow BEFORE INSERT triggers on views<br />
* [http://archives.postgresql.org/pgsql-general/2007-02/msg01466.php <nowiki>Re: Why can't I put a BEFORE EACH ROW trigger on a view?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add database and transaction-level triggers<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00451.php <nowiki>Proposal for db level triggers</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00620.php <nowiki>triggers on prepare, commit, rollback... ?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid requirement for AFTER trigger functions to return a value<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02384.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow creation of inline triggers<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00708.php<br />
}}<br />
<br />
== Inheritance ==<br />
<br />
{{TodoItem<br />
|Allow inherited tables to inherit indexes, UNIQUE constraints, and primary/foreign keys<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-05/msg00285.php <nowiki>Partitioning/inherited tables vs FKs</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00039.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00305.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow unique indexes across inherited tables (requires multi-table indexes)}}<br />
<br />
{{TodoItem<br />
|Research whether ALTER TABLE / SET SCHEMA should work on inheritance hierarchies (and thus support ONLY)}}<br />
<br />
{{TodoItem<br />
|ALTER TABLE variants sometimes support recursion and sometimes not, but this is poorly/not documented, and the ONLY marker would then be silently ignored. Clarify the documentation, and reject ONLY if it is not supported.}}<br />
<br />
== Indexes ==<br />
<br />
{{TodoItem<br />
|Prevent index uniqueness checks when UPDATE does not modify the column<br />
|Uniqueness (index) checks are done when updating a column even if the column is not modified by the UPDATE.<br />
However, HOT already short-circuits this in common cases, so more work might not be helpful.<br />
* http://www.postgresql.org/message-id/CA+TgmoZOyaTanfEvNUdiHBCuu9Zh0JVP1e_UTVbx6Rvj9vFC9Q@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Allow accurate statistics to be collected on indexes with more than one column or expression indexes, perhaps using per-index statistics<br />
* [http://archives.postgresql.org/pgsql-performance/2006-10/msg00222.php <nowiki>Re: Simple join optimized badly?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01131.php <nowiki>Stats for multi-column indexes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00741.php <nowiki>Cross-column statistics revisited</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg01431.php <nowiki>Multi-Dimensional Histograms</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00913.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg02179.php <br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg00459.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg02054.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01731.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00894.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-09/msg00679.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having a larger statistics target for indexed columns and expression indexes. <br />
}}<br />
<br />
{{TodoItem<br />
|Add REINDEX CONCURRENTLY, like CREATE INDEX CONCURRENTLY<br />
|This is difficult because you must upgrade to an exclusive table lock to replace the existing index file. CREATE INDEX CONCURRENTLY does not have this complication. This would allow index compaction without downtime. <br />
* [http://archives.postgresql.org/pgsql-performance/2007-08/msg00289.php <nowiki>Re: When/if to Reindex</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00911.php<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg00128.php<br />
* [http://www.postgresql.org/message-id/CAB7nPqTys6JUQDxUczbJb0BNW0kPrW8WdZuk11KaxQq6o98PJg@mail.gmail.com Support for REINDEX CONCURRENTLY]<br />
* [https://wiki.postgresql.org/wiki/Reindex_concurrently Wiki page listing current situation on the matter]<br />
* [http://www.postgresql.org/message-id/CAB7nPqSTFkuc7dZxCDX4HOTU63YXHRroNv2aoUzyD-Zz_8Z_Zg@mail.gmail.com REINDEX CONCURRENTLY 2.0]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multiple indexes to be created concurrently, ideally via a single heap scan<br />
|pg_restore allows parallel index builds, but it is done via subprocesses, and there is no SQL interface for this.<br />
Cluster could definitely benefit from this.<br />
* http://archives.postgresql.org/pgsql-performance/2011-04/msg00093.php<br />
* http://www.postgresql.org/message-id/CADVWZZJ5AS%3DXVrDwfTQqQP_V1+_fTYcZhq%3Dd5CbCXoALCjObbg@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Consider sorting entries before inserting into btree index<br />
* [http://archives.postgresql.org/pgsql-general/2008-01/msg01010.php <nowiki>Re: ATTN: Clodaldo was Performance problem. Could it be related to 8.3-beta4?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider using "effective_io_concurrency" for index scans<br />
|Currently only bitmap scans use this, which might be fine because most multi-row index scans use bitmap scans.<br />
* [http://www.postgresql.org/message-id/CAGTBQpZzf70n0PYJ%3DVQLd+jb3wJGo%3D2TXmY+SkJD6G_vjC5QNg@mail.gmail.com Prefetch index pages for B-Tree index scans]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow GIN indexes to be used for exclusion constraints<br />
* http://archives.postgresql.org/pgsql-hackers/2012-05/msg00669.php<br />
}}<br />
<br />
{{TodoItem<br />
| Allow "loose" or "skip" scans on btree indexes in which the first column has low cardinality<br />
* http://archives.postgresql.org/pgsql-performance/2012-08/msg00159.php<br />
}}<br />
<br />
{{TodoItem<br />
| Make the planner's "special index operator" mechanism extensible<br />
* http://www.postgresql.org/message-id/27270.1364700924@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
| Allow index-only COUNT(*) for indexes which don't support index-only scans<br />
}}<br />
<br />
{{TodoItem<br />
|Improve GIN performance<br />
* [http://www.postgresql.org/message-id/52F373CC.4050800@vmware.com Small GIN optimizations (after 9.4)]<br />
}}<br />
<br />
{{TodoItem<br />
| Teach GIN cost estimation about "fast scans"<br />
* http://www.postgresql.org/message-id/53208B4D.5000806@vmware.com<br />
}}<br />
<br />
{{TodoItem<br />
| Allow unlogged indexes<br />
* http://www.postgresql.org/message-id/11561.1414793261@sss.pgh.pa.us<br />
}}<br />
<br />
=== GIST ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add more GIST index support for geometric data types}}<br />
<br />
{{TodoItem<br />
|Allow GIST indexes to create more complex index types, like digital trees (see Aoki)}}<br />
<br />
{{TodoItem<br />
|Fix performance issues in contrib/seg and contrib/cube GiST support<br />
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904161633160.4053@aragorn.flymine.org GiST index performance]<br />
* [http://archives.postgresql.org/message-id/alpine.DEB.2.00.0904221704470.22330@aragorn.flymine.org draft patch]<br />
* [http://archives.postgresql.org/pgsql-performance/2009-05/msg00069.php <nowiki>Re: GiST index performance</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-performance/2009-06/msg00068.php <nowiki>GiST index performance</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|[http://archives.postgresql.org/message-id/4DC8D284-05CF-4E3D-9670-AC9A32C37A36@justatheory.com GiST index support for arrays]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Hash ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Add UNIQUE capability to hash indexes<br />
* [https://www.postgresql.org/message-id/592254A5.9000809@anastigmatix.net Re: PG10 Crash-safe and replicable Hash Indexes and UNIQUE]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multi-column hash indexes<br />
* This requires all columns to be specified for a query to use the index.<br />
* [https://www.postgresql.org/message-id/CA+Tgmoax6DhnKsuE_gzY5qkvmPEok77JAP1h8wOTbf+dg2Ycrw@mail.gmail.com Write Ahead Logging for Hash Indexes]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Sorting ==<br />
<br />
{{TodoItem<br />
|Consider whether duplicate keys should be sorted by block/offset<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php <nowiki>Remove hacks for old bad qsort() implementations?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider being smarter about memory and external files used during sorts<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php <nowiki>Sorting Improvements for 8.4</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider detoasting keys before sorting}}<br />
<br />
{{TodoItem<br />
|Allow sorts of skinny tuples to use even more available memory.<br />
|Now that it is not limited by MaxAllocSize, don't limit by INT_MAX either.<br />
* [http://www.postgresql.org/message-id/CA+U5nMKkRMin1pV8VMpS6_n7hcOWSG0kZS3oFL9JOa8DV6vJyQ@mail.gmail.com Re: MemoryContextAllocHuge(): selectively bypassing MaxAllocSize]<br />
}}<br />
<br />
== Cache Usage ==<br />
<br />
{{TodoItem<br />
|Consider automatic caching of statements at various levels:<br />
* Parsed query tree<br />
* Query execute plan<br />
* Query results <br />
* [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00823.php <nowiki>Cached Query Plans (was: global prepared statements)</nowiki>]<br />
* [https://www.postgresql.org/message-id/CAFj8pRAGLaiEm8ur5DWEBo7qHRWTk9HxkuUAz00CZZtJj-LkCA%40mail.gmail.com PoC plpgsql - possibility to force custom or generic plan]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider allowing higher priority queries to have referenced shared buffer pages stay in memory longer<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php <nowiki>Re: How to keep a table in memory?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix memory leak caused by negative catcache entries<br />
* [http://www.postgresql.org/message-id/51C0A1FF.2050404@vmware.com <nowiki>Re: Memory leak in PL/pgSQL function which CREATE/SELECT/DROP a temporary table</nowiki>]<br />
}}<br />
<br />
== Vacuum ==<br />
<br />
{{TodoItem<br />
|Auto-fill the free space map by scanning the buffer cache or by checking pages written by the background writer<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-02/msg01125.php <nowiki>Dead Space Map</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-03/msg00011.php <nowiki>Re: Automatic free space map filling</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow concurrent inserts to use recently created pages rather than creating new ones<br />
* http://archives.postgresql.org/pgsql-hackers/2010-05/msg00853.php<br />
}}<br />
<br />
{{TodoItem<br />
|Consider having single-page pruning update the visibility map<br />
* <nowiki>https://commitfest.postgresql.org/action/patch_view?id=75</nowiki><br />
* [http://archives.postgresql.org/pgsql-hackers/2010-02/msg02344.php <nowiki>Re: visibility maps and heap_prune</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow VACUUM FULL and CLUSTER to update the visibility map<br />
* [http://www.postgresql.org/message-id/20130112191404.255800@gmx.com index-only scans : abnormal heap fetches after VACUUM FULL]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve tracking of total relation tuple counts now that vacuum doesn't always scan the whole heap<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-06/msg00531.php Partial vacuum versus pg_class.reltuples]<br />
}}<br />
<br />
{{TodoItem<br />
|Bias FSM towards returning free space near the beginning of the heap file, in hopes that empty pages at the end can be truncated by VACUUM<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-09/msg01124.php <nowiki>FSM search modes</nowiki>]<br />
* [http://www.postgresql.org/message-id/20150424190403.GP4369@alvh.no-ip.org Re: Feedback on getting rid of VACUUM FULL]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider a more compact data representation for dead tuple locations within VACUUM<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php <nowiki>Re: Have vacuum emit a warning when it runs out of maintenance_work_mem</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide more information in order to improve user-side estimates of dead space bloat in relations<br />
* [http://archives.postgresql.org/pgsql-general/2009-05/msg01039.php <nowiki>Re: Bloated Table</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce the number of table scans performed by vacuum<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01119.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-07/msg00624.php<br />
}}<br />
<br />
{{TodoItem<br />
|Vacuum Gin indexes in physically order rather than logical order<br />
* http://archives.postgresql.org/pgsql-hackers/2012-04/msg00443.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid creation of the free space map for small tables<br />
* http://archives.postgresql.org/pgsql-hackers/2011-11/msg01751.php<br />
}}<br />
<br />
=== Auto-vacuum ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Issue log message to suggest VACUUM FULL if a table is nearly empty?<br />
*[http://www.postgresql.org/message-id/F40B0968DB0A904DA78A924E633BE78645FAAF@SYDEXCHTMP2.au.fjanz.com discussion]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent long-lived temporary tables from causing frozen-xid advancement starvation<br />
|The problem is that autovacuum cannot vacuum them to set frozen xids; only the session that created them can. <br />
* [http://archives.postgresql.org/pgsql-general/2007-06/msg01645.php <nowiki>Re: AutoVacuum Behaviour Question</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Prevent autovacuum from running if an old transaction is still running from the last vacuum<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-11/msg00899.php <nowiki>Re: Autovacuum and OldestXmin</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have autoanalyze of parent tables occur when child tables are modified<br />
* http://archives.postgresql.org/pgsql-performance/2010-06/msg00137.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow visibility map all-visible bits to be set even when an auto-ANALYZE is running<br />
* http://archives.postgresql.org/pgsql-hackers/2012-01/msg00356.php<br />
}}<br />
<br />
{{TodoItem<br />
|Improve autovacuum tuning<br />
* http://www.postgresql.org/message-id/5078AD6B.8060802@agliodbs.com<br />
* http://www.postgresql.org/message-id/20130124215715.GE4528@alvh.no-ip.org<br />
}}<br />
<br />
{{TodoItem<br />
|Improve setting of visibility map bits for read-only and insert-only workloads<br />
* http://www.postgresql.org/message-id/20130906001437.GA29264@momjian.us<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Locking ==<br />
<br />
{{TodoItem<br />
|Fix problem when multiple subtransactions of the same outer transaction hold different types of locks, and one subtransaction aborts<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-11/msg01011.php <nowiki>FOR SHARE vs FOR UPDATE locks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg00001.php <nowiki>Re: FOR SHARE vs FOR UPDATE locks</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00435.php <nowiki>Re: [PATCHES] [pgsql-patches] Phantom Command IDs, updated patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php <nowiki>Re: savepoints and upgrading locks</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve deadlock detection when a page cleaning lock conflicts with a shared buffer that is pinned<br />
* [http://archives.postgresql.org/pgsql-bugs/2008-01/msg00138.php <nowiki>BUG #3883: Autovacuum deadlock with truncate?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-committers/2008-01/msg00365.php <nowiki>Re: pgsql: Add checks to TRUNCATE, CLUSTER, and REINDEX to prevent</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Detect deadlocks involving LockBufferForCleanup()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php <nowiki>Thoughts about bug #3883</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow finer control over who is cancelled in a deadlock<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01727.php<br />
}}<br />
<br />
== Startup Time Improvements ==<br />
<br />
{{TodoItem<br />
|Allow backends to change their database without restart<br />
|This allows for faster server startup.<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00843.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-12/msg00336.php<br />
}}<br />
<br />
== Write-Ahead Log ==<br />
<br />
{{TodoItem<br />
|Eliminate need to write full pages to WAL before page modification<br />
|Currently, to protect against partial disk page writes, we write full page images to WAL before they are modified so we can correct any partial page writes during recovery. These pages can also be eliminated from point-in-time archive files. <br />
* [http://archives.postgresql.org/pgsql-hackers/2002-06/msg00655.php <nowiki>Re: Index Scans become Seq Scans after VACUUM ANALYSE</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2011-05/msg01191.php<br />
* [http://archives.postgresql.org/message-id/20120105061916.GB21048@fetter.org WIP double writes]<br />
* [http://archives.postgresql.org/message-id/4EFC449F02000025000441CD@gw.wicourts.gov double writes]<br />
* [http://archives.postgresql.org/message-id/20120110214344.GB21106@fetter.org Double-write with Fast Checksums]<br />
* [http://archives.postgresql.org/message-id/1962493974.656458.1327703514780.JavaMail.root@zimbra-prod-mbox-4.vmware.com double writes using "double-write buffer" approach]<br />
* http://archives.postgresql.org/pgsql-hackers/2012-10/msg01463.php<br />
}}<br />
<br />
{{TodoItem<br />
|When full page writes are off, write CRC to WAL and check file system blocks on recovery<br />
|If CRC check fails during recovery, remember the page in case a later CRC for that page properly matches. The difficulty is that hint bits are not WAL logged, meaning a valid page might not match the earlier CRC.}}<br />
<br />
{{TodoItem<br />
|Write full pages during file system write and not when the page is modified in the buffer cache<br />
|This allows most full page writes to happen in the background writer. It might cause problems for applying WAL on recovery into a partially-written page, but later the full page will be replaced from WAL.<br />
* [http://archives.postgresql.org/message-id/CAGvK12UST-tPhyLrSLuSpwFxZbAO79yYrhV2xaLmS2MkUxNUVQ@mail.gmail.com Page Checksums + Double Writes]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow WAL information to recover corrupted pg_controldata<br />
* [http://archives.postgresql.org/pgsql-patches/2006-06/msg00025.php <nowiki>Re: [HACKERS] pg_resetxlog -r flag</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Speed WAL recovery by allowing more than one page to be prefetched<br />
|This should be done utilizing the same infrastructure used for prefetching in general to avoid introducing complex error-prone code in WAL replay. <br />
* [http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php <nowiki>Slow PITR restore</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php <nowiki>Re: [GENERAL] Slow PITR restore</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php <nowiki>Read-ahead and parallelism in redo recovery</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve WAL concurrency by increasing lock granularity<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php <nowiki>Reworking WAL locking</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Have resource managers report the duration of their status changes<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-10/msg01468.php <nowiki>Recovery of Multi-stage WAL actions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Close deleted WAL files held open in *nix by long-lived read-only backends<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg01754.php <nowiki>Deleted WAL files held open by backends in Linux</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-12/msg00060.php <nowiki>Re: Deleted WAL files held open by backends in Linux</nowiki>]<br />
}}<br />
<br />
== Optimizer / Executor ==<br />
<br />
{{TodoItem<br />
|Improve selectivity functions for geometric operators}}<br />
<br />
{{TodoItem<br />
|Consider increasing the default values of from_collapse_limit, join_collapse_limit, and/or geqo_threshold<br />
* [http://archives.postgresql.org/message-id/4136ffa0905210551u22eeb31bn5655dbe7c9a3aed5@mail.gmail.com from_collapse_limit vs. geqo_threshold]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve ability to display optimizer analysis using OPTIMIZER_DEBUG<br />
* http://archives.postgresql.org/pgsql-hackers/2012-08/msg00597.php<br />
}}<br />
<br />
{{TodoItem<br />
|Log statements where the optimizer row estimates were dramatically different from the number of rows actually found?}}<br />
<br />
{{TodoItem<br />
|Consider compressed annealing to search for query plans<br />
|This might replace GEQO.<br />
* http://archives.postgresql.org/message-id/15658.1241278636%40sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Improve use of expression indexes for ORDER BY <br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg01553.php <nowiki>Resjunk sort columns, Heikki's index-only quals patch, and bug #5000</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Modify the planner to better estimate caching effects<br />
* http://archives.postgresql.org/pgsql-performance/2010-11/msg00117.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow shared buffer cache contents to affect index cost computations<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg01140.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow the CTE (Common Table Expression) optimization fence to be optionally disabled<br />
* http://archives.postgresql.org/pgsql-hackers/2012-09/msg00700.php<br />
* http://archives.postgresql.org/pgsql-performance/2012-11/msg00161.php<br />
* https://www.postgresql.org/message-id/5351711493487900@web53g.yandex.ru<br />
}}<br />
<br />
=== Hashing ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Consider using a hash for joining to a large IN (VALUES ...) list<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php <nowiki>Planning large IN lists</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow single batch hash joins to preserve outer pathkeys<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-09/msg00806.php Re: Potential Join Performance Issue]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Use "lazy" hash tables to look up only the tuples that are actually requested<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid building the same hash table more than once during the same query<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid hashing for distinct and then re-hashing for hash join<br />
* [http://archives.postgresql.org/message-id/4136ffa0902191346g62081081v8607f0b92c206f0a@mail.gmail.com Re: Fixing Grittner's planner issues]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-04/msg00153.php a few crazy ideas about hash joins]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Background Writer ==<br />
<br />
{{TodoItem<br />
|Consider having the background writer update the transaction status hint bits before writing out the page<br />
|Implementing this requires the background writer to have access to system catalogs and the transaction status log.<br />
* [http://www.postgresql.org/message-id/CAMkU%3D1zf1Yo0dYJzJ-pk9o4mwLuMD4Uzw6Jck7u1nC_Xb2gYWA@mail.gmail.com Re: Autovacuum fails to keep visibility map up-to-date in mostly-insert-only-tables]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider adding buffers the background writer finds reusable to the free list <br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]<br />
* [http://www.postgresql.org/message-id/CAOeZVic4HikhmzVD%3DZP4JY9g8PgpyiQQOXOELWP%3DkR+%3DH1Frgg@mail.gmail.com Page replacement algorithm in buffer cache]<br />
* [http://www.postgresql.org/message-id/002f01ce50a8$e057c7a0$a10756e0$@kapila@huawei.com Move unused buffers to freelist]<br />
}}<br />
<br />
{{TodoItem<br />
|Automatically tune bgwriter_delay based on activity rather then using a fixed interval<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php <nowiki>Background LRU Writer/free list</nowiki>]<br />
* [http://archives.postgresql.org/message-id/CA+U5nMKtvyDcV4zTr7bq7t6cA2nBfLxCJ8tQgVBnc5ddRPO+Bg@mail.gmail.com our buffer replacement strategy is kind of lame]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider whether increasing BM_MAX_USAGE_COUNT improves performance<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php <nowiki>Bgwriter LRU cleaning: we've been going at this all wrong</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Test to see if calling PreallocXlogFiles() from the background writer will help with WAL segment creation latency<br />
* [http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php <nowiki>Re: Load Distributed Checkpoints, final patch</nowiki>]<br />
}}<br />
<br />
== Concurrent Use of Resources ==<br />
<br />
{{TodoItem<br />
|Do async I/O for faster random read-ahead of data<br />
|Async I/O allows multiple I/O requests to be sent to the disk with results coming back asynchronously.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg00820.php <nowiki>Asynchronous I/O Support</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-performance/2007-09/msg00255.php <nowiki>Re: random_page_costs - are defaults of 4.0 realistic for SCSI RAID 1</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00027.php <nowiki>There's random access and then there's random access</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-01/msg00170.php <nowiki>Bitmap index scan preread using posix_fadvise (Was: There's random access and then there's random access)</nowiki>]<br />
The above patch is already applied as of 8.4, but it still remains to figure out how to handle plain indexscans effectively.<br />
* [http://archives.postgresql.org//pgsql-hackers/2009-01/msg00806.php Problems with the patch submitted for posix_fadvise in index scans]<br />
}}<br />
<br />
{{TodoItem<br />
|SMP scalability improvements<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php <nowiki>Straightforward changes for increased SMP scalability</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php <nowiki>Re: Reducing Transaction Start/End Contention</nowiki>]<br />
}}<br />
<br />
== TOAST ==<br />
<br />
{{TodoItem<br />
|Allow user configuration of TOAST thresholds<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-02/msg00213.php <nowiki>Re: Proposed adjustments in MaxTupleSize and toastthresholds</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php <nowiki>pg_lzcompress strategy parameters</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce unnecessary cases of deTOASTing<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php <nowiki>Re: [PATCHES] Eliminate more detoast copies for packed varlenas</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce costs of repeat de-TOASTing of values<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-06/msg01096.php <nowiki>WIP patch: reducing overhead for repeat de-TOASTing</nowiki>]<br />
}}<br />
<br />
== Monitoring ==<br />
<br />
{{TodoItem<br />
|Have pg_stat_activity display query strings in the correct client encoding<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-01/msg00131.php <nowiki>pg_stats queries versus per-database encodings</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Add entry creation timestamp column to pg_stat_replication<br />
* http://archives.postgresql.org/pgsql-hackers/2011-08/msg00694.php<br />
}}<br />
<br />
{{TodoItem<br />
| Allow reporting of stalls due to wal_buffer wrap-around<br />
* http://archives.postgresql.org/pgsql-hackers/2012-02/msg00826.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure pg_stat_database columns tup_returned and tup_fetched to return meaningful values<br />
* http://www.postgresql.org/message-id/20121012060345.GA29214@toroid.org<br />
}}<br />
<br />
{{TodoItem<br />
| Improve handling of pg_stat_statements handling of bind "IN" variables<br />
* [http://www.postgresql.org/message-id/CAM3SWZSpdPB3uErnXWMt3q74y0r+84ZsOt2U3HKKes_V7O+0Qg@mail.gmail.com Revisiting pg_stat_statements and IN()]<br />
}}<br />
<br />
== Miscellaneous Performance ==<br />
<br />
{{TodoItem<br />
|Use mmap() rather than shared memory for shared buffers?<br />
|This would remove the requirement for SYSV SHM but would introduce portability issues. Anonymous mmap (or mmap to /dev/zero) is required to prevent I/O overhead. We could also consider mmap() for writing WAL.<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00750.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg00756.php<br />
* http://www.postgresql.org/message-id/20140115114909.GI4963@suse.de<br />
}}<br />
<br />
{{TodoItem<br />
|Rather than consider mmap()-ing in 8k pages, consider mmap()'ing entire files into a backend?<br />
|Doing I/O to large tables would consume a lot of address space or require frequent mapping/unmapping. Extending the file also causes mapping problems that might require mapping only individual pages, leading to thousands of mappings. Another problem is that there is no way to _prevent_ I/O to disk from the dirty shared buffers so changes could hit disk before WAL is written.<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01239.php<br />
}}<br />
<br />
{{TodoItem<br />
|Allow configuration of backend priorities via the operating system<br />
|Though backend priorities make priority inversion during lock waits possible, research shows that this is not a huge problem.<br />
* [http://archives.postgresql.org/pgsql-general/2007-02/msg00493.php <nowiki>Priorities for users or queries?</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider if CommandCounterIncrement() can avoid its AcceptInvalidationMessages() call<br />
* [http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php <nowiki>pgsql: Avoid incrementing the CommandCounter when</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider Cartesian joins when both relations are needed to form an indexscan qualification for a third relation<br />
* [http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php <nowiki>Re: TB-sized databases</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider not storing a NULL bitmap on disk if all the NULLs are trailing<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php <nowiki>Proposal for Null Bitmap Optimization(for Trailing NULLs)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php <nowiki>Re: [HACKERS] Proposal for Null Bitmap Optimization(for TrailingNULLs)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Sort large UPDATE/DELETEs so it is done in heap order<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php <nowiki>Possible future performance improvement: sort updates/deletes by ctid</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add auto-tuning of work_mem<br />
* [http://www.postgresql.org/message-id/20131009143046.GT22450@momjian.us Auto-tuning work_mem and maintenance_work_mem]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider decreasing the I/O caused by updating tuple hint bits<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-05/msg00847.php <nowiki>Hint Bits and Write I/O</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-07/msg00199.php <nowiki>Re: [HACKERS] Hint Bits and Write I/O</nowiki>]<br />
* http://archives.postgresql.org/pgsql-hackers/2010-10/msg00695.php<br />
* http://archives.postgresql.org/pgsql-hackers/2010-11/msg00792.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-01/msg01063.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01408.php<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg01453.php<br />
}}<br />
<br />
{{TodoItem<br />
|Avoid reading in b-tree pages when replaying vacuum records in hot standby mode<br />
* [http://archives.postgresql.org/message-id/1272571938.4161.14739.camel@ebony <nowiki>Hot Standby tuning for btree_xlog_vacuum()</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Restructure truncation logic to be more resistant to failure<br />
|This also involves not writing dirty buffers for a truncated or dropped relation<br />
* http://archives.postgresql.org/pgsql-hackers/2010-08/msg01032.php<br />
}}<br />
<br />
{{TodoItem<br />
|Enhance foreign data wrappers, parallelism, partitioning, and perhaps add a global snapshot/transaction manager to allow creation of a proof-of-concept built-in sharding solution<br />
|Ideally these enhancements and new facilities will be available to external sharding solutions as well.<br />
* [https://wiki.postgresql.org/wiki/Built-in_Sharding Built-in sharding wiki]<br />
}}<br />
<br />
== Miscellaneous Other ==<br />
<br />
{{TodoItem<br />
|Deal with encoding issues for filenames in the server filesystem<br />
* {{MessageLink|20090413184335.39BE.52131E4D@oss.ntt.co.jp|a proposed patch here}}<br />
* {{MessageLink|8484.1244655656@sss.pgh.pa.us|some issues about it here}}<br />
* {{MessageLink|20100107103740.97A5.52131E4D@oss.ntt.co.jp|Windows-specific patch here}}<br />
}}<br />
<br />
{{TodoItem<br />
|Deal with encoding issues in the output of localeconv()<br />
* [http://archives.postgresql.org/message-id/40c6d9160904210658y590377cfw6dbbecb53d2b8be0@mail.gmail.com bug report]<br />
* [http://archives.postgresql.org/message-id/49EF8DA0.90008@tpf.co.jp draft patch]<br />
* [http://archives.postgresql.org/message-id/21710.1243620986@sss.pgh.pa.us review of patch]<br />
}}<br />
<br />
{{TodoItem<br />
|Have GB18030 handle more than 2-byte Unicode code points<br />
* [http://www.postgresql.org/message-id/20150309205145.4031.32069@wrigleys.postgresql.org GB18030 encoding doesn't support Unicode characters over 0xFFFF]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide schema name and other fields available from SQL GET DIAGNOSTICS in error reports<br />
* [http://archives.postgresql.org/message-id/dcc563d10810211907n3c59a920ia9eb7cd2a6d5ea58@mail.gmail.com <nowiki>How to get schema name which violates fk constraint</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-11/msg00846.php <nowiki>patch - Report the schema along table name in a referential failure error message</nowiki>]<br />
* {{MessageLink|3191.1263306359@sss.pgh.pa.us|Re: NOT NULL violation and error-message}}<br />
* [http://archives.postgresql.org/pgsql-hackers/2009-08/msg00213.php <nowiki>the case for machine-readable error fields</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Use sa_mask to close race conditions between signal handlers<br />
* http://www.postgresql.org/message-id/20130911013107.GA225735@tornado.leadboat.com<br />
}}<br />
<br />
{{TodoItem<br />
|Allow pg_export_snapshot() to run on hot standby servers<br />
|This will allow parallel pg_dump on such servers.<br />
* [http://www.postgresql.org/message-id/CA+U5nML2VMJ3R2YBAZ+CsAsTWF3LuYSo16Wu9+yXFrfy4%3Df2fA@mail.gmail.com pg_export_snapshot on standby side]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide a way to enumerate and unregister background workers<br />
|Right now the only way to unregister bgworkers is from within the worker with <tt>proc_exit(0)</tt> or registering with <tt>BGW_NEVER_RESTART</tt><br />
* https://www.postgresql.org/message-id/CAMsr%2BYG-fD%2BmP-BNZDheVYucC7%3DoUn8ByTQSFz7RKkVX2MRS2Q%40mail.gmail.com<br />
}}<br />
<br />
== Source Code ==<br />
<br />
{{TodoItem<br />
|Allow cross-compiling by generating the zic database on the target system}}<br />
<br />
{{TodoItem<br />
|Improve NLS maintenance of libpgport messages linked onto applications}}<br />
<br />
{{TodoItem<br />
|Use UTF8 encoding for NLS messages so all server encodings can read them properly}}<br />
<br />
{{TodoItem<br />
|Allow creation of universal binaries for Darwin<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00884.php <nowiki>Getting to universal binaries for Darwin</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider GnuTLS if OpenSSL license becomes a problem<br />
* http://archives.postgresql.org/pgsql-hackers/2011-02/msg00892.php<br />
* [http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php <nowiki>[PATCH] Add support for GnuTLS</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php <nowiki>TODO: GNU TLS</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider making NAMEDATALEN more configurable}}<br />
<br />
{{TodoItem<br />
|Research use of signals and sleep wake ups<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php <nowiki>Restartable signals 'n all that</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow C++ code to more easily access backend code<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg00302.php <nowiki>Mostly Harmless: Welcoming our C++ friends</nowiki>]<br />
* [https://www.postgresql.org/message-id/flat/CABgyVxDBd3EvRdo-Rd6eo8QPEqV8%3DShaU2SJfo16wfE0R-hXTA%40mail.gmail.com C++ port of Postgres]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider simplifying how memory context resets handle child contexts<br />
* [http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php <nowiki>Re: Memory leak in nodeAgg</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve detection of shared memory segments being used by others by checking the SysV shared memory field 'nattch'<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00656.php <nowiki>postgresql in FreeBSD jails: proposal</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00673.php <nowiki>Re: postgresql in FreeBSD jails: proposal</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Implement the non-threaded Avahi service discovery protocol<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00939.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00097.php <nowiki>Re: Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg01211.php <nowiki>Re: [PATCHES] Avahi support for Postgresql</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-04/msg00001.php <nowiki>Re: [HACKERS] Avahi support for Postgresql</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce data row alignment requirements on some 64-bit systems<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg00369.php <nowiki>[WIP] Reduce alignment requirements on 64-bit systems.</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Restructure TOAST internal storage format for greater flexibility<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-11/msg00049.php <nowiki>Re: PG_PAGE_LAYOUT_VERSION 5 - time for change</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
| Research different memory allocation methods for lists<br />
* http://archives.postgresql.org/pgsql-hackers/2011-04/msg01467.php <br />
}}<br />
<br />
{{TodoItem<br />
| Consider removing the attribute options cache<br />
* http://archives.postgresql.org/pgsql-hackers/2011-03/msg00039.php<br />
}}<br />
<br />
{{TodoItem<br />
| Restructure /contrib section<br />
* http://archives.postgresql.org/pgsql-hackers/2011-06/msg00705.php<br />
}}<br />
<br />
=== Windows ===<br />
{{TodoSubsection}}<br />
<br />
{{TodoItem<br />
|Remove configure.in check for link failure when the cause is found}}<br />
<br />
{{TodoItem<br />
|Allow psql to use readline once non-US code pages work with backslashes}}<br />
<br />
{{TodoItem<br />
|Improve signal handling<br />
* [http://archives.postgresql.org/pgsql-patches/2005-06/msg00027.php <nowiki>Simplify Win32 Signaling code</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Support PGXS when using MSVC}}<br />
<br />
{{TodoItem<br />
|Fix MSVC NLS support, like for to_char()<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-02/msg00485.php <nowiki>NLS on MSVC strikes back!</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2008-02/msg00038.php <nowiki>Fix for 8.3 MSVC locale (Was [HACKERS] NLS on MSVC strikes back!)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Fix global namespace issues when using multiple terminal server sessions<br />
* [http://archives.postgresql.org/message-id/48F3BFCC.8030107@dunslane.net problems with Windows global namespace]}}<br />
<br />
{{TodoItem<br />
|Change from the current autoconf/gmake build system to cmake<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-12/msg01869.php <nowiki>About CMake (was Re: [COMMITTERS] pgsql: Append major version number and for libraries soname major)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Improve consistency of path separator usage<br />
* http://archives.postgresql.org/message-id/49C0BDC5.4010002@hagander.net<br />
}}<br />
<br />
{{TodoItem<br />
|Fix cross-compiling on Windows<br />
* http://archives.postgresql.org/pgsql-bugs/2010-10/msg00110.php<br />
}}<br />
<br />
{{TodoItem<br />
|Reduce file statistics overhead on directory reads<br />
* http://www.postgresql.org/message-id/1338325561.82125.YahooMailNeo@web39304.mail.mud.yahoo.com<br />
}}<br />
<br />
{{TodoItem<br />
|Fix hang with long file paths<br />
* [http://www.postgresql.org/message-id/CAA4eK1JxaBofxpcgLqCx9EB%3Dm3PaXr9iFU9%3DV3ddDswsPZooxw@mail.gmail.com Long paths for tablespace leads to uninterruptible hang in Windows]<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
=== Wire Protocol Changes / v4 Protocol ===<br />
{{TodoSubsection}}<br />
<br />
<br />
{{TodoItem<br />
|Allow dynamic character set handling}}<br />
<br />
{{TodoItem<br />
|Ensure the client can determine the encoding of messages sent early in the handshake<br />
* http://www.postgresql.org/message-id/541A5659.5050006@2ndquadrant.com}}<br />
<br />
{{TodoItem<br />
|Let the client indicate character encoding of database names, user names, passwords, and of pre-auth error messages returned by the server<br />
* http://www.postgresql.org/message-id/16160.1360540050@sss.pgh.pa.us<br />
* http://www.postgresql.org/message-id/20131220030725.GA1411150@tornado.leadboat.com<br />
}}<br />
<br />
{{TodoItem<br />
|Send numeric version to clients in fixed header<br />
* [https://commitfest.postgresql.org/10/752/ <nowiki>patch to send server_version_num in v3 protocol as GUC_REPORT</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Add decoded type length/precision (i.e. typmod information)}}<br />
<br />
{{TodoItem<br />
|Mark result columns as known-not-null when possible<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-11/msg01029.php <nowiki>Adding nullable indicator to Describe</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Use compression<br />
|Specify and implement wire protocol compression. If SSL transparent compression is used, hopefully avoid the overhead of key negotiation and encryption when SSL is configured only for compression. Note that [https://www.ietf.org/mail-archive/web/tls/current/msg11619.html compression is being removed from TLS 1.3] so we really need to do it ourselves.<br />
* http://archives.postgresql.org/pgsql-hackers/2012-06/msg00793.php<br />
}}<br />
<br />
{{TodoItem<br />
|Update clients to use data types, typmod, schema.table.column names of result sets using new statement protocol}}<br />
<br />
{{TodoItem<br />
|Set protocol for wire format negotiation<br />
* [http://archives.postgresql.org/message-id/CACMqXCKkGrGXxQhjHCKCe0B8hn6sTt-1sdgHZOSGQMxrusOsQA@mail.gmail.com GUC_REPORT for protocol tunables]<br />
}}<br />
<br />
{{TodoItem<br />
|Make sure upgrading to a 4.1 protocol version will actually work smoothly<br />
* [http://archives.postgresql.org/message-id/28307.1318255008@sss.pgh.pa.us Re: libpq, PQdescribePrepared -> PQftype, PQfmod, no PQnullable]<br />
}}<br />
<br />
{{TodoItem<br />
|Allow multi-state authentication (e.g. try client peer, fall back to md5)<br />
* http://www.postgresql.org/message-id/51A44185.5060306@2ndquadrant.com<br />
* http://www.postgresql.org/message-id/55192AFE.6080106@iki.fi<br />
* http://www.postgresql.org/message-id/54DB1D4E.8090700@vmware.com<br />
* https://commitfest.postgresql.org/6/320/<br />
}}<br />
<br />
{{TodoItem<br />
|Allow re-authentication<br />
|Let the client request re-authentication as a different user mid session, for connection pools that pass through the handshake.<br />
}}<br />
<br />
{{TodoItem<br />
|Identify the affected object in CommandComplete message?<br />
* http://www.postgresql.org/message-id/CAAfz9KNGVoyM+z_2tnPKTDXG_RdR9a33Y5s+zQ9LdwTTsqqZng@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Allow negotiation of encryption, <tt>STARTTLS</tt> style, rather than forcing client to decide on SSL or !SSL before connecting<br />
* http://www.postgresql.org/message-id/5406EAD3.7070002@2ndquadrant.com}}<br />
<br />
{{TodoItem<br />
|Permit lazy fetches of large values, at least out-of-line TOASTED values<br />
* http://www.postgresql.org/message-id/53FF0EF8.100@2ndquadrant.com<br />
}}<br />
<br />
{{TodoItem<br />
|Add session-level whitelisting of types for binary-mode transfer<br />
* http://www.postgresql.org/message-id/30470.1412055068@sss.pgh.pa.us<br />
}}<br />
<br />
{{TodoItem<br />
|Send client the xid when it is allocated<br />
|Lets the client later ask the server "did this commit or not?" after interterminate result due to crash or connection loss<br />
}}<br />
<br />
{{TodoItem<br />
|Report xlog position in commit message<br />
|Help enable client-side failover by providing a token clients can use to see if a commit has replayed to replicas yet<br />
* http://www.postgresql.org/message-id/53E2D346.9030806@2ndquadrant.com<br />
}}<br />
<br />
{{TodoItem<br />
|Changes to make cancellations more reliable and more secure<br />
* http://www.postgresql.org/message-id/CADT4RqAUd7wYYsM9D7GHJnZj3J79D4W%3Dved2kqM5mVt5cuGHgg@mail.gmail.com<br />
}}<br />
<br />
{{TodoItem<br />
|Clarify semantics of statement_timeout in extended query protocol<br />
|Batched and pipelined queries have unexpected behaviour with statement_timeout. Client needs to be able to specify statement boundary with protocol message.<br />
* https://www.postgresql.org/message-id/20160528.220442.1489791680347556026.t-ishii@sraoss.co.jp<br />
}}<br />
<br />
{{TodoItem<br />
|Create a more efficient way to handle out-of-line parameters<br />
* [https://www.postgresql.org/message-id/12500.1470002232%40sss.pgh.pa.us Re: Slowness of extended protocol]<br />
}}<br />
<br />
{{TodoItem<br />
|Separate transaction delineation from protocol error recovery (in v3 both are managed via the same Sync message)<br />
* https://www.postgresql.org/message-id/CADT4RqDdo9EcFbxwB_YO2H3BVZ0t-1qqZ%3D%2B%2BdVMnYaN6BpyUGQ%40mail.gmail.com<br />
* https://www.postgresql.org/message-id/CAMsr%2BYEgnJ8ZAWPLx5%3DBCbYYq9SNTdwbwvUcb7V-vYm5d5uhbQ%40mail.gmail.com<br />
}}<br />
<br />
{{TodoEndSubsection}}<br />
<br />
== Documentation ==<br />
<br />
{{TodoItemEasy <br />
| Add contrib functions to the index<br />
* Add the functions and GUCs in the contrib modules to [http://www.postgresql.org/docs/current/static/sql-createindex.html the documentation index]: [http://archives.postgresql.org/message-id/50A2E173.6030404@2ndQuadrant.com per list discussion]<br />
}}<br />
<br />
{{TodoItem<br />
|Provide a manpage for postgresql.conf<br />
* {{messageLink|20080819194311.GH4428@alvh.no-ip.org|A smaller default postgresql.conf}}<br />
* {{messageLink|200808211910.37524.peter_e@gmx.net|A smaller default postgresql.conf}}<br />
}}<br />
<br />
{{TodoItem<br />
|Document support for N<nowiki>' '</nowiki> national character string literals, if it matches the SQL standard<br />
* http://archives.postgresql.org/message-id/1275895438.1849.1.camel@fsopti579.F-Secure.com<br />
}}<br />
<br />
{{TodoItem<br />
|Add diagrams to the documentation<br />
* http://archives.postgresql.org/pgsql-docs/2010-07/msg00001.php<br />
}}<br />
<br />
== Exotic Features ==<br />
<br />
{{TodoItem<br />
|Add pre-parsing phase that converts non-ISO syntax to supported syntax<br />
|This could allow SQL written for other databases to run without modification.}}<br />
<br />
{{TodoItem<br />
|Allow plug-in modules to emulate features from other databases}}<br />
<br />
{{TodoItem<br />
|Add features of Oracle-style packages<br />
|A package would be a schema with session-local variables, public/private functions, and initialization functions. It is also possible to implement these capabilities in any schema and not use a separate &quot;packages&quot; syntax at all.<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-08/msg00384.php <nowiki>proposal for PL packages for 8.3.</nowiki>]<br />
* [http://www.postgresql.org/message-id/CAFj8pRD4OAXp2zp7dBRg5eo6X3rtT5MHTMVRN1e1kdK8xE6E4g@mail.gmail.com proposal: schema PL session variables]<br />
* [https://www.postgresql.org/message-id/CAFj8pRCfdTLeJbTSbAFOwhuS-aWaJ61w59XwKLcVYQFAVwfVCw%40mail.gmail.com proposal: session server side variables]<br />
* [https://www.postgresql.org/message-id/81060c9d-73df-2266-8857-d584164bb699%40commandprompt.com Packages: Again]<br />
}}<br />
<br />
{{TodoItem<br />
|Consider allowing control of upper/lower case folding of unquoted identifiers<br />
* [http://archives.postgresql.org/pgsql-hackers/2004-04/msg00818.php <nowiki>Bringing PostgreSQL torwards the standard regarding case folding</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-10/msg01527.php <nowiki>Re: [SQL] Case Preservation disregarding case sensitivity?</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-03/msg00849.php <nowiki>TODO Item: Consider allowing control of upper/lower case folding of unquoted, identifiers</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-07/msg00415.php <nowiki>Identifier case folding notes</nowiki>]<br />
* [https://www.postgresql.org/message-id/ACF85C502E55A143AB9F4ECFE960660A17282D@mailserver2.local.mstarlabs.com Cluster wide option to control symbol case folding]<br />
}}<br />
<br />
{{TodoItem<br />
|Add autonomous transactions<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php <nowiki>autonomous transactions</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Give query progress indication<br />
* [[Query progress indication]]<br />
}}<br />
<br />
{{TodoItem<br />
|Rethink our type system<br />
* [[Rethinking datatypes]]<br />
}}<br />
<br />
== Features We Do ''Not'' Want ==<br />
<br />
The following features have been discussed ad nauseum on the PostgreSQL mailing lists and the consensus has been that the project is not interested in them. As such, if you are going to bring them up as potential features, you will want to be familiar with all of the arguments against these features which have been previously made over the years. If you decide to work on such features anyway, you should be aware that you face a higher-than-normal barrier to get the Project to accept them.<br />
<br />
{{TodoItem<br />
|All backends running as threads in a single process (not wanted)<br />
|This eliminates the process protection we get from the current setup. Thread creation is usually the same overhead as process creation on modern systems, so it seems unwise to use a pure threaded model, and MySQL and DB2 have demonstrated that threads introduce as many issues as they solve. Threading specific operations such as I/O, seq scans, and connection management has been discussed and will probably be implemented to enable specific performance features. Moving to a threaded engine would also require halting all other work on PostgreSQL for one to two years.<br />
* [https://www.postgresql.org/message-id/942824238.20160712165757@bitec.ru One process per session lack of sharing]<br />
}}<br />
<br />
{{TodoItem<br />
|"Oracle-style" optimizer hints (not wanted)<br />
|Optimizer hints, as implemented in Oracle and other RDBMSes, are used to work around problems in the optimizer and introduce upgrade and maintenance issues. We would rather have such problems reported and fixed. We have discussed a more sophisticated system of per-class cost adjustment instead, but a specification remains to be developed. See [[OptimizerHintsDiscussion|Optimizer Hints Discussion]] for further information.}}<br />
<br />
{{TodoItem<br />
|Embedded server (not wanted)<br />
|While PostgreSQL clients runs fine in limited-resource environments, the server requires multiple processes and a stable pool of resources to run reliably and efficiently. Stripping down the PostgreSQL server to run in the same process address space as the client application would add too much complexity and failure cases. Besides, there are several very mature embedded SQL databases already available.}}<br />
<br />
{{TodoItem<br />
|Obfuscated function source code (not wanted)<br />
|Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.<br />
* [http://archives.postgresql.org/pgsql-general/2008-09/msg00668.php <nowiki>Obfuscated stored procedures (was Re: Oracle and Postgresql)</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|Indeterminate behavior for the GROUP BY clause (not wanted)<br />
|At least one other database product allows specification of a subset of the result columns which GROUP BY would need to be able to provide predictable results; the server is free to return any value from the group. This is not viewed as a desirable feature. PostgreSQL 9.1 allows result columns that are not referenced by GROUP BY if a primary key for the same table is referenced in GROUP BY.<br />
* [http://archives.postgresql.org/pgsql-hackers/2010-03/msg00297.php <nowiki>Re: SQL compatibility reminder: MySQL vs PostgreSQL</nowiki>]<br />
}}<br />
<br />
{{TodoItem<br />
|On-disk bitmap indexes (not wanted)<br />
|The rigidity of on-disk bitmap indexes, and the existence of GIN and in-memory bitmaps make this undesirable.<br />
* [http://archives.postgresql.org/pgsql-patches/2005-07/msg00512.php <nowiki>Re: Bitmap index AM</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2006-12/msg01107.php <nowiki>Bitmap index thoughts</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg00265.php <nowiki>Stream bitmaps</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-03/msg01214.php <nowiki>Re: Bitmapscan changes - Requesting further feedback</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-patches/2007-05/msg00013.php <nowiki>Updated bitmap index patch</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2007-07/msg00741.php <nowiki>Reviewing new index types (was Re: [PATCHES] Updated bitmap indexpatch)</nowiki>]<br />
* [http://archives.postgresql.org/pgsql-hackers/2008-10/msg01023.php <nowiki>Bitmap Indexes: request for feedback</nowiki>]<br />
* [http://archives.postgresql.org/message-id/800923.27831.qm@web29010.mail.ird.yahoo.com <nowiki>bitmap indexes - performance</nowiki>]<br />
* [http://www.postgresql.org/message-id/20130914181424.GA24448@toroid.org <nowiki>[PATCH] bitmap indexes</nowiki>]<br />
}}<br />
<br />
[[Category:Todo]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon_2018_Developer_Meeting&diff=31520PgCon 2018 Developer Meeting2018-02-26T12:20:47Z<p>Ishii: /* RSVPs */</p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Tuesday 29 May, 2018 at the University of Ottawa, prior to pgCon 2018. In order to keep the numbers manageable, this meeting is by '''invitation only'''. Unfortunately it is quite possible that we've overlooked important individuals during the planning of the event - if you feel you fall into this category and would like to attend, please contact Dave Page (dpage@pgadmin.org).<br />
<br />
Please note that the attendee numbers have been kept low in order to keep the meeting more productive. Invitations have been sent only to developers that have been highly active on the database server over the 11/10 release cycles. We have not invited any contributors based on their contributions to related projects, or seniority in regional user groups or sponsoring companies.<br />
<br />
As at last years event, an Unconference will be held on Wednesday for in-depth discussion of technical topics.<br />
<br />
This is a PostgreSQL Community event.<br />
<br />
== Meeting Goals ==<br />
<br />
* Define the schedule for the 12.0 release cycle<br />
* Address any proposed timing, policy, or procedure issues<br />
* Address any proposed [http://en.wikipedia.org/wiki/Wicked_problem Wicked problems]<br />
<br />
== Time & Location ==<br />
<br />
The meeting will be:<br />
<br />
* 9:00AM to 12PM<br />
* TBD<br />
* University of Ottawa.<br />
<br />
Coffee, tea and snacks will be served starting at 8:45am. Lunch will be after the meeting.<br />
<br />
== RSVPs ==<br />
<br />
The following people have RSVPed to the meeting (in alphabetical order, by surname):<br />
<br />
* Magnus Hagander<br />
* Tatsuo Ishii<br />
* Amit Kapila<br />
* Thomas Munro<br />
<br />
== Agenda Items ==<br />
<br />
* 12.0 release and commitfest schedule (Dave)<br />
<br />
* ''Please add suggestions for agenda items here. (with your name)''<br />
<br />
==Agenda==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:30<br />
|Welcome and introductions<br />
|Dave Page<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 10:45<br />
|Coffee break<br />
|All<br />
<br />
|- <br />
|11:50 - 12:00<br />
|Any other business<br />
|Dave Page<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:00<br />
|Lunch<br />
|<br />
<br />
|}<br />
<br />
== Minutes ==<br />
<br />
=== Welcome and introductions ===<br />
<br />
Attendees:<br />
<br />
=== 12.0 release and commitfest schedule ===<br />
<br />
=== Any other business ===</div>Ishiihttps://wiki.postgresql.org/index.php?title=NewsEventsApproval&diff=28528NewsEventsApproval2016-11-02T07:29:23Z<p>Ishii: /* Procedure for Approving pgsql-announce */</p>
<hr />
<div>== Policies for Approving PostgreSQL.org Front Page News & Events & pgsql-announce ==<br />
<br />
=== General Rules ===<br />
<br />
The www.postgresql.org home page contains News and Events listings which are maintained entirely for the benefit of the PostgreSQL community. As this space would be quite valuable (up to $400 per listing) if commercially available, our admins have unlimited authority to be restrictive about what they allow on the home page.<br />
<br />
All News and Events (including Training Events) to be approved must include the following information:<br />
<br />
* Accurate contact information<br />
* A descriptive title which distinguishes the item from similar items<br />
* A 10 to 25 word summary of the item which provides enough information to clearly let RSS readers know if they want more information.<br />
* A description of the news or event which clearly explains what it is and how it relates to PostgreSQL.<br />
<br />
Other General Rules include:<br />
<br />
* All items must relate to PostgreSQL in some direct and obvious way. <br />
* Link-only events or news will never be acceptable.<br />
* The WWW admin group of the PostgreSQL project may permanently ban any organization which is the cause of substantiated complaints about accuracy, ethics or legality from members of our community.<br />
* The WWW team makes no promises about timely approval of announcements. If publication on a specific day is critical to you, you will need to contact the pgsql-www mailing list or a core team member prior to the submission.<br />
* Companies listed on the [http://www.postgresql.org/about/sponsors sponsors page] may be granted an exception to any of the limitations on news and events, such as allowed posting frequency, at the discretion of the web team.<br />
* The WWW team reserves the right to partially or entirely rewrite News or Events postings to improve clarity.<br />
* After an announcement of PostgreSQL releases (including beta or RC) has been made, no new announcement request will be accepted on the same day (or even a day or two after) to respect such that important announcement. <br />
<br />
In general, the PostgreSQL.org home page is run exclusively for the benefit of the not-for-profit member-owned PostgreSQL community. It is not an advertising venue, and site admins are entitled to reject any notice which they feel is inconsistent with the community's needs for any reason, or for no reason.<br />
<br />
== Approving News and Announcements ==<br />
<br />
All News policy below is considered to apply equally to the home page and pgsql-announce, except that pgsql-announce also carries PWN.<br />
<br />
=== PostgreSQL Core News ===<br />
<br />
All items will be approved unless inaccurate. The following types of news are generally appropriate for the home page:<br />
<br />
* All releases, major, minor and beta<br />
* Development schedule milestones<br />
* New certifications, awards & benchmarks<br />
* Core team and committer changes<br />
* Security issues<br />
* Calls for assistance/participation<br />
* Major changes to infrastructure, web, or legal structure of PostgreSQL<br />
* Major new advocacy efforts<br />
<br />
=== PostgreSQL "Family" News ===<br />
<br />
This includes news about PostgreSQL add-on projects & drivers, open source projects which are primarily based on PostgreSQL, and news about PostgreSQL regional and user groups.<br />
<br />
Any of the following items will be approved, regardless of frequency:<br />
<br />
* Any release or initial beta of a major release<br />
* Creation of any new user group, regional group, or web site<br />
* Critical security patch announcements<br />
* Substantial new articles or documentation<br />
* Infrequent calls for assistance/participation<br />
<br />
Other types of news, such as changes in leadership, will not be approved.<br />
<br />
=== Proprietary & External OSS Project News ===<br />
<br />
This includes all news from companies whose products contain, support or are based on PostgreSQL, and OSS projects which support PostgreSQL as one of several database options.<br />
<br />
The following types of news will be approved:<br />
<br />
* Brand new products/projects/services which support or center around PostgreSQL<br />
* Newly released books about PostgreSQL or with substantial (20% or more) PostgreSQL content.<br />
* First support of PostgreSQL in existing products<br />
* Major version releases (not more than once per quarter)<br />
* Critical security updates, if thought to affect many PostgreSQL community members<br />
<br />
Other types of announcements, including minor releases, pricing changes, leadership changes, 3rd-party news coverage, partnerships, and mergers & acquisitions will be rejected.<br />
<br />
In addition, commercial entities who are not financial, in-kind or code contributors to the PostgreSQL project will be restricted to ''one news item of any kind per six-month period.''<br />
<br />
=== Procedure for Approving pgsql-announce ===<br />
<br />
Since pgsql-announce goes to over 30,000 addresses, we are cautious in what we approve to that list. In some cases, this may result in a delay of up to several days in approving announcements.<br />
<br />
# Check if it's spam and reject spam.<br />
# Check if there is anything else in the 'To' or 'CC' list besides -announce; if so, reject and ask for re-submission.<br />
# Read the announcement<br />
# Consider if the announcement meets this policy and is appropriate for announcement<br />
#* if necessary, check on pgsql-www list<br />
# Approve or Reject<br />
<br />
In any case where an approver has doubts about whether to approve an announcement or not, they should err on the side of caution.<br />
<br />
Please note that PostgreSQL major/minor release posts should be handled by the release team, not by the pgsql-announce moderators.<br />
<br />
== Approving Events and Event-Related News (excluding training) ==<br />
<br />
Events must have significant PostgreSQL-related content in order to be listed.<br />
<br />
=== PostgreSQL Conferences & Events ===<br />
<br />
Any semi-annual or less frequent non-training event which is primarily about PostgreSQL or for PostgreSQL users will be entitled to be listed. Additionally, conferences which are primarily or entirely about PostgreSQL will be entitled to post news items at the following milestones, if they are each a week or more apart: <br />
<br />
* Call for Papers<br />
* Schedule Posting,<br />
* Registration Opening, <br />
* Registration Closing, <br />
* Wrap-up.<br />
<br />
Routine monthly PostgreSQL User Group meetings will ''not'' be listed. First meetings of a new PUG can be listed, as well as infrequent major special events likely to be of interest outside of the PUG's normal area.<br />
<br />
=== Open Source & Database Conferences & Events ===<br />
<br />
Open source conferences, and database conferences, which are not primarily about PostgreSQL but have significant PostgreSQL content, such as several sessions and a booth, may be listed in the Events. Additionally, the Call For Papers for these events may be accepted as News.<br />
<br />
More routine events, such as monthly local meetings or mini-conferences, will not be listed. Conferences must have significant PostgreSQL content to be worth listing, with decisions on relative significance to be made by the WWW team.<br />
<br />
== Training Events ==<br />
<br />
PostgreSQL Training may be listed from any company, under the following conditions:<br />
<br />
* Each listing must include:<br />
** Specific locations and dates for that specific training<br />
** Link to online training registration<br />
** One or more sentence description of the contents of that specific training<br />
<br />
All descriptive text should be purely informative and not include strong marketing copy or special offers unrelated to the training. The vendors website should list PostgreSQL training information, including an online schedule of upcoming trainings.<br />
<br />
In the event that any training company submits more than 4 training events to be held in any given quarter, site admins may (at their discretion) deny posting events to that company.<br />
<br />
== Rejection Notices ==<br />
<br />
In cases where the submitter appears to have gone to some effort to submit a relevant news item or event, but doesn't understand our policies, we should send them a rejection e-mail linking to this page and explaining what was wrong with their submission. This certainly goes for any of the major project sponsors.<br />
<br />
If the submission looks like a 30-second cut-and-paste job, or something else sloppy and quick, or is a submission by someone who has had multiple submissions rejected in the past for the same reason, don't bother sending a response. We get too much spam for that.<br />
<br />
Any company which has had submissions repeatedly rejected for the same reasons, and does not correct their errors when notified, risks having their community account suspended and their ability to submit news and events blocked.<br />
<br />
[[Category:Policies]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=NewsEventsApproval&diff=28243NewsEventsApproval2016-09-21T22:17:41Z<p>Ishii: /* PostgreSQL Conferences & Events */</p>
<hr />
<div>== Policies for Approving PostgreSQL.org Front Page News & Events & pgsql-announce ==<br />
<br />
=== General Rules ===<br />
<br />
The www.postgresql.org home page contains News and Events listings which are maintained entirely for the benefit of the PostgreSQL community. As this space would be quite valuable (up to $400 per listing) if commercially available, our admins have unlimited authority to be restrictive about what they allow on the home page.<br />
<br />
All News and Events (including Training Events) to be approved must include the following information:<br />
<br />
* Accurate contact information<br />
* A descriptive title which distinguishes the item from similar items<br />
* A 10 to 25 word summary of the item which provides enough information to clearly let RSS readers know if they want more information.<br />
* A description of the news or event which clearly explains what it is and how it relates to PostgreSQL.<br />
<br />
Other General Rules include:<br />
<br />
* All items must relate to PostgreSQL in some direct and obvious way. <br />
* Link-only events or news will never be acceptable.<br />
* The WWW admin group of the PostgreSQL project may permanently ban any organization which is the cause of substantiated complaints about accuracy, ethics or legality from members of our community.<br />
* The WWW team makes no promises about timely approval of announcements. If publication on a specific day is critical to you, you will need to contact the pgsql-www mailing list or a core team member prior to the submission.<br />
* Companies listed on the [http://www.postgresql.org/about/sponsors sponsors page] may be granted an exception to any of the limitations on news and events, such as allowed posting frequency, at the discretion of the web team.<br />
* The WWW team reserves the right to partially or entirely rewrite News or Events postings to improve clarity.<br />
* After an announcement of PostgreSQL releases (including beta or RC) has been made, no new announcement request will be accepted on the same day (or even a day or two after) to respect such that important announcement. <br />
<br />
In general, the PostgreSQL.org home page is run exclusively for the benefit of the not-for-profit member-owned PostgreSQL community. It is not an advertising venue, and site admins are entitled to reject any notice which they feel is inconsistent with the community's needs for any reason, or for no reason.<br />
<br />
== Approving News and Announcements ==<br />
<br />
All News policy below is considered to apply equally to the home page and pgsql-announce, except that pgsql-announce also carries PWN.<br />
<br />
=== PostgreSQL Core News ===<br />
<br />
All items will be approved unless inaccurate. The following types of news are generally appropriate for the home page:<br />
<br />
* All releases, major, minor and beta<br />
* Development schedule milestones<br />
* New certifications, awards & benchmarks<br />
* Core team and committer changes<br />
* Security issues<br />
* Calls for assistance/participation<br />
* Major changes to infrastructure, web, or legal structure of PostgreSQL<br />
* Major new advocacy efforts<br />
<br />
=== PostgreSQL "Family" News ===<br />
<br />
This includes news about PostgreSQL add-on projects & drivers, open source projects which are primarily based on PostgreSQL, and news about PostgreSQL regional and user groups.<br />
<br />
Any of the following items will be approved, regardless of frequency:<br />
<br />
* Any release or initial beta of a major release<br />
* Creation of any new user group, regional group, or web site<br />
* Critical security patch announcements<br />
* Substantial new articles or documentation<br />
* Infrequent calls for assistance/participation<br />
<br />
Other types of news, such as changes in leadership, will not be approved.<br />
<br />
=== Proprietary & External OSS Project News ===<br />
<br />
This includes all news from companies whose products contain, support or are based on PostgreSQL, and OSS projects which support PostgreSQL as one of several database options.<br />
<br />
The following types of news will be approved:<br />
<br />
* Brand new products/projects/services which support or center around PostgreSQL<br />
* Newly released books about PostgreSQL or with substantial (20% or more) PostgreSQL content.<br />
* First support of PostgreSQL in existing products<br />
* Major version releases (not more than once per quarter)<br />
* Critical security updates, if thought to affect many PostgreSQL community members<br />
<br />
Other types of announcements, including minor releases, pricing changes, leadership changes, 3rd-party news coverage, partnerships, and mergers & acquisitions will be rejected.<br />
<br />
In addition, commercial entities who are not financial, in-kind or code contributors to the PostgreSQL project will be restricted to ''one news item of any kind per six-month period.''<br />
<br />
=== Procedure for Approving pgsql-announce ===<br />
<br />
Since pgsql-announce goes to over 30,000 addresses, we are cautious in what we approve to that list. In some cases, this may result in a delay of up to several days in approving announcements.<br />
<br />
# Check if it's spam and reject spam.<br />
# Check if there is anything else in the 'To' or 'CC' list besides -announce; if so, reject and ask for re-submission.<br />
# Read the announcement<br />
# Consider if the announcement meets this policy and is appropriate for announcement<br />
#* if necessary, check on pgsql-www list<br />
# Approve or Reject<br />
<br />
In any case where an approver has doubts about whether to approve an announcement or not, they should err on the side of caution.<br />
<br />
== Approving Events and Event-Related News (excluding training) ==<br />
<br />
Events must have significant PostgreSQL-related content in order to be listed.<br />
<br />
=== PostgreSQL Conferences & Events ===<br />
<br />
Any semi-annual or less frequent non-training event which is primarily about PostgreSQL or for PostgreSQL users will be entitled to be listed. Additionally, conferences which are primarily or entirely about PostgreSQL will be entitled to post news items at the following milestones, if they are each a week or more apart: <br />
<br />
* Call for Papers<br />
* Schedule Posting,<br />
* Registration Opening, <br />
* Registration Closing, <br />
* Wrap-up.<br />
<br />
Routine monthly PostgreSQL User Group meetings will ''not'' be listed. First meetings of a new PUG can be listed, as well as infrequent major special events likely to be of interest outside of the PUG's normal area.<br />
<br />
=== Open Source & Database Conferences & Events ===<br />
<br />
Open source conferences, and database conferences, which are not primarily about PostgreSQL but have significant PostgreSQL content, such as several sessions and a booth, may be listed in the Events. Additionally, the Call For Papers for these events may be accepted as News.<br />
<br />
More routine events, such as monthly local meetings or mini-conferences, will not be listed. Conferences must have significant PostgreSQL content to be worth listing, with decisions on relative significance to be made by the WWW team.<br />
<br />
== Training Events ==<br />
<br />
PostgreSQL Training may be listed from any company, under the following conditions:<br />
<br />
* Each listing must include:<br />
** Specific locations and dates for that specific training<br />
** Link to online training registration<br />
** One or more sentence description of the contents of that specific training<br />
<br />
All descriptive text should be purely informative and not include strong marketing copy or special offers unrelated to the training. The vendors website should list PostgreSQL training information, including an online schedule of upcoming trainings.<br />
<br />
In the event that any training company submits more than 4 training events to be held in any given quarter, site admins may (at their discretion) deny posting events to that company.<br />
<br />
== Rejection Notices ==<br />
<br />
In cases where the submitter appears to have gone to some effort to submit a relevant news item or event, but doesn't understand our policies, we should send them a rejection e-mail linking to this page and explaining what was wrong with their submission. This certainly goes for any of the major project sponsors.<br />
<br />
If the submission looks like a 30-second cut-and-paste job, or something else sloppy and quick, or is a submission by someone who has had multiple submissions rejected in the past for the same reason, don't bother sending a response. We get too much spam for that.<br />
<br />
Any company which has had submissions repeatedly rejected for the same reasons, and does not correct their errors when notified, risks having their community account suspended and their ability to submit news and events blocked.<br />
<br />
[[Category:Policies]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=NewsEventsApproval&diff=28150NewsEventsApproval2016-09-07T00:16:51Z<p>Ishii: /* General Rules */</p>
<hr />
<div>== Policies for Approving PostgreSQL.org Front Page News & Events & pgsql-announce ==<br />
<br />
=== General Rules ===<br />
<br />
The www.postgresql.org home page contains News and Events listings which are maintained entirely for the benefit of the PostgreSQL community. As this space would be quite valuable (up to $400 per listing) if commercially available, our admins have unlimited authority to be restrictive about what they allow on the home page.<br />
<br />
All News and Events (including Training Events) to be approved must include the following information:<br />
<br />
* Accurate contact information<br />
* A descriptive title which distinguishes the item from similar items<br />
* A 10 to 25 word summary of the item which provides enough information to clearly let RSS readers know if they want more information.<br />
* A description of the news or event which clearly explains what it is and how it relates to PostgreSQL.<br />
<br />
Other General Rules include:<br />
<br />
* All items must relate to PostgreSQL in some direct and obvious way. <br />
* Link-only events or news will never be acceptable.<br />
* The WWW admin group of the PostgreSQL project may permanently ban any organization which is the cause of substantiated complaints about accuracy, ethics or legality from members of our community.<br />
* The WWW team makes no promises about timely approval of announcements. If publication on a specific day is critical to you, you will need to contact the pgsql-www mailing list or a core team member prior to the submission.<br />
* Companies listed on the [http://www.postgresql.org/about/sponsors sponsors page] may be granted an exception to any of the limitations on news and events, such as allowed posting frequency, at the discretion of the web team.<br />
* The WWW team reserves the right to partially or entirely rewrite News or Events postings to improve clarity.<br />
* After an announcement of PostgreSQL releases (including beta or RC) has been made, no new announcement request will be accepted on the same day (or even a day or two after) to respect such that important announcement. <br />
<br />
In general, the PostgreSQL.org home page is run exclusively for the benefit of the not-for-profit member-owned PostgreSQL community. It is not an advertising venue, and site admins are entitled to reject any notice which they feel is inconsistent with the community's needs for any reason, or for no reason.<br />
<br />
== Approving News and Announcements ==<br />
<br />
All News policy below is considered to apply equally to the home page and pgsql-announce, except that pgsql-announce also carries PWN.<br />
<br />
=== PostgreSQL Core News ===<br />
<br />
All items will be approved unless inaccurate. The following types of news are generally appropriate for the home page:<br />
<br />
* All releases, major, minor and beta<br />
* Development schedule milestones<br />
* New certifications, awards & benchmarks<br />
* Core team and committer changes<br />
* Security issues<br />
* Calls for assistance/participation<br />
* Major changes to infrastructure, web, or legal structure of PostgreSQL<br />
* Major new advocacy efforts<br />
<br />
=== PostgreSQL "Family" News ===<br />
<br />
This includes news about PostgreSQL add-on projects & drivers, open source projects which are primarily based on PostgreSQL, and news about PostgreSQL regional and user groups.<br />
<br />
Any of the following items will be approved, regardless of frequency:<br />
<br />
* Any release or initial beta of a major release<br />
* Creation of any new user group, regional group, or web site<br />
* Critical security patch announcements<br />
* Substantial new articles or documentation<br />
* Infrequent calls for assistance/participation<br />
<br />
Other types of news, such as changes in leadership, will not be approved.<br />
<br />
=== Proprietary & External OSS Project News ===<br />
<br />
This includes all news from companies whose products contain, support or are based on PostgreSQL, and OSS projects which support PostgreSQL as one of several database options.<br />
<br />
The following types of news will be approved:<br />
<br />
* Brand new products/projects/services which support or center around PostgreSQL<br />
* Newly released books about PostgreSQL or with substantial (20% or more) PostgreSQL content.<br />
* First support of PostgreSQL in existing products<br />
* Major version releases (not more than once per quarter)<br />
* Critical security updates, if thought to affect many PostgreSQL community members<br />
<br />
Other types of announcements, including minor releases, pricing changes, leadership changes, 3rd-party news coverage, partnerships, and mergers & acquisitions will be rejected.<br />
<br />
In addition, commercial entities who are not financial, in-kind or code contributors to the PostgreSQL project will be restricted to ''one news item of any kind per six-month period.''<br />
<br />
=== Procedure for Approving pgsql-announce ===<br />
<br />
Since pgsql-announce goes to over 30,000 addresses, we are cautious in what we approve to that list. In some cases, this may result in a delay of up to several days in approving announcements.<br />
<br />
# Check if it's spam and reject spam.<br />
# Check if there is anything else in the 'To' or 'CC' list besides -announce; if so, reject and ask for re-submission.<br />
# Read the announcement<br />
# Consider if the announcement meets this policy and is appropriate for announcement<br />
#* if necessary, check on pgsql-www list<br />
# Approve or Reject<br />
<br />
In any case where an approver has doubts about whether to approve an announcement or not, they should err on the side of caution.<br />
<br />
== Approving Events and Event-Related News (excluding training) ==<br />
<br />
Events must have significant PostgreSQL-related content in order to be listed.<br />
<br />
=== PostgreSQL Conferences & Events ===<br />
<br />
Any semi-annual or less frequent non-training event which is primarily about PostgreSQL or for PostgreSQL users will be entitled to be listed. Additionally, conferences which are primarily or entirely about PostgreSQL will be entitled to post news items at the following milestones, if they are each a week or more apart: <br />
<br />
* Call for Papers<br />
* Registration Opening, <br />
* Registration Closing, <br />
* Wrap-up.<br />
<br />
Routine monthly PostgreSQL User Group meetings will ''not'' be listed. First meetings of a new PUG can be listed, as well as infrequent major special events likely to be of interest outside of the PUG's normal area.<br />
<br />
=== Open Source & Database Conferences & Events ===<br />
<br />
Open source conferences, and database conferences, which are not primarily about PostgreSQL but have significant PostgreSQL content, such as several sessions and a booth, may be listed in the Events. Additionally, the Call For Papers for these events may be accepted as News.<br />
<br />
More routine events, such as monthly local meetings or mini-conferences, will not be listed. Conferences must have significant PostgreSQL content to be worth listing, with decisions on relative significance to be made by the WWW team.<br />
<br />
== Training Events ==<br />
<br />
PostgreSQL Training may be listed from any company, under the following conditions:<br />
<br />
* Each listing must include:<br />
** Specific locations and dates for that specific training<br />
** Link to online training registration<br />
** One or more sentence description of the contents of that specific training<br />
<br />
All descriptive text should be purely informative and not include strong marketing copy or special offers unrelated to the training. The vendors website should list PostgreSQL training information, including an online schedule of upcoming trainings.<br />
<br />
In the event that any training company submits more than 4 training events to be held in any given quarter, site admins may (at their discretion) deny posting events to that company.<br />
<br />
== Rejection Notices ==<br />
<br />
In cases where the submitter appears to have gone to some effort to submit a relevant news item or event, but doesn't understand our policies, we should send them a rejection e-mail linking to this page and explaining what was wrong with their submission. This certainly goes for any of the major project sponsors.<br />
<br />
If the submission looks like a 30-second cut-and-paste job, or something else sloppy and quick, or is a submission by someone who has had multiple submissions rejected in the past for the same reason, don't bother sending a response. We get too much spam for that.<br />
<br />
Any company which has had submissions repeatedly rejected for the same reasons, and does not correct their errors when notified, risks having their community account suspended and their ability to submit news and events blocked.<br />
<br />
[[Category:Policies]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2015ClusterSummit&diff=24930PgCon2015ClusterSummit2015-06-11T08:11:49Z<p>Ishii: /* Pgpool-II: toward next major version 3.5 */</p>
<hr />
<div>=pgCon 2015 Cluster Hacker Summit=<br />
<br />
This year's Cluster Hacker Summit will be part of the [[PgCon_2015_Developer_Unconference]]. As such, this page will be used to coordinate sessions to propose for the Unconference, and eventually to list an agenda for the Clustering Track.<br />
<br />
The Cluster Summit covers both general PostgreSQL clustering, as well as PostgresXC development.<br />
<br />
As it is part of the Developer Unconference, Clustering sessions will take place starting in the afternoon of Tuesday, June 16 through 5pm on Wednesday, June 17. If you are participating, and will not be able to make it on Tuesday, please note that in your attendance comments.<br />
<br />
== Attendee RSVPs ==<br />
<br />
* Josh Berkus (both days)<br />
* Koichi Suzuki<br />
* Tatsuo Ishii<br />
* Yugo Nagata<br />
* Steve Singer (arrive tuesday mid-afternoon)<br />
* Jan Wieck (arrive tuesday evening)<br />
* Shigeru Hanada<br />
* Ahsan Hadi<br />
* Ashutosh Bapat<br />
* Bruce Momjian<br />
* Etsuro Fujita<br />
* Tetsuo Sakata<br />
* Amit Langote<br />
* Kyotaro Horiguchi<br />
* Ozgun Erdogan (Wednesday)<br />
* Marco Slot (Wednesday)<br />
<br />
== Suggested Sessions ==<br />
<br />
For each session below please provide a title and a moderator/leader/speaker for the session. <br />
<br />
=== Pgpool-II: toward next major version 3.5 ===<br />
<br />
Firstly we report the project progress since last year's Cluster Summit: introducing pgpool-II 3.4. Then we explain the current status of pgpool-II 3.5 which is under development.<br />
<br />
Session Leader: Tatsuo Ishii<br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====<br />
<br />
=== FDW Enhancements ===<br />
<br />
Session Leader: Shigeru Hanada and Etsuro Fujita<br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====<br />
<br />
=== Horizontal Scalability and Sharding ===<br />
<br />
Session Leaders: Ahsan Hadi, Ashutosh Bapat <br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====<br />
<br />
=== Slony ===<br />
<br />
What is the future for Slony development? Are users interested in a new Slony based on Logical Decoding? Who's going to work on this?<br />
<br />
Session Leaders: Steve Singer, Chris Browne, Jan Wieck<br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====<br />
<br />
=== pg_shard v2.0 and Lessons Learned from NoSQL Databases ===<br />
<br />
Session Leaders: Ozgun Erdogan, Marco Slot<br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2015ClusterSummit&diff=24929PgCon2015ClusterSummit2015-06-11T08:10:49Z<p>Ishii: /* Pgpool-II: toward next major version 3.5 */</p>
<hr />
<div>=pgCon 2015 Cluster Hacker Summit=<br />
<br />
This year's Cluster Hacker Summit will be part of the [[PgCon_2015_Developer_Unconference]]. As such, this page will be used to coordinate sessions to propose for the Unconference, and eventually to list an agenda for the Clustering Track.<br />
<br />
The Cluster Summit covers both general PostgreSQL clustering, as well as PostgresXC development.<br />
<br />
As it is part of the Developer Unconference, Clustering sessions will take place starting in the afternoon of Tuesday, June 16 through 5pm on Wednesday, June 17. If you are participating, and will not be able to make it on Tuesday, please note that in your attendance comments.<br />
<br />
== Attendee RSVPs ==<br />
<br />
* Josh Berkus (both days)<br />
* Koichi Suzuki<br />
* Tatsuo Ishii<br />
* Yugo Nagata<br />
* Steve Singer (arrive tuesday mid-afternoon)<br />
* Jan Wieck (arrive tuesday evening)<br />
* Shigeru Hanada<br />
* Ahsan Hadi<br />
* Ashutosh Bapat<br />
* Bruce Momjian<br />
* Etsuro Fujita<br />
* Tetsuo Sakata<br />
* Amit Langote<br />
* Kyotaro Horiguchi<br />
* Ozgun Erdogan (Wednesday)<br />
* Marco Slot (Wednesday)<br />
<br />
== Suggested Sessions ==<br />
<br />
For each session below please provide a title and a moderator/leader/speaker for the session. <br />
<br />
=== Pgpool-II: toward next major version 3.5 ===<br />
<br />
Firstly report the project progress since last year's Cluster Summit: introducing pgpool-II 3.4. Then explain the current status of pgpool-II 3.5 under development.<br />
<br />
Session Leader: Tatsuo Ishii<br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====<br />
<br />
=== FDW Enhancements ===<br />
<br />
Session Leader: Shigeru Hanada and Etsuro Fujita<br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====<br />
<br />
=== Horizontal Scalability and Sharding ===<br />
<br />
Session Leaders: Ahsan Hadi, Ashutosh Bapat <br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====<br />
<br />
=== Slony ===<br />
<br />
What is the future for Slony development? Are users interested in a new Slony based on Logical Decoding? Who's going to work on this?<br />
<br />
Session Leaders: Steve Singer, Chris Browne, Jan Wieck<br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====<br />
<br />
=== pg_shard v2.0 and Lessons Learned from NoSQL Databases ===<br />
<br />
Session Leaders: Ozgun Erdogan, Marco Slot<br />
<br />
==== Attendees ====<br />
<br />
==== Meeting Notes ====</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2015ClusterSummit&diff=24675PgCon2015ClusterSummit2015-05-14T00:10:26Z<p>Ishii: </p>
<hr />
<div>=pgCon 2015 Cluster Hacker Summit=<br />
<br />
This year's Cluster Hacker Summit will be part of the [[PgCon_2015_Developer_Unconference]]. As such, this page will be used to coordinate sessions to propose for the Unconference, and eventually to list an agenda for the Clustering Track.<br />
<br />
The Cluster Summit covers both general PostgreSQL clustering, as well as PostgresXC development.<br />
<br />
As it is part of the Developer Unconference, Clustering sessions will take place starting in the afternoon of Tuesday, June 16 through 5pm on Wednesday, June 17. If you are participating, and will not be able to make it on Tuesday, please note that in your attendance comments.<br />
<br />
== Attendee RSVPs ==<br />
<br />
* Josh Berkus (both days)<br />
* Koichi Suzuki<br />
* Tatsuo Ishii<br />
* Yugo Nagata<br />
<br />
<br />
== Suggested Sessions ==<br />
<br />
For each session below please provide a title and a moderator/leader/speaker for the session. <br />
<br />
* PostgresXC Team Meeting: who?<br />
* BDR and Logical Decoding: Andres/Simon/?<br />
* Pgpool-II toward next major version 3.5: Tatsuo</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2015ClusterSummit&diff=24674PgCon2015ClusterSummit2015-05-14T00:09:50Z<p>Ishii: </p>
<hr />
<div>=pgCon 2015 Cluster Hacker Summit=<br />
<br />
This year's Cluster Hacker Summit will be part of the [[PgCon_2015_Developer_Unconference]]. As such, this page will be used to coordinate sessions to propose for the Unconference, and eventually to list an agenda for the Clustering Track.<br />
<br />
The Cluster Summit covers both general PostgreSQL clustering, as well as PostgresXC development.<br />
<br />
As it is part of the Developer Unconference, Clustering sessions will take place starting in the afternoon of Tuesday, June 16 through 5pm on Wednesday, June 17. If you are participating, and will not be able to make it on Tuesday, please note that in your attendance comments.<br />
<br />
== Attendee RSVPs ==<br />
<br />
* Josh Berkus (both days)<br />
* Koichi Suzuki<br />
* Tatsuo Ishii<br />
* Yugo Nagata<br />
<br />
<br />
== Suggested Sessions ==<br />
<br />
For each session below please provide a title and a moderator/leader/speaker for the session. <br />
<br />
* PostgresXC Team Meeting: who?<br />
* BDR and Logical Decoding: Andres/Simon/?<br />
* Pgpool-II toward next major version 3.5</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2014ClusterSummit&diff=22466PgCon2014ClusterSummit2014-05-27T00:51:47Z<p>Ishii: /* Projects */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2014 =<br />
<br />
Tuesday, May 20th<br />
<br />
2PM to 6PM<br />
<br />
Preceded by [[Pgcon2014PostgresXCmeeting|PostgresXC Meeting]] 9AM to 1PM<br />
<br />
Followed by the PostgresXC Pizza Demo at 7pm.<br />
<br />
University of Ottawa<br />
<br />
Room: University Center Room 205 <br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 1:00PM to 2:00PM ====<br />
<br />
Lunch supplied for anyone coming for the whole day (PostgresXC + Clustering)<br />
<br />
Due to a sudden increase in numbers, '''only''' the 15 participants staying for the full day (both XC and Clustering) will be given lunch. People attending the clustering summit only should eat their own lunch, and arrive at 2pm.<br />
<br />
==== 1:30PM to 2:00PM ====<br />
<br />
Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 2:00PM to 2:45PM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates (please volunteer below if you can give an update):<br />
<br />
* pgPool II: Tatsuo Ishii<br />
* Postgres-XC: Koichi Suzuki<br />
* Built-in Replication: ????<br />
* Postgres-XL: Mason Sharp<br />
* Stado: Mason?<br />
* Bucardo: ???<br />
* LSR & BDR: ???<br />
* Slony: Chris Browne/Jan Wieck<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 16.<br />
<br />
==== 2:45PM to 3:15PM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* Logical Replication (not present)<br />
* Exportable Parser/Planner: no activity for year. Some discussion.<br />
* FDW and SQL/MED<br />
** Function scan push-down<br />
** Node partitioning with constraint exclusion<br />
<br />
==== 3:15PM to 3:45PM ====<br />
<br />
Break<br />
<br />
==== 3:45PM to 4:30PM ====<br />
<br />
Summary of Clustering API projects, continued.<br />
<br />
==== 4:30PM to 6:00PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Tatsuo Ishii (SRA OSS)<br />
# Haruka Takatsuka (SRA OSS)<br />
# Yugo Nagata (SRA OSS)<br />
# Mason Sharp<br />
# Bruce Momjian<br />
# Chris Browne<br />
# David Wheeler<br />
# Moshe Jacobson (Nead Werx)<br />
# Chris Autry (Nead Werx)<br />
# Joe Conway<br />
# Steve Singer<br />
# Jan Wieck<br />
# Jim Mlodgenski<br />
# Vik Fearing<br />
# Marc Linster (EDB)<br />
# Ahsan Hadi (EDB)<br />
# Zahid Iqbal (EDB)<br />
# Etsuro Fujita (NTT OSS Center)<br />
# Amit Kapila<br />
# Krzysztof Nienartowicz (ESA)<br />
# Hitoshi Hemmi (NTT OSS Center)<br />
# Álvaro Hernández<br />
# Motoyuki Kawaba<br />
# Haribabu Kommi<br />
# Yurie Enomoto<br />
<br />
===RSVPS to the Cluster Summit are Closed===<br />
<br />
== Meeting Notes ==<br />
<br />
Introductions<br />
<br />
We did not capture names of attendees. Simon Riggs and Andres Freund were not able to make the meeting.<br />
<br />
=== Projects ===<br />
* pgPool II: Yugo Nagata<br />
** 3.4 improvements, adds PG exception and memory manager<br />
<br />
* pgPool II: Ahsan Hadi<br />
** performance testing<br />
** scaling improvements for 1-5 replicas and 75% read workload<br />
<br />
* Postgres-XC: Koichi Suzuki<br />
** release 1.2 items<br />
** more openness for volunteers, committers, roadmap<br />
<br />
* Stado: Mason Sharp<br />
** nothing big to report<br />
** move from Launchpad to Sourceforge<br />
<br />
* Postgres-XL: Mason Sharp<br />
** optimizations over Postgres XC<br />
** focus on stability, performance, and openness<br />
<br />
* Slony: Chris Browne/Jan Wieck<br />
** Slony top added<br />
** better tooling<br />
** add logical replication support to avoid trigger overhead, have prototype<br />
<br />
* LSR & BDR: Mark Sloan<br />
** Intel funding<br />
** still work for 9.5, e.g. DDL<br />
<br />
=== Clustering API Projects ===<br />
* Passing Query parse trees to other nodes<br />
** no one volunteered to work on it<br />
<br />
NTT is working on some features for FDWs:<br />
* FDW<br />
** add syntax to allow FDW partitions/inheritance<br />
*** this was intended for 9.4, but got pushed back<br />
** support constraint_exclusion across shards<br />
* FDW pushdowns<br />
** JOINS<br />
** Aggregates<br />
** Scans<br />
** Contributing XC/XL code to mainstream PostgreSQL.<br />
<br />
=== New Projects ===<br />
<br />
The meeting discussed a number of possible new projects. The below lack anyone qualified to work on them:<br />
<br />
* Async FDW execution<br />
* Parallel Query?<br />
* GTM<br />
** Hooks for the GTM?<br />
** Two-node sync?<br />
** WAL barrier for shards<br />
*** Problem with transaction commit order visibility differences between master/slave<br />
* Partition primary keys/foreign keys<br />
** either using the partition index, or not<br />
** other multi-table constraints<br />
<br />
There was some discussion of the new BDR features, hampered by the absence of the BDR team. This included:<br />
* Adding more simple BDR formats to core/contrib<br />
* Adding a core/contrib LSR apply plugin, maybe based on Slony copy.<br />
<br />
We discused the need for multiple host connections for HA configurations. For example, if you have a pgpool and a failover pgpool, you'd like to be able to connect to both. Jim Mlodjenski committed to working on a multihost connection change for libpq, which would look like:<br />
<br />
database=postgres host=10.0.0.1,10.0.0.2,10.0.0.3 port=5432<br />
<br />
=== PostgresXC Pizza Demo ===<br />
<br />
Koichi Suzuki demonstrated setting up and managing PostgresXC with the new pgxc_ctl. This program, despite its name, is a full command shell for a PostgresXC cluster, supporting node changes, sharding commands, and status checks.<br />
<br />
<br />
[[Category:PostgreSQL Events]]<br />
[[Category:PGCon2014]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2014ClusterSummit&diff=22355PgCon2014ClusterSummit2014-05-14T05:53:44Z<p>Ishii: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2014 =<br />
<br />
Tuesday, May 20th<br />
<br />
2PM to 6PM<br />
<br />
Preceded by [[Pgcon2014PostgresXCmeeting|PostgresXC Meeting]] 9AM to 1PM<br />
<br />
Followed by the PostgresXC Pizza Demo at 7pm.<br />
<br />
University of Ottawa<br />
<br />
Room: Desmarais 10161 <br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 1:00PM to 2:00PM ====<br />
<br />
Box Lunches supplied for anyone coming for the whole day (PostgresXC + Clustering)<br />
<br />
==== 1:30PM to 2:00PM ====<br />
<br />
Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 2:00PM to 2:45PM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates (please volunteer below if you can give an update):<br />
<br />
* pgPool II: <br />
* Postgres-XC: <br />
* Built-in Replication: <br />
* Stado:<br />
* Bucardo: <br />
* LSR & BDR:<br />
* Slony<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 16.<br />
<br />
==== 2:45PM to 3:15PM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* '''Serializable & Predicate locks on MM replication''':<br />
* '''Event Triggers''':<br />
* '''Exportable Snapshots''':<br />
* '''Planner/Parser Hooks''': <br />
* '''Logical Changeset Extraction''':<br />
* '''Foreign Data Wrappers''':<br />
<br />
==== 3:15PM to 3:45PM ====<br />
<br />
Break<br />
<br />
==== 3:45PM to 4:30PM ====<br />
<br />
Summary of Clustering API projects, continued.<br />
<br />
==== 4:30PM to 6:00PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Tatsuo Ishii (SRA OSS)<br />
# Haruka Takatsuka (SRA OSS)<br />
# Yugo Nagata (SRA OSS)<br />
# Mason Sharp<br />
# Bruce Momjian<br />
# Chris Browne<br />
# David Wheeler<br />
# Moshe Jacobson (Nead Werx)<br />
# Chris Autry (Nead Werx)<br />
# Joe Conway<br />
# Ioana Danes (Canadian Bank Note)<br />
# Arthur Karton (Canadian Bank Note)<br />
# Steve Singer<br />
# Jan Wieck<br />
# Jim Mlodgenski<br />
# Vik Fearing<br />
# Marc Linster (EDB)<br />
# Ahsan Hadi (EDB)<br />
# Zahid Iqbal (EDB)<br />
# Etsuro Fujita (NTT OSS Center)<br />
[[Category:PostgreSQL Events]]<br />
[[Category:PGCon2014]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2014ClusterSummit&diff=22352PgCon2014ClusterSummit2014-05-13T22:17:25Z<p>Ishii: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2014 =<br />
<br />
Tuesday, May 20th<br />
<br />
2PM to 6PM<br />
<br />
Preceded by [[Pgcon2014PostgresXCmeeting|PostgresXC Meeting]] 9AM to 1PM<br />
<br />
Followed by the PostgresXC Pizza Demo at 7pm.<br />
<br />
University of Ottawa<br />
<br />
Room: Desmarais 10161 <br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 1:00PM to 2:00PM ====<br />
<br />
Box Lunches supplied for anyone coming for the whole day (PostgresXC + Clustering)<br />
<br />
==== 1:30PM to 2:00PM ====<br />
<br />
Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 2:00PM to 2:45PM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates (please volunteer below if you can give an update):<br />
<br />
* pgPool II: <br />
* Postgres-XC: <br />
* Built-in Replication: <br />
* Stado:<br />
* Bucardo: <br />
* LSR & BDR:<br />
* Slony<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 16.<br />
<br />
==== 2:45PM to 3:15PM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* '''Serializable & Predicate locks on MM replication''':<br />
* '''Event Triggers''':<br />
* '''Exportable Snapshots''':<br />
* '''Planner/Parser Hooks''': <br />
* '''Logical Changeset Extraction''':<br />
<br />
==== 3:15PM to 3:45PM ====<br />
<br />
Break<br />
<br />
==== 3:45PM to 4:30PM ====<br />
<br />
Summary of Clustering API projects, continued.<br />
<br />
==== 4:30PM to 6:00PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Tatsuo Ishii (SRA OSS)<br />
# Haruka Takatsuka (SRA OSS)<br />
# Yugo Nagata (SRA OSS)<br />
# Mason Sharp<br />
# Bruce Momjian<br />
# Chris Browne<br />
# David Wheeler<br />
# Moshe Jacobson (Nead Werx)<br />
# Chris Autry (Nead Werx)<br />
# Joe Conway<br />
# Ioana Danes (Canadian Bank Note)<br />
# Arthur Karton (Canadian Bank Note)<br />
# Steve Singer<br />
# Jan Wieck<br />
# Jim Mlodgenski<br />
# Vik Fearing<br />
# Marc Linster<br />
# Ahsan Hadi<br />
# Zahid Iqbal<br />
[[Category:PostgreSQL Events]]<br />
[[Category:PGCon2014]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2014ClusterSummit&diff=22325PgCon2014ClusterSummit2014-05-13T01:28:37Z<p>Ishii: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2014 =<br />
<br />
Tuesday, May 20th<br />
<br />
2PM to 6PM<br />
<br />
Preceded by [[Pgcon2014PostgresXCmeeting|PostgresXC Meeting]] 9AM to 1PM<br />
<br />
Followed by the PostgresXC Pizza Demo at 7pm.<br />
<br />
University of Ottawa<br />
<br />
Room: Desmarais 10161 <br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 1:00PM to 2:00PM ====<br />
<br />
Box Lunches supplied for anyone coming for the whole day (PostgresXC + Clustering)<br />
<br />
==== 1:30PM to 2:00PM ====<br />
<br />
Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 2:00PM to 2:45PM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates (please volunteer below if you can give an update):<br />
<br />
* pgPool II: <br />
* Postgres-XC: <br />
* Built-in Replication: <br />
* Stado:<br />
* Bucardo: <br />
* LSR & BDR:<br />
* Slony<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 16.<br />
<br />
==== 2:45PM to 3:15PM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* '''Serializable & Predicate locks on MM replication''':<br />
* '''Event Triggers''':<br />
* '''Exportable Snapshots''':<br />
* '''Planner/Parser Hooks''': <br />
* '''Logical Changeset Extraction''':<br />
<br />
==== 3:15PM to 3:45PM ====<br />
<br />
Break<br />
<br />
==== 3:45PM to 4:30PM ====<br />
<br />
Summary of Clustering API projects, continued.<br />
<br />
==== 4:30PM to 6:00PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Tatsuo Ishii (SRA OSS)<br />
# Haruka Takatsuka (SRA OSS)<br />
# Yugo Nagata (SRA OSS)<br />
# Mason Sharp<br />
# Bruce Momjian<br />
# Chris Browne<br />
# David Wheeler<br />
# Moshe Jacobson (Nead Werx)<br />
# Chris Autry (Nead Werx)<br />
# Joe Conway<br />
# Ioana Danes (Canadian Bank Note)<br />
# Arthur Karton (Canadian Bank Note)<br />
# Steve Singer<br />
# Jan Wieck<br />
# Jim Mlodgenski<br />
# Vik Fearing<br />
# Marc Linster<br />
<br />
[[Category:PostgreSQL Events]]<br />
[[Category:PGCon2014]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2014ClusterSummit&diff=22121PgCon2014ClusterSummit2014-04-16T02:58:25Z<p>Ishii: /* Clustering and Replication Developers Summit pgCon 2014 */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2014 =<br />
<br />
Tuesday, May 20th<br />
<br />
2PM to 6PM<br />
<br />
Preceded by [[Pgcon2014PostgresXCmeeting|PostgresXC Meeting]] 9AM to 1PM<br />
<br />
University of Ottawa<br />
<br />
Room: TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 1:00PM to 2:00PM ====<br />
<br />
Box Lunches supplied for anyone coming for the whole day (PostgresXC + Clustering)<br />
<br />
==== 1:30PM to 2:00PM ====<br />
<br />
Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 2:00PM to 2:45PM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates (please volunteer below if you can give an update):<br />
<br />
* pgPoolII: <br />
* Postgres-XC: <br />
* Built-in Replication: <br />
* Stado:<br />
* Bucardo: <br />
* LSR & BDR:<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 16.<br />
<br />
==== 2:45PM to 3:15PM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* '''Serializable & Predicate locks on MM replication''':<br />
* '''Event Triggers''':<br />
* '''Exportable Snapshots''':<br />
* '''Planner/Parser Hooks''': <br />
* '''Logical Changeset Extraction''':<br />
<br />
==== 3:15PM to 3:45PM ====<br />
<br />
Break<br />
<br />
==== 3:45PM to 4:30PM ====<br />
<br />
Summary of Clustering API projects, continued.<br />
<br />
==== 4:30PM to 6:00PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Tatsuo Ishii (SRA OSS)<br />
# Haruka Takatsuka (SRA OSS)<br />
# Yugo Nagata (SRA OSS)<br />
# Mason Sharp<br />
# Bruce Momjian<br />
# Chris Browne<br />
# David Wheeler<br />
# Moshe Jacobson (Nead Werx)<br />
# Chris Autry (Nead Werx)<br />
# Joe Conway<br />
# Ioana Danes (Canadian Bank Note)<br />
# Steve Singer<br />
[[Category:PostgreSQL Events]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2014ClusterSummit&diff=21923PgCon2014ClusterSummit2014-03-07T02:11:36Z<p>Ishii: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2013 =<br />
<br />
Tuesday, May 20th<br />
<br />
2PM to 6PM<br />
<br />
Preceded by [[Pgcon2014PostgresXCmeeting|PostgresXC Meeting]] 9AM to 1PM<br />
<br />
University of Ottawa<br />
<br />
Room: TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 1:00PM to 2:00PM ====<br />
<br />
Box Lunches supplied for anyone coming for the whole day (PostgresXC + Clustering)<br />
<br />
==== 1:30PM to 2:00PM ====<br />
<br />
Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 2:00PM to 2:45PM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates (please volunteer below if you can give an update):<br />
<br />
* pgPoolII: <br />
* Postgres-XC: <br />
* Built-in Replication: <br />
* Stado:<br />
* Bucardo: <br />
* LSR & BDR:<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 16.<br />
<br />
==== 2:45PM to 3:15PM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* '''Serializable & Predicate locks on MM replication''':<br />
* '''Event Triggers''':<br />
* '''Exportable Snapshots''':<br />
* '''Planner/Parser Hooks''': <br />
* '''Logical Changeset Extraction''':<br />
<br />
==== 3:15PM to 3:45PM ====<br />
<br />
Break<br />
<br />
==== 3:45PM to 4:30PM ====<br />
<br />
Summary of Clustering API projects, continued.<br />
<br />
==== 4:30PM to 6:00PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Tatsuo Ishii (and 2 others from SRA OSS)<br />
<br />
[[Category:PostgreSQL Events]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2014ClusterSummit&diff=21922PgCon2014ClusterSummit2014-03-07T02:11:17Z<p>Ishii: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2013 =<br />
<br />
Tuesday, May 20th<br />
<br />
2PM to 6PM<br />
<br />
Preceded by [[Pgcon2014PostgresXCmeeting|PostgresXC Meeting]] 9AM to 1PM<br />
<br />
University of Ottawa<br />
<br />
Room: TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 1:00PM to 2:00PM ====<br />
<br />
Box Lunches supplied for anyone coming for the whole day (PostgresXC + Clustering)<br />
<br />
==== 1:30PM to 2:00PM ====<br />
<br />
Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 2:00PM to 2:45PM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates (please volunteer below if you can give an update):<br />
<br />
* pgPoolII: <br />
* Postgres-XC: <br />
* Built-in Replication: <br />
* Stado:<br />
* Bucardo: <br />
* LSR & BDR:<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 16.<br />
<br />
==== 2:45PM to 3:15PM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* '''Serializable & Predicate locks on MM replication''':<br />
* '''Event Triggers''':<br />
* '''Exportable Snapshots''':<br />
* '''Planner/Parser Hooks''': <br />
* '''Logical Changeset Extraction''':<br />
<br />
==== 3:15PM to 3:45PM ====<br />
<br />
Break<br />
<br />
==== 3:45PM to 4:30PM ====<br />
<br />
Summary of Clustering API projects, continued.<br />
<br />
==== 4:30PM to 6:00PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Tatsuo Ishii (and 2 others)<br />
<br />
[[Category:PostgreSQL Events]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Pgpool-II&diff=20968Pgpool-II2013-10-11T22:08:31Z<p>Ishii: Update English mailing list URL and fix typo</p>
<hr />
<div>== Project Overview ==<br />
<br />
'''pgpool-II''' is a middleware that works between PostgreSQL servers and a PostgreSQL database client. It provides the following features.<br />
<br />
* Connection Pooling: pgpool-II saves connections to the PostgreSQL servers, and reuse them whenever a new connection with the same properties (i.e. username, database, protocol version) comes in. It reduces connection overhead, and improves system's overall throughput.<br />
<br />
* Replication: pgpool-II can manage multiple PostgreSQL servers. Using the replication function enables creating a realtime backup on 2 or more physical disks, so that the service can continue without stopping servers in case of a disk failure.<br />
<br />
* Load Balance: If a database is replicated, executing a SELECT query on any server will return the same result. pgpool-II takes an advantage of the replication feature to reduce the load on each PostgreSQL server by distributing SELECT queries among multiple servers, improving system's overall throughput. At best, performance improves proportionally to the number of PostgreSQL servers. Load balance works best in a situation where there are a lot of users executing many queries at the same time.<br />
<br />
* Limiting Exceeding Connections: There is a limit on the maximum number of concurrent connections with PostgreSQL, and connections are rejected after this many connections. Setting the maximum number of connections, however, increases resource consumption and affect system performance. pgpool-II also has a limit on the maximum number of connections, but extra connections will be queued instead of returning an error immediately.<br />
<br />
* Parallel Query: Using the parallel query function, data can be divided among the multiple servers, so that a query can be executed on all the servers concurrently to reduce the overall execution time. Parallel query works the best when searching large-scale data.<br />
<br />
== Project Status ==<br />
<br />
In production status. There are number of commercial systems using pgpool-II.<br />
<br />
== Project Contacts ==<br />
<br />
* [http://www.pgpool.net/mediawiki/index.php/Main_Page Development page]<br />
* [http://pgpool.sraoss.jp/ Japanese page]<br />
* [http://www.pgpool.net/mailman/listinfo/pgpool-general Mailing lists(English)]<br />
* [http://www.sraoss.jp/mailman/listinfo/pgpool-general-jp Mailing lists(Japanese)]<br />
<br />
== General Information ==<br />
<br />
* Scalability: Yes (up to 128 DB nodes)<br />
* Read Scaling: Yes<br />
* Write Scaling: No (possible to have up to 128 DB nodes, but performance is 60-70% of plain PostgreSQL)<br />
* Synchronous replication: Yes<br />
* Triggers/procedures: Yes<br />
* Parallel Query: Yes<br />
* Failover/HA: Yes<br />
* Online Provisioning: Yes<br />
* PostgreSQL Upgrades: No<br />
* Detached Node/WAN: No<br />
* PostgreSQL Core Modifications Required: No<br />
* Programming Languages: C<br />
<br />
== Clustering Model ==<br />
<br />
Pgpool-II is a query based replication system.<br />
<br />
== Use Case ==<br />
<br />
* There are three modes: replication(R), master/slave(M) and parallel query(P)<br />
* Following functionalities available in each mode<br />
** Connection pooling (R,M,P)<br />
** Automatic failover (R,M)<br />
** Online recovery (R, M when used with streaming replication)<br />
* Master/slave mode can be used with Slony-I and Streaming replication<br />
* Dedicated GUI tool is available (pgpoolAdmin)<br />
<br />
== Drawbacks ==<br />
<br />
* Cannot correctly handle functions with side effects in SELECT<br />
** nextval() can be handled correctly<br />
** pgpool-II 3.0 removes this drawbacks by recognizing such functions in SELECT <br />
* Need table locks when inserting tables having SERIAL data types<br />
** pgpool-II 3.0 automatically issues row lock rather than table locks<br />
<br />
== Future plans ==<br />
<br />
* Allow to replicate SERIAL/sequence in more reliable way<br />
<br />
== Project Sponsors ==<br />
<br />
* Work sponsored by [http://www.sraoss.co.jp/index_en.php SRA OSS, Inc. Japan]<br />
<br />
== Others ==<br />
<br />
* Commercial support is avilable from [http://www.sraoss.co.jp/index_en.php SRA OSS, Inc. Japan]<br />
<br />
<br />
[[Category:middleware]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PostgreSQL_derived_databases&diff=20934PostgreSQL derived databases2013-10-10T06:27:12Z<p>Ishii: </p>
<hr />
<div>A list of PostgreSQL derived forks and rebranded distributions in alphabetical order.<br />
<br />
{| align="center" border="1" cellspacing="0" {{Prettytable}}<br />
|-<br />
!{{Hl2}} |Name<br />
!{{Hl2}} |Vendor<br />
!{{Hl2}} |License<br />
!{{Hl2}} |Availability<br />
!{{Hl2}} |Notes<br />
|-<br />
|Aster Data<br />
|Teradata<br />
|Proprietary<br />
|2005-....<br />
|PostgreSQL + Map/Reduce<br />
|-<br />
|Bizgres<br />
|Greenplum<br />
|BSD<br />
|2005-2007<br />
|PostgreSQL + BI features<br />
|-<br />
|Cybercluster<br />
|Cybertec<br />
|BSD<br />
|2007-2010<br />
|Clustering (pgCluster fork)<br />
|-<br />
|Greenplum Database <br />
|Greenplum<br />
|proprietary<br />
|2005-....<br />
|PostgreSQL + BI features (formerly known as "Bizgres MPP")<br />
|-<br />
|EnterpriseDB Advanced Server<br />
|EnterpriseDB<br />
|proprietary<br />
|2008-....<br />
|PostgreSQL + Oracle compatibility<br />
|-<br />
|EnterpriseDB Postgres Plus<br />
|EnterpriseDB<br />
|open-source (varies)<br />
|2008-....<br />
|PostgreSQL re-distribution<br />
|-<br />
|GridSQL<br />
|EnterpriseDB<br />
|GPL<br />
|2008-2010<br />
|PostgreSQL + BI Features (formerly ExtenDB)<br />
|-<br />
|Fujitsu Supported PostgreSQL<br />
|Fujitsu<br />
|BSD ; and possibly proprietary extensions<br />
|2006-2007<br />
|Seem to have support both Community versions and ones with their own storage engine.<br />
|-<br />
|Great Bridge PostgreSQL<br />
|Great Bridge LLC<br />
|BSD<br />
|1999-2001<br />
|PostgreSQL re-distribution<br />
|-<br />
|HadoopDB<br />
|Yale University<br />
|Apache License V2.0<br />
|2009-....<br />
|PostgreSQL + shared-nothing cluster + Hadoop [http://db.cs.yale.edu/hadoopdb/hadoopdb.html]<br />
|-<br />
|Mammoth<br />
|Command Prompt<br />
|BSD<br />
|2005-2010<br />
|PostgreSQL + contrib modules<br />
|-<br />
|Netezza<br />
|IBM<br />
|proprietary<br />
|2002-....<br />
|Appliance based on PostgreSQL SQL engine<br />
|-<br />
|NuSphere UltraSQL<br />
|NuSphere<br />
|proprietary<br />
|2002-2003<br />
|Native Win32 port of PostgreSQL<br />
|-<br />
|ParAccel<br />
|Actian<br />
|proprietary<br />
|2005-....<br />
|PostgreSQL + BI features<br />
|-<br />
|Pervasive PostgreSQL<br />
|Pervasive<br />
|BSD<br />
|2005-2006<br />
|PostgreSQL re-distribution<br />
|-<br />
|pgCluster<br />
|SRA<br />
|BSD<br />
|2002-2005<br />
|Clustering (Share Nothing)<br />
|-<br />
|pgCluster-II<br />
|SRA<br />
|BSD<br />
|2006-2007<br />
|Clustering (Shared Disk)<br />
|-<br />
|PostgresForest<br />
|NTT<br />
|BSD<br />
|2006-2010<br />
|Clustering <br />
|-<br />
|Postgres Plus<br />
|EnterpriseDB<br />
|OSS<br />
|2008-....<br />
|PostgreSQL + contrib + apps + drivers <br />
|-<br />
|Postgres Plus Advanced Server<br />
|EnterpriseDB<br />
|proprietary<br />
|2008-....<br />
|Postgres + Oracle compatibility + apps, formally EnterpriseDB AS<br />
|-<br />
|Postgres R<br />
|<br />
|BSD<br />
|2006-2010<br />
|Clustering<br />
|-<br />
|Postgres-XC<br />
|PGXCDG<br />
|BSD<br />
|2010-....<br />
|Clustering [http://postgresxc.wikia.com/wiki/Postgres-XC_Wiki]<br />
|-<br />
|PowerGres<br />
|SRA OSS<br />
|proprietary<br />
|2003-....<br />
|Native Win32 port of PostgreSQL and Linux RPM<br />
|-<br />
|PowerGres Plus<br />
|SRA OSS<br />
|proprietary<br />
|2003-....<br />
|PostgreSQL + custom storage engine, redundant WAL, encrypted database<br />
|-<br />
|PostgreSQL for Solaris 10<br />
|Sun<br />
|BSD<br />
|...<br />
|PostgreSQL re-distribution<br />
|-<br />
|RecDB<br />
|umn.edu<br />
|BSD<br />
|2013-....<br />
|Recommendation Engine [http://www-users.cs.umn.edu/~sarwat/RecDB/]<br />
|-<br />
|Red Hat Database<br />
|Red Hat<br />
|BSD<br />
|2002-2003<br />
|PostgreSQL re-distribution<br />
|-<br />
|Red Shift<br />
|Amazon<br />
|Private/Cloud-based <br />
|2013-....<br />
|Data Warehouse on AWS (based on ParACCEL)<br />
|-<br />
|TelegraphCQ<br />
|UC Berkeley<br />
|BSD<br />
|2000-2008<br />
|Data Stream oriented fork of PostgreSQL<br />
|-<br />
|TruCQ<br />
|Truviso<br />
|proprietary<br />
|2008-2012<br />
|Fork of TelegraphCQ<br />
|-<br />
|Vertica<br />
|HP<br />
|proprietary<br />
|2005-....<br />
| Column-oriented DataWarehouse (created by Stonebraker)<br />
|-<br />
|Yahoo! Everest<br />
|Yahoo!<br />
|private<br />
|2008-....<br />
|multi-peta-byte database / MPP [http://fr.scribd.com/doc/3159239/70-EverestPGCon-RT]<br />
|}<br />
<br />
== Related documents ==<br />
<br />
* https://github.com/rafaelma/postgresql-timeline<br />
* http://de.slideshare.net/pgconf/elephant-roads-a-tour-of-postgres-forks<br />
* https://github.com/daamien/artwork/tree/master/inkscape/PostgreSQL_timeline<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Derivative Products|!]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PgCon2013CanadaClusterSummit&diff=19502PgCon2013CanadaClusterSummit2013-05-02T04:48:46Z<p>Ishii: /* RSVP List */</p>
<hr />
<div>= Clustering and Replication Developers Summit pgCon 2013 = <br />
<br />
Tuesday, May 21st<br />
<br />
9:30AM to 2:30pm<br />
<br />
Followed by PostgresXC Summit 3pm to 6pm<br />
<br />
University of Ottawa<br />
<br />
Room TBD<br />
<br />
'''Sponsored by NTT Open Source'''<br />
<br />
=== Agenda ===<br />
<br />
==== 9AM to 9:30AM ====<br />
<br />
Seating and coffee. Please bring any last-minute agenda items to Josh Berkus at this time.<br />
<br />
==== 9:30AM to 10:15AM ====<br />
<br />
Introductions, and status reports from Replication/Clustering Projects:<br />
<br />
Status updates:<br />
<br />
* pgPoolII: Tatsuo Ishii<br />
* Postgres-XC: Koichi Suzuki<br />
* Built-in Replication: Simon Riggs<br />
* Stado: Mason Sharp<br />
<br />
If you are at the summit representing a specific replication or clustering tool, you should prepare a 1-3 minute summary of current progress and issues. If you want to use slides, please provide slides in PDF form to Josh Berkus by Friday, May 17.<br />
<br />
==== 10:15AM to 10:30 AM ====<br />
<br />
Break<br />
<br />
==== 10:30AM to 11:30AM ====<br />
<br />
Summary of Clustering API projects.<br />
<br />
Summit attendees who have been working on [[ClusterFeatures|core clustering features]] should give an update as to progress and current issues. Please present a 5-10 minute summary. Attendees may use their own laptops for slides, or give slides to Josh Berkus.<br />
<br />
Topics:<br />
<br />
* Event Triggers: Dimitri Fontaine<br />
* Exportable Snapshots:<br />
* Feed XID<br />
* Hooks in the planer<br />
<br />
==== 11:30AM to 12:30PM ====<br />
<br />
Discussion of priorities, progress and ideas for core clustering projects and APIs.<br />
<br />
Goal of this discussion is to modify the list of core clustering features and get commitments for hackers to work on specific features. Also, to supply discussion items for the following day's Developer Meeting<br />
<br />
==== 12:30PM to 1:30PM ====<br />
<br />
Lunch and follow-up discussion. Box lunches will be supplied.<br />
<br />
==== 1:30PM to 2:30PM ====<br />
<br />
Follow-up discussion. Consolidation of future clustering API goals and projects.<br />
<br />
=== RSVP List ===<br />
<br />
# Josh Berkus<br />
# Koichi Suzuki<br />
# Kevin Grittner<br />
# Jim Mlodgenski<br />
# Mason Sharp<br />
# Nikhil Sontakke<br />
# Steve Singer<br />
# Jan Wieck<br />
# David Wheeler<br />
# Ashutosh Bapat<br />
# Galy Lee<br />
# Fujii Masao<br />
# Dimitri Fontaine<br />
# Andres Freund<br />
# Christophe Pettus<br />
# Tatsuo Ishii<br />
<br />
= PostgresXC Day =<br />
<br />
=== 3pm to 6pm ===<br />
<br />
Same room as clustering summit.<br />
<br />
* Topics in Version 1.1<br />
* Roadmap toward version 1.2 and beyond<br />
* Development Issues<br />
* Experiences<br />
<br />
=== Extension on Wednesday and Saturday ===<br />
<br />
Informal open discussion on Postgres-XC feature and internal will be held at Koichi's hotel room on 22nd, Wednesday. Depending upon topics, similar discussion can be held on Saturday.<br />
<br />
=== RSVP List ===<br />
<br />
Please check if you can join. Add yourself in the list too.<br />
<br />
# Ahsan Hadi<br />
# Ashutosh Bapat<br />
# Hitoshi Hemmi<br />
# Koichi Suzuki<br />
# Tetsuo Sakata<br />
# Galy Lee<br />
# Mason Sharp<br />
# Jim Mlodgenski<br />
# Nikhil Sontakke<br />
# Josh Berkus<br />
# Christophe Pettus<br />
[[Category:PostgreSQL Events]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=PostgreSQL_Conference_Europe_Talks_2012&diff=18453PostgreSQL Conference Europe Talks 20122012-10-26T04:09:12Z<p>Ishii: /* Seine */</p>
<hr />
<div>= PostgreSQL Conference Europe 2012 Talks =<br />
<br />
== Talks: Wednesday 24th October, 2012 ==<br />
<br />
=== Bellevue ===<br />
<br />
=== Seine ===<br />
<br />
* [http://www.sraoss.co.jp/event_seminar/2012/20121024_pgpool-II_pgconfEU2012_sraoss.pdf Boosting Performance and Reliability by using pgpool-II (Tatsuo Ishii)]<br />
<br />
=== Thames ===<br />
<br />
* [[Media:Pgconfeu12-collectd%2Bpsql.pdf|Watch your Elephants -- Using collectd for PostgreSQL performance analysis]] ([http://tokkee.org/ Sebastian 'tokkee' Harl])<br />
* [[Media:Range-types.pdf|Range Types in PostgreSQL 9.2 - Your Life Will Never Be the Same (Jonathan S. Katz)]]<br />
<br />
=== Vltava ===<br />
* [[Media:Plpgsql internals.pdf| PL/pgSQL internals -- some details from PL/pgSQL environment]]<br />
* [[Media:Indexy.pdf| Indexy jsou grunt -- basic and enhanced using of indexes in PostgreSQL]]<br />
<br />
== Talks: Thursday 25th October, 2012 ==<br />
<br />
=== Bellevue ===<br />
<br />
=== Seine ===<br />
<br />
=== Thames ===<br />
<br />
* [[Media:Universal_Data_Access_with_SQL_MED.pdf|Universal Data Access with SQL/MED (David Fetter)]]<br />
* [https://github.com/Oslandia/presentations/tree/master/pgconf_eu_2012 Topology and network analysis with PostgreSQL and PostGIS (Vincent Picavet)]<br />
* [https://github.com/Oslandia/presentations/tree/master/pgconf_eu_2012 PostGIS 2.0 and beyond (Vincent Picavet)]<br />
<br />
<br />
=== Vltava ===<br />
* [[Media: Marketing-postgres.pdf|Marketing PostgreSQL (Jonathan S. Katz)]]<br />
* [[Media: Pgconf2012_sprocwrapper.pdf|Java Stored Procedure Wrapper and PGObserver (Jan Mussler)]]<br />
<br />
[[Category:PostgreSQL Europe]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18083Developer FAQ/ja2012-08-24T01:40:49Z<p>Ishii: /* どのようなデバッグ機能を利用できますか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
* バックエンドプロセスを終了させることにより、OSが完全に素早くリソースを開放でき、メモリーリークとファイルディスクリプタリークを防止することができます。<br />
* スレッド化されたプログラムをデバッグするのは、プロセスをデバッグするのよりもずっと困難です。それに、コアダンプもスレッドではあまり役に立ちません。<br />
* 読み込み専用の実行形式マップと共有バッファを使用するのはプロセスをスレッドのように扱うことになり、非常にメモリ効率が良いです。<br />
* 頻繁にプロセスを生成、消滅させることによりメモリの断片化を防ぐことができます。これは、長い時間動き続けるプロセスでは管理が難しい問題です。<br />
<br />
(一つのクエリを複数のコアで処理するために、個々のバックエンドプロセスが複数のスレッドを使うべきかどうかというのはまた別の問題で、ここでは取り扱いません)。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== ブランチはどのように管理されていますか? ===<br />
<br />
ブランチの管理とバックポートに関しては、[[Working_with_Git#Using_Back_Branches|Using Back Branches]]と[[Committing with Git]]を参照して下さい。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
=== 著作権の譲渡に合意する必要がありますか? ===<br />
<br />
いいえ。貢献者は自分の著作権を保持します(ヨーロッパの国々ではどちらにせよそうなります)。貢献者は、PostgreSQL Global Development Groupの成員であると見なされます(PGDGに著作権を与えることはできません。なぜなら、PGDGは法的な実体がないからです)。これは、Linuxカーネルや、他の多くのオープンソースプロジェクトで採用されている方法です。<br />
<br />
=== 私の著作権表示を適当な場所に追加しても良いですか? ===<br />
<br />
いいえ、そうしないでください。私達は法律的な事項に関する表示は、短く明快にしておきたいと考えています。また、営利企業のユーザにはこれが問題になることがあると聞いています。<br />
<br />
=== PostgreSQLライセンス自身が著作権を完全な形で表示することを要求しているのではありませんか? ===<br />
<br />
その通りです。また、これがPostgreSQL Global Development Groupがすべての著作権を保持している理由です。ちなみに、合衆国の法律では著作権が認められるために著作権表示をする必要はありません。ヨーロッパの国々の法律でも同様です。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== 問い合わせ処理に変更を加える必要が出てきました。パーサ関係のファイルについて手短に説明して下さい。 ===<br />
<br />
パーサ関係のファイルは 「src/backend/parser」ディレクトリにあります。<br />
<br />
scan.lは、字句解析器(lexer)を定義します。字句解析機は、SQL文を含む文字列を一連のトークンに分解します。トークンは通常は一個の単語(空白を含まず、空白によって区切られているもの)ですが、単一引用符、二重引用符で囲まれている場合は、文字列全体になり得ます。字句解析機は基本的に正規表現を使って定義されており、様々なトークンのタイプが記述できます。<br />
<br />
gram.yは、字句解析器が生成したトークンを基本構成要素として使ってSQL文の文法(構文構造)を定義します。文法は、BNF記法で定義されています。BNFは正規表現に似ていますが、文字ではなく、トークン上で動きます。また、パターン(ルール、あるいはBNFにおける生成規則)には名前が付けられており、再帰的に定義できます。よって、自分自身をパターンとして呼び出すことができます。<br />
<br />
実際の字句解析器は、flexというツールを使ってscan.lから生成されます。flexのマニュアルは http://flex.sourceforge.net/manual/ で参照できます。<br />
<br />
実際のパーサは、bisonというツールを使ってgram.yから生成されます。bisonのマニュアルは http://www.gnu.org/s/bison/ で参照できます。<br />
<br />
一つ注意しておくと、もし以前にflexやbisonを使ったことがない場合、学習曲線はかなり急なものになるでしょう。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
まず、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18082Developer FAQ/ja2012-08-24T01:38:40Z<p>Ishii: </p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
* バックエンドプロセスを終了させることにより、OSが完全に素早くリソースを開放でき、メモリーリークとファイルディスクリプタリークを防止することができます。<br />
* スレッド化されたプログラムをデバッグするのは、プロセスをデバッグするのよりもずっと困難です。それに、コアダンプもスレッドではあまり役に立ちません。<br />
* 読み込み専用の実行形式マップと共有バッファを使用するのはプロセスをスレッドのように扱うことになり、非常にメモリ効率が良いです。<br />
* 頻繁にプロセスを生成、消滅させることによりメモリの断片化を防ぐことができます。これは、長い時間動き続けるプロセスでは管理が難しい問題です。<br />
<br />
(一つのクエリを複数のコアで処理するために、個々のバックエンドプロセスが複数のスレッドを使うべきかどうかというのはまた別の問題で、ここでは取り扱いません)。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== ブランチはどのように管理されていますか? ===<br />
<br />
ブランチの管理とバックポートに関しては、[[Working_with_Git#Using_Back_Branches|Using Back Branches]]と[[Committing with Git]]を参照して下さい。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
=== 著作権の譲渡に合意する必要がありますか? ===<br />
<br />
いいえ。貢献者は自分の著作権を保持します(ヨーロッパの国々ではどちらにせよそうなります)。貢献者は、PostgreSQL Global Development Groupの成員であると見なされます(PGDGに著作権を与えることはできません。なぜなら、PGDGは法的な実体がないからです)。これは、Linuxカーネルや、他の多くのオープンソースプロジェクトで採用されている方法です。<br />
<br />
=== 私の著作権表示を適当な場所に追加しても良いですか? ===<br />
<br />
いいえ、そうしないでください。私達は法律的な事項に関する表示は、短く明快にしておきたいと考えています。また、営利企業のユーザにはこれが問題になることがあると聞いています。<br />
<br />
=== PostgreSQLライセンス自身が著作権を完全な形で表示することを要求しているのではありませんか? ===<br />
<br />
その通りです。また、これがPostgreSQL Global Development Groupがすべての著作権を保持している理由です。ちなみに、合衆国の法律では著作権が認められるために著作権表示をする必要はありません。ヨーロッパの国々の法律でも同様です。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== 問い合わせ処理に変更を加える必要が出てきました。パーサ関係のファイルについて手短に説明して下さい。 ===<br />
<br />
パーサ関係のファイルは 「src/backend/parser」ディレクトリにあります。<br />
<br />
scan.lは、字句解析器(lexer)を定義します。字句解析機は、SQL文を含む文字列を一連のトークンに分解します。トークンは通常は一個の単語(空白を含まず、空白によって区切られているもの)ですが、単一引用符、二重引用符で囲まれている場合は、文字列全体になり得ます。字句解析機は基本的に正規表現を使って定義されており、様々なトークンのタイプが記述できます。<br />
<br />
gram.yは、字句解析器が生成したトークンを基本構成要素として使ってSQL文の文法(構文構造)を定義します。文法は、BNF記法で定義されています。BNFは正規表現に似ていますが、文字ではなく、トークン上で動きます。また、パターン(ルール、あるいはBNFにおける生成規則)には名前が付けられており、再帰的に定義できます。よって、自分自身をパターンとして呼び出すことができます。<br />
<br />
実際の字句解析器は、flexというツールを使ってscan.lから生成されます。flexのマニュアルは http://flex.sourceforge.net/manual/ で参照できます。<br />
<br />
実際のパーサは、bisonというツールを使ってgram.yから生成されます。bisonのマニュアルは http://www.gnu.org/s/bison/ で参照できます。<br />
<br />
一つ注意しておくと、もし以前にflexやbisonを使ったことがない場合、学習曲線はかなり急なものになるでしょう。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18081Developer FAQ/ja2012-08-24T01:06:49Z<p>Ishii: /* PostgreSQLライセンス自身がは著作権を完全な形で表示することを要求しているのではありませんか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
* バックエンドプロセスを終了させることにより、OSが完全に素早くリソースを開放でき、メモリーリークとファイルディスクリプタリークを防止することができます。<br />
* スレッド化されたプログラムをデバッグするのは、プロセスをデバッグするのよりもずっと困難です。それに、コアダンプもスレッドではあまり役に立ちません。<br />
* 読み込み専用の実行形式マップと共有バッファを使用するのはプロセスをスレッドのように扱うことになり、非常にメモリ効率が良いです。<br />
* 頻繁にプロセスを生成、消滅させることによりメモリの断片化を防ぐことができます。これは、長い時間動き続けるプロセスでは管理が難しい問題です。<br />
<br />
(一つのクエリを複数のコアで処理するために、個々のバックエンドプロセスが複数のスレッドを使うべきかどうかというのはまた別の問題で、ここでは取り扱いません)。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== ブランチはどのように管理されていますか? ===<br />
<br />
ブランチの管理とバックポートに関しては、[[Working_with_Git#Using_Back_Branches|Using Back Branches]]と[[Committing with Git]]を参照して下さい。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
=== 著作権の譲渡に合意する必要がありますか? ===<br />
<br />
いいえ。貢献者は自分の著作権を保持します(ヨーロッパの国々ではどちらにせよそうなります)。貢献者は、PostgreSQL Global Development Groupの成員であると見なされます(PGDGに著作権を与えることはできません。なぜなら、PGDGは法的な実体がないからです)。これは、Linuxカーネルや、他の多くのオープンソースプロジェクトで採用されている方法です。<br />
<br />
=== 私の著作権表示を適当な場所に追加しても良いですか? ===<br />
<br />
いいえ、そうしないでください。私達は法律的な事項に関する表示は、短く明快にしておきたいと考えています。また、営利企業のユーザにはこれが問題になることがあると聞いています。<br />
<br />
=== PostgreSQLライセンス自身が著作権を完全な形で表示することを要求しているのではありませんか? ===<br />
<br />
その通りです。また、これがPostgreSQL Global Development Groupがすべての著作権を保持している理由です。ちなみに、合衆国の法律では著作権が認められるために著作権表示をする必要はありません。ヨーロッパの国々の法律でも同様です。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18079Developer FAQ/ja2012-08-24T01:05:35Z<p>Ishii: </p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
* バックエンドプロセスを終了させることにより、OSが完全に素早くリソースを開放でき、メモリーリークとファイルディスクリプタリークを防止することができます。<br />
* スレッド化されたプログラムをデバッグするのは、プロセスをデバッグするのよりもずっと困難です。それに、コアダンプもスレッドではあまり役に立ちません。<br />
* 読み込み専用の実行形式マップと共有バッファを使用するのはプロセスをスレッドのように扱うことになり、非常にメモリ効率が良いです。<br />
* 頻繁にプロセスを生成、消滅させることによりメモリの断片化を防ぐことができます。これは、長い時間動き続けるプロセスでは管理が難しい問題です。<br />
<br />
(一つのクエリを複数のコアで処理するために、個々のバックエンドプロセスが複数のスレッドを使うべきかどうかというのはまた別の問題で、ここでは取り扱いません)。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== ブランチはどのように管理されていますか? ===<br />
<br />
ブランチの管理とバックポートに関しては、[[Working_with_Git#Using_Back_Branches|Using Back Branches]]と[[Committing with Git]]を参照して下さい。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
=== 著作権の譲渡に合意する必要がありますか? ===<br />
<br />
いいえ。貢献者は自分の著作権を保持します(ヨーロッパの国々ではどちらにせよそうなります)。貢献者は、PostgreSQL Global Development Groupの成員であると見なされます(PGDGに著作権を与えることはできません。なぜなら、PGDGは法的な実体がないからです)。これは、Linuxカーネルや、他の多くのオープンソースプロジェクトで採用されている方法です。<br />
<br />
=== 私の著作権表示を適当な場所に追加しても良いですか? ===<br />
<br />
いいえ、そうしないでください。私達は法律的な事項に関する表示は、短く明快にしておきたいと考えています。また、営利企業のユーザにはこれが問題になることがあると聞いています。<br />
<br />
=== PostgreSQLライセンス自身がは著作権を完全な形で表示することを要求しているのではありませんか? ===<br />
<br />
その通りです。また、これがPostgreSQL Global Development Groupがすべての著作権を保持している理由です。ちなみに、合衆国の法律では著作権が認められるために著作権表示をする必要はありません。ヨーロッパの国々の法律でも同様です。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18078Developer FAQ/ja2012-08-24T00:57:57Z<p>Ishii: </p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
* バックエンドプロセスを終了させることにより、OSが完全に素早くリソースを開放でき、メモリーリークとファイルディスクリプタリークを防止することができます。<br />
* スレッド化されたプログラムをデバッグするのは、プロセスをデバッグするのよりもずっと困難です。それに、コアダンプもスレッドではあまり役に立ちません。<br />
* 読み込み専用の実行形式マップと共有バッファを使用するのはプロセスをスレッドのように扱うことになり、非常にメモリ効率が良いです。<br />
* 頻繁にプロセスを生成、消滅させることによりメモリの断片化を防ぐことができます。これは、長い時間動き続けるプロセスでは管理が難しい問題です。<br />
<br />
(一つのクエリを複数のコアで処理するために、個々のバックエンドプロセスが複数のスレッドを使うべきかどうかというのはまた別の問題で、ここでは取り扱いません)。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== ブランチはどのように管理されていますか? ===<br />
<br />
ブランチの管理とバックポートに関しては、[[Working_with_Git#Using_Back_Branches|Using Back Branches]]と[[Committing with Git]]を参照して下さい。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
=== 著作権の譲渡に合意する必要がありますか? ===<br />
<br />
いいえ。貢献者は自分の著作権を保持します(ヨーロッパの国々ではどちらにせよそうなります)。貢献者は、Postgres Global Development Groupの成員であると見なされます(PGDGに著作権を与えることはできません。なぜなら、PGDGは法的な実体がないからです)。これは、Linuxカーネルや、他の多くのオープンソースプロジェクトで採用されている方法です。<br />
<br />
=== 私の著作権表示を適当な場所に追加しても良いですか? ===<br />
<br />
いいえ、そうしないでください。私達は法律的な事項に関する表示は、短く明快にしておきたいと考えています。また、営利企業のユーザにはこれが問題になることがあると聞いています。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18077Developer FAQ/ja2012-08-24T00:41:46Z<p>Ishii: /* リグレッションテスト */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
* バックエンドプロセスを終了させることにより、OSが完全に素早くリソースを開放でき、メモリーリークとファイルディスクリプタリークを防止することができます。<br />
* スレッド化されたプログラムをデバッグするのは、プロセスをデバッグするのよりもずっと困難です。それに、コアダンプもスレッドではあまり役に立ちません。<br />
* 読み込み専用の実行形式マップと共有バッファを使用するのはプロセスをスレッドのように扱うことになり、非常にメモリ効率が良いです。<br />
* 頻繁にプロセスを生成、消滅させることによりメモリの断片化を防ぐことができます。これは、長い時間動き続けるプロセスでは管理が難しい問題です。<br />
<br />
(一つのクエリを複数のコアで処理するために、個々のバックエンドプロセスが複数のスレッドを使うべきかどうかというのはまた別の問題で、ここでは取り扱いません)。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== ブランチはどのように管理されていますか? ===<br />
<br />
ブランチの管理とバックポートに関しては、[[Working_with_Git#Using_Back_Branches|Using Back Branches]]と[[Committing with Git]]を参照して下さい。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18057Developer FAQ/ja2012-08-23T02:38:11Z<p>Ishii: /* CVS ブランチはどのように管理されていますか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
* バックエンドプロセスを終了させることにより、OSが完全に素早くリソースを開放でき、メモリーリークとファイルディスクリプタリークを防止することができます。<br />
* スレッド化されたプログラムをデバッグするのは、プロセスをデバッグするのよりもずっと困難です。それに、コアダンプもスレッドではあまり役に立ちません。<br />
* 読み込み専用の実行形式マップと共有バッファを使用するのはプロセスをスレッドのように扱うことになり、非常にメモリ効率が良いです。<br />
* 頻繁にプロセスを生成、消滅させることによりメモリの断片化を防ぐことができます。これは、長い時間動き続けるプロセスでは管理が難しい問題です。<br />
<br />
(一つのクエリを複数のコアで処理するために、個々のバックエンドプロセスが複数のスレッドを使うべきかどうかというのはまた別の問題で、ここでは取り扱いません)。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== ブランチはどのように管理されていますか? ===<br />
<br />
ブランチの管理とバックポートに関しては、[[Working_with_Git#Using_Back_Branches|Using Back Branches]]と[[Committing with Git]]を参照して下さい。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
一部の環境 (特にWindows) では、環境のロケールと文字エンコーディングとの組み合わせの問題で、"make check" ではテスト用データベースの作成に失敗する場合があります。その場合、"make check NO_LOCALE=1" としてロケールなし (Cロケール) でテストしてください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18055Developer FAQ/ja2012-08-22T10:23:00Z<p>Ishii: /* なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
* バックエンドプロセスを終了させることにより、OSが完全に素早くリソースを開放でき、メモリーリークとファイルディスクリプタリークを防止することができます。<br />
* スレッド化されたプログラムをデバッグするのは、プロセスをデバッグするのよりもずっと困難です。それに、コアダンプもスレッドではあまり役に立ちません。<br />
* 読み込み専用の実行形式マップと共有バッファを使用するのはプロセスをスレッドのように扱うことになり、非常にメモリ効率が良いです。<br />
* 頻繁にプロセスを生成、消滅させることによりメモリの断片化を防ぐことができます。これは、長い時間動き続けるプロセスでは管理が難しい問題です。<br />
<br />
(一つのクエリを複数のコアで処理するために、個々のバックエンドプロセスが複数のスレッドを使うべきかどうかというのはまた別の問題で、ここでは取り扱いません)。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== CVS ブランチはどのように管理されていますか? ===<br />
<br />
[[CVS Branch Management]] を参照してください。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
一部の環境 (特にWindows) では、環境のロケールと文字エンコーディングとの組み合わせの問題で、"make check" ではテスト用データベースの作成に失敗する場合があります。その場合、"make check NO_LOCALE=1" としてロケールなし (Cロケール) でテストしてください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18054Developer FAQ/ja2012-08-22T08:10:17Z<p>Ishii: /* ソースコードの構成はどうなっていますか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://www.postgresql.org/developer/ext.backend.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== CVS ブランチはどのように管理されていますか? ===<br />
<br />
[[CVS Branch Management]] を参照してください。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
一部の環境 (特にWindows) では、環境のロケールと文字エンコーディングとの組み合わせの問題で、"make check" ではテスト用データベースの作成に失敗する場合があります。その場合、"make check NO_LOCALE=1" としてロケールなし (Cロケール) でテストしてください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18053Developer FAQ/ja2012-08-22T08:03:51Z<p>Ishii: /* どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論され、インフラチームによって管理されています。postgresql.orgのウェブサイトのソースコードは Subversion のリポジトリに格納され、[http://pgweb.postgresql.org Tracプロジェクト]の一部として提供されています。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://anoncvs.postgresql.org/cvsweb.cgi/~checkout~/pgsql/src/tools/backend/index.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== CVS ブランチはどのように管理されていますか? ===<br />
<br />
[[CVS Branch Management]] を参照してください。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
一部の環境 (特にWindows) では、環境のロケールと文字エンコーディングとの組み合わせの問題で、"make check" ではテスト用データベースの作成に失敗する場合があります。その場合、"make check NO_LOCALE=1" としてロケールなし (Cロケール) でテストしてください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18052Developer FAQ/ja2012-08-22T01:48:38Z<p>Ishii: /* どの項目の開発が望まれていますか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#開発者向きの良書はありますか?|開発者向けの書籍]])<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論されています。プロジェクトのページは http://pgweb.postgresql.org/ にあり、ソースコードを取得できます。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://anoncvs.postgresql.org/cvsweb.cgi/~checkout~/pgsql/src/tools/backend/index.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== CVS ブランチはどのように管理されていますか? ===<br />
<br />
[[CVS Branch Management]] を参照してください。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
一部の環境 (特にWindows) では、環境のロケールと文字エンコーディングとの組み合わせの問題で、"make check" ではテスト用データベースの作成に失敗する場合があります。その場合、"make check NO_LOCALE=1" としてロケールなし (Cロケール) でテストしてください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18043Developer FAQ/ja2012-08-21T09:37:20Z<p>Ishii: /* どのような開発環境が必要ですか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。<br />
もっとも、Windows上のほとんどの開発は、今のところマイクロソフトの Visual Studio 2005(version 8)開発環境と付属のツールで行われています。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#What_books_are_good_for_developers.3F|開発者向けの書籍]]).<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論されています。プロジェクトのページは http://pgweb.postgresql.org/ にあり、ソースコードを取得できます。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://anoncvs.postgresql.org/cvsweb.cgi/~checkout~/pgsql/src/tools/backend/index.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== CVS ブランチはどのように管理されていますか? ===<br />
<br />
[[CVS Branch Management]] を参照してください。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
一部の環境 (特にWindows) では、環境のロケールと文字エンコーディングとの組み合わせの問題で、"make check" ではテスト用データベースの作成に失敗する場合があります。その場合、"make check NO_LOCALE=1" としてロケールなし (Cロケール) でテストしてください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18042Developer FAQ/ja2012-08-21T09:31:09Z<p>Ishii: /* どのようにすれば PostgreSQL の開発に参加できますか? */</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細は「[[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]」を参照して下さい。<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。他のソフトウェアベンダのコンパイラを使う開発者もいます。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#What_books_are_good_for_developers.3F|開発者向けの書籍]]).<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論されています。プロジェクトのページは http://pgweb.postgresql.org/ にあり、ソースコードを取得できます。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://anoncvs.postgresql.org/cvsweb.cgi/~checkout~/pgsql/src/tools/backend/index.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== CVS ブランチはどのように管理されていますか? ===<br />
<br />
[[CVS Branch Management]] を参照してください。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
一部の環境 (特にWindows) では、環境のロケールと文字エンコーディングとの組み合わせの問題で、"make check" ではテスト用データベースの作成に失敗する場合があります。その場合、"make check NO_LOCALE=1" としてロケールなし (Cロケール) でテストしてください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishiihttps://wiki.postgresql.org/index.php?title=Developer_FAQ/ja&diff=18037Developer FAQ/ja2012-08-21T01:12:47Z<p>Ishii: Update 1.1 & 1.2</p>
<hr />
<div>{{Languages}}<br />
<br />
== 開発への参加 ==<br />
<br />
=== どのようにすれば PostgreSQL の開発に参加できますか? ===<br />
<br />
ソースコードをダウンロードして読んでください。 詳細はここ: [[#最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?|最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は?]]<br />
<br />
[http://archives.postgresql.org/pgsql-hackers/ pgsql-hackers メーリングリスト] ("hackers" と呼ばれます) に参加し、読んでください。ここはプロジェクトの主要開発者やコアメンバが開発について議論する場です。<br />
<br />
=== 最新のソースツリーをダウンロードする方法、また最新のソースに追随する方法は? ===<br />
<br />
ソースツリーを取得する方法は幾つかあります。たまに開発に参加するだけの人は最新のソースツリー・スナップショットを ftp://ftp.postgresql.org/pub/snapshot/ から取得できます。<br />
<br />
一般的な開発者はソースコード管理システムに anonymous でアクセスして取得しています。ソースツリーは現在 git で管理されています。git からのソースコード取得について、詳細は http://developer.postgresql.org/pgdocs/postgres/git.html と [[Working with Git]] を参考にしてください。<br />
<br />
=== どのような開発環境が必要ですか? ===<br />
<br />
PostgreSQL は主にC言語で開発されています。ソースコードの対象は、主な UNIX プラットフォームと Windows (XP, 2000 以降) です。<br />
<br />
多くの開発者は Unix ライクなOS上で、[http://gcc.gnu.org GCC], [http://www.gnu.org/software/make/make.html GNU Make], [http://www.gnu.org/software/gdb/gdb.html GDB], [http://www.gnu.org/software/autoconf/ Autoconf] などのオープンソースのツールを利用して開発しています。もしあなたがオープンソースソフトウェアに貢献した経験があれば、これらのツールは既に良くご存知でしょう。Windows これらのツールを使う開発者は [http://www.mingw.org/ MinGW] を使用します。他のソフトウェアベンダのコンパイラを使う開発者もいます。<br />
<br />
PostgreSQL をビルドするために必要なソフトウェアの完全な一覧は「[http://www.postgresql.jp/document/current/html/install-requirements.html 必要条件]」を参照してください。<br />
<br />
ソースコードを頻繁にリビルドする開発者は configure 時に --enable-depend フラグを指定することもできます。これを使うと、ヘッダファイルを修正した際に、それに依存する全てのソースファイルもリビルドされるようになります。<br />
<br />
src/Makefile.custom で環境変数を設定することができます (例: CUSTOM_COPT)。これはすべてのコンパイルで使用されます。<br />
<br />
=== どの項目の開発が望まれていますか? ===<br />
未解決の機能は [[Todo]] にまとまっています。<br />
<br />
それぞれの項目については、ML の[http://archives.postgresql.org/ アーカイブ]、標準SQL、推奨書籍などを参考にしてください。参照: [[#What_books_are_good_for_developers.3F|開発者向けの書籍]]).<br />
<br />
=== どのようにすれば PostgreSQL ウェブサイトの開発に参加できますか? ===<br />
PostgreSQL ウェブサイトの開発は、[http://archives.postgresql.org/pgsql-www/ pgsql-www メーリングリスト]で議論されています。プロジェクトのページは http://pgweb.postgresql.org/ にあり、ソースコードを取得できます。<br />
<br />
== 開発ツールとヘルプ ==<br />
<br />
=== ソースコードの構成はどうなっていますか? ===<br />
<br />
『[http://anoncvs.postgresql.org/cvsweb.cgi/~checkout~/pgsql/src/tools/backend/index.html How PostgreSQL Processes a Query] (PostgreSQL のクエリ処理方式)』(これはソースコードの src/tools/backend/index.html にもあります) をブラウザで見てください。データフロー、フローチャートの中のバックエンド構成要素、共有メモリ内の構成について、簡単に記述されています。フローチャート内の矩形をクリックすると説明が表示されます。説明文の中のディレクトリ名をクリックすると、ソースディレクトリにジャンプし、実際のソースコードを読むことができます。他にも、ソースコード・ディレクトリの中に README ファイルが幾つかあり、モジュールの関数を説明しています。ブラウザからそれらのファイルを読むこともできます。<br />
<br />
ソースツリーに含まれる文書以外には、コードについて記述されている論文や発表資料が http://www.postgresql.org/developer/coding にあります。素晴らしい発表資料は http://neilconway.org/talks/hacking/ でも見つかります。<br />
<br />
=== 開発に利用できるツールには何がありますか? ===<br />
<br />
まず、src/tools ディレクトリ内にある全てのファイルは開発者のために用意されたものです。<br />
<br />
RELEASE_CHANGES リリースのたびに変更が必要な項目<br />
backend backend ディレクトリ内の説明と処理の流れ<br />
ccsym 使用中のコンパイラが作成する標準 define を見つける<br />
copyright コピーライト<br />
<br />
entab スペース文字をタブ文字に変換する (pgindent で使用される)<br />
find_static static 関数に変更できる関数を見つける<br />
find_typedef ソースコード中の typedef を見つける<br />
find_badmacros 括弧の使い方が不適切なマクロを見つける<br />
fsync ファイル同期を行うシステムコールのコストを比較するスクリプト<br />
make_ctags vi 用の 'tags' ファイルを各ディレクトリに作成する<br />
make_diff *.orig とソースの差分を作成する<br />
make_etags emacs 用の 'etags' ファイルを作成する<br />
make_keywords キーワードを SQL'92 と比較する<br />
make_mkid mkid ID ファイルを作成する<br />
pgcvslog それぞれのリリースのための変更リストを作成する<br />
pginclude インクルード・ファイルを追加 / 削除するスクリプト<br />
pgindent ソースファイルのインデントを行う<br />
pgtest 半自動化されたビルドシステム<br />
thread スレッドのテストをするスクリプト<br />
<br />
src/include/catalog には以下のファイルもあります。<br />
<br />
unused_oids システムカタログ内で使われていないOIDを見つけるスクリプト<br />
duplicate_oids システムカタログ内で重複しているOIDを見つけるスクリプト<br />
<br />
tools/backend については既に他の Q&A で説明済みです。<br />
<br />
第2に、タグファイルを扱えるエディタが必要です。関数呼び出しから関数定義をタグ付けできます。さらに低いレベルの関数を手繰ることができ、その後元の関数へ戻ることができます。tag または etags をサポートしているエディタは数多くあります。<br />
<br />
第3に、id-utils を ftp://ftp.gnu.org/gnu/id-utils/ から取得してください。<br />
<br />
tools/make_mkid を実行し、ソースのシンボルのアーカイブを作成することで、高速に検索できます。<br />
<br />
cscope (http://cscope.sf.net/) を使う開発者もいます。その他には glimpse (http://webglimpse.net/) も使われます。<br />
<br />
tools/make_diff は差分パッチファイルを作成するツールです。パッチはコンテキスト形式になります。メーリングリストにパッチを投稿する場合はこのコンテキスト形式にしてください。<br />
<br />
pgindent はソースコードのスタイルを標準の書式に修正するツールです。通常は、開発サイクルの最終段階で実行されます。ソースコードのスタイルについては[[#What.27s_the_formatting_style_used_in_PostgreSQL_source_code.3F|この質問]]も参考にしてください。<br />
<br />
pginclude は #include を必要ならば追加、不要ならば削除するスクリプトです。<br />
<br />
型や関数のようなビルトイン・オブジェクトを追加する場合、それらに対して OID を割り当てる必要があります。この際の規約は、1-9999 の範囲の OID を重複が無いように手作業で割り当てることです。(機構的にはそれぞれのシステムカタログ内で一意であれば問題ないのですが、分かりやすくするためシステム全体で一意になるようにしています。) unused_oids というスクリプトが src/include/catalog にあり、現在使用していない OID を表示します。新しい OID を割り当てる際には unused_oids を参照して未使用のものを使ってください。可能ならば、関連する機能を持つ既存のオブジェクトの近くの OID を選びます。また、OID の割り当てミスを検出する duplicate_oids スクリプトもあります。<br />
<br />
=== どんなスタイルが PostgreSQL ソースコードでは使われますか? ===<br />
<br />
私たちの標準スタイルは BSD 式です。コードのインデントにはタブを用い、タブはスペース4個分としています。使用するエディタやファイルビューアのタブ幅をスペース4個に設定しておいてください。<br />
<br />
'''vi''' の場合には <code>.exrc</code> か <code>.vimrc</code> で以下の設定をします:<br />
set tabstop=4 shiftwidth=4 noexpandtab<br />
<br />
'''less''' や '''more''' では、<code>-x4</code> を指定すると適切にインデントされます。<br />
<br />
tools/editors ディレクトリには emacs, xemacs, vim 用のサンプル設定ファイルがあります。これは PostgreSQL のコーディング・スタイルを維持するのに役立ちます。<br />
<br />
pgindent は OS の indent ツールに適切なフラグを指定して実行し、コードを整形します。pgindent は全てのソースコード・ファイルに倒して、ベータテストの時期に実行されます。全てのソースファイルは一貫性のある形式に自動で整形されます。記述したとおりに改行されることが必要なコメントは、ブロックコメント形式にする必要があります。コメントを /*------ から開始してください。ブロックコメントは勝手に整形されることはありません。<br />
<br />
ドキュメントの『[http://www.postgresql.jp/document/current/html/source-format.html 書式]』も参照してください。また、[http://archives.postgresql.org/message-id/1221125165.5637.12.camel@abbas-laptop この投稿]は変数や関数名の命名方針について述べています。<br />
<br />
なぜ私たちがソースコード・スタイルにこれほど気にするのかについては、コーディングスタイルの価値が[http://ezine.daemonnews.org/200112/single_coding_style.html この記事]で述べられています。<br />
<br />
=== システムカタログのダイアグラムはありますか? ===<br />
<br />
はい。以下を参照してください<br />
* [http://dalibo.org/_media/articles/catalog.png PNG 形式]<br />
* [http://svn.postgresql.fr/repos/materials/advocacy/trunk/posters/catalogs83.svg SVG 形式]<br />
<br />
=== 開発者向きの良書はありますか? ===<br />
<br />
5冊挙げておきます:<br />
* An Introduction to Database Systems, by C.J. Date, Addison, Wesley<br />
* A Guide to the SQL Standard, by C.J. Date, et. al, Addison, Wesley<br />
* Fundamentals of Database Systems, by Elmasri and Navathe<br />
* Transaction Processing, by Jim Gray and Andreas Reuter, Morgan Kaufmann<br />
* Transactional Information Systems, by Gerhard Weikum and Gottfried Vossen, Morgan Kaufmann<br />
<br />
=== configure とは何ですか? ===<br />
<br />
configure と configure.in ファイルは GNU autoconf パッケージの一部です。configure を使うと、OS の様々な機能をチェックし、その結果をCプログラムと Makefile の変数に設定します。autoconf は PostgreSQL のメインサーバにインストールされています。configure にオプションを追加するには、configure.in を編集し、その後 autoconf を実行して configure ファイルを生成してください。<br />
<br />
configure がユーザに実行される場合、OS の様々な機能をチェックし、その結果を config.status と config.cache に記録します。そして、複数の *.in ファイルを変更します。例えば、Makefile.in がありますが、configure はその中の全ての @var@ パラメータを設定して Makefile ファイルを生成します。<br />
<br />
あなたがファイルを編集する必要が生じた場合、configure によって生成されるファイルを変更するのは時間の無駄になります。代わりに *.in ファイルを編集し、再度 configure を実行することでファイルを生成してください。トップディレクトリで make distclean を実行すると、configure が生成する全てのファイルが削除されます。ソースコードとして配布されるファイルだけが残ることになります。<br />
<br />
=== 新しい環境へ移植するためにはどうしたら良いですか? ===<br />
<br />
新しい環境へ移植 (port) するためには多くの箇所を変更する必要があります。まず src/template から始めましょう。移植先の OS に対応する適切なエントリを追加します。また、src/config.guess を使ってそのOSを src/template/.similar に追加します。OS のバージョンを厳密に一致させてはいけません。configure テストは、最初に正確なOSバージョンを探し、もし見つからなければ、バージョン番号を除いて探そうとします。src/configure.in を編集し、新しいOSを追加します。(上記の configure に関する質問も参照) その後、autoconf を実行するか、src/configure にもパッチを当てます。<br />
<br />
次に、src/include/port をチェックし、新しいOS用のファイルを適切に記述して追加します。願わくば、src/include/storage/s_lock.h に既に移植先のCPU用のロックコードがあることを祈りましょう。src/makefiles ディレクトリにも環境ごとの Makefile があります。専用のファイルが必要な場合には、backend/port ディレクトリへ追加します。<br />
<br />
=== なぜスレッド, RAWデバイス, 非同期I/O 等の "イケてる" 機能を使わないのですか? ===<br />
<br />
OS はサポートしたばかりの最新機能は非常に魅力的ですが、そういった誘惑には抵抗しています。<br />
<br />
1つ目に、我々は 15 以上の OS をサポートしているため、採用する前に新機能は広く採用されていいなければなりません。2つ目に、イケてる機能の多くは、実際には劇的な改善に繋がりません。3つ目に、新機能の中には悪い側面を持つものがあり、信頼性を犠牲にしたり、追加のコードを要求されることがあります。それゆえ、我々は新機能にすぐに飛びつきはせず、こなれるまで見送ります。, then ask for testing to show that a measurable improvement is possible.<br />
<br />
例として、現在バックエンド・コードでスレッドが使われていない理由を挙げます:<br />
<br />
* 歴史的に、スレッドはサポートしない環境とバグがありました。<br />
* 1つのバックエンドでエラーが生じると他のバックエンドにも悪影響が及びます。<br />
* バックエンドのその他の初期化時間と比較して、スレッドの速度面の利点は微々たるものです。<br />
* バックエンド・コードが複雑になります。<br />
<br />
つまり、私たちは新機能を無視しているわけではありません。採用に慎重なだけなのです。TODO リストには、この分野に関する私たちの見解に関する議論がリンクされている場合があります。<br />
<br />
=== CVS ブランチはどのように管理されていますか? ===<br />
<br />
[[CVS Branch Management]] を参照してください。<br />
<br />
=== どこでSQL標準のコピーが入手できますか? ===<br />
[http://www.iso.ch/ ISO] や [http://www.ansi.org ANSI] で購入してください。ISO/ANSI 9075 を探します。ANSI のほうが安価ですが、内容は同じです。<br />
<br />
SQL標準の公式コピーは高価なので、開発者の多くはインターネット上にあるドラフト版を利用しています。そのいくつかを挙げます:<br />
* SQL-92 http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt<br />
* SQL:1999 http://www.cse.iitb.ac.in/dbms/Data/Papers-Other/SQL1999/ansi-iso-9075-2-1999.pdf<br />
* SQL:2003 http://www.wiscorp.com/sql_2003_standard.zip<br />
* SQL:2008 (preliminary) http://www.wiscorp.com/sql200n.zip<br />
<br />
PostgreSQL 文書には PostgreSQL に関する情報と [http://www.postgresql.jp/document/current/html/features.html SQL準拠] に関する記述があります。<br />
<br />
SQL標準に関するウェブページを挙げます:<br />
* http://troels.arvin.dk/db/rdbms/links/#standards<br />
* http://www.wiscorp.com/SQLStandards.html<br />
* http://www.contrib.andrew.cmu.edu/~shadow/sql.html#syntax (SQL-92)<br />
* http://dbs.uni-leipzig.de/en/lokal/standards.pdf (paper)<br />
<br />
注意として、SQL標準のコピーを読むことは、PostgreSQL の開発者になるためには必ずしも必要ではありません。SQL標準の記述を理解することは難しく、長年の経験も必要です。そして、どのみち PostgreSQL の多くの機能は、SQL標準では規定されていないのです。<br />
<br />
<br />
=== 技術的な質問の回答はどこで得られますか? ===<br />
<br />
技術的な質問の多くは pgsql-hackers メーリングリストで応えられています。過去のアーカイブは http://archives.postgresql.org/pgsql-hackers/ にあります。<br />
<br />
もし過去の議論や回答が見つからない場合には、気軽にメーリングリストに投稿してください。<br />
<br />
IRC (irc.freenode.net #postgresql チャネル) でも、新機能の開発に関する質問も含め、主要開発者 (Major contributors) が技術的な質問に答えてくれるでしょう。<br />
<br />
=== なぜ CVS を SVN, Git, Monotone, VSS 等に置き換えないのですか? ===<br />
<br />
2010年9月、PostgreSQL プロジェクトは CVS を Git に置き換えました。<br />
<br />
== 開発プロセス ==<br />
<br />
=== 開発項目を選んだ後、何をすればよいですか? ===<br />
<br />
あなたがやりたいことの提案書を添えて、email を pgsql-hackers に送ってください (即採用とはいかないことを覚悟してください)。あなた1人だけで考えて開発することはお勧めしません。別の人が同じ TODO 項目に取り組んでいるかもしれませんし、あなたが TODO 項目を誤解しているかもしれないからです。email では、あなたが採用するつもりの内部実装と、ユーザから見える変更 (新しい文法など) の両方を議論してください。複雑なパッチの場合には、実際に開発を始める前にコミュニティのフィードバックを受けることが重要です。そのような手順を踏まなければ、パッチは却下されてしまうでしょう。もしあなたの開発が企業にスポンサーされている場合には、より効率的に行えるよう[http://momjian.us/main/writings/pgsql/company_contributions/ この記事]を読んでください。<br />
<br />
レビュー待ちのパッチ・キューは wiki の [[CommitFest]] で管理されています。<br />
<br />
=== どのように変更箇所をテストすれば良いですか? ===<br />
<br />
==== 基本システムテスト ====<br />
<br />
あなたのコードをテストする最も簡単な方法は、最新バージョンのコードでビルドし、コンパイラの警告が出ないことを確認することです。<br />
<br />
configure の際に --enable-cassert オプションを指定してビルドするのも良いでしょう。これはソースコード中のアサーションを有効にし、データ破壊やアクセス違反をより多く検知できるようになります。多くの場合、デバッグが容易になります。<br />
<br />
その後、psql を使って性能をテストしてください。<br />
<br />
==== リグレッションテスト ====<br />
<br />
次のステップは、あなたが行った変更に対して既存のリグレッションテスト (回帰テスト) を行うことです。テストするには、ソースツリーのルート・ディレクトリで "make check" を入力してください。失敗した場合には、調査する必要があります。<br />
<br />
もしあなたが既存の動作を意図的に変更した場合には、リグレッションテストには失敗するでしょうが、それは実際には間違った動作ではありません。その場合、リグレッションテストを変更するパッチも作成してください。<br />
<br />
一部の環境 (特にWindows) では、環境のロケールと文字エンコーディングとの組み合わせの問題で、"make check" ではテスト用データベースの作成に失敗する場合があります。その場合、"make check NO_LOCALE=1" としてロケールなし (Cロケール) でテストしてください。<br />
<br />
==== その他の実行時テスト ====<br />
<br />
開発には以下のようなツールもよく利用されています。<br />
* valgrind (http://valgrind.kde.org) : メモリテスト<br />
* gprof (GNU binutils に含まれます), oprofile (http://oprofile.sourceforge.net/) : プロファイリング<br />
<br />
==== ユニットテスト、統計的解析、モデルチェックなどはどうですか? ====<br />
<br />
テスト用フレームワークについては既に多くの議論があり、れらのアイデアを採用している開発者もいます。<br />
<br />
Makefile はインクルードファイルに対して依存性を持たないように注意してください。make clean の後でも make が動作する必要があります。もし GCC を使っているのであれば、--enable-depend オプションを configure 時に指定することで、コンパイラに依存性を自動計算させることができます。<br />
<br />
=== パッチの開発後、次に何をすれば良いですか? ===<br />
<br />
パッチを pgsql-hackers@postgresql.org へ投稿してください。あなたのパッチが迅速にレビューされ、採用されるようにするため、「[[Submitting a Patch|パッチの投稿]]」にあるガイドラインに従うよう努めてください。<br />
<br />
=== パッチの投稿後には何がありますか? ===<br />
<br />
パッチは他の開発者のレビューを受けることになります。採用されることもあれば、追加開発が必要だとして送り返されることもあります。このプロセスの詳しい解説は、『[[Submitting a Patch#Patch review and commit|パッチを投稿するには]]』にあります。<br />
<br />
=== どうすればパッチのレビューに参加できますか? ===<br />
<br />
あなたが [[CommitFestInProgress|CommitFest]] に登録されているパッチのレビューに参加することは大歓迎です。詳細は、「[[Reviewing a Patch|パッチのレビュー]]」を参考にしてください。<br />
<br />
== 技術的な質問 ==<br />
=== どうすればバックエンドのコードからシステムカタログへ効率的なアクセスができますか? ===<br />
<br />
最初にあなたが必要とするタプル (行) を見つける必要があります。それには2つの方法があります。1つは SearchSysCache() やその類似関数を呼び、既知のカタログ用インデックスを使ってシステムカタログを取得する方法です。これはシステムカタログにアクセスする方法として推奨されています。なぜなら、初回の呼び出して必要な行がキャッシュにロードされ、それ以降の呼び出しでは元の表にアクセスする必要が無くなるためです。利用可能なキャッシュの一覧は、src/backend/utils/cache/syscache.c に記載されています。src/backend/utils/cache/lsyscache.c は数多くの特定の列を取得するためのキャッシュ検索関数が定義されています。<br />
<br />
返却される行はキャッシュで管理されています。そのため、SearchSysCache() から返された行を変更や削除してはいけません。使用後には ReleaseSysCache() で行を解放する必要があります。解放されたキャッシュは必要に応じて破棄されます。もし ReleaseSysCache() を呼ばなかった場合、キャッシュのエントリはトランザクションの終了までロックされます。開発時には良いかもしれませんが、実際にリリースされるコードでは許されません。<br />
<br />
もしシステムキャッシュが利用できない場合には、全てのバックエンドで共有されるバッファキャッシュを介して、表から直接データを取得する必要があります。バックエンドは行を自動的にバッファキャッシュに読み込みます。これを行うには、heap_open() で表を開いた後に、その表のスキャンを heap_beginscan() で開始し、heap_getnext() を HeapTupleIsValid() が true を返す限り繰り返し呼び出します。最後に heap_endscan() を呼びます。スキャンの際にはキーも指定できますが、インデックスは使われません。全ての行がキーと比較され、適合する行のみが返却されます。<br />
<br />
ブロック番号とオフセット番号が分かっている場合には heap_fetch() で行を取得することもできます。heap_fetch() では、バッファキャッシュ上の行のロック / アンロックは自動的に行われますが、利用後には Buffer ポインタを渡して ReleaseBuffer() を呼び出す必要があります。<br />
<br />
行が得られた後、全ての行タイプで共通のデータを取得することができます。t_self と t_oid は、単に HeapTuple 構造体のエントリにアクセスするだけで読み取れます。表ごとに異なる列を取得する場合には、HeapTuple ポインタ を GETSTRUCT() マクロに渡します。返却されるポインタは構造体のポインタにキャストして使います。例えば pg_proc ならば Form_pg_proc ポインタ、pg_type ならば Form_pg_type ポインタです。その後は構造体ポインタを介してフィールドにアクセスできます:<br />
<br />
((Form_pg_class) GETSTRUCT(tuple))->relnatts<br />
<br />
注意としては、この方法は、固定長かつ非NULLであり、そのフィールドよりも前方の列も固定長かつ非NULLの列でのみ利用可能なことです。さもなければ列の位置は不定になるため、heap_getattr() やその類似関数を使って行から値を取り出す必要があります。<br />
<br />
また、有効な行に対して構造体のフィールドを直接書き換えることは避けてください。最も良い方法は、heap_modifytuple() に変更前の行と変更内容を渡すことです。palloc された新しい行が返却され、heap_update() に渡すことができます。削除の場合は、行の t_self を heap_delete() に渡します。t_self は heap_update() でも使うことができます。覚えておく必要があるのは、行は、ReleaseSysCache() の呼び出しで解放されるシステムキャッシュにあるコピーでも、eap_getnext(), heap_endscan(), heap_fetch() の場合は ReleaseBuffer() で解放されるディスクバッファから直接読み取った行でも、構わないということです。もしくは、palloc された行であれば、使用後には pfree() で解放する必要があります。<br />
<br />
=== なぜ表, 列, 型, 関数, ビューの名前は Name, NameData, char * といった異なる型として参照されるのですか? ===<br />
<br />
表, 列, 型, 関数, ビューの名前はシステムテーブルに Name 型の列として保持されています。Name は固定長でヌル終端の文字列です。サイズは NAMEDATALEN バイトです (デフォルト64バイト)。<br />
<br />
typedef struct nameData<br />
{<br />
char data[NAMEDATALEN];<br />
} NameData;<br />
typedef NameData *Name;<br />
<br />
表, 列, 型, 関数, ビューの名前はユーザクエリを経由して、可変長のヌル終端された文字列としてバックエンドに渡されます。<br />
<br />
heap_open() などの多くの関数は、両方の名前型で呼び出れます。Name 型は NULL 終端されているため、char * 型を引数に取る関数に渡しても大丈夫です。ディスク上の名前 (Name) がユーザから渡された名前 (char *) と比較される機会は多く、Name と char * を入れ替えて使える場合も頻繁にあります。<br />
<br />
=== なぜデータ構造体を作成するために Node や List を使うのですか? ===<br />
バックエンドの中で柔軟にデータをやり取りする一貫性のある方法だからです。全ての Node はその型を表す NodeTag フィールド持っています。List は複数の Node を保持する単方向リンクリストです。List 内に要素の順序が意味を持つか否かは用途によります。<br />
<br />
以下に List 操作コマンドの一部を示します:<br />
<br />
;lfirst(i)<br />
;lfirst_int(i)<br />
;lfirst_oid(i)<br />
:データを返します。(それぞれセル i を ポインタ, 整数, OID として)<br />
<br />
;lnext(i)<br />
:i の次のセルを返します。<br />
<br />
;foreach(i, list)<br />
:list をループし、それぞれのセルを i に格納します。<br />
<br />
重要なのは、i が ListCell * 型であることです。セルに格納されたデータではありません。lfirst 関数のいずれかを使ってセルのデータを取得する必要があります。<br />
<br />
以下はループ処理を行う典型的なコードです。List 型は Var * 型のデータを格納しており、要素それぞれを処理したい場合です:<br />
<br />
List *list;<br />
ListCell *i;<br />
...<br />
foreach(i, list)<br />
{<br />
Var *var = (Var *) lfirst(i);<br />
...<br />
/* ここで var を使う */<br />
}<br />
<br />
;lcons(node, list)<br />
:node を list の先頭に追加します。list が NIL ならばリストを新規作成します。<br />
<br />
;lappend(list, node)<br />
:node を list の末尾に追加します。<br />
<br />
;list_concat(list1, list2)<br />
:list1 の末尾に list2 を追加します。<br />
<br />
;list_length(list)<br />
:list の長さを返します。<br />
<br />
;list_nth(list, i)<br />
:list の i 番目の要素を返します。番号は 0 から数えます。<br />
<br />
;lcons_int, ...<br />
:整数版の lcons_int, lappend_int や、OID 版の lcons_oid, lappend_oid もあります。<br />
<br />
gdb を使って、ノードを簡単に表示することができます。最初に gdb の表示切り詰めを無効化してください。<br />
<br />
(gdb) set print elements 0<br />
<br />
List, Node, 構造体の内容を表示するには、gdb 形式で値を表示する代わりに次の2つのコマンドを使うと、詳しい情報を得ることができます。List の中の Node は展開され、Node はその詳細が出力されます。1番目の関数は短い形式、2番目の関数は長い形式で表示します:<br />
<br />
(gdb) call print(any_pointer)<br />
(gdb) call pprint(any_pointer)<br />
<br />
出力はサーバログに行われますが、postmaster を使わずバックエンドを直接起動していた場合には画面に表示されます。<br />
<br />
=== 構造体にフィールドを追加する際、他に何をする必要がありますか? ===<br />
<br />
パーサ、リライタ、オプティマイザ、エグゼキュータ (parser, rewriter, optimizer, executor) に渡す構造体の場合には、処理の追加が必要です。構造体の多くは src/backend/nodes で定義されるルーチンをサポートしており、構造体の作成、コピー、読み取り、書き出しを行うことができます。特に、ほとんどのノード型は copyfuncs.c と equalfuncs.c への対応が必須であり、一部は outfuncs.c や readfuncs.c もサポートする必要があります。新しいフィールドをこれらのファイルでもサポートするよう変更してください。そのほかにも追加したフィールドに対応するコードが無いかを探してください。これには既存のフィールドがどのように扱われているかを参考にするのが良いでしょう。mkid が役に立ちます。([[#What_tools_are_available_for_developers.3F|利用可能なツール]] 参照)<br />
<br />
=== なぜメモリ確保に palloc() と pfree() を使うのですか? ===<br />
<br />
palloc() と pfree() は malloc() と free() の代わりに使われます。その理由は、クエリの完了時に確保した全てのメモリを容易に解放するためです。たとえどこでメモリを確保したのかが分らなくなっても、全てのメモリを解放することが可能になります。クエリ単位ではないメモリ領域もありますが、バックエンドが定義解放します。<br />
<br />
=== ereport() とは何ですか? ===<br />
<br />
ereport() はフロントエンドにメッセージを送信します。また、実行中のクエリを終了することもできます。使い方の詳細は「[http://www.postgresql.jp/document/current/html/error-message-reporting.html サーバ内部からのエラーの報告]」を参照してください。<br />
<br />
=== CommandCounterIncrement() とは何ですか? ===<br />
<br />
通常は、コマンド文は自身が変更した行を見ることはできません。これは「UPDATE foo SET x = x + 1」が正常に動作するために必要です。<br />
<br />
しかしながら、トランザクションの中で、そのトランザクションが直前に行った変更結果が必要になる場合もあります。これはコマンド・カウンタ (Command Counter) を利用することで実現できます。カウンタを増加させることでトランザクションを断片に分割し、それぞれの断片はそれ以前に実行した断片の結果を読み取ることができるようになります。CommandCounterIncrement() はコマンド・カウンタを増加させ、トランザクションに新しい断片を追加する処理です。<br />
<br />
=== どのようなデバッグ機能を利用できますか? ===<br />
<br />
ます、もしあなたがC言語で開発しているならば、'''必ず''' --enable-cassert と --enable-debug オプションを有効にして configure を行った状態で動作することを確認してください。アサーションを有効にすると多くの正常性確認処理が有効になります。デバッグシンボルはデバッガ (例えば gdb) を使って期待通りに動作しないコードを追うのに役立ちます。<br />
<br />
PostgreSQL サーバには -d オプションがあり、これは詳細メッセージをログに記録します (elog または ereport で DEBUGn の情報を出力します)。-d オプションはデバッグレベルの数値を1つ引数に取ります。高いデバッグレベルを指定するとログファイルのサイズが大きくなるので注意してください。<br />
<br />
postmaster が実行中ならば、ウィンドウ (コンソール) を1つ開いて psql を開始します。その後、その psql が接続している postgres プロセスの PID を、SELECT pg_backend_pid() を使って取得します。デバッガをその postgres の PID にアタッチします。デバッガからブレークポイントを設定し、その後 psql セッションからクエリを発行します。もしエラーやログメッセージを出力している場所を探しているのであれば、errfinish にブレークポイントを設定するのが良いでしょう。もしセッションの開始処理をデバッグしたいのであれば、環境変数 PGOPTIONS="-W n" を指定してから psql を開始してください。開始処理に n 秒の遅延を行うため、その間に postgres プロセスにデバッガをアタッチすることができます。ブレークポイントを適切に設定した後に開始処理を継続することになります。<br />
<br />
もし postmaster が実行されていないならば、postgres バックエンドをコマンドラインから開始し、SQL 文を直接入力することもできます。しかしながら、これはあまり良い方法ではありません。psql ほど使いやすい環境ではなく (例えばコマンド履歴がありません)、並行処理をテストすることもできないためです。initdb が正常に動作しなくなってしまった場合には役立つかもしれませんが、それ以外の状況ではお勧めしません。<br />
<br />
どの関数の実行に時間がかかっているかを知るためにプロファイリングを有効にしてコンパイルすることもできます。configure の際に --enable-profiling を指定してください (この時、性能を測定したいのであれば --enable-casserts は使わないでください。アサーションのチェックは無視できるほど軽量ではないためです)。<br />
サーバプロセスからのプロファイル・ファイルは pgsql/data ディレクトリに出力されます。psql 等のクライアントからのプロファイル・ファイルは、クライアントのカレントディレクトリに置かれます。<br />
<br />
[[Category:FAQ]]<br />
[[Category:Japanese]]</div>Ishii