https://wiki.postgresql.org/api.php?action=feedcontributions&user=Mha&feedformat=atomPostgreSQL wiki - User contributions [en]2024-03-29T08:38:51ZUser contributionsMediaWiki 1.35.13https://wiki.postgresql.org/index.php?title=Apt&diff=38367Apt2023-11-06T10:07:55Z<p>Mha: /* News */</p>
<hr />
<div>==PostgreSQL packages for Debian and Ubuntu==<br />
<br />
The PostgreSQL Global Development Group (PGDG) maintains an APT repository of PostgreSQL packages for Debian and Ubuntu located at https://apt.postgresql.org/pub/repos/apt/.<br />
We aim at building PostgreSQL server packages as well as extensions and modules packages on several Debian/Ubuntu releases for all PostgreSQL versions supported.<br />
<br />
Currently, we support<br />
<br />
* '''Debian buster''' (10), '''bullseye''' (11), '''bookworm''' (12), '''trixie''' (testing/13) and '''sid''' (unstable)<br />
* '''Ubuntu focal''' (20.04), '''jammy''' (22.04), '''lunar''' (23.04), '''mantic''' (23.10)<br />
* Architectures: '''amd64''' (64-bit x86), '''i386''' (32-bit x86, being phased out), '''arm64''' (64-bit ARM), '''ppc64el''' (little-endian 64-bit POWER)<br />
* '''PostgreSQL 10, 11, 12, 13, 14, 15''', [[Apt/FAQ#I_want_to_try_the_beta_version_of_the_next_PostgreSQL_release|16 beta]],[[Apt/FAQ#Development_snapshots|17 devel]]<br />
* Server extensions such as Slony-I, various PL languages, and datatypes<br />
* Applications like omnidb, pgbouncer, and pgpool-II<br />
<br />
Packages for older PostgreSQL versions and older Debian/Ubuntu distributions are deprecated but will continue to stay in the repository (or be moved to apt-archive.postgresql.org), and will usually not be updated anymore.<br />
<br />
==Quickstart==<br />
<br />
'''TL;DR:'''<br />
sudo apt install -y postgresql-common<br />
sudo /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh<br />
<br />
==Manual Repository Configuration==<br />
<br />
Import the repository key from '''https://www.postgresql.org/media/keys/ACCC4CF8.asc''':<br />
<br />
sudo apt install curl ca-certificates<br />
sudo install -d /usr/share/postgresql-common/pgdg<br />
<nowiki>sudo curl -o /usr/share/postgresql-common/pgdg/apt.postgresql.org.asc --fail https://www.postgresql.org/media/keys/ACCC4CF8.asc</nowiki><br />
<br />
Create '''/etc/apt/sources.list.d/pgdg.list'''. The distributions are called ''codename'''''-pgdg'''. In the example, replace ''bookworm'' with the actual distribution you are using. File contents:<br />
<br />
<nowiki>deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.asc] https://apt.postgresql.org/pub/repos/apt</nowiki> '''bookworm'''-pgdg main<br />
<br />
(You may determine the codename of your distribution by running '''lsb_release -c'''). For a script version of the above file creation, presuming you are using a supported release:<br />
<br />
<nowiki>sudo sh -c 'echo "deb [signed-by=/usr/share/postgresql-common/pgdg/apt.postgresql.org.asc] https://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'</nowiki><br />
<br />
Finally, update the package lists, and start installing packages:<br />
<br />
sudo apt update<br />
sudo apt install postgresql-15<br />
<br />
==Notes==<br />
Have a look at the '''[[Apt/FAQ|FAQ]]'''.<br />
<br />
The above does not add the sources repo (deb-src) commented out; if you need source packages, you will need to modify /etc/apt/sources.list.d/pgdg.list to add it.<br />
<br />
This repository provides "postgresql" and "postgresql-client" ''meta-packages'' that depend on the latest postgresql-xy, ... packages, similar to the ones present in Debian and Ubuntu. Once a new PostgreSQL version is released, these meta-packages will be updated to depend on the new version. If you rather want to stay with a particular PostgreSQL version, you should install specific packages like "postgresql-15" instead of "postgresql".<br />
<br />
For packages of development/alpha/beta versions of PostgreSQL, see the [[Apt/FAQ#I_want_to_try_the_beta_version_of_the_next_PostgreSQL_release|FAQ entry about beta versions]].<br />
<br />
==News==<br />
<br />
* 2023-11-05: Ubuntu bionic (18.04) and kinetic (22.10) removed from apt.postgresql.org.<br />
* 2023-08-17: Ubuntu bionic (18.04) moving to apt-archive.postgresql.org: https://www.postgresql.org/message-id/ZN4OigxPJA236qlg%40msg.df7cb.de<br />
* 2022-11-11: Repository key handling changed: https://www.postgresql.org/message-id/Y25%2BRkZxiZKBOKio%40msg.df7cb.de<br />
* 2022-11-07: Debian stretch (9) has been removed: https://www.postgresql.org/message-id/Y2kmqL%2BpCuSZiQBV%40msg.df7cb.de<br />
* 2022-09-19: Ubuntu xenial and impish have been removed from apt.postgresql.org.<br />
* 2022-08-12: Debian stretch (9) is no longer supported and will be removed from apt.postgresql.org at the end of October: https://www.postgresql.org/message-id/YvZaQJpK2TE0nw%2BK%40msg.df7cb.de<br />
* 2022-07-24: Ubuntu impish (21.10) is no longer supported<br />
* 2022-07-06: Ubuntu groovy (20.10) and hirsute (21.04) have been migrated to apt-archive.postgresql.org. xenial (16.04) has been copied as well, and will be removed from apt.postgresql.org at the end of August.<br />
* 2022-07-05:<br />
** PostgreSQL 16devel packages added, see [[Apt/FAQ#Development_snapshots]]<br />
** The repository now features [[Apt/FAQ#Snapshot_distributions|*-pgdg-snapshot distributions]] with snapshot builds of all packages<br />
** We have a [https://twitter.com/pg_apt Twitter feed] now<br />
* 2022-02-16: Ubuntu jammy (22.04) added, hirsute (21.04) is no longer supported<br />
* 2021-09-30: PostgreSQL 14 released<br />
* 2021-08-12: Ubuntu impish (21.10) support added; groovy is no longer supported<br />
* 2021-06-30: PostgreSQL 15devel packages added, see [[Apt/FAQ#Development_snapshots]]<br />
* 2021-05-20: PostgreSQL 14beta1 added, Ubuntu xenial (16.04) deprecated, Ubuntu hirsute (21.04) added<br />
* 2021-01-28: Distributions moving to apt-archive.postgresql.org: jessie wheezy eoan disco trusty precise: https://www.postgresql.org/message-id/YBMtd6nRuXyU2zS4%40msg.df7cb.de<br />
<br />
Older news items: [[Apt/OldNews]]<br />
<br />
==Resources==<br />
<br />
* [[Apt/FAQ|FAQ]]<br />
* [https://apt.postgresql.org/pub/repos/apt/ Package repository]<br />
* [https://qa.debian.org/developer.php?login=pkg-postgresql-public@lists.alioth.debian.org PostgreSQL in Debian]<br />
<br />
===Contact===<br />
<br />
* Mailing list: pgsql-pkg-debian@postgresql.org ([https://archives.postgresql.org/pgsql-pkg-debian/ Archives])<br />
* IRC channel: #postgresql-apt @ irc.libera.chat<br />
<br />
===Maintainers===<br />
<br />
* Christoph Berg (Cybertec)<br />
* Marco Nenciarini (EnterpriseDB)<br />
* Michael Banck (credativ)<br />
<br />
====Past Contributors====<br />
<br />
* Dimitri Fontaine<br />
* Magnus Hagander<br />
<br />
===Bugs===<br />
<br />
Please report bugs:<br />
* on the pgsql-pkg-debian@postgresql.org mailing list, or<br />
* open an issue in [https://redmine.postgresql.org/projects/pgapt/issues Redmine], or<br />
* open a bug in the [https://bugs.debian.org/ Debian BTS].<br />
<br />
===Documentation===<br />
<br />
* [[Apt/RepoDocs]]<br />
* [[Apt/Jenkins]]<br />
* [[Apt/NewPostgreSQLVersion]]<br />
<br />
==Acknowledgements==<br />
<br />
Work on setting up the archive was kindly supported by [https://www.credativ.de/ credativ], [https://www.2ndquadrant.com/ 2ndQuadrant], [https://redpill-linpro.com/ Redpill Linpro],<br />
and funding from the European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement 258862.<br />
<br />
The Jenkins CI server is kindly hosted by [https://www.dg-i.net/ DG-i].<br />
<br />
The ARM build server is kindly hosted by [https://intl.huaweicloud.com/en-us/ HUAWEI Cloud Services].<br />
<br />
The ppc64el build server is kindly hosted by [https://www.ibm.com/ibm/clientcenter/montpellier/ IBM Power Systems Linux Center, Montpellier].<br />
<br />
The s390x build server is kindly hosted by the [https://linuxone.cloud.marist.edu/ IBM LinuxONE Community Cloud at Marist College].<br />
<br />
The repository and the x86 build server are hosted on postgresql.org hardware.</div>Mhahttps://wiki.postgresql.org/index.php?title=PgCon_2023_Developer_Meeting&diff=37696PgCon 2023 Developer Meeting2023-03-28T09:39:45Z<p>Mha: /* 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 />
# Peter Eisentraut<br />
# Andres Freund<br />
# Stephen Frost<br />
# Etsuro Fujita<br />
# Magnus Hagander<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 />
# Heikki Linnakangas<br />
<br />
The following people will not be in Ottawa, and do not plan to attend:<br />
<br />
# Daniel Gustafsson<br />
# Tatsuo Ishii<br />
# Dean Rasheed<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>Mhahttps://wiki.postgresql.org/index.php?title=PgCon_2023_Developer_Meeting&diff=37694PgCon 2023 Developer Meeting2023-03-27T20:18:05Z<p>Mha: /* 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 />
# Peter Eisentraut<br />
# Andres Freund<br />
# Stephen Frost<br />
# Etsuro Fujita<br />
# Magnus Hagander<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 />
# Heikki Linnakangas<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>Mhahttps://wiki.postgresql.org/index.php?title=Apt&diff=36590Apt2021-11-25T11:11:12Z<p>Mha: Clarify what deprecated means</p>
<hr />
<div>==PostgreSQL packages for Debian and Ubuntu==<br />
<br />
The PostgreSQL Global Development Group (PGDG) maintains an APT repository of PostgreSQL packages for Debian and Ubuntu located at http://apt.postgresql.org/pub/repos/apt/.<br />
We aim at building PostgreSQL server packages as well as extensions and modules packages on several Debian/Ubuntu releases for all PostgreSQL versions supported.<br />
<br />
Currently, we support<br />
<br />
* '''Debian 9''' (stretch), '''10''' (buster), '''11''' (bullseye), '''12''' (bookworm), and '''unstable''' (sid)<br />
* '''Ubuntu 18.04''' (bionic), '''20.04''' (focal), '''21.04''' (hirsute, amd64 only), '''21.10''' (impish, amd64 only)<br />
* Architectures: '''amd64''' (64-bit x86), '''i386''' (32-bit x86, being phased out), '''arm64''' (64-bit ARM), '''ppc64el''' (little-endian 64-bit POWER)<br />
* '''PostgreSQL 9.6, 10, 11, 12, 13, 14''', [[Apt/FAQ#Development_snapshots|15 devel]]<br />
* Server extensions such as Slony-I, various PL languages, and datatypes<br />
* Applications like omnidb, pgbouncer, and pgpool-II<br />
<br />
Packages for older PostgreSQL versions and older Debian/Ubuntu distributions are deprecated but will continue to stay in the repository (or be moved to apt-archive.postgresql.org), and will usually not be updated anymore.<br />
<br />
==Quickstart==<br />
<br />
Import the repository key from '''https://www.postgresql.org/media/keys/ACCC4CF8.asc''':<br />
<br />
sudo apt install curl ca-certificates gnupg<br />
<nowiki>curl https://www.postgresql.org/media/keys/ACCC4CF8.asc | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/apt.postgresql.org.gpg >/dev/null</nowiki><br />
<br />
Create '''/etc/apt/sources.list.d/pgdg.list'''. The distributions are called ''codename'''''-pgdg'''. In the example, replace ''buster'' with the actual distribution you are using. File contents:<br />
<br />
<nowiki>deb http://apt.postgresql.org/pub/repos/apt</nowiki> '''buster'''-pgdg main<br />
<br />
(You may determine the codename of your distribution by running '''lsb_release -c'''). For a script version of the above file creation, presuming you are using a supported release:<br />
<br />
<nowiki>sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'</nowiki><br />
<br />
Finally, update the package lists, and start installing packages:<br />
<br />
sudo apt update<br />
sudo apt install postgresql-14<br />
<br />
'''Alternately''', [https://salsa.debian.org/postgresql/postgresql-common/raw/master/pgdg/apt.postgresql.org.sh this shell script] will automate the repository setup.<br />
The script is included in the ''postgresql-common'' package in Debian and Ubuntu, so you can also run it straight from there:<br />
sudo apt install postgresql-common<br />
sudo sh /usr/share/postgresql-common/pgdg/apt.postgresql.org.sh<br />
Note that the shell script leaves the source package repo (deb-src) commented out; if you need source packages, you will need to modify /etc/apt/sources.list.d/pgdg.list to enable it.<br />
<br />
<!--'''9.4 beta only:''' See [[Apt/FAQ#I_want_to_try_the_beta_version_of_the_next_PostgreSQL_release|FAQ on beta releases]]--><br />
Have a look at the '''[[Apt/FAQ|FAQ]]'''.<br />
<br />
'''Note:''' This repository provides "postgresql", "postgresql-contrib", and "postgresql-client" ''meta-packages'' that depend on the latest postgresql-x.y, ... packages, similar to the ones present in Debian and Ubuntu. Once a new PostgreSQL version is released, these meta-packages will be updated to depend on the new version. If you rather want to stay with a particular PostgreSQL version, you should install specific packages like "postgresql-11" instead of "postgresql".<br />
<br />
For packages of development/alpha/beta versions of PostgreSQL, see the [[Apt/FAQ#I_want_to_try_the_beta_version_of_the_next_PostgreSQL_release|FAQ entry about beta versions]].<br />
<br />
==News==<br />
<br />
* 2021-09-30: PostgreSQL 14 released<br />
* 2021-08-12: Ubuntu impish (21.10) support added; groovy is no longer supported<br />
* 2021-06-30: PostgreSQL 15devel packages added, see [[Apt/FAQ#Development_snapshots]]<br />
* 2021-05-20: PostgreSQL 14beta1 added, Ubuntu xenial (16.04) deprecated, Ubuntu hirsute (21.04) added<br />
* 2021-01-28: Distributions moving to apt-archive.postgresql.org: jessie wheezy eoan disco trusty precise: https://www.postgresql.org/message-id/YBMtd6nRuXyU2zS4%40msg.df7cb.de<br />
* 2020-11-12: Ubuntu groovy (20.10) support added<br />
* 2020-09-24: PostgreSQL 13 released<br />
* 2020-07-13: Debian jessie and Ubuntu eoan are unsupported now<br />
* 2020-05-04: arm64 added as new architecture: https://www.df7cb.de/blog/2020/arm64-on-apt.postgresql.org.html<br />
* 2020-03-24: apt-archive.postgresql.org announced: https://www.df7cb.de/blog/2020/apt-archive.postgresql.org.html<br />
* 2020-02-15: Ubuntu focal (20.04) support added<br />
* 2020-01-27: Ubuntu disco (19.04) is no longer supported.<br />
* 2019-08-05: Ubuntu cosmic (18.10) removed, Debian bullseye (11) and Ubuntu eoan (19.10) added.<br />
* 2019-07-03: PostgreSQL 13devel packages added, see [[Apt/FAQ#Development_snapshots]]<br />
* 2019-05-22: PostgreSQL 12beta1 packages added, see [[Apt/FAQ#I_want_to_try_the_beta_version_of_the_next_PostgreSQL_release]]<br />
* 2019-05-14: Ubuntu trusty (14.04) is no longer supported.<br />
* 2019-03-25: Debian jessie/ppc64el disabled because ftp.debian.org removed it. Debian removed jessie-backports (all architectures), so we had to remove postgresql-pllua from jessie-pgdg because it depends on backports.<br />
* 2019-01-26: PostgreSQL 9.3 deprecated, no new modules will be built; Ubuntu disco (19.04) is being prepared<br />
* 2018-11-01: Ubuntu cosmic (18.10) added.<br />
* 2018-05-31: Debian wheezy (7) is unsupported now.<br />
* 2018-05-24: PostgreSQL 11 beta1 packages available, see [[Apt/FAQ#I_want_to_try_the_beta_version_of_the_next_PostgreSQL_release]]<br />
* 2018-01-17: Ubuntu zesty (17.04) is unsupported now, Ubuntu removed it from their mirrors<br />
* 2017-10-05: PostgreSQL 10.0 has been released, postgresql-10 is the default version pulled in by "postgresql.deb" now<br />
* 2017-05-18: PostgreSQL 10beta1 packages added, see [[Apt/FAQ#I_want_to_try_the_beta_version_of_the_next_PostgreSQL_release]]<br />
* 2017-04-25: Ubuntu zesty (17.04) and Debian stretch (9) added, Ubuntu precise (12.04) deprecated: https://www.postgresql.org/message-id/20170425113312.d7odg7juvnunhtex%40msg.credativ.de<br />
* 2017-02-23: postgresql-10 development snapshots available for sid, jessie, xenial, and trusty (via -pgdg-testing): [[Apt/FAQ#Development_snapshots]]<br />
* 2016-09-29: ppc64el added as new architecture, along with full 9.6 support for all packages: https://www.postgresql.org/message-id/c86548a4-eea0-ff5d-9a14-1c136ef39ab6%402ndquadrant.it<br />
* 2016-09-17: Ubuntu wily (15.10) deprecated.<br />
* 2016-09-05: Redmine project for issue tracking: https://redmine.postgresql.org/projects/pgapt/issues<br />
* 2016-07-31: Older versions of packages available: https://www.postgresql.org/message-id/20160731194944.amiwidhsoqh4osac%40msg.df7cb.de<br />
* 2016-03-31: Ubuntu xenial (16.04) added.<br />
* 2016-03-05: Debian squeeze (6) deprecated.<br />
<br />
Older news items: [[Apt/OldNews]]<br />
<br />
==Resources==<br />
<br />
* [[Apt/FAQ|FAQ]]<br />
* [http://apt.postgresql.org/pub/repos/apt/ Package repository]<br />
* [https://qa.debian.org/developer.php?login=pkg-postgresql-public@lists.alioth.debian.org PostgreSQL in Debian]<br />
<br />
===Contact===<br />
<br />
* Mailing list: pgsql-pkg-debian@postgresql.org ([http://archives.postgresql.org/pgsql-pkg-debian/ Archives])<br />
* IRC channel: #postgresql-apt @ irc.libera.chat<br />
<br />
===Maintainers===<br />
<br />
* Christoph Berg (credativ)<br />
* Marco Nenciarini (2ndQuadrant)<br />
* Michael Banck (credativ)<br />
<br />
====Past Contributors====<br />
<br />
* Dimitri Fontaine<br />
* Magnus Hagander<br />
<br />
===Bugs===<br />
<br />
Please report bugs:<br />
* on the pgsql-pkg-debian@postgresql.org mailing list, or<br />
* open an issue in [https://redmine.postgresql.org/projects/pgapt/issues Redmine], or<br />
* open a bug in the [http://bugs.debian.org/ Debian BTS].<br />
<br />
===Documentation===<br />
<br />
* [[Apt/RepoDocs]]<br />
* [[Apt/Jenkins]]<br />
* [[Apt/NewPostgreSQLVersion]]<br />
<br />
==Acknowledgements==<br />
<br />
Work on setting up the archive was kindly supported by [http://www.credativ.de/ credativ], [http://www.2ndquadrant.com/ 2ndQuadrant], [http://redpill-linpro.com/ Redpill Linpro],<br />
and funding from the European Union's Seventh Framework Programme (FP7/2007-2013) under grant agreement 258862.<br />
<br />
The amd64/i386 build servers are kindly hosted by [https://www.dg-i.net/ DG-i] and [https://www.credativ.de/ credativ].<br />
<br />
The ARM build server is kindly hosted by [https://intl.huaweicloud.com/en-us/ HUAWEI Cloud Services].<br />
<br />
The ppc64el build server is kindly hosted by [https://www.ibm.com/ibm/clientcenter/montpellier/ IBM Power Systems Linux Center, Montpellier].<br />
<br />
The repository is hosted on postgresql.org hardware.</div>Mhahttps://wiki.postgresql.org/index.php?title=Working_with_Git&diff=36516Working with Git2021-10-11T21:14:11Z<p>Mha: Recommend https:// over git:// urls.</p>
<hr />
<div>This page collects various wisdom on working with the [http://git.postgresql.org/ PostgreSQL Git repository]. There are also [[Other Git Repositories]] you might work with, most notably the official [http://github.com/postgres Github mirror] which you might fork on that site.<br />
<br />
==Getting Started==<br />
<br />
A simple way to get started might look like this:<br />
<br />
git clone https://git.postgresql.org/git/postgresql.git<br />
cd postgresql<br />
git checkout -b my-cool-feature<br />
$EDITOR<br />
git commit -a<br />
git diff --patience master my-cool-feature > ../my-cool-feature.patch<br />
<br />
Note that <code>git checkout -b my-cool-feature</code> creates a new branch and checks it out at the same time. Typically, you would develop each feature in a separate branch.<br />
<br />
See the documentation and tutorials at http://git.or.cz/ for a more detailed Git introduction. For a more detailed lesson, check out http://progit.org and maybe get a hardcopy to help support the site.<br />
<br />
You may wish to put the following in your .git/info/exclude [[GitExclude]].<br />
Now that the master repository has been converted to git, the standard<br />
.gitignore files should cover all build products, so you don't need<br />
most of what is listed in that reference. You might still want to<br />
exclude *~, tags, and /cscope.out, though.<br />
<br />
=== Keeping your master branch local synchronized ===<br />
<br />
First, add the origin as a remote. You only need to do this once:<br />
<br />
git remote add origin https://git.postgresql.org/git/postgresql.git<br />
<br />
Next, fetch from your public git repository:<br />
<br />
git fetch origin master<br />
<br />
Merge any new patches from your public repository:<br />
<br />
git merge FETCH_HEAD<br />
<br />
Merge in any changes from the main branch:<br />
<br />
git fetch origin master<br />
git merge FETCH_HEAD<br />
<br />
Now check that it still compiles, passes regression, etc. Make sure you've<br />
invoked ./configure, and then:<br />
<br />
make check<br />
make maintainer-clean<br />
<br />
Assuming all that's good, do a dry run.<br />
<br />
git push --dry-run origin master<br />
<br />
If that's happy, push it out to your public repository.<br />
<br />
git push origin master<br />
<br />
If not, fix any merge failures, do an other dry run, and push.<br />
<br />
=== Tracking Other Branches ===<br />
<br />
Lets say you're happy tracking master, but you'd really like to track any one of the other potential branches at git.postgresql.org<br />
<br />
git remote add <super-fun-branch> https://git.postgresql.org/super-fun-branch.git<br />
git fetch super-fun-branch<br />
git checkout super-fun-branch #this will stage your remote branch for a local checkout<br />
git checkout -b super-fun-branch-name #the name can be wahtever you choose<br />
<br />
Now you have a local branch within your local git repo tracking a different branches history. Most importantly, you can now push to that repo if you have to without making an explicit clone to track the history. It's pretty much impossible to not share some common history with the master branch.<br />
<br />
=== Using Back Branches ===<br />
<br />
Since the git repository contains branches for each of the major versions of PostgreSQL, it's easy to work on the latest code from an older version instead of the current one. Here's how you might list the possibilities and checkout an older version:<br />
<br />
git branch -r<br />
git checkout -b REL8_3_STABLE origin/REL8_3_STABLE<br />
<br />
Note that if you've already checked out and used a later version, you might need to clean up some of the files left behind by it. It's suggested to run:<br />
<br />
make maintainer-clean<br />
<br />
To get rid of as many of those as possible. You might need to delete some files left behind after that anyway before git will allow you to do the checkout (src/interfaces/ecpg/preproc/preproc.y can be a problem with the specific example above).<br />
<br />
=== Testing a patch ===<br />
<br />
This is a typical setup to review a patch text file, as typically sent by e-mail:<br />
<br />
git checkout -b feature-to-review<br />
patch -p1 < feature.patch<br />
<br />
If the patch fails to apply, there will be file.rej files left behind showing the part that didn't apply. If your directory tree is clean of build information, you can easily find these later using:<br />
<br />
git status<br />
<br />
=== Patch cleanup ===<br />
<br />
Patch diff submission works best when the author does a round of self-review of the actual patch--not just the code, but the physical diff file produced. [[Creating Clean Patches]] covers practices commonly used to produce better patch diff output.<br />
<br />
==Publishing Your Work==<br />
<br />
If you develop a feature over a longer period of time, you want to allow for intermediate review. The traditional approach to that has been emailing huge patches around. The more advanced approach that we want to try (see also Peter Eisentraut's [http://petereisentraut.blogspot.com/2008/02/on-patch-review.html blog entry]) is that you push your Git branches to a private area on <code>git.postgresql.org</code>, where others can pull your work, operate on it using the familiar Git tools, and perhaps even send you improvements as Git-formatted patches. See [http://git.postgresql.org/adm/help the git.postgresql.org site] for instructions on how to sign up, and how to use the repository. You may need to eventually create a patch via e-mail as part of officially [[Submitting a Patch]].<br />
<br />
==Pushing New Branches==<br />
<br />
If you create a new branch, generally for a new feature test, you'll need to push it to git.postgresql.org. <br />
<br />
git push origin new_feature_branch<br />
<br />
Note that, if you have a completely blank repository then not even the branch "master" will exist and will need to be pushed.<br />
<br />
If you ''are'' working with the postgresql core code, do NOT casually make up your own branches and push them, without clearing it on the pgsql-hackers list first. Generally, you want to use your private repo area instead.<br />
<br />
==Removing a Branch==<br />
<br />
Once your feature has been committed to the PostgreSQL repository, you can usually remove your local feature branch. This works as follows:<br />
<br />
# switch to a different branch<br />
git checkout master<br />
git branch -D my-cool-feature<br />
<br />
==Working with the users/foo/postgres.git==<br />
<br />
One option while requesting a project at git.postgresql.org is to have a clone of the main postgresql repository.<br />
<br />
That is very nice feature, but how do you sync the upstream code?!<br />
<br />
One method is to create a git clone in your own repository and add a new remote to handle the syncing :<br />
<br />
# clone your repos<br />
git clone ssh://git@git.postgresql.org/users/foo/postgres.git my_postgres<br />
<br />
# add a new remote<br />
git remote add pgmaster https://git.postgresql.org/git/postgresql.git<br />
<br />
# track some old versions<br />
git checkout -b REL8_3_STABLE origin/REL8_3_STABLE<br />
git checkout -b REL8_4_STABLE origin/REL8_4_STABLE<br />
<br />
# change the remote of master and our old versions tracked<br />
git config branch.REL8_3_STABLE.remote pgmaster<br />
git config branch.REL8_4_STABLE.remote pgmaster<br />
git config branch.master.remote pgmaster<br />
<br />
# pull from postgres official git for each branch<br />
# and finally push to origin<br />
git checkout master<br />
git pull<br />
git push origin<br />
git checkout REL8_3_STABLE<br />
git pull<br />
git push origin<br />
git checkout REL8_4_STABLE<br />
git pull<br />
git push origin<br />
<br />
<br />
This way, PostgreSQL is easy to sync for each branch. Pulling from the official and pushing to your own repository.<br />
<br />
Create your own branch and work as usual. Users who have a local clone of the postgresql.git can add your branch in their repository and happily merge, just as you do.<br />
<br />
==Using the Web Interface==<br />
<br />
Try the web interface at http://git.postgresql.org/. It offers browsing, "blame" functionality, snapshots, and other advanced features, and it is much faster than CVSweb. Even if you don't care for Git or version control systems, you will probably enjoy the web interface.<br />
<br />
==RSS Feeds==<br />
<br />
The Git service provides RSS feeds that report about commits to the repositories. Some people may find this to be an alternative to subscribing to the pgsql-committers mailing list. The URL for the RSS feed from the PostgreSQL repository is http://git.postgresql.org/gitweb/?p=postgresql.git;a=rss. Other options are available; they can be found via the [http://git.postgresql.org/ home page] of the web interface.<br />
<br />
==PostgreSQL Style==<br />
<br />
The PostgreSQL source uses 4-character tabs, making the output from <code>git diff</code> look odd. You can fix that by putting this into your.<code>git/config</code> file:<br />
<br />
[core]<br />
pager = less -x4<br />
<br />
==Continuing the "rsync the CVSROOT" workflow==<br />
<br />
Aidan van Dyk {{messageLink|20090602162347.GF23972@yugib.highrise.ca|published a nice tutorial}} on how to keep several branches using a single copy of historical objects. This is roughly equivalent to keeping several checkouts of a rsync'ed copy of CVSROOT, which is what some committers were used to doing with CVS.<br />
<br />
<br />
[[Category:Git]]</div>Mhahttps://wiki.postgresql.org/index.php?title=Committers&diff=36241Committers2021-07-08T10:50:46Z<p>Mha: </p>
<hr />
<div>This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit or when added as a committer, oldest first; this isn't intended to imply anything about depth of contribution.<br />
<br />
* Bruce Momjian (momjian)<br />
* Tom Lane (tgl)<br />
* Michael Meskes (meskes)<br />
* Tatsuo Ishii (ishii)<br />
* Peter Eisentraut (petere)<br />
* Joe Conway (joe)<br />
* Alvaro Herrera (alvherre)<br />
* Andrew Dunstan (adunstan)<br />
* Magnus Hagander (mha)<br />
* Heikki Linnakangas (heikki)<br />
* Robert Haas (rhaas)<br />
* Jeff Davis (jdavis)<br />
* Stephen Frost (sfrost)<br />
* Fujii Masao (fujii)<br />
* Noah Misch (noah)<br />
* Andres Freund (andres)<br />
* Dean Rasheed (deanr)<br />
* Andrew Gierth (rhodiumtoad)<br />
* Alexander Korotkov (smagen)<br />
* Amit Kapila (amitkapila)<br />
* Tomas Vondra (fuzzycz)<br />
* Michael Paquier (michael-kun)<br />
* Thomas Munro (macdice)<br />
* Peter Geoghegan (pgeoghegan)<br />
* Etsuro Fujita (efujita)<br />
* David Rowley (drowley)<br />
* Daniel Gustafsson (d_gustafsson)<br />
* John Naylor (john.naylor)<br />
<br />
== Notes on the Commit Log ==<br />
<br />
Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole. <br />
<br />
== New Committers and Removing Committers ==<br />
<br />
New committers are added approximately annually by the Core Team. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:<br />
<br />
* several years of substantial contributions to the project<br />
* multiple and continuing code contributions<br />
* responsibility for maintenance of one or more areas of the codebase<br />
* track record of reviewing and helping other contributors with their patches<br />
* high quality code contributions which require very little revision or correction for commit<br />
* demonstrated understanding of the process and criteria for patch acceptance<br />
<br />
Generally, new committers are selected March or April and announced at pgCon.<br />
<br />
Committers who have become inactive and have not contributed significantly to the PostgreSQL project in several years are removed as committers. Again, the review process for this is approximately annual.<br />
<br />
[[Category:Community]]</div>Mhahttps://wiki.postgresql.org/index.php?title=Committers&diff=36232Committers2021-07-02T13:20:59Z<p>Mha: </p>
<hr />
<div>This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit or when added as a committer, oldest first; this isn't intended to imply anything about depth of contribution.<br />
<br />
* Bruce Momjian (momjian)<br />
* Tom Lane (tgl)<br />
* Michael Meskes (meskes)<br />
* Tatsuo Ishii (ishii)<br />
* Peter Eisentraut (petere)<br />
* Joe Conway (joe)<br />
* Alvaro Herrera (alvherre)<br />
* Andrew Dunstan (adunstan)<br />
* Magnus Hagander (mha)<br />
* Heikki Linnakangas (heikki)<br />
* Robert Haas (rhaas)<br />
* Jeff Davis (jdavis)<br />
* Stephen Frost (sfrost)<br />
* Fujii Masao (fujii)<br />
* Noah Misch (noah)<br />
* Andres Freund (andres)<br />
* Dean Rasheed (deanr)<br />
* Andrew Gierth (rhodiumtoad)<br />
* Alexander Korotkov (smagen)<br />
* Amit Kapila (amitkapila)<br />
* Tomas Vondra (fuzzycz)<br />
* Michael Paquier (michael-kun)<br />
* Thomas Munro (macdice)<br />
* Peter Geoghegan (pgeoghegan)<br />
* Etsuro Fujita (efujita)<br />
* David Rowley (drowley)<br />
* Daniel Gustafsson (d_gustafsson)<br />
<br />
== Notes on the Commit Log ==<br />
<br />
Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole. <br />
<br />
== New Committers and Removing Committers ==<br />
<br />
New committers are added approximately annually by the Core Team. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:<br />
<br />
* several years of substantial contributions to the project<br />
* multiple and continuing code contributions<br />
* responsibility for maintenance of one or more areas of the codebase<br />
* track record of reviewing and helping other contributors with their patches<br />
* high quality code contributions which require very little revision or correction for commit<br />
* demonstrated understanding of the process and criteria for patch acceptance<br />
<br />
Generally, new committers are selected March or April and announced at pgCon.<br />
<br />
Committers who have become inactive and have not contributed significantly to the PostgreSQL project in several years are removed as committers. Again, the review process for this is approximately annual.<br />
<br />
[[Category:Community]]</div>Mhahttps://wiki.postgresql.org/index.php?title=UPSERT&diff=36087UPSERT2021-05-30T16:27:19Z<p>Mha: </p>
<hr />
<div>This page summarizes the <tt>INSERT ... ON CONFLICT UPDATE</tt> patch. This feature is popularly known as "UPSERT".<br />
<br />
The patch has been committed [http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=168d5805e4c08bed7b95d351bf097cff7c07dd65], and will appear in PostgreSQL 9.5. This Wiki page was only maintained until a few weeks before commit, where the patch further evolved in some minor aspects (most notably, the syntax became <tt>ON CONFLICT DO UPDATE/NOTHING</tt>). It is now only of historic interest.<br />
<br />
CommitFest entry: https://commitfest.postgresql.org/3/35/<br />
<br />
Committed version's INSERT documentation: http://www.postgresql.org/docs/devel/static/sql-insert.html<br />
<br />
= "UPSERT" definition =<br />
<br />
"UPSERT" is a DBMS feature that allows a DML statement's author to atomically either insert a row, or on the basis of the row already existing, <tt>UPDATE</tt> that existing row instead, while safely giving little to no further thought to concurrency. One of those two outcomes must be guaranteed, regardless of concurrent activity, which has been called "the essential property of UPSERT". Examples include MySQL's <tt>INSERT...ON DUPLICATE KEY UPDATE</tt>, or VoltDB's <tt>UPSERT</tt> statement.<br />
<br />
The absence of this feature from Postgres has been a long-standing complaint from Postgres users [http://petereisentraut.blogspot.com/2010/05/merge-syntax.html] [http://lucumr.pocoo.org/2014/2/16/a-case-for-upserts/] [http://lwn.net/Articles/601144/] [https://postgresql.uservoice.com/forums/21853-general].<br />
<br />
= Goals for implementation =<br />
<br />
<b>Primary goals:</b><br />
<br />
* In general, guarantee insert-or-update "atomicity" for the simple cases - guarantee one or the other of those two outcomes ("the essential property of UPSERT"). Don't be inferior in any way to existing, subxact-looping approach to UPSERT.<br />
** Avoid having to invent "<tt>READ COMMITTED</tt> serialization failures" [http://www.postgresql.org/message-id/CAM3SWZQXBWR6UaxcR7fNkUP-bss0zRO2dp7UWofxh1tWO8SoeA@mail.gmail.com]. These seem like a cop out. This goal is a special case of our first primary goal.<br />
** Avoid "unprincipled deadlocks" - deadlocks that the user has no reasonable way of avoiding [https://wiki.postgresql.org/wiki/Value_locking#.22Unprincipled_Deadlocking.22_and_value_locking]. These too seem like a cop out. Again, this goal is a special case of our first primary goal.<br />
* Advance usability over the status quo - don't introduce a feature with significant foot-guns, unnecessary subtle behaviors, or big performance surprises<br />
<br />
As outlined below, SQL <tt>MERGE</tt> seemingly <i>doesn't</i> meet this standard (principally because it lacks "the essential property of UPSERT", which appears to be in tension with supporting a fully flexible join).<br />
<br />
<b>Secondary goal:</b><br />
<br />
* Avoid duplicate key violations that the implementation must trap and handle. Don't burn through XIDs with expensive subtransactions - the existing, subxact-looping approach to UPSERT implies that XIDs are consumed at an intractably high rate (intractable for at least some use cases, like the multi-master replication conflict resolution use case).<br />
<br />
<b>Tertiary goals:</b><br />
<br />
* Support for UPSERT of multiple values in one operation is desirable. The current looping approach really needs to loop over single values, making UPSERT of significant numbers of rows very slow.<br />
* It would be nice to offer an <tt>INSERT IGNORE</tt> - the ability to not proceed with insertion in respect of certain slots/rows proposed for insertion when doing so implies a unique violation must be thrown. This is primarily important for ETL-type use cases.<br />
<br />
= Current Status of patch =<br />
<br />
<b>Important:</b> Note that <tt>git format-patch</tt> has been used to generate cumulative patch set revisions. The code is structured to be cumulative, and has extensive commit message commentary, to make its integration into PostgreSQL as straightforward as possible. These commit messages are thought to be a useful way of gaining an understanding of how the proposed <tt>ON CONFLICT UPDATE/IGNORE</tt> patch fits together.<br />
<br />
<strike>Note that approach #1 and #2 to [[Value locking]] are being maintained in parallel. When "V1.X" is referred to, there are actually two cumulative patchsets [http://git-scm.com/docs/git-format-patch] of "V1.X" (one for each approach to [[Value locking]])</strike>.<br />
<br />
<b>Update:</b> As of V2.0, only approach #2 to value locking is being maintained.<br />
<br />
== Revisions ==<br />
<br />
Committing <tt>ON CONFLICT IGNORE</tt> first is now considered to be the best way of committing the code incrementally [http://www.postgresql.org/message-id/54F56B42.2010304@iki.fi].<br />
<br />
Most recently, V4.0 posted. Featured further revamp of RLS, and integrated the recent clean-up work of Andres, Peter and Heikki.<br />
<br />
Before that, V3.4 posted. Featured new approach to RLS, and somewhat refined handling of WAL-logging and logical decoding (essentially, a hybrid of earlier approaches).Before that, V3.3 posted. Featured full support for <tt>ON CONFLICT IGNORE</tt> with updatable views (<tt>UPDATE</tt> remains unsupported), and a new, refactored approach to logical decoding. Before that, V3.2 posted. Features full inheritance support, new approach to WAL logging to suit logical decoding. Also, multiple indexes can be inferred at once. Collations and opclasses can now be specified in inference clause, in case they are ever semantically significant. Before that, V3.1 posted. This featured refinements to value locking scheme, so that tokens were stored directly in <tt>t_ctid</tt> field in tuples. Before that, V3.0 posted. This featured a new way of breaking out the code (<tt>ON CONFLICT IGNORE</tt> is the first in a series of cumulative patches ending in <tt>ON CONFLICT UPDATE</tt>), and logical decoding fixes.<br />
<br />
Before that, V2.3 posted. This featured an overhaul of tqual.c visibility routine's handling of "super deleted" tuples, livelock insurance for exclusion constraints, plus some miscellaneous polishing. Before that, v2.2 posted. This featured extensive refactoring, following feedback from Andres Freund. Before that, V2.1 posted. This had a minor bug fix for an issue with user-defined rules, as well as fixing some bit-rot. Before that, V2.0 posted, adding support for row-level security. This was very significant because it closes out all open issues with support for/by interrelated features (e.g. inheritance, updatable views). Issues around semantics now seem all but settled. Now, the core mechanism and code should be our focus.<br />
<br />
Before that, V1.8 posted, which has support for partial index inference, making it possible to use partial unique indexes with the ON CONFLICT UPDATE variant. Before that, V1.7 posted, which featured minor clean-up. Before that, V1.6 posted, which had slight tweaks to per-statement trigger execution order, as well as minor documentation and comment fix-ups. Before that, V1.5 posted, establishing new <tt>RETURNING</tt> behavior (updated tuples projected). Before that, V1.4 posted, which includes support for <tt>postgres_fdw</tt>, costing of arbiter unique indexes where there are multiple alternatives, and a pseudo-alias syntax (which makes aliases <tt>TARGET.*</tt> and <tt>EXCLUDED.*</tt> visible in <tt>UPDATE</tt> auxiliary query only - compare <tt>OLD.*</tt> and <tt>NEW.*</tt> in the context of user-defined rules). Controversy over "failure to play nice" with other features has died down, as has controversy over syntax, and to a large extent controversy over value locking.<br />
<br />
When V1.3 was posted, it added "unique index inference", requiring users to always specify which unique index they'd like to use as an arbiter of whether on not the update path should be taken (this is inferred in the sense that a unique index isn't directly named, but rather the implementation figures that out based on a set of columns/expressions). This is mandatory for the <tt>ON CONFLICT UPDATE</tt> variant, but optional for the <tt>ON CONFLICT IGNORE</tt> variant. We're currently still looking at approaches to value locking. Approach #2 has been integrated into a revised patch with the same revised syntax, as a stepping stone to settling questions around value locking. We are now well equipped to compare at least approach #1 and #2 to [[value locking]].<br />
<br />
== Documentation ==<br />
<br />
(This used to live in a third party S3 bucket, which has since been deleted)<br />
<br />
== Testing ==<br />
<br />
Apart from the main regression and isolation tests included with the patch set, there has also been extensive use of stress-testing as part of the development of the patch. A stress-testing suite in maintained here: https://github.com/petergeoghegan/upsert.<br />
<br />
Jeff Janes wrote a variant of his general-purpose stress-testing suite that was very useful for flushing out bugs. It is maintained separately here: https://github.com/petergeoghegan/jjanes_upsert.<br />
<br />
== PgCon Talk ==<br />
<br />
A reasonable overview of the <i>trade-off</i> involved in implementing UPSERT (i.e. the tension between linking value locking and row locking) was a focus of Peter Geoghegan's pgCon talk, [http://www.pgcon.org/2014/schedule/attachments/327_upsert_weird.pdf "Why UPSERT is weird"]. Note that this relates to an obsolete version of the syntax, but that should mostly not matter.<br />
<br />
= UPSERT as implemented in practice =<br />
<br />
Discussion of how users of RDBMS systems in general deal with the UPSERT problem today. This includes all currently released versions of PostgreSQL, and a number of other SQL-based systems, too.<br />
<br />
== PostgreSQL (today) ==<br />
<br />
To correctly UPSERT in PostgreSQL today, without any dedicated, native support, one must use a retry loop in <tt>READ COMMITTED</tt> mode. The ad-hoc implementation should attempt an <tt>INSERT</tt>, and if that fails, <tt>UPDATE</tt>. The implementation must loop until one of those two outcomes occurs, since is general <tt>INSERT</tt>s and <tt>UPDATE</tt>s may be hindered by concurrent activity in a way that makes neither an <tt>INSERT</tt> or <tt>UPDATE</tt> occur (e.g. a duplicate violation can occur, or the <tt>UPDATE</tt> may not affect any rows).<br />
<br />
See:<br />
<br />
* [http://www.postgresql.org/docs/9.4/static/plpgsql-control-structures.html#PLPGSQL-ERROR-TRAPPING PL/PgSQL upsert example from manual]<br />
* [http://www.depesz.com/2012/06/10/why-is-upsert-so-complicated/ Depesz - why is upsert so complicated]<br />
* [http://stackoverflow.com/q/17267417/398670 How do I do an UPSERT (<tt>MERGE</tt>, <tt>INSERT … ON DUPLICATE UPDATE</tt>) in PostgreSQL?]<br />
* [http://stackoverflow.com/q/1109061/398670 Insert, on duplicate update in PostgreSQL?]<br />
<br />
Many users attempt to use naïve approaches, like an <tt>UPDATE</tt> followed by an <tt>INSERT ... IF NOT EXISTS</tt> that fall down in the face of concurrent operation. Another common though incorrect approach in PostgreSQL is to use data-modifying CTEs. The correct solution is slow and clumsy to use, and is unsuitable for significant amounts of data. It also potentially burns through a lot of subtransaction IDs - avoiding burning XIDs is an explicit goal of the current "native UPSERT in PostgreSQL" effort.<br />
<br />
== Oracle, MS-SQL, DB2: SQL <tt>MERGE</tt> ==<br />
<br />
Users of MS-SQL and Oracle frequently use <tt>MERGE</tt> to implement an upsert operation. However, users often incorrectly assume that <tt>MERGE</tt> is immune to concurrency effects, e.g:<br />
<br />
* [http://stackoverflow.com/q/237327/398670 Oracle: how to UPSERT (update or insert into a table?)]<br />
* [http://stackoverflow.com/q/2479488/398670 syntax for single row <tt>MERGE</tt> / upsert in SQL Server]<br />
* [http://www.sergeyv.com/blog/archive/2010/09/10/sql-server-upsert-equivalent.aspx SQL Server UPSERT equivalent]<br />
* [http://www.sqlservercentral.com/Forums/Topic1316908-391-1.aspx Is <tt>MERGE</tt> always the way to go for upserts?]<br />
* [http://dba.stackexchange.com/q/21418/7788 Is there a better alternative to <tt>MERGE</tt> or <tt>@@rowcount</tt>?]<br />
* [http://weblogs.sqlteam.com/dang/archive/2009/01/31/UPSERT-Race-Condition-With-MERGE.aspx Upsert race condition with <tt>MERGE</tt>]<br />
* [http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0010873.html?cp=SSEPGG_10.5.0%2F2-12-7-168&lang=en DB2 <tt>MERGE</tt> statement].<br />
* [https://www.ibm.com/developerworks/community/blogs/SQLTips4DB2LUW/entry/merge?lang=en More on DB2 <tt>MERGE</tt>]<br />
* [http://stackoverflow.com/questions/330241/does-db2-have-an-insert-or-update-statement Discussion of UPSERTs in DB2].<br />
<br />
The apparent confusion on what problem <tt>MERGE</tt> is or is not intended to solve seems unlikely, but in fact there is plenty of evidence for it. Although it has been a problem for as long as <tt>MERGE</tt> has existed, people continue to be confused by it. Many of the above links are quite recent.<br />
<br />
Documentation for Oracle and MS SQL makes no reference to concurrency in <tt>MERGE</tt>, as noted in the Syntax section below.<br />
<br />
Also, <tt>MERGE</tt> can do a lot more than a simple upsert, and has somewhat complex/verbose syntax as a result.<br />
<br />
Bizarrely, in addition to <tt>MERGE</tt>, Oracle offers a "hint" that has the executor <tt>IGNORE</tt> would-be duplicate violations [http://richardfoote.wordpress.com/2010/12/20/oracle11g-ignore_row_on_dupkey_index-hint-micro-cuts/].<br />
<br />
== MySQL: <tt>INSERT ... ON DUPLICATE KEY UPDATE</tt> ==<br />
<br />
MySQL offers [http://dev.mysql.com/doc/refman/5.7/en/insert-on-duplicate.html <tt>INSERT ... ON DUPLICATE KEY UPDATE</tt>], which is widely used and understood. Although it has some "gotchas" that we hope to avoid (e.g. "If more than one unique index is matched, only the first is updated. It is not recommended to use this statement on tables with more than one unique index."[https://mariadb.com/kb/en/mariadb/documentation/sql-commands/data-manipulation/insert-commands/insert-on-duplicate-key-update/]), it does make guarantees around concurrency, and so offers something broadly comparable to the <tt>ON CONFLICT UPDATE</tt> patch.<br />
<br />
== SQLite: <tt> ... ON CONFLICT ... </tt> / <tt>INSERT/UPDATE ... OR ...</tt> ==<br />
<br />
SQLite has an [https://www.sqlite.org/lang_conflict.html <tt>ON CONFLICT</tt> clause for <tt>INSERT</tt>].<br />
<br />
SQLite's <tt>ON CONFLICT</tt> clause may apply to constraints (other than foreign key constraints). It isn't just an UPSERT feature, though that's one of its roles.<br />
<br />
It's logical to consider PostgreSQL's constraints as if they are unconditionally defined as <tt>ON CONFLICT ROLLBACK</tt>.<br />
<br />
For UPSERT, SQLite offers the shortened syntax <tt>OR</tt> instead of <tt>ON CONFLICT</tt>, but the behavior is the same.<br />
<br />
== Teradata ==<br />
<br />
Teradata offers a non-standard UPSERT (which they call "UPSERT", or occasionally "atomic UPSERT") [http://www.info.teradata.com/htmlpubs/DB_TTU_14_00/index.html#page/Connectivity/B035_2509_071A/2509ch06.08.43.html], <i>as well as</i> SQL <tt>MERGE</tt> [http://www.info.teradata.com/htmlpubs/DB_TTU_14_00/index.html#page/SQL_Reference/B035_1146_111A/ch03.034.302.html]. The former appeared in an earlier version of Teradata than the latter. This suggests that having both features at once may make sense. The UPSERT implementation also appears to offer guarantees around concurrency, and so is broadly comparable to the <tt>ON CONFLICT UPDATE</tt> feature proposed for PostgreSQL.<br />
<br />
== VoltDB ==<br />
<br />
VoltDB recently added a new UPSERT feature:<br />
<br />
http://voltdb.com/blog/new-powerful-way-do-upserts-voltdb<br />
<br />
This feature is invoked via a non-standard <tt>INSERT</tt> variant syntax. This implementation also appears to offer guarantees around concurrency, and so is broadly comparable to the <tt>ON CONFLICT UPDATE</tt> feature proposed for PostgreSQL.<br />
<br />
= Syntax discussion =<br />
<br />
Discussion of syntax we could use, and syntax of proposed patch. Includes limitations implied by syntax of proposed patch.<br />
<br />
== SQL <tt>MERGE</tt> syntax ==<br />
<br />
The SQL standard provides a <tt>MERGE</tt> statement, and says:<br />
<br />
<blockquote><br />
If a table T, as well as being updatable, is insertable-into, then rows can be inserted into it (subject to applicable<br />
Access Rules and Conformance Rules). The primary effect of an <insert statement> on T is to insert into T<br />
each of the zero or more rows contained in a specified table. The primary effect of a <merge statement> on T<br />
is to replace zero or more rows in T with specified rows and/or to insert into T zero or more specified rows,<br />
depending on the result of a <search condition> and on whether one or both of <merge when matched clause><br />
and <merge when not matched clause> are specified.<br />
</blockquote><br />
<br />
The syntax specified by the standard (leaving out <override clause> for the <tt>INSERT</tt> case, since we don't support that for plain old <tt>INSERT</tt>) is:<br />
<br />
<code><br />
MERGE INTO table_name [ [ AS ] alias ]<br />
USING { table_name | ( subquery ) } [ [ AS ] alias ]<br />
ON condition<br />
[ WHEN MATCHED THEN<br />
UPDATE SET { column_name = expression } [, ...] ]<br />
[ WHEN NOT MATCHED THEN<br />
INSERT [ ( column_name [, ...] ) ] VALUES ( expression [, ...] ) ]<br />
</code><br />
<br />
(Technically, the WHEN clauses can be in either order, but each is only allowed once.)<br />
<br />
Some database products have extended the standard syntax; for example, adding the option to say "AND expression" after WHEN or allowing MATCHED or NOT MATCHED to be present more than once. In some cases a DELETE option is allowed as a product-specific extension.<br />
<br />
The standard does not generally address implementation techniques, so it contains no mention of indexes, 2PL, or MVCC regarding any statement. To use the techniques being discussed for UPSERT, the ON condition would need to allow matching from the second table name (or the subquery) to the target table on a unique index. Kevin Grittner has suggested requiring such a match for the initial implementation.<br />
<br />
=== <tt>MERGE</tt> advantages ===<br />
<br />
* In the SQL Standard<br />
* Already used (if not necessarily correctly) by many users and products<br />
* <tt>JOIN</tt> can be optimized usefully. For example, in systems with support for SQL <tt>MERGE</tt>, it appears to be possible for the optimizer to vary its choice of join algorithm (often it's a nestloop join, but it doesn't have to be - there doesn't even have to be an index on the target table). This is particularly important for the bulk loading/datawarehousing use case that <tt>MERGE</tt> addresses very well - the general-purpose merge join algorithm can be used for big bulk operations.<br />
<br />
=== <tt>MERGE</tt> disadvantages ===<br />
<br />
* The SQL standard doesn't specify concurrency behaviour for <tt>MERGE</tt> any more than it does for <tt>INSERT</tt>, <tt>UPDATE</tt>, or <tt>DELETE</tt>; so (like other DML) our behavior with concurrent access may not be the same as other database products. In particular, the SQL standard does not require that <tt>MERGE</tt> be atomic in the sense of atomically providing either an <tt>INSERT</tt> or <tt>UPDATE</tt>, and other products do not provide any such guarantees with their <tt>MERGE</tt> statement.<br />
<br />
* The SQL-standard <tt>MERGE</tt> doesn't provide for choosing an index, so use of a unique index would need to be conditioned on equality quals against indexed columns in order to provide the behavior being discussed for UPSERT.<br />
<br />
* Implementing an extended subset of <tt>MERGE</tt> support for UPSERT will impact a future implementation of full <tt>MERGE</tt> support:<br />
** Different concurrency and locking semantics will be needed for a <tt>MERGE</tt> without equality quals matching a unique index of the target table.<br />
** Users may be very surprised when failure to compare for equality on the columns of a unique index results in slower execution or less graceful interaction with other transactions, such as deadlocks.<br />
** The design for <tt>MERGE</tt> when the conditions don't allow joining using a unique index has not yet been done. It may require different locking, allow deadlocks or other serialization failures, or allow the same anomalies which can occur with other DML statements, and which will not be possible when the unique index is used.<br />
<br />
* If a subquery (rather than a direct table reference) is used for the second relation reference, there is no restriction on what that subquery may join on. Delineating the cases where we must use a dirty snapshot, and where we must use an MVCC snapshot seems very difficult and subtle - Peter Geoghegan [http://www.postgresql.org/message-id/CAM3SWZT7jS6nS2vQyxwV6k7MfPorAqK4DJa0r9dCiE=qBS09dQ@mail.gmail.com] [http://www.postgresql.org/message-id/CAM3SWZRnFxAHKrxYXrCLYOvQsEqewaNkF2t_tYvYO_7Lnk27Ug@mail.gmail.com].<br />
<br />
* The ON expression will need to be evaluated to see whether it properly compares to a unique index on the target table. Initially this will need to be done to determine whether the <tt>MERGE</tt> is allowed at all; later it will determine which sort of plan is allowed. It would be easier to match an index name, provided the index name is known and stable.<br />
<br />
* <tt>MERGE</tt> will probably need to fire before row insert triggers <i>after</i> deciding to insert, since in general it cannot reverse the triggers having been fired - the implementation should probably have decided on insertion by then. In contrast, UPSERT will have to fire before row triggers <i>before</i> deciding to <tt>INSERT</tt> or <tt>UPDATE</tt> (by value locking the value extracted from the affected tuple) [http://www.postgresql.org/message-id/CAM3SWZSXRjV_i5Zx3wWq3W7LSp5X09RE_ZYZH5V9TAUu7aCwzA@mail.gmail.com]. With UPSERT, we are deciding to take the alternative path based on the modified tuple. With <tt>MERGE</tt>, we may prefer not to.<br />
<br />
=== Detailed comments and concerns ===<br />
<br />
The SQL standard does not and cannot really comment on concurrency for <tt>MERGE</tt> any more than it does for <tt>INSERT</tt>, <tt>UPDATE</tt>, and <tt>DELETE</tt>. It never mentions indexes or any particular concurrency control mechanism; instead it describes the the minimum requirements at each isolation level (allowing any product to provide additional guarantees as it sees fit and is able to do so). So, the minimum requirement for the <tt>MERGE</tt> statement at any isolation level is the same as for other DML. We are considering an UPSERT implementation which would be providing additional guarantees; so for the case where matching on a unique index is possible, there would be guarantees beyond other cases, which we would need to document. There are concerns that:<br />
# The different guarantees with and without the index may confuse users.<br />
# Users may sometimes fail to match an index when they ''think'' they are matching; resulting in slower performance and different handling of concurrency problems.<br />
# The different plans used with and without the index may result in messy code.<br />
<br />
Peter Geoghegan gave a reasonable overview of why <tt>MERGE</tt> is quite different from a pragmatic UPSERT implementation in the pgsql-hackers thread [http://www.postgresql.org/message-id/CAM3SWZRP0c3g6+aJ=YYDGYAcTZg0xA8-1_FCVo5Xm7hrEL34kw@mail.gmail.com SQL <tt>MERGE</tt> is quite distinct from UPSERT]. It seems quite reasonable to suppose that one day PostgreSQL will have both "UPSERT" and SQL <tt>MERGE</tt>, since each addresses distinct use-cases, even if that isn't well understood by the user community at large.<br />
<br />
== Adopting an existing non-standard syntax ==<br />
<br />
We could potentially gain better uptake by using an existing vendor's syntax, but would be bound to conform more closely to expectations about the behavior and capabilities of that vendor's feature.<br />
<br />
=== MySQL's <tt>INSERT ... ON DUPLICATE KEY UPDATE</tt> ===<br />
<br />
Does not provide a mechanism for specifying an arbiter unique index. DML query author must know ahead of time that a conflict is only possible when it originates from one particular unique index. MySQL docs advise against using the statement when there is more than one unique index to begin with, which seems very restrictive (this seems to have something to do with it breaking their statement-based/logical replication - the order that unique indexes are considered is apparently storage engine defined).<br />
<br />
MySQL's <tt>INSERT IGNORE</tt> is not equivalent to <tt>INSERT...ON CONFLICT IGNORE</tt>, in that it ignores not-NULL violations. This seems undesirable, and for the purposes of <tt>ON CONFLICT UPDATE</tt>, a conflict is always a duplicate violation (or possibly an exclusion constraint violation for <tt>ON CONFLICT IGNORE</tt>). NULL values can always be filtered with things like an IS NULL in a query predicate. <tt>ON CONFLICT UPDATE/IGNORE</tt> concerns conflicts that are fundamentally unpredictable, in that they relate to the state of the entire table (including state not visible to the command's MVCC snapshot).<br />
<br />
=== SQLite's <tt>INSERT ... ON CONFLICT REPLACE</tt> ===<br />
<br />
Similarly, does not accept an arbiter unique index. Same objections apply with the SQLite command as apply to MySQL's UPSERT (the <tt>INSERT ... ON DUPLICATE KEY UPDATE</tt> command).<br />
<br />
=== Teradata's Atomic UPSERT (<tt>UPDATE ... ELSE INSERT ...</tt>) ===<br />
<br />
Little used, not much advantage over rolling our own. Does seem to mandate <tt>UPDATE</tt> predicate that implies one particular unique index, and does make concurrency guarantees, though.<br />
<br />
=== VoltDB's UPSERT ===<br />
<br />
VoltDB's new UPSERT command [http://docs.voltdb.com/UsingVoltDB/sqlref_upsert.php] allows the user to UPSERT, with it only being possible to <tt>UPDATE</tt> using the excluded-from-insert tuple as a whole (without specifying which attributes to <tt>UPDATE</tt> when the alternative path is taken <i>at all</i>). This simplicity does have a certain appeal [http://www.postgresql.org/message-id/CA+TgmoZN=2AJKi1n4Jz5BkmYi8r_CPUDW+DtoppmTeLVmsOoqw@mail.gmail.com].<br />
<br />
Adopting VoltDB's UPSERT command for PostgreSQL (or any non-standard syntax that has the implementation simply do a whole-row <tt>UPDATE</tt> in the event of a would-be conflict) is thought to imply usability issues that are unlikely to be acceptable [http://www.postgresql.org/message-id/CAM3SWZT=VXBJ7QKAidAmYbU40aP10udSqOOqhViX3Ykj7WBv9A@mail.gmail.com].<br />
<br />
== Syntax as proposed in the patch - <tt>INSERT ... ON CONFLICT {UPDATE | IGNORE}</tt> ==<br />
<br />
The proposed <tt>INSERT ... ON CONFLICT UPDATE</tt> patch is most comparable to Teradata's <tt>UPSERT</tt>, or VoltDB's <tt>UPSERT</tt>, or MySQL's <tt>INSERT ... ON DUPLICATE UPDATE</tt>, or SQLite's <tt>INSERT ... ON CONFLICT REPLACE</tt>. It is essentially an entirely custom syntax, though.<br />
<br />
=== Custom syntax advantages ===<br />
<br />
* Total freedom to define semantics<br />
<br />
* Quicker and easier to implement<br />
<br />
=== Custom syntax disadvantages ===<br />
<br />
* Users of ORMs etc need to add support to their tools, wait for support to be added, or break out into "native SQL" and do direct queries. Given the huge adoption of ORMs like JPA (Hibernate/EclipseLink/etc), ActiveRecord, etc, this is a serious concern; it will take longer for the feature to be accessible to users. On the other hand, there doesn't seem to be any evidence of these ORMs currently supporting SQL <tt>MERGE</tt>, possibly because of its failure to guarantee atomicity. Also, the Django people have expressed interest in the new syntax. Django core team member and notable Postgres-feature-implementer [https://www.kickstarter.com/projects/mjtamlyn/improved-postgresql-support-in-django Marc Tamlyn] said of the new syntax: "So in my opinion, yes we would support it in a future version of Django, potentially not that far in the future" [https://groups.google.com/forum/#!msg/django-developers/hdzkoLYVjBY/8b9J5dVgMToJ].<br />
<br />
* Barrier to adoption/understanding<br />
<br />
* We risk inventing new problems along with our new solutions, then being stuck with them<br />
<br />
* Non-standard<br />
<br />
* To the extent that a non-standard syntax represents a "true UPSERT", with strict guarantees around concurrency that meet our goals for UPSERT in PostgreSQL, the custom syntax also implies that there is no useful optimization leeway. There is no conventional join involved, and so bulk loading/data warehousing use cases will probably be better off with SQL <tt>MERGE</tt>.<br />
<br />
=== Overview of <tt>ON CONFLICT</tt> syntax itself ===<br />
<br />
The proposed patch modifies the INSERT statement such that its syntax matches this description:<br />
<br />
<code><br />
[ WITH [ RECURSIVE ] with_query [, ...] ]<br />
INSERT INTO table_name [ ( column_name [, ...] ) ]<br />
{ DEFAULT VALUES | VALUES ( { expression | DEFAULT } [, ...] ) [, ...] | query }<br />
[ ON CONFLICT [ ( { column_name_index | ( expression_index ) } [ COLLATE collation ] [ opclass ] [, ...] [ WHERE index_predicate ] ) ]<br />
{ IGNORE | UPDATE<br />
SET { column_name = { expression | DEFAULT } |<br />
( column_name [, ...] ) = ( { expression | DEFAULT } [, ...] )<br />
} [, ...]<br />
[ WHERE condition ]<br />
}<br />
]<br />
[ RETURNING * | output_expression [ [ AS ] output_name ] [, ...] ]<br />
</code><br />
<br />
Example of the use of the feature's syntax (as currently proposed) follow:<br />
<br />
<code lang="sql"><br />
-- These examples assume the following table:<br />
CREATE TABLE upsert (key int4 PRIMARY KEY, val text, is_active boolean default true);<br />
<br />
<br />
-- IGNORE variant (does nothing on conflict, no<br />
-- row locks taken, mostly an ETL thing):<br />
INSERT INTO upsert(key, val) VALUES(1, 'insert')<br />
ON CONFLICT IGNORE;<br />
<br />
<br />
-- Can have had system infer unique index from<br />
-- inference expression, and make that arbiter<br />
-- of whether or not to IGNORE, though - just ask:<br />
INSERT INTO upsert(key, val) VALUES(1, 'insert')<br />
ON CONFLICT (key) -- optional for "IGNORE" variant<br />
IGNORE;<br />
<br />
<br />
-- Predicate within UPDATE auxiliary statement<br />
-- (row is still locked when the UPDATE predicate<br />
-- isn't satisfied):<br />
INSERT INTO upsert(key, val) VALUES(1, 'insert')<br />
ON CONFLICT (key) UPDATE -- inference expression "(key)" mandatory for UPDATE variant<br />
-- EXCLUDED.* carries forward effects of<br />
-- INSERT BEFORE row-level triggers:<br />
SET val = EXCLUDED.val <br />
WHERE TARGET.val != 'delete'; <br />
<br />
<br />
-- Multi-row insert-or-update, with reference<br />
-- to rejected tuples using special EXCLUDED.*<br />
-- expression:<br />
INSERT INTO upsert(key, val)<br />
VALUES(1, 'Foo'), (2, 'Bar'), (3, 'Baz')<br />
ON CONFLICT (key) UPDATE SET val = EXCLUDED.val;<br />
<br />
<br />
-- RETURNING will project successfully inserted<br />
-- rows, *and* successfully updated rows:<br />
WITH t AS(<br />
INSERT INTO upsert(key, val)<br />
VALUES(11, 'Foo'), (12, 'Bar')<br />
ON CONFLICT (key) UPDATE SET val = EXCLUDED.val<br />
RETURNING TARGET.key, TARGET.val -- TARGET.* alias must be used (if the RETURNING columns are qualified at all), even here<br />
)<br />
SELECT key, val FROM t;<br />
<br />
<br />
ALTER TABLE upsert DROP CONSTRAINT upsert_pkey;<br />
CREATE UNIQUE INDEX text_index ON upsert (val);<br />
<br />
<br />
-- Infer only particular opclass (fails):<br />
INSERT INTO upsert(key, val)<br />
VALUES(1, 'Foo') ON CONFLICT (val text_pattern_ops) UPDATE SET val = EXCLUDED.val;<br />
<br />
-- Infer only particular collation (fails):<br />
INSERT INTO upsert(key, val)<br />
VALUES(1, 'Foo') ON CONFLICT (val collate "C") UPDATE SET val = EXCLUDED.val;<br />
<br />
DROP INDEX text_index;<br />
<br />
<br />
-- Partial unique index support:<br />
CREATE UNIQUE INDEX ON upsert (key) WHERE is_active;<br />
<br />
INSERT INTO upsert(key, val) VALUES(10, 'Wombat')<br />
-- Works with only partial index on "key",<br />
-- covering "WHERE is_active" (this would also<br />
-- work if we didn't drop "upsert_pkey" and<br />
-- create the partial unique index)<br />
ON CONFLICT (key WHERE is_active)<br />
UPDATE SET val = EXCLUDED.val;<br />
</code><br />
<br />
The syntax does not accept subqueries within either the <tt>UPDATE</tt> targetlist, or the <tt>UPDATE</tt> predicate; only the row being updated (via the <tt>TARGET.*</tt> alias), and the row originally proposed for insertion (via the <tt>EXCLUDED.*</tt> pseudo-alias expression) may be referenced. But the INSERT is not further restricted in any way - it may accept tuples from any source, have a <tt>VALUES()</tt> with subqueries within its value list, have CTEs, appear in data-modifying CTEs, etc. While somewhat restricted, the <tt>UPDATE</tt> may still make use of operators and functions in its targetlist and <tt>WHERE</tt> clause freely.<br />
<br />
All of these restrictions are identical to restrictions on the structure of SQL <tt>MERGE</tt> query <tt>WHEN MATCHED THEN UPDATE</tt> "handlers"; those handlers have their own similarly restricted <tt>WHERE</tt> clauses and targetlists, that can only reference the 2 tuples on each side of the <tt>JOIN</tt> driving the <tt>MERGE</tt> -- <tt>ON CONFLICT UPDATE</tt> only allows referencing of the <tt>TARGET.*</tt> and <tt>EXCLUDED.*</tt> pseudo-aliases. The big restriction with <tt>INSERT</tt> with <tt>ON CONFLICT UPDATE</tt> as compared to <tt>MERGE</tt> is that the user must always be happy with an <tt>INSERT</tt> as one possible outcome - this provides the implementation with a useful way to terminate the retry loop, which appears necessary in order to offer users the "essential UPSERT property". Only a would-be duplicate violation can arbitrate whether or not the alternative path is taken (and <i>not</i> a totally flexible <tt>JOIN</tt> finding or failing to find an existing tuple in the target, which is far more ticklish). The <tt>ON CONFLICT UPDATE</tt> feature is about <i>guarantees</i>, whereas <tt>MERGE</tt> makes few or no guarantees around concurrency (e.g. never getting a duplicate violation in simple cases), either as described by the standard, or as described by the documentation of any real-world implementation, or as actually implemented in other systems.<br />
<br />
In the future, it will be quite feasible (if not necessarily desirable) to modify the <tt>ON CONFLICT UPDATE</tt> implementation to have multiple possible "handlers", evaluated in sequence like SQL <tt>MERGE</tt>, including a <tt>DELETE</tt>-based handler. Provided the <tt>INSERT</tt> cannot accept a <tt>WHERE</tt> clause, and continues to "drive" the UPSERT, that should work fine, while preserving the "essential UPSERT property". This could be simulated with the current implementation, by just locking (and not updating) a row, and then deleting the row with a new <tt>READ COMMITTED</tt> command (so as to be sure to have a new snapshot, just in case the row locked is not visible to the original MVCC snapshot); subtleties with visibility make that approach something that probably shouldn't be widely advised. Still, provided a distinct, new command/snapshot is used, this workaround to the lack of "<tt>DELETE</tt> handlers" should be safe.<br />
<br />
==== Command tag ====<br />
<br />
The feature uses a dedicated "UPSERT" command tag, reporting the number of rows inserted or updated. The <tt>IGNORE</tt> variant always reports rows using the existing "INSERT" command tag, though. For example:<br />
<br />
<code lang="sql"><br />
postgres=# create table upsert (key int4 primary key, val text);<br />
CREATE TABLE<br />
postgres=# INSERT INTO upsert values(1, 'Foo'), (2, 'Bar') ON CONFLICT (key) UPDATE SET val = EXCLUDED.val;<br />
UPSERT 0 2<br />
postgres=# INSERT INTO upsert values(2, 'Baz'), (3, 'Fizz') ON CONFLICT (key) UPDATE SET val = EXCLUDED.val;<br />
UPSERT 0 2<br />
postgres=# INSERT INTO upsert values(1, 'Tres'), (2, 'Mono') ON CONFLICT IGNORE;<br />
INSERT 0 0<br />
</code><br />
<br />
==== Restrictions on query structure in detail ====<br />
<br />
As already mentioned, these restrictions affect targetlist and predicate, just as with SQL <tt>MERGE</tt>:<br />
<br />
<code><br />
INSERT INTO UPSERT VALUES (17, 'Woody') ON CONFLICT (key) UPDATE SET val = (SELECT 'f');<br />
ERROR: 0A000: cannot use subquery in ON CONFLICT UPDATE<br />
LINE 1: ...VALUES (17, 'Woody') ON CONFLICT (key) UPDATE SET val = (SELECT 'f...<br />
^<br />
<br />
INSERT INTO UPSERT VALUES (18, 'Carl') ON CONFLICT (key) UPDATE SET val = (SELECT val FROM upsert);<br />
ERROR: 0A000: cannot use subquery in ON CONFLICT UPDATE<br />
LINE 1: ... VALUES (18, 'Carl') ON CONFLICT (key) UPDATE SET val = (SELECT va...<br />
^<br />
<br />
INSERT INTO UPSERT VALUES (19, 'Trevor') ON CONFLICT (key) UPDATE SET val = 'f' WHERE TARGET.key IN (SELECT 1);<br />
ERROR: 0A000: cannot use subquery in ON CONFLICT UPDATE<br />
LINE 1: ...evor') ON CONFLICT (key) UPDATE SET val = 'f' WHERE TARGET.key IN (SELECT...<br />
^<br />
</code><br />
<br />
Note that the syntax does not restrict the "INSERT part" of these queries in any way. To give a not particularly practical example of how the "INSERT part" of the statement is no less flexible than INSERTs in general, the following is possible:<br />
<code><br />
postgres=# select * from upsert;<br />
key | val <br />
-----+-----<br />
1 | a<br />
2 | b<br />
3 | c<br />
(3 rows)<br />
<br />
postgres=# insert into upsert select key, val from upsert on conflict (key) update set val = 'new';<br />
UPSERT 0 3<br />
postgres=# select * from upsert;<br />
key | val <br />
-----+-----<br />
1 | new<br />
2 | new<br />
3 | new<br />
(3 rows)<br />
</code><br />
<br />
==== "Cardinality violation" errors in detail ====<br />
<br />
The SQL standard requires that MERGE raise a "cardinality violation" error [https://github.com/postgres/postgres/blob/REL9_3_STABLE/src/backend/utils/errcodes.txt#L145] when more than one row is affected by an SQL <tt>MERGE</tt> command. The following examples show questionable usage of the <tt>ON CONFLICT UPDATE</tt> feature, which will cause PostgreSQL to raise an analogous cardinality violation error (unless otherwise noted):<br />
<br />
<code><br />
-- Raises "cardinality violation" error.<br />
--<br />
-- Doesn't matter if there is or is not existing row with<br />
-- value of 1 within "key"<br />
INSERT INTO upsert(key, val)<br />
VALUES(1, 'Foo'), (1, 'Bar')<br />
ON CONFLICT (key) UPDATE SET val = EXCLUDED.val;<br />
ERROR: 21000: ON CONFLICT UPDATE command could not lock/update self-inserted tuple<br />
HINT: Ensure that no rows proposed for insertion within the same command have duplicate constrained values.<br />
<br />
<br />
-- Also raises same error, since row locked within<br />
-- ExecLockUpdateTuple() a second time after first update:<br />
INSERT INTO upsert(key, val)<br />
VALUES(5, 'Fizz'), (5, 'Arr')<br />
ON CONFLICT (key) UPDATE SET val = EXCLUDED.val<br />
-- XXX: Maybe only raise error when UPDATE required?<br />
WHERE EXCLUDED.val != 'Arr';<br />
ERROR: 21000: ON CONFLICT UPDATE command could not lock/update self-inserted tuple<br />
HINT: Ensure that no rows proposed for insertion within the same command have duplicate constrained values.<br />
<br />
<br />
-- Does not raise error, provided row with PK value<br />
-- 5 already exists (and so aren't inserted and then<br />
-- locked by same command, as might have happened in<br />
-- previous examples).<br />
--<br />
-- We merely lock the one existing row twice, which does<br />
-- *not* result in a cardinality violation error:<br />
INSERT INTO upsert(key, val)<br />
VALUES(5, 'Fizz'), (5, 'Arr')<br />
ON CONFLICT (key) UPDATE SET val = EXCLUDED.val<br />
WHERE 1 = 2;<br />
</code><br />
<br />
The idea of raising "cardinality violation" errors is to ensure that any one row is affected no more than once per statement executed. In the lexicon of the SQL standard's discussion of SQL <tt>MERGE</tt>, the SQL statement is "deterministic". The user ought to be confident that a row will not be affected more than once - if that isn't the case, then it isn't predictable what the final value of a row affected multiple times will be.<br />
<br />
The implementation figures out that a cardinality violation occurred due to <code>HeapTupleSatisfiesUpdate()</code> returning <code>HeapTupleInvisible</code> (<i>and</i> the command ID matches the current command's, which it should, since a <code>HeapTupleInvisible</code> return value is traditionally a "can't happen" error).<br />
<br />
Note that the possibility of a cardinality violation is considered after row locking, but before updating. So in last example above (with predicate of "WHERE 1 = 2"), an existing row needs to be there in order for there to be no cardinality violation - if the predicate passed for one proposed row, and it was successfully updated (or maybe inserted), whereas it did not pass for another proposed row (linked to the same <i>existing</i> row as the first proposed row) but still had to be locked, we'd still get a cardinality violation, <i>even though the other row would not go on to be updated if we didn't get an error</i>.<br />
<br />
This restrictions imposed might be more severe than strictly necessary to only prevent the SQL standard's idea of a "cardinality violation", but this seems unlikely to matter.<br />
<br />
The following example shows an arguably spurious "cardinality violation" that is actually pretty inconsequential in practice:<br />
<br />
<code><br />
postgres=# select * from upsert;<br />
key | val <br />
-----+-----<br />
(0 rows)<br />
<br />
postgres=# WITH aa AS (<br />
INSERT INTO upsert VALUES (1, 'Foo')<br />
RETURNING *)<br />
INSERT INTO upsert SELECT * FROM aa<br />
ON CONFLICT (key) UPDATE SET val = EXCLUDED.val;<br />
ERROR: 21000: ON CONFLICT UPDATE command could not lock/update self-inserted tuple<br />
HINT: Ensure that no rows proposed for insertion within the same command have duplicate constrained values.<br />
</code><br />
<br />
Note that if the UPSERT's values don't come from the data-modifying CTE, we'll just get a duplicate violation instead, due to the implementation-defined ordering of DML statement execution within the command:<br />
<br />
<code><br />
postgres=# select * from upsert;<br />
key | val <br />
-----+-----<br />
(0 rows)<br />
<br />
postgres=# WITH aa AS (<br />
INSERT INTO upsert VALUES (1, 'Foo')<br />
RETURNING *)<br />
INSERT INTO upsert values(1, 'Bar')<br />
ON CONFLICT (key) UPDATE SET val = EXCLUDED.val;<br />
ERROR: 23505: duplicate key value violates unique constraint "upsert_pkey"<br />
DETAIL: Key (key)=(1) already exists.<br />
SCHEMA NAME: public<br />
TABLE NAME: upsert<br />
CONSTRAINT NAME: upsert_pkey<br />
</code><br />
<br />
It seems quite unlikely that this theoretical risk of what are arguably spurious "cardinality violations" actually matters. It is only noted here for completeness. There is, however, arguably a difference with historic behavior here. To illustrate:<br />
<br />
<code><br />
postgres=# select * from upsert;<br />
key | val <br />
-----+--------<br />
20 | Before<br />
21 | Before<br />
(2 rows)<br />
<br />
postgres=# with aaa as (UPDATE upsert set val = 'After' returning key, val) update upsert set val = 'Outer Value' from aaa where upsert.key = aaa.key;<br />
UPDATE 0<br />
postgres=# select * from upsert;<br />
key | val <br />
-----+-------<br />
20 | After<br />
21 | After<br />
(2 rows)<br />
</code><br />
<br />
Note that the outer <tt>UPDATE</tt> does not affect any rows (their "val" remains 'After', and is never 'Outer Value'), because the nested data-modifying CTE updates first. This is because <tt>ExecUpdate()</tt> (fed here by a CTE Scan) handles a <tt>HeapTupleSelfUpdated</tt> return value from <tt>heap_update()</tt> as follows:<br />
<br />
<code><br />
/*<br />
* The target tuple was already updated or deleted by the<br />
* current command, or by a later command in the current<br />
* transaction. The former case is possible in a join UPDATE<br />
* where multiple tuples join to the same target tuple. This<br />
* is pretty questionable, but Postgres has always allowed it:<br />
* we just execute the first update action and ignore<br />
* additional update attempts.<br />
</code><br />
<br />
So the top-level <tt>UPDATE</tt> finds the tuple modified by the data-modifying CTE it joins on. Each <tt>ExecUpdate()</tt> call outside the CTE becomes a no-op.<br />
<br />
Simply ignoring additional update attempts (as <tt>ExecUpdate()</tt> already does here) is an alternative to throwing a cardinality violation for <tt>ON CONFLICT UPDATE</tt> that isn't outrageous, but is thought to be more surprising given the behavior of SQL <tt>MERGE</tt>, and the increased likelihood of this kind of thing with UPSERT. The comparison between the new <tt>HeapTupleInvisible</tt> handler, and the existing <tt>ExecUpdate()</tt> handler for <tt>HeapTupleSelfUpdated</tt> is more or less an "apples to apples" comparison; in contrast to the <tt>ExecUpdate()</tt> call to <tt>heap_update()</tt>, a <tt>HeapTupleSelfUpdated</tt> return value from <tt>heap_lock_tuple()</tt> is impossible from the new <tt>ExecLockUpdateTuple()</tt> call site. The comparison is more or less "apples to apples" because a <tt>DirtySnapshot</tt> is used by the index scan that finds conflicting TIDs, and never an MVCC snapshot as in the case of <tt>ExecUpdate()</tt>. The exact observed return codes (ultimately originating from <tt>HeapTupleSatisfiesUpdate()</tt>) are different, but the basic issue of a situation arising where we detect that a command affects the same row multiple times is the same.<br />
<br />
= Challenges, issues (with <tt>ON CONFLICT</tt> patch) =<br />
<br />
Current open items (items that are either points of contention, or that clearly must be fixed) are listed in this category. These are distinct from interesting/odd behavior that should be discussed ("Miscellaneous odd properties") that the patch exhibits, which is also discussed.<br />
<br />
== Open Items ==<br />
<br />
Open Items (items which definitely must be fixed, not just discussed) are:<br />
<br />
=== Value Locking mechanism ===<br />
See dedicated [[Value locking|value locking page]] for a definition of value locking, and a full explanation.<br />
<br />
<b>Update:</b> Controversy has more or less died down. Approach #2 is likely to be used in final patch, but maintaining approach #1 in parallel with approach #2 seems useful for testing, since approach #1 has the most "conceptually pure" implementation of [[Value locking]]; it will continue to be a useful basis of comparison. For example, Jeff Janes found race conditions within approach #2 only at one point [http://www.postgresql.org/message-id/CAMkU=1w8e9Q6ZX3U85RtsyCMpdYWFrvVAO3=uNEvtqiRUzntaQ@mail.gmail.com], and the knowledge that #1 was apparently unaffected aided debugging.<br />
<br />
=== RLS ===<br />
<strike>Due to the timing of the patch, we have yet to consider row-level security (per-column privileges are considered, and have tests, however). Note, however, that the proposed <tt>ON CONFLICT UPDATE</tt> patch correctly preserved the guarantees of per-column privileges.<br />
<br />
The current revision has a clear security bug pertaining to RLS. Example session demonstrating how to leak data that should be protected by "USING ( expression )" security qual, but isn't:</strike><br />
<br />
<code><br />
postgres=> select * from upsert;<br />
key | val <br />
-----+-----<br />
2 | Bar<br />
(1 row)<br />
<br />
postgres=> update upsert set val = val where key = 1;<br />
UPDATE 0<br />
postgres=> INSERT INTO upsert values (1, 'Random String') on conflict (key) update set val = TARGET.val;<br />
ERROR: 44000: new row violates WITH CHECK OPTION for "upsert"<br />
DETAIL: Failing row contains (1, Secret).<br />
LOCATION: ExecWithCheckOptions, execMain.c:1719<br />
</code><br />
<br />
<strike>Note that the system leaked the existing tuple values (that is, "1, Secret)"), in violation of the guarantees made by RLS. The CREATE POLICY docs do state: "An example of this is attempting to insert a duplicate value into a column which is the primary key or has a unique constraint. If the insert fails then the user can infer that the value already exists (this example assumes that the user is permitted by policy to insert records which they are not allowed to see)". However, this seems like something considerably more serious than that, since non-constrained values are reported, too.<br />
<br />
In this example, the query written by a malicious party does not <tt>INSERT</tt> because there was an existing row (if there was no existing row, then there'd be principled, standard enough RLS check error, but with reporting of values supplied by the user). When it goes to <tt>UPDATE</tt>, security quals are not added to the <tt>UPDATE</tt>, and so the <tt>UPDATE</tt> actually is at least attempted. The check does fail at the <tt>UPDATE</tt> stage, so the malicious party is denied the opportunity to write data spuriously, but as things stand ON CONFLICT effectively gives attackers a way to avoid having security quals added to the <tt>UPDATE</tt>.</strike><br />
<br />
<b>Update:</b> Following discussion with Stephen Frost [http://www.postgresql.org/message-id/20141121205926.GK28859@tamriel.snowman.net], it isn't immediately clear that the solution here is to make sure that the auxiliary <tt>UPDATE</tt> has an appropriate security qual. More discussion is required.<br />
<br />
<strike><b>Update:</b> Following further discussion with Stephen Frost [http://www.postgresql.org/message-id/20150109214041.GK3062@tamriel.snowman.net], V2.0 was written which defines semantics that are thought to be acceptable, and avoids the leak outlined above. See <tt>CREATE POLICY</tt> documentation (linked to above) for more information.</strike><br />
<br />
<b>Update:</b> A finer-grained approach is probably needed, after all. UPDATE-related tuples will probably end up never having INSERT-related with check options enforced, for example. V3.4 takes this approach.<br />
<br />
=== <strike>Partial unique indexes</strike> ===<br />
<br />
<strike>It seems like we should probably have partial unique index support from the first committed version. This is important for the <tt>UPDATE</tt> variant in particular, where currently we cannot infer a unique index from any legal specification, even though we must in order to use such indexes -- so currently we can't use them. This is something that a future revision will hopefully natively support without naming the unique index directly, which remains unacceptable.</strike><br />
<br />
Note that the <tt>IGNORE</tt> variant <i>always</i> supported partial unique indexes, provided the user didn't require that ignored would-be unique violations were restricted to some particular partial unique index.<br />
<br />
<b>Update: </b> V1.8 has the ability to infer partial unique indexes via its new, extended unique index inference specification clause. Importantly, since the UPDATE variant mandates an inference specification, this addition makes it possible to use the feature to UPSERT with partial unique indexes. Note that any tuple proposed for insertion must ultimately be covered by the partial index - otherwise an error is thrown within the executor.<br />
<br />
=== <strike>Non-default opclasses</strike> ===<br />
<br />
<strike>There should be a way of supporting non-default opclasses within the first committed version. Non-default opclasses seldom or never introduce an alternative notion of equality as compared to the default opclass (that is, there "equals" operator is in practice (almost?) invariably the same as that of the default opclass, conventionally "operator =(type, type)"; the non-default opclasses shipped with Postgres introduce alternative sort orders, not alternative notions of equality).<br />
<br />
Note that this implies creating a new note under the doc's "System Dependencies on Operator Classes" subsection [http://www.postgresql.org/docs/devel/static/xindex.html#XINDEX-OPCLASS-DEPENDENCIES]. Like <tt>DISTINCT</tt> or <tt>GROUP BY</tt>, the idea of equality for the purposes of <tt>ON CONFLICT UPDATE/IGNORE</tt> <i>unique index inference</i> is likely to be formalized as the idea of equality implied by the default opclass "equals" operator (which in practice gives the implementation leeway to use at least all shipped non-default opclasses).<br />
<br />
Maybe the unique index inference process would be better off formally not caring about the use of non-default opclasses [http://www.postgresql.org/message-id/CAM3SWZQCN6JZ_OKi1GJr8dR_J+BaDiW8xkm235Ww3oaqxhmj1A@mail.gmail.com].<br />
<br />
<b>Update: </b> V1.8 formally documents that opclasses that support distinct notions of "equals" (which is inconsistent with established PostgreSQL convention) might theoretically be problematic. It formally becomes a matter of whatever unique indexes happen to be available on the expressions/attributes under consideration driving that definition of "equals" (by having one operator class or another). All shipped non-default operator classes have identical "equals" operators to their type's default anyway, with the sole exception of the internal record non-default opclass [http://www.postgresql.org/message-id/54988BF5.9000405@vmware.com] (this is only used to implement materialized views, and so is deliberately obfuscated with non-standard operator spellings).</strike><br />
<br />
<b>Update: </b> V3.2 allows the user to specify an opclass (or collation), should that be semantically significant. Even where it is, a difference in opclass across actually defined unique indexes is required for failing to account for such a difference to be a real problem.<br />
<br />
=== <strike><tt>RETURNING</tt> behavior</strike> ===<br />
<br />
<strike>In the <tt>ON CONFLICT UPDATE/IGNORE</tt> patch, <tt>RETURNING</tt> currently only return tuples actually inserted - as when a BEFORE ROW INSERT trigger returns <tt>NULL</tt>, <tt>RETURNING</tt> returns no tuple when an insert does not actually proceed. Original discussion of this point [http://www.postgresql.org/message-id/CAM3SWZSBpioO3A7rx4_8wO86Si=09dmq=hk6V-UaK3N+cZqZgQ@mail.gmail.com] shows the consensus in now that the implementation should also return/project updated rows in the event of a <tt>RETURNING</tt> clause. This is expected in the next revision (V1.5). </strike><br />
<br />
<b>Update:</b> V1.5 establishes this behavior for <tt>RETURNING</tt>. Adopting this behavior occurred in consultation with the Django community [http://www.postgresql.org/message-id/1416465441.8931.240.camel@TTY32].<br />
<br />
Note that <tt>RETURNING</tt> does not make visible the "<tt>EXCLUDED.*</tt>" alias from the <tt>UPDATE</tt> (just the generic "<tt>TARGET.*</tt>" alias is visible there). Doing so is thought to create annoying ambiguity for the simple, common cases [http://www.postgresql.org/message-id/CAM3SWZTcpy9rroLM3TkfuU4HDLrEtuGzxLptGn2vLhVAFwQCVA@mail.gmail.com] for little to no benefit. At some point in the future, we may pursue a way of exposing if <tt>RETURNING</tt>-projected tuples were inserted and updated, but this probably doesn't need to make it into the first committed iteration of the feature [http://www.postgresql.org/message-id/CA+Tgmoa+1Ychm9x8fx6x2t7J=WBP7+bgnYRCM39FTiT5u-qgrA@mail.gmail.com].<br />
<br />
=== <strike><tt>postgres_fdw</tt></strike> ===<br />
<br />
<strike>There is no support for <tt>postgres_fdw</tt>. This is probably a fairly straightforward matter of adding new deparsing logic to <tt>deparseInsertSql()</tt>.</strike><br />
<br />
Implementation has support for the <tt>IGNORE</tt> variant (provided no unique index inference specification is provided, because there is no concept of a unique index on a foreign table. There is never anything to infer.). <tt>postgres_fdw</tt> will support <tt>ON CONFLICT UPDATE</tt>, purely because that variant mandates an inference specification clause.<br />
<br />
=== <strike>Syntax (<tt>MERGE</tt>, custom, other)</strike> ===<br />
<br />
<b>Update:</b> While some people continue to want to use a custom <tt>MERGE</tt>-like syntax that is inspired by <tt>MERGE</tt>, the idea of a fully general <tt>MERGE</tt> that offers UPSERT-like guarantees has fallen out of favor generally. [http://www.postgresql.org/message-id/CA+U5nMJczTGSJB2ZFEt8a11XR-1VB_F-kfN3=_28muGcPg7Ktg@mail.gmail.com] [http://www.postgresql.org/message-id/1412800198.94254.YahooMailNeo@web122306.mail.ne1.yahoo.com] [http://www.postgresql.org/message-id/1412802111.32497.YahooMailNeo@web122306.mail.ne1.yahoo.com]. This just leaves open the details of to what extent a custom syntax, constrained in a way similar to <tt>INSERT ... ON CONFLICT UPDATE</tt> takes <i>inspiration</i> from <tt>MERGE</tt>. That is a far less contentious issue, since we're essentially only talking about spelling.<br />
<br />
<strike>Consensus seems to be that an alias-like referencing to the tuple (in the style of <tt>OLD.*/NEW.*</tt>) is desirable. This necessitates adding a dummy RTE to the query during parse analysis, which presents its own difficulties.</strike><br />
<br />
<b>Update:</b> V1.4 has an pseudo-alias <tt>EXCLUDED.*</tt>/<tt>TARGET.*</tt> syntax (these aliases are only visible in the <tt>UPDATE</tt> auxiliary query - neither alias will be visible in the <tt>INSERT</tt>'s <tt>RETURNING</tt> clause, if any, for example). Issues around syntax seem to have very much settled down - it seems opinion has converged around the most recent formulation of the <tt>ON CONFLICT UPDATE</tt> syntax (with pseudo-alias <tt>EXCLUDED.*</tt> expressions, and new <tt>RETURNING</tt> behavior).<br />
<br />
=== <strike>Plan/EXPLAIN output</strike> ===<br />
<br />
As of V1.3, a sequential scan, which is hidden and has certain aspects folded into its parent ModifyTable node in EXPLAIN output, is now guaranteed. So recent versions look like this (note the lack of any relation scan node - there is a hidden sequential scan that will never be executed in the conventional manner, but only selectively, by using it with <tt>EvalPlanQual()</tt>).<br />
<br />
<b>Update</b>: V2.2 now shows TARGET.* alias in all explain nodes (due to parser refactoring):<br />
<br />
<b>Update</b>: V3.3 now shows "Conflict Arbiter [unique] Indexes" in EXPLAIN output (all formats):<br />
<code><br />
postgres=# EXPLAIN ANALYZE INSERT INTO upsert VALUES(1, 'Art')<br />
ON CONFLICT (key) UPDATE SET val = EXCLUDED.val WHERE TARGET.key = 1;<br />
QUERY PLAN <br />
----------------------------------------------------------------------------------------------------------------------<br />
Insert on upsert target (cost=0.00..0.01 rows=1 width=0) (actual time=0.136..0.136 rows=0 loops=1)<br />
Conflict Arbiter Indexes: upsert_pkey<br />
-> Result (cost=0.00..0.01 rows=1 width=0) (actual time=0.002..0.003 rows=1 loops=1)<br />
-> Conflict Update on upsert target (cost=0.00..25.88 rows=6 width=36) (actual time=0.052..0.052 rows=0 loops=1)<br />
Filter: (key = 1)<br />
Planning time: 0.149 ms<br />
Execution time: 0.254 ms<br />
(6 rows)<br />
</code><br />
<br />
=== <strike>Inheritance</strike> ===<br />
<strike>We should probably figure out a way to support limited cases of table inheritance/partitioning, where the partition key is conflict-updated on</strike>.<br />
<br />
<b>Update:</b> version V1.3 has good support for inheritance (and updatable views).<br />
<br />
<b>Update:</b> version V3.2 removes the final limitation on inheritance: inheritance parents can support unique index inference (and so can support UPSERT). Of course, the general restrictions that inheritance has on enforcing unique constraints across inheritance children limit the usefulness of using UPSERT with inheritance.<br />
<br />
=== <strike>Trigger behavior</strike> ===<br />
<strike>Trigger behavior for statement-level triggers seems funny (row-level triggers are probably fine, though)</strike>. Simon Riggs writes of <tt>MERGE</tt> [http://www.postgresql.org/message-id/1208372338.4259.202.camel@ebony.site]:<br />
<br />
<blockquote><br />
It's unclear whether MERGE should activate statement-level triggers, or not. Few of the above sources are explicit either way on this point.<br />
DB2 always runs both <tt>UPDATE</tt> and <tt>INSERT</tt> statement-level triggers, whether or not rows have been changed; I would suggest we do that also for<br />
before triggers. For after statement triggers I would suggest that we track how many updates and inserts are caused and if updates > 0 then we<br />
activate the after statement for update triggers, and if inserts > 0 then we activate the after statement for insert triggers. If a statement level trigger is activated by both update and insert then it would be possible for both <tt>TRIGGER_FIRED_BY_UPDATE()</tt> and <tt>TRIGGER_FIRED_BY_DELETE()</tt> to be true (for statement level triggers only), which would be a change from what we do now, even if the old behaviour was not explicitly mutually exclusive. In both cases I suggest we run Update triggers before Insert triggers consistently for both before and after statement triggers.<br />
</blockquote><br />
<br />
On the other hand, <i>Rules</i> can't really work with <tt>MERGE</tt> or UPSERT (note that <i>user-defined</i> rules are completely unsupported by the ON CONFLICT patch) - it's not clear how various types of user-defined rules should affect a hybrid <tt>INSERT</tt>/<tt>UPDATE</tt> top level statement, which is effectively what <tt>INSERT</tt> with an <tt>ON CONFLICT UPDATE</tt> clause is. Therefore, rather than attempting to expand user-defined rules, the implementation throws an error.<br />
<br />
Kevin Grittner points out [http://www.postgresql.org/message-id/1412967336.93211.YahooMailNeo@web122301.mail.ne1.yahoo.com] that the standard requires that all statement-level triggers must be fired regardless of how many rows are affected. <strike>Discuss</strike>.<br />
<br />
<b>Update:</b> V1.3 has the above behavior, which appears to be the consensus. Therefore, the implementation always fires insert and update statement-level triggers (both <tt>BEFORE</tt> and <tt>AFTER</tt>, for both <tt>UPDATE</tt> and <tt>INSERT</tt>, regardless of whatever else happened during statement execution).<br />
<br />
<b>Update:</b> V1.6 standardizes and documents the order in which statement-level triggers are executed<br />
<br />
Exposing whether or not trigger functions are called as a result of an <tt>ON CONFLICT IGNORE</tt> is a concern [http://www.postgresql.org/message-id/CAM3SWZRvjyu8nnvw_JHeXx4YMQ9XaA7u0GEtLbCgym0oEAn_7Q@mail.gmail.com], particularly with <tt>INSTEAD OF</tt> triggers on views, where the corresponding "redirected" insert (redirected by the user-defined trigger function) should probably also <tt>IGNORE</tt>, as already happens automatically in the case of updatable views with <tt>ON CONFLICT IGNORE</tt>. This may be addressed later.<br />
<br />
== Miscellaneous odd properties of proposed <tt>ON CONFLICT</tt> patch ==<br />
<br />
This section lists unusual properties of the proposed patch, that are <i>qualitatively</i> different to any existing DML behaviors. These are not considered open items because there is no dispute around the behaviors, and they may well be totally acceptable. They are highlighted here (and not under "Open Items") as possible points of concern in the future, that ought to be <i>discussed</i> sooner rather than later.<br />
<br />
=== Why still lock row when <tt>UPDATE</tt> predicate isn't satisfied? ===<br />
<br />
The implementation uses <tt>heap_lock_tuple()</tt> to lock a row ahead of deciding to <tt>UPDATE</tt>. The row is locked ahead of evaluating the <tt>UPDATE</tt>'s predicate, on conclusively locked, latest tuple version - if the implementation finds that there has been a concurrent <tt>UPDATE</tt> when row locking, it loops back to the start and retries (it re-finds the tuple using a <tt>DirtySnapshot</tt>, and may even go on to <tt>INSERT</tt> if the concurrent <tt>UPDATE</tt> created a new non-conflicting tuple version). This is convenient to the implementation, because the <tt>UPDATE</tt> qual need only be evaluated once, on a conclusively locked row version. During a discussion about SQL <tt>MERGE</tt> several years ago, Simon Riggs considered the possibility of having to do this [http://www.postgresql.org/message-id/1208372338.4259.202.camel@ebony.site]. It allows us to not have to teach <tt>ExecUpdate()</tt> to care about the case where there was a conflict -- conflicts at the row level necessitate restart (not the usual follow the update chain <tt>EvalPlanQual()</tt> thing). In the patch, <tt>ExecUpdate()</tt> is called with the row already locked by a dedicated <tt>heap_lock_tuple()</tt>-calling routine.<br />
<br />
This seems to also make sense on user-visible grounds. It would be surprising if a <tt>REPEATABLE READ</tt> transaction had a serialization failure due to the same UPSERT statement being executed twice. After all, that won't happen with a regular <tt>UPDATE</tt> (although in that case, it won't happen because our xact's snapshot won't see a new version where the <tt>UPDATE</tt> qual is satisfied). This approach seems less different. Besides, it's quite possible that someone only wants to lock rows, and making that happen with a "<tt>WHERE 1 = 2</tt>" predicate is perhaps neater, and does not involve <tt>UPDATE</tt> row-level triggers (unlike a "column = column" targetlist, which isn't quite as close to an "<tt>UPDATE</tt> no-op").<br />
<br />
Note that <tt>postgres_fdw</tt> also locks rows ahead of updating them [http://www.postgresql.org/docs/devel/static/fdw-planning.html], in the first of two distinct phases (so the deparsed <tt>UPDATE</tt> statement executed on the foreign server actually contain a ctid-based qual only - the TID that the query established the right to <tt>UPDATE</tt> by locking in the "first phase", using <tt>SELECT FOR UPDATE</tt>). This is because similarly, the <tt>postgres_fdw</tt>-based <tt>UPDATE</tt> needs to establish the right to <tt>UPDATE</tt> ahead of doing so (there could be local and foreign quals).<br />
<br />
=== Visibility issues and the proposed syntax (<tt>WHERE</tt> clause/predicate stuff) ===<br />
<br />
There are, in general, certain situations in which PostgreSQL's <tt>READ COMMITTED</tt> isolation level can give results that violate snapshot isolation (sometimes known as an "MVCC violation", or "Snapshot Isolation violation" - this happens using an executor facility known internally as <tt>EvalPlanQual()</tt>).<br />
<br />
Example setup:<br />
<br />
CREATE TABLE x<br />
(<br />
c int<br />
);<br />
<br />
INSERT INTO x VALUES(1);<br />
{|<br />
|+ Read Committed mode snapshot isolation violation example<br />
! session 1<br />
! session 2<br />
|-<br />
|<br />
BEGIN;<br />
UPDATE x SET c = c + (SELECT max(c) FROM x);<br />
|-<br />
| ||<br />
BEGIN;<br />
UPDATE x SET c = c + (SELECT max(c) FROM x);<br />
Session 2 performs the same query concurrently.<br />
|-<br />
| <br />
COMMIT;<br />
|-<br />
| ||<br />
COMMIT;<br />
|}<br />
<br />
-- Returns no rows (since value within only row's "c" column is actually 3):<br />
select * from x where c = 4;<br />
<br />
This, and other similar cases are better documented in the official documentation [http://www.postgresql.org/docs/9.4/static/transaction-iso.html#XACT-READ-COMMITTED], or the executor README [https://github.com/postgres/postgres/blob/REL9_4_STABLE/src/backend/executor/README#L147].<br />
<br />
The proposed UPSERT patch adds some interesting variation. During an early discussion of SQL <tt>MERGE</tt>, Robert Haas originally pointed out [http://www.postgresql.org/message-id/AANLkTineR-rDFWENeddLg=GrkT+epMHk2j9X0YqpiTY8@mail.gmail.com] the necessity of a new "MVCC violation" in order to ensure that the stated goals for UPSERT could be met (in particular, atomicity in the sense of always getting an <tt>INSERT</tt> or <tt>UPDATE</tt> in <tt>READ COMMITTED</tt> mode):<br />
<br />
<blockquote><br />
<p><br />
But let's back up and talk about MVCC for a minute. Suppose we have three source tuples, (1), (2), and (3); and the target table contains tuples (1) and (2), of which only (1) is visible to our MVCC snapshot; suppose also an equijoin. Clearly, source tuple (1) should fire the MATCHED rule and source tuple (3) should fire the NOT MATCHED rule, but what in the world should source tuple (2) do? AFAICS, the only sensible behavior is to throw a serialization error, because no matter what you do the results won't be equivalent to a serial execution of the transaction that committed target tuple (2) and the transaction that contains the <tt>MERGE</tt>.</p><br />
<br />
<p>Even with predicate locks, it's not obvious how to me how to solve this problem. Target tuple (2) may already be there, and its transaction already committed, by the time the <tt>MERGE</tt> statement gets around to looking at the source data.</p><br />
</blockquote><br />
<br />
UPSERT (or at least, any implementation that meets our goals) potentially <tt>UPDATE</tt>s a row without any version of it being visible to the command's MVCC snapshot (again, in <tt>READ COMMITTED</tt> mode only). This is distinct from the prior MVCC violation just illustrated, in that in order for the prior MVCC violation to occur, at least <i>some</i> version of the row being updated must be visible; in general, a relation scan from which a ModifyTable node pulls up tuples expects to pull up tuples that are visible to the MVCC snapshot. Whereas <tt>INSERT ... ON CONFLICT UPDATE</tt> may <tt>UPDATE</tt> a tuple only accessible to the command via a <tt>DirtySnapshot</tt> (in <tt>READ COMMITTED</tt> mode - higher isolation levels throw a serialization error when they find the tuple isn't visible to their MVCC snapshot following a special check). The row will be visible to new snapshots, but is not necessarily visible to our own.<br />
<br />
The <tt>UPDATE</tt> <tt>WHERE</tt> clause (predicate) is only evaluated once, on this conclusively-locked tuple, and not any other version of the same tuple. It is therefore possible (in <tt>READ COMMITTED</tt> mode) that the predicate may "fail to be satisfied" according to the command's MVCC snapshot. As already explained, it might simply be that there is no row version visible, but it's also possible that there <i>is</i> some row version that <i>is</i> visible, but only as a version that doesn't satisfy the predicate. If, however, the conclusively-locked version satisfies the predicate, it is posited that that is good enough and the tuple is <tt>UPDATE</tt>d. <i>The MVCC-snapshot-visible row version is denied the opportunity to prevent the <tt>UPDATE</tt> from taking place</i>, because we don't walk the <tt>UPDATE</tt> chain in the usual way.<br />
<br />
Peter Geoghegan writes [http://www.postgresql.org/message-id/CAM3SWZTEODEJLz82LK4eF2HYX+qEKrbc8-Vtq3_-aOf6kRSfiA@mail.gmail.com]:<br />
<br />
<blockquote><br />
We all seem to be in agreement that we should update at <tt>READ COMMITTED</tt> if *no* version of the tuple is visible. It seems utterly arbitrary to me to suggest that on the one hand it's okay to introduce one particular "MVCC violation", but not another equivalent one. The first scenario is one in which we update despite our update's (or rather insert's) "predicate" not being satisfied (according to our MVCC snapshot). The second scenario is one in which the same "predicate" is also not satisfied according to our MVCC snapshot, but in a slightly different way. Why bother introducing a complicated distinction, if it's a distinction without a difference? I'd rather have a behavior that is consistent, easy to reason about, and easy to explain. And so, the predicate is considered once, after conclusively locking a conflict tuple.<br />
</blockquote><br />
<br />
<b>Update:</b> This issue is directly illustrated by a new isolation tests added in V1.3 (see <tt>insert-conflict-update-3</tt>).<br />
<br />
=== <i>Theoretical</i> lock starvation hazards ===<br />
<br />
The file <tt>src/backend/access/heap/README.tuplock</tt> states [https://github.com/postgres/postgres/blob/REL9_4_STABLE/src/backend/access/heap/README.tuplock#L15]:<br />
<br />
<blockquote><br />
When it is necessary to wait for a tuple-level lock to be released, the basic<br />
delay is provided by XactLockTableWait or MultiXactIdWait on the contents of<br />
the tuple's XMAX. However, that mechanism will release all waiters<br />
concurrently, so there would be a race condition as to which waiter gets the<br />
tuple, potentially leading to indefinite starvation of some waiters. The<br />
possibility of share-locking makes the problem much worse --- a steady stream<br />
of share-lockers can easily block an exclusive locker forever. To provide<br />
more reliable semantics about who gets a tuple-level lock first, we use the<br />
standard lock manager, which implements the second level mentioned above. The<br />
protocol for waiting for a tuple-level lock is really<br />
<br />
LockTuple()<br />
XactLockTableWait()<br />
mark tuple as locked by me<br />
UnlockTuple()<br />
</blockquote><br />
<br />
The current UPSERT patch has lock arbitration that is a little fuzzier than this. Shared lockers don't cause conflicts, and we're using <tt>heap_lock_tuple()</tt>, so arbitration behaves approximately fairly in practice (we aren't attempting to simply grab the lmgr-controlled row lock, which the README is talking about: we're attempting to lock the row using the higher-level <tt>heap_lock_tuple()</tt> facility, whose implementation is actually described here). The exact same risk exists when using the "subxact looping" pattern, the existing approach that the docs suggest -- retrying index tuple inserts in the face of possible conflicts (conflicts due to concurrent insertions) also has loose lock arbitration rules with respect to the order that conflicting inserters complete relative to each other (i.e. there is no <i>strict</i> queue fairness). Stress-testing has shown the risk of lock starvation to be vanishingly small, but it's still a theoretical risk.<br />
<br />
No one has expressed concern about this, but it's an issue that deserves highlighting as a possible concern. Note that with other snapshot isolation databases, like Oracle, handling of concurrent <tt>UPDATE</tt>s at <tt>READ COMMITTED</tt> is quite different to the equivalent handling within Postgres: The entire statement is undone and restarted with a new snapshot, so that snapshot-isolation cannot be violated (which <tt>EvalPlanQual()</tt> allows). In principle, this can loop forever (possibly, it errors-out after enough retries). Oracle basically considers <tt>READ COMMITTED</tt> to be what you should use when you want Oracle to restart the statement, rather than the app restarting the transaction (as in <tt>SERIALIZABLE</tt> mode).</div>Mhahttps://wiki.postgresql.org/index.php?title=Committers&diff=35959Committers2021-05-03T16:15:32Z<p>Mha: </p>
<hr />
<div>This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit or when added as a committer, oldest first; this isn't intended to imply anything about depth of contribution.<br />
<br />
* Bruce Momjian (momjian)<br />
* Tom Lane (tgl)<br />
* Michael Meskes (meskes)<br />
* Tatsuo Ishii (ishii)<br />
* Peter Eisentraut (petere)<br />
* Joe Conway (joe)<br />
* Alvaro Herrera (alvherre)<br />
* Andrew Dunstan (adunstan)<br />
* Magnus Hagander (mha)<br />
* Heikki Linnakangas (heikki)<br />
* Robert Haas (rhaas)<br />
* Jeff Davis (jdavis)<br />
* Stephen Frost (sfrost)<br />
* Fujii Masao (fujii)<br />
* Noah Misch (noah)<br />
* Andres Freund (andres)<br />
* Dean Rasheed (deanr)<br />
* Andrew Gierth (rhodiumtoad)<br />
* Alexander Korotkov (smagen)<br />
* Amit Kapila (amitkapila)<br />
* Tomas Vondra (fuzzycz)<br />
* Michael Paquier (michael-kun)<br />
* Thomas Munro (macdice)<br />
* Peter Geoghegan (pgeoghegan)<br />
* Etsuro Fujita (efujita)<br />
* David Rowley (drowley)<br />
<br />
== Notes on the Commit Log ==<br />
<br />
Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole. <br />
<br />
== New Committers and Removing Committers ==<br />
<br />
New committers are added approximately annually by the Core Team. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:<br />
<br />
* several years of substantial contributions to the project<br />
* multiple and continuing code contributions<br />
* responsibility for maintenance of one or more areas of the codebase<br />
* track record of reviewing and helping other contributors with their patches<br />
* high quality code contributions which require very little revision or correction for commit<br />
* demonstrated understanding of the process and criteria for patch acceptance<br />
<br />
Generally, new committers are selected March or April and announced at pgCon.<br />
<br />
Committers who have become inactive and have not contributed significantly to the PostgreSQL project in several years are removed as committers. Again, the review process for this is approximately annual.<br />
<br />
[[Category:Community]]</div>Mhahttps://wiki.postgresql.org/index.php?title=HowToUseYourPostgreSQLMailAccount&diff=35762HowToUseYourPostgreSQLMailAccount2021-03-03T14:15:34Z<p>Mha: </p>
<hr />
<div>== Logging In/Account Creation ==<br />
<br />
Email accounts under @postgresql.org are not generally available, and are only<br />
for specific use cases or for for a number of people who are "grandfathered" in.<br />
<br />
== How to Access Your PostgreSQL.org Address ==<br />
<br />
The postgresql.org mail system is accessible through various different interfaces, depending on how you want to use it you can choose between:<br />
<br />
<br />
'''Webinterface:''' Go to [https://webmail.postgresql.org postgresql.org webmail system] and log in. This gets you into<br />
RoundCube, a fairly simple webmail interface. It is even multi-lingual.<br />
<br />
'''POP3/IMAP4:''' You can access imap.postgresql.org via POP3 or IMAP4 using the hostname imap.postgresql.org. Connections need to use TLS encryption, either directly or using STARTTLS. At least TLS 1.2 is required.<br />
<br />
'''SMTP:''' we provide an authenticated-only SMTP relay service using the hostname smtp.postgresql.org. Connections need to use TLS encryption, either through smtps or STARTTLS.</div>Mhahttps://wiki.postgresql.org/index.php?title=User:Mha&diff=35584User:Mha2021-01-06T12:58:29Z<p>Mha: </p>
<hr />
<div>asdf</div>Mhahttps://wiki.postgresql.org/index.php?title=User:Mha&diff=35583User:Mha2021-01-06T12:58:02Z<p>Mha: </p>
<hr />
<div>asd</div>Mhahttps://wiki.postgresql.org/index.php?title=HowToUseYourPostgreSQLMailAccount&diff=35511HowToUseYourPostgreSQLMailAccount2020-11-11T13:18:43Z<p>Mha: Remove old outdated data that has nothing to do with mail services and everything to do with the old way of handling regional/press contacts. Update technical information to be relevant.</p>
<hr />
<div>== Logging In/Account Creation ==<br />
<br />
Email accounts under @postgresql.org are not generally available, and are only<br />
for specific use cases or for for a number of people who are "grandfathered" in.<br />
<br />
== How to Access Your PostgreSQL.org Address ==<br />
<br />
The postgresql.org mail system is accessible through various different interfaces, depending on how you want to use it you can choose between:<br />
<br />
<br />
'''Webinterface:''' Go to [https://webmail.postgresql.org postgresql.org webmail system] and log in. This gets you into<br />
RoundCube, a fairly simple webmail interface. It is even multi-lingual.<br />
<br />
'''POP3/IMAP4:''' You can access imap.postgresql.org via POP3 or IMAP4 using the hostname imap.postgresql.org. Connections need to use TLS encryption, either directly or using STARTTLS.<br />
<br />
'''SMTP:''' we provide an authenticated-only SMTP relay service using the hostname smtp.postgresql.org. Connections need to use TLS encryption, either through smtps or STARTTLS.</div>Mhahttps://wiki.postgresql.org/index.php?title=PGLister:_How_to_Moderate&diff=35510PGLister: How to Moderate2020-11-11T13:03:04Z<p>Mha: </p>
<hr />
<div>{{Languages}}<br />
<br />
[https://lists.postgresql.org/ PGLister] is a mailing list management system designed to better [[PGLister_Announce | address the needs]] of the PostgreSQL community. PGLister is updated to work with recent improvements in email technology and spam filtering as well as provide an easy-to-use interface to manage list access. The guide below explains how a moderator can manage lists assigned for moderation.<br />
<br />
== Before you moderate for this first time ==<br />
<br />
In order to be assigned as a moderator to lists managed by [https://lists.postgresql.org/ PGLister], you must have logged into PGLister at least once. You can follow these steps to log in:<br />
<br />
# Visit [https://lists.postgresql.org/ PGLister] at [https://lists.postgresql.org/ https://lists.postgresql.org/]<br />
# Click on [https://lists.postgresql.org/manage/ Manage Subscriptions]. '''If your community account is already authenticated, then you will be logged into PGLister and redirected to the PGLister dashboard. You are now done.'''<br />
# If your account is not authenticated, you will be redirect to the community login page. Please log in with your community credentials here.<br />
## If you do not have a community account, you will need to register for one. Follow the steps to register a community account. When you are finished with sign up, return to Step 1 of this guide.<br />
# If you successfully authenticate your account, you will be redirect to the [https://lists.postgresql.org/manage/ PGLister Dashboard] where you can manage your PostgreSQL mailing list subscriptions as well as moderate lists.<br />
# If this is the first time you authenticated with PGLister and/or would like to request to be added as a moderator to a mailing list, please contact [mailto:sysadmins@lists.postgresql.org sysadmins@lists.postgresql.org] with your requests details.<br />
<br />
== Moderating Lists ==<br />
<br />
If you are a moderator of any list on PGLister, you will have access to the [https://lists.postgresql.org/moderate/ moderation dashboard]. You can find the link to the moderation dashboard underneath the "Manage lists" heading on the [https://lists.postgresql.org/manage/ PGLister Dashboard]. Click "Moderate / Manage Lists" to access to the [https://lists.postgresql.org/moderate/ moderation dashboard].<br />
<br />
Below will break down each section in the moderation dashboard and how to moderate the mailing lists you help manage.<br />
<br />
=== The "Moderation" Screen ===<br />
<br />
When mailing lists that you moderate have messages that require review, they will appear in the "Moderation" section of the moderation [https://lists.postgresql.org/moderate/ moderation dashboard]. As a moderator, you will also receive an email that provides several courses of action to take on the message. '''NOTE: THE EMAIL SENT TO MODERATORS REQUESTING MODERATION DOES NOT CONTAIN A MESSAGE PREVIEW.''' If you would like to preview the message before setting a course of action, you must visit the [https://lists.postgresql.org/moderate/ moderation dashboard] to view the message preview. Please see below for instructions on how to do so.<br />
<br />
==== Moderation Metadata ====<br />
<br />
The metadata on a message queued for moderation contains the following information:<br />
<br />
* Date: When the message was sent<br />
* List: Which list the message was sent to (e.g. "pgsql-hackers")<br />
* Reason: The reason why the message is in the moderation queue (e.g. "sender is not a subscriber of any list)<br />
* Spam score: The spam score assigned by the local spamassassin system.<br />
<br />
==== Moderation Message Info ====<br />
<br />
The data contained in the "Message" section on the moderation dashboard includes the following:<br />
<br />
* From: The email address ending the message. Shows both From address and envelope sender if they differ.<br />
* Size: The size of the message (unsurprisingly)<br />
* Attachments: If there are any attachments, the number of attachments are listed here. If you click on the number, a popover box appears that contains a list of the attachments, their type and their size.<br />
* Subject: The subject of the message. If you click on "Subject," a popover box appears that contains a preview of the message. Based on the email client used to send the message, this can at times appear to be garbled text.<br />
* Message ID: Contains a URL that activates a popover with the message ID<br />
<br />
==== Moderation Actions ====<br />
<br />
The actions section determines what to do with the message. In other words, "Actions" comprises the moderator's decision with the message, such as whether or not it should be sent out to the list. Below is what each action does for a message:<br />
<br />
* '''Ignore''': This is the default action. Ignore is a no-op: it does not perform any action on the message.<br />
* '''Approve''': Approves the message to be sent to the list.<br />
* '''Whitelist''': Both approve the message and add the sender's email address to the whitelist of that mailing list. '''NOTE: This means that a sender can ALWAYS send messages to the mailing list that are automatically approved without any moderation.'''<br />
* '''Discard''': Removes the message from the moderation queue and does '''not''' send the message to the mailing list. The sender does '''not''' receive a notification that the message was not approved for sending. This is typically used for messages that are spam.<br />
* '''Reject''' submenu: Shows options for rejecting a message. A message is delivered to the sender and the message is removed from the moderation queue. This action does '''not''' send the message to the mailing list. The sender receives a notification that the message was not approved for sending as well as the reason why it was rejected. ''Please be polite with your responses'': someone sending an email to the list may not be aware of the list policy, so try to point them to the correct reference.<br />
** '''Reject''': Prompts the moderator to enter a reason for rejecting the message<br />
** '''Other submenu options''': Sends a pre-defined standard message about rejection. The contents of the message can be shown by hovering the mouse over the option before selecting it.<br />
* '''Unsubscribe''': Unsubscribes the sender from the list. This requires the sender to be identified as an active subscriber of the list.<br />
* '''Reject unsub''': The same as ''reject'', except the reason is set to a pre-canned message with full instructions for how to use the List headers to unsubscribe from a message. This is the appropriate choice when an unsubscribe request is received from a sender who is not identified as a subscriber of the list.<br />
<br />
In order to finalize all the selected actions, a moderator must click '''Moderate''' at the bottom of the Moderation section.<br />
<br />
==== Explaining the Moderation email ====<br />
<br />
It is also possible to moderate messages from an email sent to moderators of a list. You will probably want to see a preview of the message before applying a moderation action, but fortunately you can do this from the email. All actions are the same as [[#Moderation Actions|moderation actions]] described above, but as soon as you click on the URL, this action is taken. A few notes:<br />
<br />
* '''Preview''': Brings you to a preview of the message. This opens up a tab in your browser with the contents of the message.<br />
<br />
=== List Management Overview ===<br />
<br />
The list management overview of the moderation screen is a list of the mailing lists that you moderate. If you click on one of the lists, you will be brought to the individual list management page.<br />
<br />
== List Management ==<br />
<br />
The list management section of PGLister enables a moderator to perform the following actions:<br />
<br />
* View which email addresses are subscribed to the list. This also allows a moderator to unsubscribe email addresses from a list<br />
* Subscribe new email addresses to the list<br />
* Whitelist email addresses that are always allowed to post messages to the list<br />
<br />
=== View/Unsubscribe ===<br />
<br />
The view/unsubscribe portion of the list manager allows a moderator to see who is subscribed to a mailing list and have the option of unsubscribing those email addresses.<br />
<br />
There is a box that allows for a moderator to search for an email address. If nothing is typed into the box, then all email addresses subscribed to that list are displayed in the next view. From there, a moderator can view the email addresses that are subscribed to the list as well as unsubscribe these particular email addresses.<br />
<br />
=== Subscribe ===<br />
<br />
The subscribe section allows a moderator to subscribe an email address to the list. If you are adding an email address using this method, please be sure that the owner of the email address has given you permission to do so as the email address will automatically be subscribed to the mailing list without any additional confirmation.<br />
<br />
=== Whitelist ===<br />
<br />
The whitelist section allows a moderator to manage email addresses that can always post to the particular email list without moderator approval. A moderator can also remove email addresses from the whitelist too. Please use this feature carefully. If you have any questions on how the whitelist works, please send an email to [mailto:sysadmins@postgresql.org sysadmins@postgresql.org].</div>Mhahttps://wiki.postgresql.org/index.php?title=PGLister:_How_to_Moderate&diff=35509PGLister: How to Moderate2020-11-11T12:57:17Z<p>Mha: This is no longer included in the mod motices</p>
<hr />
<div>{{Languages}}<br />
<br />
[https://lists.postgresql.org/ PGLister] is a mailing list management system designed to better [[PGLister_Announce | address the needs]] of the PostgreSQL community. PGLister is updated to work with recent improvements in email technology and spam filtering as well as provide an easy-to-use interface to manage list access. The guide below explains how a moderator can manage lists assigned for moderation.<br />
<br />
== Before you moderate for this first time ==<br />
<br />
In order to be assigned as a moderator to lists managed by [https://lists.postgresql.org/ PGLister], you must have logged into PGLister at least once. You can follow these steps to log in:<br />
<br />
# Visit [https://lists.postgresql.org/ PGLister] at [https://lists.postgresql.org/ https://lists.postgresql.org/]<br />
# Click on [https://lists.postgresql.org/manage/ Manage Subscriptions]. '''If your community account is already authenticated, then you will be logged into PGLister and redirected to the PGLister dashboard. You are now done.'''<br />
# If your account is not authenticated, you will be redirect to the community login page. Please log in with your community credentials here.<br />
## If you do not have a community account, you will need to register for one. Follow the steps to register a community account. When you are finished with sign up, return to Step 1 of this guide.<br />
# If you successfully authenticate your account, you will be redirect to the [https://lists.postgresql.org/manage/ PGLister Dashboard] where you can manage your PostgreSQL mailing list subscriptions as well as moderate lists.<br />
# If this is the first time you authenticated with PGLister and/or would like to request to be added as a moderator to a mailing list, please contact [mailto:sysadmins@lists.postgresql.org sysadmins@lists.postgresql.org] with your requests details.<br />
<br />
== Moderating Lists ==<br />
<br />
If you are a moderator of any list on PGLister, you will have access to the [https://lists.postgresql.org/moderate/ moderation dashboard]. You can find the link to the moderation dashboard underneath the "Manage lists" heading on the [https://lists.postgresql.org/manage/ PGLister Dashboard]. Click "Moderate / Manage Lists" to access to the [https://lists.postgresql.org/moderate/ moderation dashboard].<br />
<br />
Below will break down each section in the moderation dashboard and how to moderate the mailing lists you help manage.<br />
<br />
=== The "Moderation" Screen ===<br />
<br />
When mailing lists that you moderate have messages that require review, they will appear in the "Moderation" section of the moderation [https://lists.postgresql.org/moderate/ moderation dashboard]. As a moderator, you will also receive an email that provides several courses of action to take on the message. '''NOTE: THE EMAIL SENT TO MODERATORS REQUESTING MODERATION DOES NOT CONTAIN A MESSAGE PREVIEW.''' If you would like to preview the message before setting a course of action, you must visit the [https://lists.postgresql.org/moderate/ moderation dashboard] to view the message preview. Please see below for instructions on how to do so.<br />
<br />
==== Moderation Metadata ====<br />
<br />
The metadata on a message queued for moderation contains the following information:<br />
<br />
* Date: When the message was sent<br />
* List: Which list the message was sent to (e.g. "pgsql-hackers")<br />
* Reason: The reason why the message is in the moderation queue (e.g. "sender is not a subscriber of any list)<br />
<br />
==== Moderation Message Info ====<br />
<br />
The data contained in the "Message" section on the moderation dashboard includes the following:<br />
<br />
* Sender: The email address ending the message<br />
* Subject: The subject of the message. If you click on "Subject," a popover box appears that contains a preview of the message. Based on the email client used to send the message, this can at times appear to be garbled text.<br />
* Message ID: Contains a URL that activates a popover with the message ID<br />
<br />
==== Moderation Actions ====<br />
<br />
The actions section determines what to do with the message. In other words, "Actions" comprises the moderator's decision with the message, such as whether or not it should be sent out to the list. Below is what each action does for a message:<br />
<br />
* '''Ignore''': This is the default action. Ignore is a no-op: it does not perform any action on the message.<br />
* '''Approve''': Approves the message to be sent to the list.<br />
* '''Whitelist''': Both approve the message and add the sender's email address to the whitelist of that mailing list. '''NOTE: This means that a sender can ALWAYS send messages to the mailing list that are automatically approved without any moderation.'''<br />
* '''Discard''': Removes the message from the moderation queue and does '''not''' send the message to the mailing list. The sender does '''not''' receive a notification that the message was not approved for sending. This is typically used for messages that are spam.<br />
* '''Reject''': Prompts the moderator to enter a reason for rejecting the message to be delivered to the sender and removes the message from the moderation queue. This action does '''not''' send the message to the mailing list. The sender receives a notification that the message was not approved for sending as well as the reason why it was rejected. ''Please be polite with your responses'': someone sending an email to the list may not be aware of the list policy, so try to point them to the correct reference.<br />
* '''Unsubscribe''': Unsubscribes the sender from the list. This requires the sender to be identified as an active subscriber of the list.<br />
* '''Reject unsub''': The same as ''reject'', except the reason is set to a pre-canned message with full instructions for how to use the List headers to unsubscribe from a message. This is the appropriate choice when an unsubscribe request is received from a sender who is not identified as a subscriber of the list.<br />
<br />
In order to finalize all the selected actions, a moderator must click '''Moderate''' at the bottom of the Moderation section.<br />
<br />
==== Explaining the Moderation email ====<br />
<br />
It is also possible to moderate messages from an email sent to moderators of a list. You will probably want to see a preview of the message before applying a moderation action, but fortunately you can do this from the email. All actions are the same as [[#Moderation Actions|moderation actions]] described above, but as soon as you click on the URL, this action is taken. A few notes:<br />
<br />
* '''Preview''': Brings you to a preview of the message. This opens up a tab in your browser with the contents of the message.<br />
<br />
=== List Management Overview ===<br />
<br />
The list management overview of the moderation screen is a list of the mailing lists that you moderate. If you click on one of the lists, you will be brought to the individual list management page.<br />
<br />
== List Management ==<br />
<br />
The list management section of PGLister enables a moderator to perform the following actions:<br />
<br />
* View which email addresses are subscribed to the list. This also allows a moderator to unsubscribe email addresses from a list<br />
* Subscribe new email addresses to the list<br />
* Whitelist email addresses that are always allowed to post messages to the list<br />
<br />
=== View/Unsubscribe ===<br />
<br />
The view/unsubscribe portion of the list manager allows a moderator to see who is subscribed to a mailing list and have the option of unsubscribing those email addresses.<br />
<br />
There is a box that allows for a moderator to search for an email address. If nothing is typed into the box, then all email addresses subscribed to that list are displayed in the next view. From there, a moderator can view the email addresses that are subscribed to the list as well as unsubscribe these particular email addresses.<br />
<br />
=== Subscribe ===<br />
<br />
The subscribe section allows a moderator to subscribe an email address to the list. If you are adding an email address using this method, please be sure that the owner of the email address has given you permission to do so as the email address will automatically be subscribed to the mailing list without any additional confirmation.<br />
<br />
=== Whitelist ===<br />
<br />
The whitelist section allows a moderator to manage email addresses that can always post to the particular email list without moderator approval. A moderator can also remove email addresses from the whitelist too. Please use this feature carefully. If you have any questions on how the whitelist works, please send an email to [mailto:sysadmins@postgresql.org sysadmins@postgresql.org].</div>Mhahttps://wiki.postgresql.org/index.php?title=PGLister:_How_to_Moderate&diff=35502PGLister: How to Moderate2020-11-05T18:33:17Z<p>Mha: </p>
<hr />
<div>{{Languages}}<br />
<br />
[https://lists.postgresql.org/ PGLister] is a mailing list management system designed to better [[PGLister_Announce | address the needs]] of the PostgreSQL community. PGLister is updated to work with recent improvements in email technology and spam filtering as well as provide an easy-to-use interface to manage list access. The guide below explains how a moderator can manage lists assigned for moderation.<br />
<br />
== Before you moderate for this first time ==<br />
<br />
In order to be assigned as a moderator to lists managed by [https://lists.postgresql.org/ PGLister], you must have logged into PGLister at least once. You can follow these steps to log in:<br />
<br />
# Visit [https://lists.postgresql.org/ PGLister] at [https://lists.postgresql.org/ https://lists.postgresql.org/]<br />
# Click on [https://lists.postgresql.org/manage/ Manage Subscriptions]. '''If your community account is already authenticated, then you will be logged into PGLister and redirected to the PGLister dashboard. You are now done.'''<br />
# If your account is not authenticated, you will be redirect to the community login page. Please log in with your community credentials here.<br />
## If you do not have a community account, you will need to register for one. Follow the steps to register a community account. When you are finished with sign up, return to Step 1 of this guide.<br />
# If you successfully authenticate your account, you will be redirect to the [https://lists.postgresql.org/manage/ PGLister Dashboard] where you can manage your PostgreSQL mailing list subscriptions as well as moderate lists.<br />
# If this is the first time you authenticated with PGLister and/or would like to request to be added as a moderator to a mailing list, please contact [mailto:sysadmins@lists.postgresql.org sysadmins@lists.postgresql.org] with your requests details.<br />
<br />
== Moderating Lists ==<br />
<br />
If you are a moderator of any list on PGLister, you will have access to the [https://lists.postgresql.org/moderate/ moderation dashboard]. You can find the link to the moderation dashboard underneath the "Manage lists" heading on the [https://lists.postgresql.org/manage/ PGLister Dashboard]. Click "Moderate / Manage Lists" to access to the [https://lists.postgresql.org/moderate/ moderation dashboard].<br />
<br />
Below will break down each section in the moderation dashboard and how to moderate the mailing lists you help manage.<br />
<br />
=== The "Moderation" Screen ===<br />
<br />
When mailing lists that you moderate have messages that require review, they will appear in the "Moderation" section of the moderation [https://lists.postgresql.org/moderate/ moderation dashboard]. As a moderator, you will also receive an email that provides several courses of action to take on the message. '''NOTE: THE EMAIL SENT TO MODERATORS REQUESTING MODERATION DOES NOT CONTAIN A MESSAGE PREVIEW.''' If you would like to preview the message before setting a course of action, you must visit the [https://lists.postgresql.org/moderate/ moderation dashboard] to view the message preview. Please see below for instructions on how to do so.<br />
<br />
==== Moderation Metadata ====<br />
<br />
The metadata on a message queued for moderation contains the following information:<br />
<br />
* Date: When the message was sent<br />
* List: Which list the message was sent to (e.g. "pgsql-hackers")<br />
* Reason: The reason why the message is in the moderation queue (e.g. "sender is not a subscriber of any list)<br />
<br />
==== Moderation Message Info ====<br />
<br />
The data contained in the "Message" section on the moderation dashboard includes the following:<br />
<br />
* Sender: The email address ending the message<br />
* Subject: The subject of the message. If you click on "Subject," a popover box appears that contains a preview of the message. Based on the email client used to send the message, this can at times appear to be garbled text.<br />
* Message ID: Contains a URL that activates a popover with the message ID<br />
<br />
==== Moderation Actions ====<br />
<br />
The actions section determines what to do with the message. In other words, "Actions" comprises the moderator's decision with the message, such as whether or not it should be sent out to the list. Below is what each action does for a message:<br />
<br />
* '''Ignore''': This is the default action. Ignore is a no-op: it does not perform any action on the message.<br />
* '''Approve''': Approves the message to be sent to the list.<br />
* '''Whitelist''': Both approve the message and add the sender's email address to the whitelist of that mailing list. '''NOTE: This means that a sender can ALWAYS send messages to the mailing list that are automatically approved without any moderation.'''<br />
* '''Discard''': Removes the message from the moderation queue and does '''not''' send the message to the mailing list. The sender does '''not''' receive a notification that the message was not approved for sending. This is typically used for messages that are spam.<br />
* '''Reject''': Prompts the moderator to enter a reason for rejecting the message to be delivered to the sender and removes the message from the moderation queue. This action does '''not''' send the message to the mailing list. The sender receives a notification that the message was not approved for sending as well as the reason why it was rejected. ''Please be polite with your responses'': someone sending an email to the list may not be aware of the list policy, so try to point them to the correct reference.<br />
* '''Unsubscribe''': Unsubscribes the sender from the list. This requires the sender to be identified as an active subscriber of the list.<br />
* '''Reject unsub''': The same as ''reject'', except the reason is set to a pre-canned message with full instructions for how to use the List headers to unsubscribe from a message. This is the appropriate choice when an unsubscribe request is received from a sender who is not identified as a subscriber of the list.<br />
<br />
In order to finalize all the selected actions, a moderator must click '''Moderate''' at the bottom of the Moderation section.<br />
<br />
==== Explaining the Moderation email ====<br />
<br />
It is also possible to moderate messages from an email sent to moderators of a list. You will probably want to see a preview of the message before applying a moderation action, but fortunately you can do this from the email. All actions are the same as [[#Moderation Actions|moderation actions]] described above, but as soon as you click on the URL, this action is taken. A few notes:<br />
<br />
* '''Preview''': Brings you to a preview of the message. This opens up a tab in your browser with the contents of the message.<br />
* '''Reject''': Reject is currently not supported from the moderation email. If you would like to provide a rejection reason for the message, you will have to view the moderation dashboard.<br />
<br />
=== List Management Overview ===<br />
<br />
The list management overview of the moderation screen is a list of the mailing lists that you moderate. If you click on one of the lists, you will be brought to the individual list management page.<br />
<br />
== List Management ==<br />
<br />
The list management section of PGLister enables a moderator to perform the following actions:<br />
<br />
* View which email addresses are subscribed to the list. This also allows a moderator to unsubscribe email addresses from a list<br />
* Subscribe new email addresses to the list<br />
* Whitelist email addresses that are always allowed to post messages to the list<br />
<br />
=== View/Unsubscribe ===<br />
<br />
The view/unsubscribe portion of the list manager allows a moderator to see who is subscribed to a mailing list and have the option of unsubscribing those email addresses.<br />
<br />
There is a box that allows for a moderator to search for an email address. If nothing is typed into the box, then all email addresses subscribed to that list are displayed in the next view. From there, a moderator can view the email addresses that are subscribed to the list as well as unsubscribe these particular email addresses.<br />
<br />
=== Subscribe ===<br />
<br />
The subscribe section allows a moderator to subscribe an email address to the list. If you are adding an email address using this method, please be sure that the owner of the email address has given you permission to do so as the email address will automatically be subscribed to the mailing list without any additional confirmation.<br />
<br />
=== Whitelist ===<br />
<br />
The whitelist section allows a moderator to manage email addresses that can always post to the particular email list without moderator approval. A moderator can also remove email addresses from the whitelist too. Please use this feature carefully. If you have any questions on how the whitelist works, please send an email to [mailto:sysadmins@postgresql.org sysadmins@postgresql.org].</div>Mhahttps://wiki.postgresql.org/index.php?title=NewAnnounceProcessSeptember2020&diff=35315NewAnnounceProcessSeptember20202020-09-10T11:42:52Z<p>Mha: Created page with "As of September 10th 2020, direct emails to the pgsql-announce mailing list are no longer accepted. There are several reasons for this: * Reduce the chances that email to the..."</p>
<hr />
<div>As of September 10th 2020, direct emails to the pgsql-announce mailing list are no longer accepted.<br />
<br />
There are several reasons for this:<br />
* Reduce the chances that email to the list gets flagged as spam. Many senders on pgsql-announce today are sending from domains that disallow relaying through mailing lists, which also means other emails to the list get hurt because systems “learn” that this happens.<br />
* More clearly differentiate between emails from the PostgreSQL project itself and other announcements.<br />
* Ensure that no tracking pixels and similar entries can be sent to subscribers through the lists.<br />
* Make it possible for subscribers to decide which topics they are interested in receiving email about, through the use of tags.<br />
* Unify the moderation practices between news on www.postgresql.org and pgsql-announce that have sometimes been inconsistent, and posting to both have often led to very different delivery times depending on order of moderation.<br />
<br />
Instead of posting directly to the list, posters will be using the system for posting news to www.postgresql.org. Anything posted as news there will automatically be sent as an email to pgsql-announce, and the same set of tags that are used for the website will be used for email delivery.<br />
<br />
All emails will be sent from a system address that will handle eventual bounces, but the reply address of the email will be selected by the person sending the announcement from one of the confirmed addresses for the organisation. All organisations that want to post news will have to confirm at least one email address to be used (this is done from the same interface), and can have multiple ones if wanted. Specifically, the From address in the email letter header will be set to noreply-announce@postgresql.org, and the Reply-To header will be set to the selected email address, so a user hitting 'reply' in nearly all mail clients will have the To address populated with the selected email address.<br />
<br />
Just like for the website, email content can be written in markdown (and previewed on the site), which will be delivered as a rich text email to the recipients (along with a plain markdown version as well, of course). Emails will be delivered immediately as the news item on the website is approved.<br />
<br />
There are sure to be some issues with this system in the beginning, so if you are running into any form of problems or have questions about it, please don’t hesitate to reach out to us at webmaster@postgresql.org. If you are uncertain, please do so *before* submitting news for moderation!</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_13_Open_Items&diff=35110PostgreSQL 13 Open Items2020-07-07T08:55:04Z<p>Mha: /* Open Issues */</p>
<hr />
<div>== Open Issues ==<br />
<br />
'''NOTE''': Please add new open items to the bottom of the list.<br />
<br />
* [https://www.postgresql.org/message-id/20200606041146.slqfg7cuptx27tuy@alap3.anarazel.de HashAggs-that-spill patch introduced a perf regression affecting classic in-memory HashAggs]<br />
** Owner: Jeff Davis<br />
<br />
* [https://www.postgresql.org/message-id/20200625203629.7m6yvut7eqblgmfo@alap3.anarazel.de Many users rely on hashagg exceeding work_mem, regardless of whether or not that is the intended behavior in Postgres 12]<br />
** When these users don't continue to get fast in-memory hash aggs after an upgrade to Postgres 13, they'll simply conclude that it's a regression.<br />
** Increasing work_mem isn't usually an option, since that affects everything equally.<br />
** There are good general reasons to preferentially give hash aggregate more memory than a sort used for a group aggregate, so these users will certainly have a point if this happens. <br />
** Owner: Jeff Davis<br />
<br />
* [https://www.postgresql.org/message-id/CAApHDvo_dmNozQQTmN-2jGp1vT%3Ddxx7Q0vd%2BMvD1cGpv2HU%3DSg%40mail.gmail.com explain non-text format should always include all fields, even if zero]<br />
** [https://www.postgresql.org/message-id/20200619040358.GZ17995@telsasoft.com incremental sort] Owner: James Coleman, Tomas Vondra<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAB%3DJe-GOWMj1PTPkeUhjqQp-4W3%3DnW-pXe2Hjax6rJFffB5_Aw%40mail.gmail.com Initiating Physical Replication on a Logical Replication Session]<br />
<br />
* [https://www.postgresql.org/message-id/9ddfbf8c-2f67-904d-44ed-cf8bc5916228@oss.nttdata.com min_safe_lsn column in pg_replication_slots view]<br />
** Owner: Alvaro Herrera<br />
<br />
* [https://www.postgresql.org/message-id/flat/2edc7b27-031f-b2b6-0db2-864241c91cb9%402ndquadrant.com output columns of \dAo and \dAp]<br />
** original commit: b0b5e20cd8d<br />
<br />
* [https://www.postgresql.org/message-id/flat/CA%2Bfd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg%40mail.gmail.com Replication slot spill statistics in the wrong place]<br />
** original commit: 9290ad198b1<br />
<br />
== Decisions to Re-Check Mid Beta ==<br />
<br />
* [https://postgr.es/m/9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com Default setting for enable_hashagg_disk]<br />
** This thread is [https://postgr.es/m/CAH2-WzmD+i1pG6rc1+Cjc4V6EaFJ_qSuKCCHVnH=oruqD-zqow@mail.gmail.com now mostly a discussion] of the separate "Many users rely on hashagg exceeding work_mem, regardless of whether or not that is the intended behavior in Postgres 12" item, which seems like the real problem here<br />
** Owner: Jeff Davis<br />
<br />
== Older Bugs ==<br />
<br />
=== Live issues ===<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAKcux6k2KoQ%3DWjvNdW_Jyct7HuoVvqdgj-bEiXavS1BqOPzi%2Bw%40mail.gmail.com ERROR with FOR UPDATE/SHARE for partitioned table.]<br />
** Affects v12 and probably v11 (partition pruning)<br />
<br />
=== Fixed issues ===<br />
<br />
* [https://www.postgresql.org/message-id/20200615131405.GM52676@paquier.xyz Failures with wal_consistency_checking - SPGist/VACUUM_REDIRECT record]<br />
** Fixed at: {{PgCommitURL|a44dd932ff3816de7fe0414063cfcc5656117c3a}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200217225333.GA30974@alvherre.pgsql pg_dump does not reproduce ALTER ... DEPENDS ON EXTENSION]<br />
** Fixed at: {{PgCommitURL|5fc703946bf3b18642ce83b937671d254a8ac5b5}}<br />
** Still affected in previous versions, but only patched to PG13<br />
<br />
* [https://www.postgresql.org/message-id/20200328151721.GB12854%40nol pg_stat_statements doesn't report buffer consumption from parallel utility workers]<br />
** Commit: {{PgCommitURL|9da0cc35284bdbe8d442d732963303ff0e0a40bc}} (parallel btree index build) - Fixed at 5c71362174eb56676f8b91c73ec066dd5513fd4b<br />
** Commit: {{PgCommitURL|40d964ec997f64227bc0ff5e058dc4a5770a70a9}} (parallel vacuum) - Fixed at 3a5e22138a8d014590834eb808c99a436c246aab<br />
<br />
* [https://www.postgresql.org/message-id/flat/21519.1585272409%40sss.pgh.pa.us Intermittent assertion failure in SyncRepGetSyncStandbysPriority]<br />
** Fixed at: {{PgCommitURL|f332241a60aa9c0945d74642cb3dbcbc11621154}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200408152412.GZ2228%40telsasoft.com DETACH PARTITION and FOR EACH ROW triggers on partitioned tables]<br />
** Fixed at: {{PgCommitURL|afccd76f1ccef73a341e9b0c6efb29a429f35aa4}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200323165059.GA24950%40alvherre.pgsql hash node details apparently accessing pfreed allocation]<br />
** Commit: {{PgCommitURL|3fc6e2d7f}}<br />
** Fixed at: {{PgCommitURL|5c27bce7f3}}, {{PgCommitURL|969f9d0b4}}<br />
** Fixed in backbranches by: {{PgCommitURL|5c27bce7f}} et al<br />
<br />
* [https://www.postgresql.org/message-id/CAFiTN-u64S5bUiPL1q5kwpHNd0hRnf1OE-bzxNiOs5zo84i51w%40mail.gmail.com Crash involving logical replication REPLICA IDENTITY FULL and subscribe+publish]<br />
** Affects v10-master<br />
** Fixed at: {{PgCommitURL|7ccb2f54d9f3f3c5b4ac092d62c846b02a47f8d5}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAJGNTeO93u-5APMga6WH41eTZ3Uee9f3s8dCpA-GSSqNs1b=Ug@mail.gmail.com segmentation fault using currtid and partitioned tables]<br />
** Issue with tableam (since v12)<br />
** Fixed at: {{PgCommitURL|e786be5fcb257a09b05bd8e509c8d1b82e626352}}<br />
<br />
=== Nothing to do ===<br />
<br />
* [https://www.postgresql.org/message-id/20200415233848.saqp72pcjv2y6ryi%40alap3.anarazel.de xid wraparound danger due to INDEX_CLEANUP false.]<br />
** Affects v12<br />
** This bug [https://www.postgresql.org/message-id/CA+TgmoYD7Xpr1DWEWWXxiw4-WC1NBJf3Rb9D2QGpVYH9ejz9fA@mail.gmail.com will not be fixed] in v13 or other backbranches.<br />
** Maybe it can be fixed by future work that makes B-Tree page recycling work at the tail end of the same VACUUM operation that initially deletes the pages, but that's out of scope for now.<br />
<br />
== Non-bugs ==<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 13beta3 ===<br />
<br />
* [https://www.postgresql.org/message-id/2895b53b033c47ccb22972b589050dd9@EX13D05UWC001.ant.amazon.com pg_stat_statements + track_planning performance regression]<br />
** Fixed at: {{PgCommitURL|d1763ea8c9c32837d373a196ed0c2e1256a55824}}<br />
** Owner: Fujii Masao<br />
<br />
* Review the decision to enable deduplication by default (i.e. use 'on' as the default setting for the 'deduplicate_items' B-Tree storage parameter).<br />
** Commit: {{PgCommitURL|0d861bbb}}<br />
** Owner: Peter Geoghegan<br />
** The deduplication feature will [https://www.postgresql.org/message-id/CAH2-Wzm1u8HmCamGj2LmtvUudzai5qDJryTotu++JLLD9KVMRw@mail.gmail.com remain enabled by default].<br />
<br />
* [https://www.postgresql.org/message-id/flat/a9408304-4381-a5af-d259-e55d349ae4ce@2ndquadrant.com rethink libpq's default min SSL version]<br />
** Commit: {{PgCommitURL|6e682f61a5bdb08164a805419144318db6b7229f}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/8d55969f-ba37-b89a-6494-e9322ccdb35d%40oss.nttdata.com Review for GetWALAvailability()]<br />
** Commit: {{PgCommitURL|b8fd4e02c6d01183bf6def5897ad6cf7766bfff4}}<br />
<br />
* [https://www.postgresql.org/message-id/f91de4fb-a7ab-b90e-8132-74796e049d51%40oss.nttdata.com Assertion failure in pg_copy_logical_replication_slot()]<br />
** Commit: {{PgCommitURL|a82ba066ea217e7fe4da3c20ced01e7ca976a351}}<br />
<br />
* [https://www.postgresql.org/message-id/CAApHDvo_dmNozQQTmN-2jGp1vT%3Ddxx7Q0vd%2BMvD1cGpv2HU%3DSg%40mail.gmail.com explain non-text format should always include all fields, even if zero]<br />
** [https://www.postgresql.org/message-id/20200619040624.GA17995@telsasoft.com hashagg spill to disk] Owner: Jeff Davis<br />
** Commit: {{PgCommitURL|d73e9a57bf5bd977d9bf36bc07c77a1acf45e35b}}<br />
<br />
=== resolved before 13beta2 ===<br />
<br />
* [https://www.postgresql.org/message-id/flat/CA%2BhUKGJUw08dPs_3EUcdO6M90GnjofPYrWp4YSLaBkgYwS-AqA%40mail.gmail.com Should we rename effective_io_concurrency?] It now has a different meaning and you might want to turn it up higher, though the default behaviour hasn't changed.<br />
** Commit: {{PgCommitURL|b09ff536}}<br />
** No one argued strongly in favour of changing it, so let's leave it as it is.<br />
<br />
* [https://postgr.es/m/CAB=Je-GOWMj1PTPkeUhjqQp-4W3=nW-pXe2Hjax6rJFffB5_Aw@mail.gmail.com SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762]<br />
** Commit: {{PgCommitURL|10ffe0fa}}<br />
<br />
* [https://www.postgresql.org/message-id/e9766d71-8655-ac86-bdf6-77e0e7169977@2ndquadrant.com Moving fe_archive.c to src/fe_utils/]<br />
** Commit: {{PgCommitURL|a3b2bf1f}}<br />
<br />
* [https://www.postgresql.org/message-id/20200519151202.u2p2gpiawoaznsv2@development Trouble with hashagg spill I/O pattern and costing]<br />
** Fixed at: {{PgCommitURL|896ddf9b3cd7dcf70e43f733ae8fec5dfe6e31af}}<br />
** Fixed at: {{PgCommitURL|4cad2534da6d17067d98cf04be2dfc1bda8f2cd0}}<br />
<br />
* [https://postgr.es/m/99b2eab335c1592c925d8143979c8e9e81e1575f.camel@j-davis.com Possible regression with FORTIFY_SOURCE]<br />
** Fixed at: {{PgCommitURL|1fbb6c93df30801f83c6804ab7befde3cdefe677}}<br />
<br />
* [https://www.postgresql.org/message-id/8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com GUC naming]<br />
** Fixed at: {{PgCommitURL|13e0fa7ae50cd0e91158877dba37098492b234e8}}<br />
<br />
* [https://www.postgresql.org/message-id/20200606001926.zin5getvvhqppnm2%40alap3.anarazel.de Global barrier w/disable atomics leads to spinlock use in signal handlers]<br />
** Commit: {{PgCommitURL|fd49d53807575e009f7b66771d48c9356344d7d1}}<br />
<br />
* [https://www.postgresql.org/message-id/CAApHDvpEKbfZa18mM1TD7qV6PG+w97pwCWq5tVD0dX7e11gRJw@mail.gmail.com Missing EXPLAIN ANALYZE properties for parallel HashAgg plans]<br />
** Commit: {{PgCommitURL|9bdb300dedf086cc54edf740088208e6b24307ef}}<br />
<br />
=== resolved before 13beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/20200406025651.fpzdb5yyb7qyhqko@alap3.anarazel.de 2pc leaks fds]<br />
** Commit: {{PgCommitURL|0dc8ead4}}<br />
** Owner: Alvaro Herrera<br />
** Fixed at {{PgCommitURL|91c40548}} and {{PgCommitURL|b060dbe000}}<br />
<br />
* [https://www.postgresql.org/message-id/20200408.093710.447591748588426656.horikyota.ntt@gmail.com Two issues related to slot-invalidation ]<br />
** Crash on logical-walsender startup after slot invalidation<br />
*** Fixed at {{PgCommitURL|d0abe78d84274cc203f3d117b8006dc2164ca31a}}<br />
** Checkpointer missses requests when slot invalidation occurs<br />
*** Fixed at {{PgCommitURL|1816a1c6ffe46782eee9a16a974b4aa3f4b8457b}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200310190142.GB29065%40telsasoft.com#78420835db672ec62b83e00789efb367 "backend type in log_line_prefix": Update file_fdw]<br />
** Fixed at {{PgCommitURL|0830d21f5b01064837dc8bd910ab31a5b7a1101a}}<br />
<br />
* [https://www.postgresql.org/message-id/753391579708726@iva3-77ae5995f07f.qloud-c.yandex.net Rework handling of wal_receiver_create_temp_slot to fit with WAL receiver architecture]<br />
** Fixed at {{PgCommitURL|092c6936de49e}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAMbWs4_maqdBnRR4x01pDpoV-CiQ%2BRvMQaPm4JoTPbA%3DmZmhMw%40mail.gmail.com Negative cost is seen for plan node: Hash agg spill to disk]<br />
** Fixed at: {{PgCommitURL|7351bfeda33b60b69c15791c7eb77a127546df26}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200315234833.GA31110%40alvherre.pgsql#c50e981ed9dd24101c0ec054d5511d7f control max length of parameter values logged]<br />
** Fixed at {{PgCommitURL|0b34e7d307e6a142ee94800e6d5f3e73449eeffd}}<br />
<br />
* [https://www.postgresql.org/message-id/16346-6210ad7a0ea81be1@postgresql.org BUG #16346: pg_upgrade fails on a trigger with a comment]<br />
** Fixed at: {{PgCommitURL|a9d70c108786712a1023c65e360602edf7bafbf4}}<br />
<br />
* [https://postgr.es/m/ec63d70b668818255486a83ffadc3aec492c1f57.camel%40j-davis.com Tweak memory accounting for Hash Aggregation]<br />
** Fixed at: {{PgCommitURL|50a38f65177ea7858bc97f71ba0757ba04c1c167}}<br />
<br />
* [https://www.postgresql.org/message-id/20200410080910.GZ1606@paquier.xyz pg_basebackup, manifests and backends older than ~12]<br />
** Fixed at: {{PgCommitURL|542d7817f774ea9d94798eb95cdf250d4f1527d9}}<br />
<br />
* [https://www.postgresql.org/message-id/58c8d171-e665-6fa3-a9d3-d9423b694dae@enterprisedb.com Vacuum o/p with (full 1, parallel 0) option throwing an error]<br />
** Fixed at: {{PgCommitURL|24d2d38b1eb86c0b410ad0f07f66566a83c6f05c}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200411214639.GK2228%40telsasoft.com sqlsmith crash incremental sort]<br />
** Fixed at: {{PgCommitURL|de0dc1a84710f127fdd40f87e783797cc2d69a77}}<br />
<br />
* [https://www.postgresql.org/message-id/2266d9f2-70fe-3156-8fea-e3403461cbdc@2ndquadrant.com Rename libpq parameters ssl{min|max}protocolversion to ssl_{min|max}_protocol_version?]<br />
** Fixed at: {{PgCommitURL|401aad67045b2d467571b54abe229fdd115a228c}}<br />
<br />
* [https://www.postgresql.org/message-id/20200402054120.GC14618@telsasoft.com consistency of explain output: two spaces, equals vs colons, semicolons (WAL)]<br />
** Fixed at: {{PgCommitURL|69bfaf2e1de49de76d7dec1c45511932a5ef502b}}<br />
<br />
* [https://www.postgresql.org/message-id/20200414065336.GI1492@paquier.xyz Incremental sorts and EXEC_FLAG_REWIND]<br />
** Fixed at: {{PgCommitURL|c4427226483c78618ba45eff34917400a77718a5}}<br />
<br />
* consistency of explain output: two spaces, equals vs colons, semicolons (incremental sort)<br />
** [https://www.postgresql.org/message-id/20200407042521.GH2228%40telsasoft.com incremental sort]<br />
** Fixed at: {{PgCommitURL|6a918c3ac8a6b1d8b53cead6fcb7cbd84eee5750}}<br />
<br />
* [https://postgr.es/m/981DE552-E399-45C2-9F60-3F0E3770CC61@yesql.se Naming issue with client-side sslpassword hook]<br />
** Fixed at: {{PgCommitURL|36d1087611bf96b0cd716666fc8c4a2d168fa501}}<br />
<br />
* [https://postgr.es/m/21247.1589296570@sss.pgh.pa.us Naming issues for wait events, and particularly SLRU caches]<br />
** Fixed at: {{PgCommitURL|3048898e73c75f54bb259323382e0e7f6368cb6f}} and predecessor patches<br />
<br />
* [https://postgr.es/m/20200515090817.GA212736@paquier.xyz pg_stat_wal_receiver and flushedUpto/writtenUpto]<br />
** Fixed at: {{PgCommitURL|2c8dd05d6cbc86b7ad21cfd7010e041bb4c3950b}}<br />
<br />
== Won't Fix ==<br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
<br />
* Feature Freeze: April 7, 2020 ('''Last Day to Commit Features''')<br />
* Beta 1: May 21, 2020<br />
* Beta 2: June 25, 2020<br />
<br />
[[Category:Open_Items]]</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_13_Open_Items&diff=35109PostgreSQL 13 Open Items2020-07-07T08:54:49Z<p>Mha: /* Open Issues */</p>
<hr />
<div>== Open Issues ==<br />
<br />
'''NOTE''': Please add new open items to the bottom of the list.<br />
<br />
* [https://www.postgresql.org/message-id/20200606041146.slqfg7cuptx27tuy@alap3.anarazel.de HashAggs-that-spill patch introduced a perf regression affecting classic in-memory HashAggs]<br />
** Owner: Jeff Davis<br />
<br />
* [https://www.postgresql.org/message-id/20200625203629.7m6yvut7eqblgmfo@alap3.anarazel.de Many users rely on hashagg exceeding work_mem, regardless of whether or not that is the intended behavior in Postgres 12]<br />
** When these users don't continue to get fast in-memory hash aggs after an upgrade to Postgres 13, they'll simply conclude that it's a regression.<br />
** Increasing work_mem isn't usually an option, since that affects everything equally.<br />
** There are good general reasons to preferentially give hash aggregate more memory than a sort used for a group aggregate, so these users will certainly have a point if this happens. <br />
** Owner: Jeff Davis<br />
<br />
* [https://www.postgresql.org/message-id/CAApHDvo_dmNozQQTmN-2jGp1vT%3Ddxx7Q0vd%2BMvD1cGpv2HU%3DSg%40mail.gmail.com explain non-text format should always include all fields, even if zero]<br />
** [https://www.postgresql.org/message-id/20200619040358.GZ17995@telsasoft.com incremental sort] Owner: James Coleman, Tomas Vondra<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAB%3DJe-GOWMj1PTPkeUhjqQp-4W3%3DnW-pXe2Hjax6rJFffB5_Aw%40mail.gmail.com Initiating Physical Replication on a Logical Replication Session]<br />
<br />
* [https://www.postgresql.org/message-id/9ddfbf8c-2f67-904d-44ed-cf8bc5916228@oss.nttdata.com min_safe_lsn column in pg_replication_slots view]<br />
** Owner: Alvaro Herrera<br />
<br />
* [https://www.postgresql.org/message-id/flat/2edc7b27-031f-b2b6-0db2-864241c91cb9%402ndquadrant.com output columns of \dAo and \dAp]<br />
** original commit: b0b5e20cd8d<br />
<br />
* [https://www.postgresql.org/message-id/flat/CA%2Bfd4k5_pPAYRTDrO2PbtTOe0eHQpBvuqmCr8ic39uTNmR49Eg%40mail.gmail.com Replication slot spill statistics int eh wrong place]<br />
** original commit: 9290ad198b1<br />
<br />
== Decisions to Re-Check Mid Beta ==<br />
<br />
* [https://postgr.es/m/9d9d1e1252a52ea1bad84ea40dbebfd54e672a0f.camel@j-davis.com Default setting for enable_hashagg_disk]<br />
** This thread is [https://postgr.es/m/CAH2-WzmD+i1pG6rc1+Cjc4V6EaFJ_qSuKCCHVnH=oruqD-zqow@mail.gmail.com now mostly a discussion] of the separate "Many users rely on hashagg exceeding work_mem, regardless of whether or not that is the intended behavior in Postgres 12" item, which seems like the real problem here<br />
** Owner: Jeff Davis<br />
<br />
== Older Bugs ==<br />
<br />
=== Live issues ===<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAKcux6k2KoQ%3DWjvNdW_Jyct7HuoVvqdgj-bEiXavS1BqOPzi%2Bw%40mail.gmail.com ERROR with FOR UPDATE/SHARE for partitioned table.]<br />
** Affects v12 and probably v11 (partition pruning)<br />
<br />
=== Fixed issues ===<br />
<br />
* [https://www.postgresql.org/message-id/20200615131405.GM52676@paquier.xyz Failures with wal_consistency_checking - SPGist/VACUUM_REDIRECT record]<br />
** Fixed at: {{PgCommitURL|a44dd932ff3816de7fe0414063cfcc5656117c3a}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200217225333.GA30974@alvherre.pgsql pg_dump does not reproduce ALTER ... DEPENDS ON EXTENSION]<br />
** Fixed at: {{PgCommitURL|5fc703946bf3b18642ce83b937671d254a8ac5b5}}<br />
** Still affected in previous versions, but only patched to PG13<br />
<br />
* [https://www.postgresql.org/message-id/20200328151721.GB12854%40nol pg_stat_statements doesn't report buffer consumption from parallel utility workers]<br />
** Commit: {{PgCommitURL|9da0cc35284bdbe8d442d732963303ff0e0a40bc}} (parallel btree index build) - Fixed at 5c71362174eb56676f8b91c73ec066dd5513fd4b<br />
** Commit: {{PgCommitURL|40d964ec997f64227bc0ff5e058dc4a5770a70a9}} (parallel vacuum) - Fixed at 3a5e22138a8d014590834eb808c99a436c246aab<br />
<br />
* [https://www.postgresql.org/message-id/flat/21519.1585272409%40sss.pgh.pa.us Intermittent assertion failure in SyncRepGetSyncStandbysPriority]<br />
** Fixed at: {{PgCommitURL|f332241a60aa9c0945d74642cb3dbcbc11621154}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200408152412.GZ2228%40telsasoft.com DETACH PARTITION and FOR EACH ROW triggers on partitioned tables]<br />
** Fixed at: {{PgCommitURL|afccd76f1ccef73a341e9b0c6efb29a429f35aa4}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200323165059.GA24950%40alvherre.pgsql hash node details apparently accessing pfreed allocation]<br />
** Commit: {{PgCommitURL|3fc6e2d7f}}<br />
** Fixed at: {{PgCommitURL|5c27bce7f3}}, {{PgCommitURL|969f9d0b4}}<br />
** Fixed in backbranches by: {{PgCommitURL|5c27bce7f}} et al<br />
<br />
* [https://www.postgresql.org/message-id/CAFiTN-u64S5bUiPL1q5kwpHNd0hRnf1OE-bzxNiOs5zo84i51w%40mail.gmail.com Crash involving logical replication REPLICA IDENTITY FULL and subscribe+publish]<br />
** Affects v10-master<br />
** Fixed at: {{PgCommitURL|7ccb2f54d9f3f3c5b4ac092d62c846b02a47f8d5}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAJGNTeO93u-5APMga6WH41eTZ3Uee9f3s8dCpA-GSSqNs1b=Ug@mail.gmail.com segmentation fault using currtid and partitioned tables]<br />
** Issue with tableam (since v12)<br />
** Fixed at: {{PgCommitURL|e786be5fcb257a09b05bd8e509c8d1b82e626352}}<br />
<br />
=== Nothing to do ===<br />
<br />
* [https://www.postgresql.org/message-id/20200415233848.saqp72pcjv2y6ryi%40alap3.anarazel.de xid wraparound danger due to INDEX_CLEANUP false.]<br />
** Affects v12<br />
** This bug [https://www.postgresql.org/message-id/CA+TgmoYD7Xpr1DWEWWXxiw4-WC1NBJf3Rb9D2QGpVYH9ejz9fA@mail.gmail.com will not be fixed] in v13 or other backbranches.<br />
** Maybe it can be fixed by future work that makes B-Tree page recycling work at the tail end of the same VACUUM operation that initially deletes the pages, but that's out of scope for now.<br />
<br />
== Non-bugs ==<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 13beta3 ===<br />
<br />
* [https://www.postgresql.org/message-id/2895b53b033c47ccb22972b589050dd9@EX13D05UWC001.ant.amazon.com pg_stat_statements + track_planning performance regression]<br />
** Fixed at: {{PgCommitURL|d1763ea8c9c32837d373a196ed0c2e1256a55824}}<br />
** Owner: Fujii Masao<br />
<br />
* Review the decision to enable deduplication by default (i.e. use 'on' as the default setting for the 'deduplicate_items' B-Tree storage parameter).<br />
** Commit: {{PgCommitURL|0d861bbb}}<br />
** Owner: Peter Geoghegan<br />
** The deduplication feature will [https://www.postgresql.org/message-id/CAH2-Wzm1u8HmCamGj2LmtvUudzai5qDJryTotu++JLLD9KVMRw@mail.gmail.com remain enabled by default].<br />
<br />
* [https://www.postgresql.org/message-id/flat/a9408304-4381-a5af-d259-e55d349ae4ce@2ndquadrant.com rethink libpq's default min SSL version]<br />
** Commit: {{PgCommitURL|6e682f61a5bdb08164a805419144318db6b7229f}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/8d55969f-ba37-b89a-6494-e9322ccdb35d%40oss.nttdata.com Review for GetWALAvailability()]<br />
** Commit: {{PgCommitURL|b8fd4e02c6d01183bf6def5897ad6cf7766bfff4}}<br />
<br />
* [https://www.postgresql.org/message-id/f91de4fb-a7ab-b90e-8132-74796e049d51%40oss.nttdata.com Assertion failure in pg_copy_logical_replication_slot()]<br />
** Commit: {{PgCommitURL|a82ba066ea217e7fe4da3c20ced01e7ca976a351}}<br />
<br />
* [https://www.postgresql.org/message-id/CAApHDvo_dmNozQQTmN-2jGp1vT%3Ddxx7Q0vd%2BMvD1cGpv2HU%3DSg%40mail.gmail.com explain non-text format should always include all fields, even if zero]<br />
** [https://www.postgresql.org/message-id/20200619040624.GA17995@telsasoft.com hashagg spill to disk] Owner: Jeff Davis<br />
** Commit: {{PgCommitURL|d73e9a57bf5bd977d9bf36bc07c77a1acf45e35b}}<br />
<br />
=== resolved before 13beta2 ===<br />
<br />
* [https://www.postgresql.org/message-id/flat/CA%2BhUKGJUw08dPs_3EUcdO6M90GnjofPYrWp4YSLaBkgYwS-AqA%40mail.gmail.com Should we rename effective_io_concurrency?] It now has a different meaning and you might want to turn it up higher, though the default behaviour hasn't changed.<br />
** Commit: {{PgCommitURL|b09ff536}}<br />
** No one argued strongly in favour of changing it, so let's leave it as it is.<br />
<br />
* [https://postgr.es/m/CAB=Je-GOWMj1PTPkeUhjqQp-4W3=nW-pXe2Hjax6rJFffB5_Aw@mail.gmail.com SIGSEGV from START_REPLICATION 0/XXXXXXX in XLogSendPhysical () at walsender.c:2762]<br />
** Commit: {{PgCommitURL|10ffe0fa}}<br />
<br />
* [https://www.postgresql.org/message-id/e9766d71-8655-ac86-bdf6-77e0e7169977@2ndquadrant.com Moving fe_archive.c to src/fe_utils/]<br />
** Commit: {{PgCommitURL|a3b2bf1f}}<br />
<br />
* [https://www.postgresql.org/message-id/20200519151202.u2p2gpiawoaznsv2@development Trouble with hashagg spill I/O pattern and costing]<br />
** Fixed at: {{PgCommitURL|896ddf9b3cd7dcf70e43f733ae8fec5dfe6e31af}}<br />
** Fixed at: {{PgCommitURL|4cad2534da6d17067d98cf04be2dfc1bda8f2cd0}}<br />
<br />
* [https://postgr.es/m/99b2eab335c1592c925d8143979c8e9e81e1575f.camel@j-davis.com Possible regression with FORTIFY_SOURCE]<br />
** Fixed at: {{PgCommitURL|1fbb6c93df30801f83c6804ab7befde3cdefe677}}<br />
<br />
* [https://www.postgresql.org/message-id/8bff2e4e8020c3caa16b61a46918d21b573eaf78.camel@j-davis.com GUC naming]<br />
** Fixed at: {{PgCommitURL|13e0fa7ae50cd0e91158877dba37098492b234e8}}<br />
<br />
* [https://www.postgresql.org/message-id/20200606001926.zin5getvvhqppnm2%40alap3.anarazel.de Global barrier w/disable atomics leads to spinlock use in signal handlers]<br />
** Commit: {{PgCommitURL|fd49d53807575e009f7b66771d48c9356344d7d1}}<br />
<br />
* [https://www.postgresql.org/message-id/CAApHDvpEKbfZa18mM1TD7qV6PG+w97pwCWq5tVD0dX7e11gRJw@mail.gmail.com Missing EXPLAIN ANALYZE properties for parallel HashAgg plans]<br />
** Commit: {{PgCommitURL|9bdb300dedf086cc54edf740088208e6b24307ef}}<br />
<br />
=== resolved before 13beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/20200406025651.fpzdb5yyb7qyhqko@alap3.anarazel.de 2pc leaks fds]<br />
** Commit: {{PgCommitURL|0dc8ead4}}<br />
** Owner: Alvaro Herrera<br />
** Fixed at {{PgCommitURL|91c40548}} and {{PgCommitURL|b060dbe000}}<br />
<br />
* [https://www.postgresql.org/message-id/20200408.093710.447591748588426656.horikyota.ntt@gmail.com Two issues related to slot-invalidation ]<br />
** Crash on logical-walsender startup after slot invalidation<br />
*** Fixed at {{PgCommitURL|d0abe78d84274cc203f3d117b8006dc2164ca31a}}<br />
** Checkpointer missses requests when slot invalidation occurs<br />
*** Fixed at {{PgCommitURL|1816a1c6ffe46782eee9a16a974b4aa3f4b8457b}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200310190142.GB29065%40telsasoft.com#78420835db672ec62b83e00789efb367 "backend type in log_line_prefix": Update file_fdw]<br />
** Fixed at {{PgCommitURL|0830d21f5b01064837dc8bd910ab31a5b7a1101a}}<br />
<br />
* [https://www.postgresql.org/message-id/753391579708726@iva3-77ae5995f07f.qloud-c.yandex.net Rework handling of wal_receiver_create_temp_slot to fit with WAL receiver architecture]<br />
** Fixed at {{PgCommitURL|092c6936de49e}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAMbWs4_maqdBnRR4x01pDpoV-CiQ%2BRvMQaPm4JoTPbA%3DmZmhMw%40mail.gmail.com Negative cost is seen for plan node: Hash agg spill to disk]<br />
** Fixed at: {{PgCommitURL|7351bfeda33b60b69c15791c7eb77a127546df26}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200315234833.GA31110%40alvherre.pgsql#c50e981ed9dd24101c0ec054d5511d7f control max length of parameter values logged]<br />
** Fixed at {{PgCommitURL|0b34e7d307e6a142ee94800e6d5f3e73449eeffd}}<br />
<br />
* [https://www.postgresql.org/message-id/16346-6210ad7a0ea81be1@postgresql.org BUG #16346: pg_upgrade fails on a trigger with a comment]<br />
** Fixed at: {{PgCommitURL|a9d70c108786712a1023c65e360602edf7bafbf4}}<br />
<br />
* [https://postgr.es/m/ec63d70b668818255486a83ffadc3aec492c1f57.camel%40j-davis.com Tweak memory accounting for Hash Aggregation]<br />
** Fixed at: {{PgCommitURL|50a38f65177ea7858bc97f71ba0757ba04c1c167}}<br />
<br />
* [https://www.postgresql.org/message-id/20200410080910.GZ1606@paquier.xyz pg_basebackup, manifests and backends older than ~12]<br />
** Fixed at: {{PgCommitURL|542d7817f774ea9d94798eb95cdf250d4f1527d9}}<br />
<br />
* [https://www.postgresql.org/message-id/58c8d171-e665-6fa3-a9d3-d9423b694dae@enterprisedb.com Vacuum o/p with (full 1, parallel 0) option throwing an error]<br />
** Fixed at: {{PgCommitURL|24d2d38b1eb86c0b410ad0f07f66566a83c6f05c}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/20200411214639.GK2228%40telsasoft.com sqlsmith crash incremental sort]<br />
** Fixed at: {{PgCommitURL|de0dc1a84710f127fdd40f87e783797cc2d69a77}}<br />
<br />
* [https://www.postgresql.org/message-id/2266d9f2-70fe-3156-8fea-e3403461cbdc@2ndquadrant.com Rename libpq parameters ssl{min|max}protocolversion to ssl_{min|max}_protocol_version?]<br />
** Fixed at: {{PgCommitURL|401aad67045b2d467571b54abe229fdd115a228c}}<br />
<br />
* [https://www.postgresql.org/message-id/20200402054120.GC14618@telsasoft.com consistency of explain output: two spaces, equals vs colons, semicolons (WAL)]<br />
** Fixed at: {{PgCommitURL|69bfaf2e1de49de76d7dec1c45511932a5ef502b}}<br />
<br />
* [https://www.postgresql.org/message-id/20200414065336.GI1492@paquier.xyz Incremental sorts and EXEC_FLAG_REWIND]<br />
** Fixed at: {{PgCommitURL|c4427226483c78618ba45eff34917400a77718a5}}<br />
<br />
* consistency of explain output: two spaces, equals vs colons, semicolons (incremental sort)<br />
** [https://www.postgresql.org/message-id/20200407042521.GH2228%40telsasoft.com incremental sort]<br />
** Fixed at: {{PgCommitURL|6a918c3ac8a6b1d8b53cead6fcb7cbd84eee5750}}<br />
<br />
* [https://postgr.es/m/981DE552-E399-45C2-9F60-3F0E3770CC61@yesql.se Naming issue with client-side sslpassword hook]<br />
** Fixed at: {{PgCommitURL|36d1087611bf96b0cd716666fc8c4a2d168fa501}}<br />
<br />
* [https://postgr.es/m/21247.1589296570@sss.pgh.pa.us Naming issues for wait events, and particularly SLRU caches]<br />
** Fixed at: {{PgCommitURL|3048898e73c75f54bb259323382e0e7f6368cb6f}} and predecessor patches<br />
<br />
* [https://postgr.es/m/20200515090817.GA212736@paquier.xyz pg_stat_wal_receiver and flushedUpto/writtenUpto]<br />
** Fixed at: {{PgCommitURL|2c8dd05d6cbc86b7ad21cfd7010e041bb4c3950b}}<br />
<br />
== Won't Fix ==<br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
<br />
* Feature Freeze: April 7, 2020 ('''Last Day to Commit Features''')<br />
* Beta 1: May 21, 2020<br />
* Beta 2: June 25, 2020<br />
<br />
[[Category:Open_Items]]</div>Mhahttps://wiki.postgresql.org/index.php?title=User:Mha&diff=35095User:Mha2020-07-02T20:22:05Z<p>Mha: </p>
<hr />
<div>asdf</div>Mhahttps://wiki.postgresql.org/index.php?title=User:Mha&diff=35089User:Mha2020-07-02T19:30:51Z<p>Mha: </p>
<hr />
<div>test111</div>Mhahttps://wiki.postgresql.org/index.php?title=Committers&diff=33529Committers2019-05-29T14:52:17Z<p>Mha: </p>
<hr />
<div>This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit or when added as a committer, oldest first; this isn't intended to imply anything about depth of contribution.<br />
<br />
* Bruce Momjian (momjian)<br />
* Tom Lane (tgl)<br />
* Michael Meskes (meskes)<br />
* Tatsuo Ishii (ishii)<br />
* Peter Eisentraut (petere)<br />
* Teodor Sigaev (teodor)<br />
* Joe Conway (joe)<br />
* Alvaro Herrera (alvherre)<br />
* Andrew Dunstan (adunstan)<br />
* Magnus Hagander (mha)<br />
* Heikki Linnakangas (heikki)<br />
* Robert Haas (rhaas)<br />
* Greg Stark (stark)<br />
* Kevin Grittner (kgrittn)<br />
* Jeff Davis (jdavis)<br />
* Stephen Frost (sfrost)<br />
* Fujii Masao (fujii)<br />
* Noah Misch (noah)<br />
* Andres Freund (andres)<br />
* Dean Rasheed (deanr)<br />
* Andrew Gierth (rhodiumtoad)<br />
* Alexander Korotkov (smagen)<br />
* Amit Kapila (amitkapila)<br />
* Tomas Vondra (fuzzycz)<br />
* Michael Paquier (michael-kun)<br />
* Thomas Munro (macdice)<br />
* Peter Geoghegan (pgeoghegan)<br />
* Etsuro Fujita (efujita)<br />
* David Rowley (drowley)<br />
<br />
== Notes on the Commit Log ==<br />
<br />
Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole. <br />
<br />
== New Committers and Removing Committers ==<br />
<br />
New committers are added approximately annually by the Core Team. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:<br />
<br />
* several years of substantial contributions to the project<br />
* multiple and continuing code contributions<br />
* responsibility for maintenance of one or more areas of the codebase<br />
* track record of reviewing and helping other contributors with their patches<br />
* high quality code contributions which require very little revision or correction for commit<br />
* demonstrated understanding of the process and criteria for patch acceptance<br />
<br />
Generally, new committers are selected March or April and announced at pgCon.<br />
<br />
Committers who have become inactive and have not contributed significantly to the PostgreSQL project in several years are removed as committers. Again, the review process for this is approximately annual.<br />
<br />
[[Category:Community]]</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_12_Open_Items&diff=33313PostgreSQL 12 Open Items2019-04-12T12:18:02Z<p>Mha: /* resolved before 12beta1 */</p>
<hr />
<div>== Open Issues ==<br />
Peter, this is an open item, and I think as the committer of the<br />
'''NOTE''': Please add new open items to the bottom of the list.<br />
<br />
<br />
* [https://www.postgresql.org/message-id/20190225074539.az6j3u464cvsoxh6@depesz.com Segfault when restoring -Fd dump on current HEAD]<br />
** This was fixed in 19455c9f5, but then 3b925e905 made the compatibility argument moot, so should we undo 19455c9f5?<br />
** Patch for that is at [https://www.postgresql.org/message-id/CA+q6zcXx0XHqLsFJLaUU2j5BDiBAHig=YRoBC_YVq7VJGvzBEA@mail.gmail.com]<br />
* [https://www.postgresql.org/message-id/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com pg_dump is broken for partition tablespaces]<br />
** Commit: {{PgCommitURL|ca4103025dfe26eaaf6a500dec9170fbb176eebc}}, Author: David Rowley, Owner: Alvaro Herrera<br />
* [https://www.postgresql.org/message-id/21516.1552489217@sss.pgh.pa.us Debate INFO messages in ATTACH PARTITION and SET NOT NULL]<br />
* [https://www.postgresql.org/message-id/CAMkU=1x8taZfsbPkv_MsWbTtzibW_yQHXoMhF_DTtm=z2hVHDg@mail.gmail.com compiler warning in pgcrypto imath.c]<br />
** Commit: {{PgCommitURL|48e24ba6b7fd3bfd156b51e8d768fd48df0d288b}}, Author: Noah Misch, Owner: Noah Misch<br />
* [https://www.postgresql.org/message-id/CA%2BTgmoZP-CTmEPZdmqEOb%2B6t_Tts2nuF7eoqxxvXEHaUoBDmsw%40mail.gmail.com Should effective_io_concurrency + 10 be used for an index's page deletion table scans, or a new GUC]<br />
* [https://www.postgresql.org/message-id/CAOuzzgqS-CL18_zKF7pF-wymG8mUeUZveNYYSrXKQRn1VaJsug@mail.gmail.com GSSAPI encryption missing protocol documentation]<br />
** Commit: {{PgCommitURL|b0b39f72b9904bcb80f97b35837ccff1578aa4b8}}, Author: Robbie Harwood, Owner: Stephen Frost<br />
* [https://www.postgresql.org/message-id/CA+hUKGJRzLo7tZExWfSbwM3XuK7aAK7FhdBV0FLkbUG+W0v0zg@mail.gmail.com Wrong answers from queries using a GIST index]<br />
** Commit: {{PgCommitURL|9155580fd5fc2a0cbb23376dfca7cd21f59c2c7b}}, Author: Anastasia Lubennikova, Andrey V. Lepikhov, Owner: Heikki Linnakangas<br />
* [https://www.postgresql.org/message-id/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com Add vacuum_index_cleanup for toast relations?]<br />
** Commit: {{PgCommitURL|a96c41feec6b6616eb9d5baee9a9e08c20533c38}}, Author: Masahiko Sawada, Owner: Robert Haas<br />
* [https://www.postgresql.org/message-id/CAHGQGwHa_dX%3DdRcbR5QVTs6W5mgCy3qZ2fEwREaiXpES1B2%2Bjw%40mail.gmail.com Add TRUNCATE option to vacuum command as well as reloption]<br />
** Commit: {{PgCommitURL|119dcfad988d5b5d9f52b256087869997670aa36}}, Author: Tsunakawa Takayuki, Owner: Fujii Masao<br />
* [https://www.postgresql.org/message-id/a620f85a-42ab-e0f3-3337-b04b97e2e2f5%40redhat.com COLLATE: Hash partition vs UPDATE]<br />
** [https://www.postgresql.org/message-id/b462ff0c-a846-dce6-b0a7-ab1397e73b98%40lab.ntt.co.jp Patch proposed]<br />
* [https://www.postgresql.org/message-id/20190408002847.GA904@telsasoft.com Cleanup/remove/update references to OID column]<br />
** Commit: {{PgCommitURL|578b229718e8f15fa779e20f086c4b6bb3776106}}, Author: Andres Freund, Owner: Andres Freund<br />
* [https://www.postgresql.org/message-id/20190411134947.GA22043@alvherre.pgsql Consider invalid indexes for REINDEX INDEX CONCURRENTLY?]<br />
** Commit: {{PgCommitURL|5dc92b844e680c54a7ecd68de0ba53c949c3d605}}, Author: Michael Paquier, Owner: Peter Eisentraut<br />
<br />
== Decisions to Recheck Mid-Beta ==<br />
<br />
== Older Bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp selecting from partition directly can't use constraint exclusion]<br />
** [https://commitfest.postgresql.org/23/2072 CF entry]<br />
* [https://www.postgresql.org/message-id/15672-b9fa7db32698269f%40postgresql.org ATPostAlterTypeCleanup causes child indexes to be recreated with wrong relfilnode]<br />
* [https://www.postgresql.org/message-id/15726-6d67e4fa14f027b3@postgresql.org parallel queries failed ERROR: invalid name syntax CONTEXT: parallel worker]<br />
* [https://www.postgresql.org/message-id/15734-2daa8761eeed8e20@postgresql.org Walsender process crashing when executing SHOW ALL]<br />
* [https://www.postgresql.org/message-id/7961.1552498252%40sss.pgh.pa.us RelationData.rd_partcheck should get its own memory context]<br />
** [https://www.postgresql.org/message-id/036852f2-ba7f-7a1f-21c6-00bc3515eda3%40lab.ntt.co.jp Patch posted]<br />
* [https://www.postgresql.org/message-id/15746-6e0482a4c0f915cb@postgresql.org BUG #15746: cache lookup failed for function in plpgsql block]<br />
<br />
=== Live issues ===<br />
<br />
=== Fixed issues ===<br />
<br />
* [https://www.postgresql.org/message-id/20181009.181536.142257785.horiguchi.kyotaro@lab.ntt.co.jp Bypass processing of wraparound autovacuums not marked as aggressive]<br />
** Problem exists since the point where aggressive vacuums have been introduced, v12 has only added extra logs to look after the impossible case of wraparound autovacuums not aggressive.<br />
** Fixed in: {{PgCommitURL|2aa6e331ead7f3ad080561495ad4bd3bc7cd8913}}<br />
* [https://www.postgresql.org/message-id/15733-7692379e310b80ec%40postgresql.org An insert destined at partition created after a column has been dropped from the parent table fails]<br />
** Fixed in: {{PgCommitURL|6b0208ebc436b33bd80ce264299b4b1b8d59b68a}}<br />
<br />
== Non-bugs ==<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 12beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/15727-0be246e7d852d229@postgresql.org PANIC: cannot abort transaction XXX, it was already committed]<br />
** One issue fixed in: {{PgCommitURL|41f5e04aec6cf63ba8392adf70e9289e9c3706d6}}<br />
** Another issue fixed in: {{PgCommitURL|f7feb020c3d8d5aff24204af28359b99ee65bf8f}}<br />
* [https://www.postgresql.org/message-id/201902021315.6h6ktmmsgjmx@alvherre.pgsql remove \cset from pgbench]<br />
** Fixed in: {{PgCommitURL|25ee70511ec2ccbef0ad3fe64875a4d552cdcd50}}<br />
* [https://www.postgresql.org/message-id/20190322032612.GA323@alvherre.pgsql pg_partition_root crashes when using top-most parent in input]<br />
** Fixed in: {{PgCommitURL|2ab6d28d233af17987ea323e3235b2bda89b4f2e}}<br />
* [https://www.postgresql.org/message-id/CA+HiwqEGoa485g18mt9GUdF8fH4mKDgpeoc32XiW-dRUFpN5Lw@mail.gmail.com Server crash in transformPartitionRangeBounds]<br />
** Fixed in: {{PgCommitURL|cdde886d36b5a4d7ad9e1d02596f7fa1c8c129e3}}<br />
* [https://www.postgresql.org/message-id/20190326020853.GM2558@paquier.xyz Misleading errors with column references in default expressions and partition bounds]<br />
** Fixed in: {{PgCommitURL|ecfed4a12247cf4659eee6b6ea27405e35fe57f8}}<br />
* [https://www.postgresql.org/message-id/8305.1553884377@sss.pgh.pa.us Planner's partitionwise-join code crashes under GEQO]<br />
** Fixed in: {{PgCommitURL|7ad6498fd5a654de6e743814c36cf619a3b5ddb6}}<br />
* [https://www.postgresql.org/message-id/flat/19465.1541636036@sss.pgh.pa.us Inadequate index locking causes Assert failure]<br />
** Fixed in: {{PgCommitURL|9c703c169a872d144f2f79d2fb211c82587adfa7}}<br />
* [https://www.postgresql.org/message-id/87wolmg60q.fsf@news-spur.riddles.org.uk Inlining of nested CTEs with recursive terms]<br />
** Fixed in: {{PgCommitURL|9476131278c7bfc435ad9a21fc8e981272ac0dd2}}<br />
* [https://www.postgresql.org/message-id/DF4PR8401MB11964EDB77C860078C343BEBEE5A0@DF4PR8401MB1196.NAMPRD84.PROD.OUTLOOK.COM Indexes part of a partition tree cannot be run with REINDEX CONCURRENTLY]<br />
** Fixed in: {{PgCommitURL|ef6f30fe77af69a8c775cca82bf993b10c9889ee}}<br />
* [https://www.postgresql.org/message-id/flat/CABUevEzD_duH_hGyZw14o%2BkhHBw-rWSSAxbEKt5HWy2cK0Djdw%40mail.gmail.com#d8a9d175134a072dd1477c3fac96f76a Keep track of checksum failures in shared object, last failure time and pg_stat_checkums view]<br />
** Commit: {{PgCommitURL|6b9e875f7286d8535bff7955e5aa3602e188e436}}, Author: Magnus Hagander, Owner: Magnus Hagander<br />
** Fixed in: {{PgCommitURL|77bd49adba4711b4497e7e39a5ec3a9812cbd52a}}<br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
* feature freeze: April 7, 2019<br />
* beta1: XXX<br />
* beta2: XXX<br />
* rc1: XXX<br />
* ga: XXX<br />
<br />
[[Category:Open_Items]]</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_12_Open_Items&diff=33312PostgreSQL 12 Open Items2019-04-12T12:17:42Z<p>Mha: </p>
<hr />
<div>== Open Issues ==<br />
Peter, this is an open item, and I think as the committer of the<br />
'''NOTE''': Please add new open items to the bottom of the list.<br />
<br />
<br />
* [https://www.postgresql.org/message-id/20190225074539.az6j3u464cvsoxh6@depesz.com Segfault when restoring -Fd dump on current HEAD]<br />
** This was fixed in 19455c9f5, but then 3b925e905 made the compatibility argument moot, so should we undo 19455c9f5?<br />
** Patch for that is at [https://www.postgresql.org/message-id/CA+q6zcXx0XHqLsFJLaUU2j5BDiBAHig=YRoBC_YVq7VJGvzBEA@mail.gmail.com]<br />
* [https://www.postgresql.org/message-id/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com pg_dump is broken for partition tablespaces]<br />
** Commit: {{PgCommitURL|ca4103025dfe26eaaf6a500dec9170fbb176eebc}}, Author: David Rowley, Owner: Alvaro Herrera<br />
* [https://www.postgresql.org/message-id/21516.1552489217@sss.pgh.pa.us Debate INFO messages in ATTACH PARTITION and SET NOT NULL]<br />
* [https://www.postgresql.org/message-id/CAMkU=1x8taZfsbPkv_MsWbTtzibW_yQHXoMhF_DTtm=z2hVHDg@mail.gmail.com compiler warning in pgcrypto imath.c]<br />
** Commit: {{PgCommitURL|48e24ba6b7fd3bfd156b51e8d768fd48df0d288b}}, Author: Noah Misch, Owner: Noah Misch<br />
* [https://www.postgresql.org/message-id/CA%2BTgmoZP-CTmEPZdmqEOb%2B6t_Tts2nuF7eoqxxvXEHaUoBDmsw%40mail.gmail.com Should effective_io_concurrency + 10 be used for an index's page deletion table scans, or a new GUC]<br />
* [https://www.postgresql.org/message-id/CAOuzzgqS-CL18_zKF7pF-wymG8mUeUZveNYYSrXKQRn1VaJsug@mail.gmail.com GSSAPI encryption missing protocol documentation]<br />
** Commit: {{PgCommitURL|b0b39f72b9904bcb80f97b35837ccff1578aa4b8}}, Author: Robbie Harwood, Owner: Stephen Frost<br />
* [https://www.postgresql.org/message-id/CA+hUKGJRzLo7tZExWfSbwM3XuK7aAK7FhdBV0FLkbUG+W0v0zg@mail.gmail.com Wrong answers from queries using a GIST index]<br />
** Commit: {{PgCommitURL|9155580fd5fc2a0cbb23376dfca7cd21f59c2c7b}}, Author: Anastasia Lubennikova, Andrey V. Lepikhov, Owner: Heikki Linnakangas<br />
* [https://www.postgresql.org/message-id/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com Add vacuum_index_cleanup for toast relations?]<br />
** Commit: {{PgCommitURL|a96c41feec6b6616eb9d5baee9a9e08c20533c38}}, Author: Masahiko Sawada, Owner: Robert Haas<br />
* [https://www.postgresql.org/message-id/CAHGQGwHa_dX%3DdRcbR5QVTs6W5mgCy3qZ2fEwREaiXpES1B2%2Bjw%40mail.gmail.com Add TRUNCATE option to vacuum command as well as reloption]<br />
** Commit: {{PgCommitURL|119dcfad988d5b5d9f52b256087869997670aa36}}, Author: Tsunakawa Takayuki, Owner: Fujii Masao<br />
* [https://www.postgresql.org/message-id/a620f85a-42ab-e0f3-3337-b04b97e2e2f5%40redhat.com COLLATE: Hash partition vs UPDATE]<br />
** [https://www.postgresql.org/message-id/b462ff0c-a846-dce6-b0a7-ab1397e73b98%40lab.ntt.co.jp Patch proposed]<br />
* [https://www.postgresql.org/message-id/20190408002847.GA904@telsasoft.com Cleanup/remove/update references to OID column]<br />
** Commit: {{PgCommitURL|578b229718e8f15fa779e20f086c4b6bb3776106}}, Author: Andres Freund, Owner: Andres Freund<br />
* [https://www.postgresql.org/message-id/20190411134947.GA22043@alvherre.pgsql Consider invalid indexes for REINDEX INDEX CONCURRENTLY?]<br />
** Commit: {{PgCommitURL|5dc92b844e680c54a7ecd68de0ba53c949c3d605}}, Author: Michael Paquier, Owner: Peter Eisentraut<br />
<br />
== Decisions to Recheck Mid-Beta ==<br />
<br />
== Older Bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp selecting from partition directly can't use constraint exclusion]<br />
** [https://commitfest.postgresql.org/23/2072 CF entry]<br />
* [https://www.postgresql.org/message-id/15672-b9fa7db32698269f%40postgresql.org ATPostAlterTypeCleanup causes child indexes to be recreated with wrong relfilnode]<br />
* [https://www.postgresql.org/message-id/15726-6d67e4fa14f027b3@postgresql.org parallel queries failed ERROR: invalid name syntax CONTEXT: parallel worker]<br />
* [https://www.postgresql.org/message-id/15734-2daa8761eeed8e20@postgresql.org Walsender process crashing when executing SHOW ALL]<br />
* [https://www.postgresql.org/message-id/7961.1552498252%40sss.pgh.pa.us RelationData.rd_partcheck should get its own memory context]<br />
** [https://www.postgresql.org/message-id/036852f2-ba7f-7a1f-21c6-00bc3515eda3%40lab.ntt.co.jp Patch posted]<br />
* [https://www.postgresql.org/message-id/15746-6e0482a4c0f915cb@postgresql.org BUG #15746: cache lookup failed for function in plpgsql block]<br />
<br />
=== Live issues ===<br />
<br />
=== Fixed issues ===<br />
<br />
* [https://www.postgresql.org/message-id/20181009.181536.142257785.horiguchi.kyotaro@lab.ntt.co.jp Bypass processing of wraparound autovacuums not marked as aggressive]<br />
** Problem exists since the point where aggressive vacuums have been introduced, v12 has only added extra logs to look after the impossible case of wraparound autovacuums not aggressive.<br />
** Fixed in: {{PgCommitURL|2aa6e331ead7f3ad080561495ad4bd3bc7cd8913}}<br />
* [https://www.postgresql.org/message-id/15733-7692379e310b80ec%40postgresql.org An insert destined at partition created after a column has been dropped from the parent table fails]<br />
** Fixed in: {{PgCommitURL|6b0208ebc436b33bd80ce264299b4b1b8d59b68a}}<br />
<br />
== Non-bugs ==<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 12beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/15727-0be246e7d852d229@postgresql.org PANIC: cannot abort transaction XXX, it was already committed]<br />
** One issue fixed in: {{PgCommitURL|41f5e04aec6cf63ba8392adf70e9289e9c3706d6}}<br />
** Another issue fixed in: {{PgCommitURL|f7feb020c3d8d5aff24204af28359b99ee65bf8f}}<br />
* [https://www.postgresql.org/message-id/201902021315.6h6ktmmsgjmx@alvherre.pgsql remove \cset from pgbench]<br />
** Fixed in: {{PgCommitURL|25ee70511ec2ccbef0ad3fe64875a4d552cdcd50}}<br />
* [https://www.postgresql.org/message-id/20190322032612.GA323@alvherre.pgsql pg_partition_root crashes when using top-most parent in input]<br />
** Fixed in: {{PgCommitURL|2ab6d28d233af17987ea323e3235b2bda89b4f2e}}<br />
* [https://www.postgresql.org/message-id/CA+HiwqEGoa485g18mt9GUdF8fH4mKDgpeoc32XiW-dRUFpN5Lw@mail.gmail.com Server crash in transformPartitionRangeBounds]<br />
** Fixed in: {{PgCommitURL|cdde886d36b5a4d7ad9e1d02596f7fa1c8c129e3}}<br />
* [https://www.postgresql.org/message-id/20190326020853.GM2558@paquier.xyz Misleading errors with column references in default expressions and partition bounds]<br />
** Fixed in: {{PgCommitURL|ecfed4a12247cf4659eee6b6ea27405e35fe57f8}}<br />
* [https://www.postgresql.org/message-id/8305.1553884377@sss.pgh.pa.us Planner's partitionwise-join code crashes under GEQO]<br />
** Fixed in: {{PgCommitURL|7ad6498fd5a654de6e743814c36cf619a3b5ddb6}}<br />
* [https://www.postgresql.org/message-id/flat/19465.1541636036@sss.pgh.pa.us Inadequate index locking causes Assert failure]<br />
** Fixed in: {{PgCommitURL|9c703c169a872d144f2f79d2fb211c82587adfa7}}<br />
* [https://www.postgresql.org/message-id/87wolmg60q.fsf@news-spur.riddles.org.uk Inlining of nested CTEs with recursive terms]<br />
** Fixed in: {{PgCommitURL|9476131278c7bfc435ad9a21fc8e981272ac0dd2}}<br />
* [https://www.postgresql.org/message-id/DF4PR8401MB11964EDB77C860078C343BEBEE5A0@DF4PR8401MB1196.NAMPRD84.PROD.OUTLOOK.COM Indexes part of a partition tree cannot be run with REINDEX CONCURRENTLY]<br />
** Fixed in: {{PgCommitURL|ef6f30fe77af69a8c775cca82bf993b10c9889ee}}<br />
* [https://www.postgresql.org/message-id/flat/CABUevEzD_duH_hGyZw14o%2BkhHBw-rWSSAxbEKt5HWy2cK0Djdw%40mail.gmail.com#d8a9d175134a072dd1477c3fac96f76a Keep track of checksum failures in shared object, last failure time and pg_stat_checkums view]<br />
** Commit: {{PgCommitURL|6b9e875f7286d8535bff7955e5aa3602e188e436}}, Author: Magnus Hagander, Owner: Magnus Hagander<br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
* feature freeze: April 7, 2019<br />
* beta1: XXX<br />
* beta2: XXX<br />
* rc1: XXX<br />
* ga: XXX<br />
<br />
[[Category:Open_Items]]</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_12_Open_Items&diff=33311PostgreSQL 12 Open Items2019-04-12T12:17:08Z<p>Mha: Reverted edits by Mha (talk) to last revision by Michael-kun</p>
<hr />
<div>== Open Issues ==<br />
Peter, this is an open item, and I think as the committer of the<br />
'''NOTE''': Please add new open items to the bottom of the list.<br />
<br />
<br />
* [https://www.postgresql.org/message-id/20190225074539.az6j3u464cvsoxh6@depesz.com Segfault when restoring -Fd dump on current HEAD]<br />
** This was fixed in 19455c9f5, but then 3b925e905 made the compatibility argument moot, so should we undo 19455c9f5?<br />
** Patch for that is at [https://www.postgresql.org/message-id/CA+q6zcXx0XHqLsFJLaUU2j5BDiBAHig=YRoBC_YVq7VJGvzBEA@mail.gmail.com]<br />
* [https://www.postgresql.org/message-id/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com pg_dump is broken for partition tablespaces]<br />
** Commit: {{PgCommitURL|ca4103025dfe26eaaf6a500dec9170fbb176eebc}}, Author: David Rowley, Owner: Alvaro Herrera<br />
* [https://www.postgresql.org/message-id/21516.1552489217@sss.pgh.pa.us Debate INFO messages in ATTACH PARTITION and SET NOT NULL]<br />
* [https://www.postgresql.org/message-id/CAMkU=1x8taZfsbPkv_MsWbTtzibW_yQHXoMhF_DTtm=z2hVHDg@mail.gmail.com compiler warning in pgcrypto imath.c]<br />
** Commit: {{PgCommitURL|48e24ba6b7fd3bfd156b51e8d768fd48df0d288b}}, Author: Noah Misch, Owner: Noah Misch<br />
* [https://www.postgresql.org/message-id/flat/CABUevEzD_duH_hGyZw14o%2BkhHBw-rWSSAxbEKt5HWy2cK0Djdw%40mail.gmail.com#d8a9d175134a072dd1477c3fac96f76a Keep track of checksum failures in shared object, last failure time and pg_stat_checkums view]<br />
** Commit: {{PgCommitURL|6b9e875f7286d8535bff7955e5aa3602e188e436}}, Author: Magnus Hagander, Owner: Magnus Hagander<br />
* [https://www.postgresql.org/message-id/CA%2BTgmoZP-CTmEPZdmqEOb%2B6t_Tts2nuF7eoqxxvXEHaUoBDmsw%40mail.gmail.com Should effective_io_concurrency + 10 be used for an index's page deletion table scans, or a new GUC]<br />
* [https://www.postgresql.org/message-id/CAOuzzgqS-CL18_zKF7pF-wymG8mUeUZveNYYSrXKQRn1VaJsug@mail.gmail.com GSSAPI encryption missing protocol documentation]<br />
** Commit: {{PgCommitURL|b0b39f72b9904bcb80f97b35837ccff1578aa4b8}}, Author: Robbie Harwood, Owner: Stephen Frost<br />
* [https://www.postgresql.org/message-id/CA+hUKGJRzLo7tZExWfSbwM3XuK7aAK7FhdBV0FLkbUG+W0v0zg@mail.gmail.com Wrong answers from queries using a GIST index]<br />
** Commit: {{PgCommitURL|9155580fd5fc2a0cbb23376dfca7cd21f59c2c7b}}, Author: Anastasia Lubennikova, Andrey V. Lepikhov, Owner: Heikki Linnakangas<br />
* [https://www.postgresql.org/message-id/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com Add vacuum_index_cleanup for toast relations?]<br />
** Commit: {{PgCommitURL|a96c41feec6b6616eb9d5baee9a9e08c20533c38}}, Author: Masahiko Sawada, Owner: Robert Haas<br />
* [https://www.postgresql.org/message-id/CAHGQGwHa_dX%3DdRcbR5QVTs6W5mgCy3qZ2fEwREaiXpES1B2%2Bjw%40mail.gmail.com Add TRUNCATE option to vacuum command as well as reloption]<br />
** Commit: {{PgCommitURL|119dcfad988d5b5d9f52b256087869997670aa36}}, Author: Tsunakawa Takayuki, Owner: Fujii Masao<br />
* [https://www.postgresql.org/message-id/a620f85a-42ab-e0f3-3337-b04b97e2e2f5%40redhat.com COLLATE: Hash partition vs UPDATE]<br />
** [https://www.postgresql.org/message-id/b462ff0c-a846-dce6-b0a7-ab1397e73b98%40lab.ntt.co.jp Patch proposed]<br />
* [https://www.postgresql.org/message-id/20190408002847.GA904@telsasoft.com Cleanup/remove/update references to OID column]<br />
** Commit: {{PgCommitURL|578b229718e8f15fa779e20f086c4b6bb3776106}}, Author: Andres Freund, Owner: Andres Freund<br />
* [https://www.postgresql.org/message-id/20190411134947.GA22043@alvherre.pgsql Consider invalid indexes for REINDEX INDEX CONCURRENTLY?]<br />
** Commit: {{PgCommitURL|5dc92b844e680c54a7ecd68de0ba53c949c3d605}}, Author: Michael Paquier, Owner: Peter Eisentraut<br />
<br />
== Decisions to Recheck Mid-Beta ==<br />
<br />
== Older Bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp selecting from partition directly can't use constraint exclusion]<br />
** [https://commitfest.postgresql.org/23/2072 CF entry]<br />
* [https://www.postgresql.org/message-id/15672-b9fa7db32698269f%40postgresql.org ATPostAlterTypeCleanup causes child indexes to be recreated with wrong relfilnode]<br />
* [https://www.postgresql.org/message-id/15726-6d67e4fa14f027b3@postgresql.org parallel queries failed ERROR: invalid name syntax CONTEXT: parallel worker]<br />
* [https://www.postgresql.org/message-id/15734-2daa8761eeed8e20@postgresql.org Walsender process crashing when executing SHOW ALL]<br />
* [https://www.postgresql.org/message-id/7961.1552498252%40sss.pgh.pa.us RelationData.rd_partcheck should get its own memory context]<br />
** [https://www.postgresql.org/message-id/036852f2-ba7f-7a1f-21c6-00bc3515eda3%40lab.ntt.co.jp Patch posted]<br />
* [https://www.postgresql.org/message-id/15746-6e0482a4c0f915cb@postgresql.org BUG #15746: cache lookup failed for function in plpgsql block]<br />
<br />
=== Live issues ===<br />
<br />
=== Fixed issues ===<br />
<br />
* [https://www.postgresql.org/message-id/20181009.181536.142257785.horiguchi.kyotaro@lab.ntt.co.jp Bypass processing of wraparound autovacuums not marked as aggressive]<br />
** Problem exists since the point where aggressive vacuums have been introduced, v12 has only added extra logs to look after the impossible case of wraparound autovacuums not aggressive.<br />
** Fixed in: {{PgCommitURL|2aa6e331ead7f3ad080561495ad4bd3bc7cd8913}}<br />
* [https://www.postgresql.org/message-id/15733-7692379e310b80ec%40postgresql.org An insert destined at partition created after a column has been dropped from the parent table fails]<br />
** Fixed in: {{PgCommitURL|6b0208ebc436b33bd80ce264299b4b1b8d59b68a}}<br />
<br />
== Non-bugs ==<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 12beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/15727-0be246e7d852d229@postgresql.org PANIC: cannot abort transaction XXX, it was already committed]<br />
** One issue fixed in: {{PgCommitURL|41f5e04aec6cf63ba8392adf70e9289e9c3706d6}}<br />
** Another issue fixed in: {{PgCommitURL|f7feb020c3d8d5aff24204af28359b99ee65bf8f}}<br />
* [https://www.postgresql.org/message-id/201902021315.6h6ktmmsgjmx@alvherre.pgsql remove \cset from pgbench]<br />
** Fixed in: {{PgCommitURL|25ee70511ec2ccbef0ad3fe64875a4d552cdcd50}}<br />
* [https://www.postgresql.org/message-id/20190322032612.GA323@alvherre.pgsql pg_partition_root crashes when using top-most parent in input]<br />
** Fixed in: {{PgCommitURL|2ab6d28d233af17987ea323e3235b2bda89b4f2e}}<br />
* [https://www.postgresql.org/message-id/CA+HiwqEGoa485g18mt9GUdF8fH4mKDgpeoc32XiW-dRUFpN5Lw@mail.gmail.com Server crash in transformPartitionRangeBounds]<br />
** Fixed in: {{PgCommitURL|cdde886d36b5a4d7ad9e1d02596f7fa1c8c129e3}}<br />
* [https://www.postgresql.org/message-id/20190326020853.GM2558@paquier.xyz Misleading errors with column references in default expressions and partition bounds]<br />
** Fixed in: {{PgCommitURL|ecfed4a12247cf4659eee6b6ea27405e35fe57f8}}<br />
* [https://www.postgresql.org/message-id/8305.1553884377@sss.pgh.pa.us Planner's partitionwise-join code crashes under GEQO]<br />
** Fixed in: {{PgCommitURL|7ad6498fd5a654de6e743814c36cf619a3b5ddb6}}<br />
* [https://www.postgresql.org/message-id/flat/19465.1541636036@sss.pgh.pa.us Inadequate index locking causes Assert failure]<br />
** Fixed in: {{PgCommitURL|9c703c169a872d144f2f79d2fb211c82587adfa7}}<br />
* [https://www.postgresql.org/message-id/87wolmg60q.fsf@news-spur.riddles.org.uk Inlining of nested CTEs with recursive terms]<br />
** Fixed in: {{PgCommitURL|9476131278c7bfc435ad9a21fc8e981272ac0dd2}}<br />
* [https://www.postgresql.org/message-id/DF4PR8401MB11964EDB77C860078C343BEBEE5A0@DF4PR8401MB1196.NAMPRD84.PROD.OUTLOOK.COM Indexes part of a partition tree cannot be run with REINDEX CONCURRENTLY]<br />
** Fixed in: {{PgCommitURL|ef6f30fe77af69a8c775cca82bf993b10c9889ee}}<br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
* feature freeze: April 7, 2019<br />
* beta1: XXX<br />
* beta2: XXX<br />
* rc1: XXX<br />
* ga: XXX<br />
<br />
[[Category:Open_Items]]</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_12_Open_Items&diff=33310PostgreSQL 12 Open Items2019-04-12T12:15:56Z<p>Mha: </p>
<hr />
<div>== Open Issues ==<br />
Peter, this is an open item, and I think as the committer of the<br />
'''NOTE''': Please add new open items to the bottom of the list.<br />
<br />
<br />
* [https://www.postgresql.org/message-id/20190225074539.az6j3u464cvsoxh6@depesz.com Segfault when restoring -Fd dump on current HEAD]<br />
** This was fixed in 19455c9f5, but then 3b925e905 made the compatibility argument moot, so should we undo 19455c9f5?<br />
** Patch for that is at [https://www.postgresql.org/message-id/CA+q6zcXx0XHqLsFJLaUU2j5BDiBAHig=YRoBC_YVq7VJGvzBEA@mail.gmail.com]<br />
* [https://www.postgresql.org/message-id/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com pg_dump is broken for partition tablespaces]<br />
** Commit: {{PgCommitURL|ca4103025dfe26eaaf6a500dec9170fbb176eebc}}, Author: David Rowley, Owner: Alvaro Herrera<br />
* [https://www.postgresql.org/message-id/21516.1552489217@sss.pgh.pa.us Debate INFO messages in ATTACH PARTITION and SET NOT NULL]<br />
* [https://www.postgresql.org/message-id/CAMkU=1x8taZfsbPkv_MsWbTtzibW_yQHXoMhF_DTtm=z2hVHDg@mail.gmail.com compiler warning in pgcrypto imath.c]<br />
** Commit: {{PgCommitURL|48e24ba6b7fd3bfd156b51e8d768fd48df0d288b}}, Author: Noah Misch, Owner: Noah Misch<br />
* [https://www.postgresql.org/message-id/flat/CABUevEzD_duH_hGyZw14o%2BkhHBw-rWSSAxbEKt5HWy2cK0Djdw%40mail.gmail.com#d8a9d175134a072dd1477c3fac96f76a Keep track of checksum failures in shared object, last failure time and pg_stat_checkums view]<br />
** Commit: {{PgCommitURL|b0b39f72b9904bcb80f97b35837ccff1578aa4b8}}, Author: Robbie Harwood, Owner: Stephen Frost<br />
* [https://www.postgresql.org/message-id/CA+hUKGJRzLo7tZExWfSbwM3XuK7aAK7FhdBV0FLkbUG+W0v0zg@mail.gmail.com Wrong answers from queries using a GIST index]<br />
** Commit: {{PgCommitURL|9155580fd5fc2a0cbb23376dfca7cd21f59c2c7b}}, Author: Anastasia Lubennikova, Andrey V. Lepikhov, Owner: Heikki Linnakangas<br />
* [https://www.postgresql.org/message-id/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com Add vacuum_index_cleanup for toast relations?]<br />
** Commit: {{PgCommitURL|a96c41feec6b6616eb9d5baee9a9e08c20533c38}}, Author: Masahiko Sawada, Owner: Robert Haas<br />
* [https://www.postgresql.org/message-id/CAHGQGwHa_dX%3DdRcbR5QVTs6W5mgCy3qZ2fEwREaiXpES1B2%2Bjw%40mail.gmail.com Add TRUNCATE option to vacuum command as well as reloption]<br />
** Commit: {{PgCommitURL|119dcfad988d5b5d9f52b256087869997670aa36}}, Author: Tsunakawa Takayuki, Owner: Fujii Masao<br />
* [https://www.postgresql.org/message-id/a620f85a-42ab-e0f3-3337-b04b97e2e2f5%40redhat.com COLLATE: Hash partition vs UPDATE]<br />
** [https://www.postgresql.org/message-id/b462ff0c-a846-dce6-b0a7-ab1397e73b98%40lab.ntt.co.jp Patch proposed]<br />
* [https://www.postgresql.org/message-id/20190408002847.GA904@telsasoft.com Cleanup/remove/update references to OID column]<br />
** Commit: {{PgCommitURL|578b229718e8f15fa779e20f086c4b6bb3776106}}, Author: Andres Freund, Owner: Andres Freund<br />
* [https://www.postgresql.org/message-id/20190411134947.GA22043@alvherre.pgsql Consider invalid indexes for REINDEX INDEX CONCURRENTLY?]<br />
** Commit: {{PgCommitURL|5dc92b844e680c54a7ecd68de0ba53c949c3d605}}, Author: Michael Paquier, Owner: Peter Eisentraut<br />
<br />
== Decisions to Recheck Mid-Beta ==<br />
<br />
== Older Bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp selecting from partition directly can't use constraint exclusion]<br />
** [https://commitfest.postgresql.org/23/2072 CF entry]<br />
* [https://www.postgresql.org/message-id/15672-b9fa7db32698269f%40postgresql.org ATPostAlterTypeCleanup causes child indexes to be recreated with wrong relfilnode]<br />
* [https://www.postgresql.org/message-id/15726-6d67e4fa14f027b3@postgresql.org parallel queries failed ERROR: invalid name syntax CONTEXT: parallel worker]<br />
* [https://www.postgresql.org/message-id/15734-2daa8761eeed8e20@postgresql.org Walsender process crashing when executing SHOW ALL]<br />
* [https://www.postgresql.org/message-id/7961.1552498252%40sss.pgh.pa.us RelationData.rd_partcheck should get its own memory context]<br />
** [https://www.postgresql.org/message-id/036852f2-ba7f-7a1f-21c6-00bc3515eda3%40lab.ntt.co.jp Patch posted]<br />
* [https://www.postgresql.org/message-id/15746-6e0482a4c0f915cb@postgresql.org BUG #15746: cache lookup failed for function in plpgsql block]<br />
<br />
=== Live issues ===<br />
<br />
=== Fixed issues ===<br />
<br />
* [https://www.postgresql.org/message-id/20181009.181536.142257785.horiguchi.kyotaro@lab.ntt.co.jp Bypass processing of wraparound autovacuums not marked as aggressive]<br />
** Problem exists since the point where aggressive vacuums have been introduced, v12 has only added extra logs to look after the impossible case of wraparound autovacuums not aggressive.<br />
** Fixed in: {{PgCommitURL|2aa6e331ead7f3ad080561495ad4bd3bc7cd8913}}<br />
* [https://www.postgresql.org/message-id/15733-7692379e310b80ec%40postgresql.org An insert destined at partition created after a column has been dropped from the parent table fails]<br />
** Fixed in: {{PgCommitURL|6b0208ebc436b33bd80ce264299b4b1b8d59b68a}}<br />
<br />
== Non-bugs ==<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 12beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/15727-0be246e7d852d229@postgresql.org PANIC: cannot abort transaction XXX, it was already committed]<br />
** One issue fixed in: {{PgCommitURL|41f5e04aec6cf63ba8392adf70e9289e9c3706d6}}<br />
** Another issue fixed in: {{PgCommitURL|f7feb020c3d8d5aff24204af28359b99ee65bf8f}}<br />
* [https://www.postgresql.org/message-id/201902021315.6h6ktmmsgjmx@alvherre.pgsql remove \cset from pgbench]<br />
** Fixed in: {{PgCommitURL|25ee70511ec2ccbef0ad3fe64875a4d552cdcd50}}<br />
* [https://www.postgresql.org/message-id/20190322032612.GA323@alvherre.pgsql pg_partition_root crashes when using top-most parent in input]<br />
** Fixed in: {{PgCommitURL|2ab6d28d233af17987ea323e3235b2bda89b4f2e}}<br />
* [https://www.postgresql.org/message-id/CA+HiwqEGoa485g18mt9GUdF8fH4mKDgpeoc32XiW-dRUFpN5Lw@mail.gmail.com Server crash in transformPartitionRangeBounds]<br />
** Fixed in: {{PgCommitURL|cdde886d36b5a4d7ad9e1d02596f7fa1c8c129e3}}<br />
* [https://www.postgresql.org/message-id/20190326020853.GM2558@paquier.xyz Misleading errors with column references in default expressions and partition bounds]<br />
** Fixed in: {{PgCommitURL|ecfed4a12247cf4659eee6b6ea27405e35fe57f8}}<br />
* [https://www.postgresql.org/message-id/8305.1553884377@sss.pgh.pa.us Planner's partitionwise-join code crashes under GEQO]<br />
** Fixed in: {{PgCommitURL|7ad6498fd5a654de6e743814c36cf619a3b5ddb6}}<br />
* [https://www.postgresql.org/message-id/flat/19465.1541636036@sss.pgh.pa.us Inadequate index locking causes Assert failure]<br />
** Fixed in: {{PgCommitURL|9c703c169a872d144f2f79d2fb211c82587adfa7}}<br />
* [https://www.postgresql.org/message-id/87wolmg60q.fsf@news-spur.riddles.org.uk Inlining of nested CTEs with recursive terms]<br />
** Fixed in: {{PgCommitURL|9476131278c7bfc435ad9a21fc8e981272ac0dd2}}<br />
* [https://www.postgresql.org/message-id/DF4PR8401MB11964EDB77C860078C343BEBEE5A0@DF4PR8401MB1196.NAMPRD84.PROD.OUTLOOK.COM Indexes part of a partition tree cannot be run with REINDEX CONCURRENTLY]<br />
** Fixed in: {{PgCommitURL|ef6f30fe77af69a8c775cca82bf993b10c9889ee}}<br />
** Commit: {{PgCommitURL|6b9e875f7286d8535bff7955e5aa3602e188e436}}, Author: Magnus Hagander, Owner: Magnus Hagander<br />
* [https://www.postgresql.org/message-id/CA%2BTgmoZP-CTmEPZdmqEOb%2B6t_Tts2nuF7eoqxxvXEHaUoBDmsw%40mail.gmail.com Should effective_io_concurrency + 10 be used for an index's page deletion table scans, or a new GUC]<br />
* [https://www.postgresql.org/message-id/CAOuzzgqS-CL18_zKF7pF-wymG8mUeUZveNYYSrXKQRn1VaJsug@mail.gmail.com GSSAPI encryption missing protocol documentation]<br />
** Fixed in: {{PgCommitURL|77bd49adba4711b4497e7e39a5ec3a9812cbd52a}}<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
* feature freeze: April 7, 2019<br />
* beta1: XXX<br />
* beta2: XXX<br />
* rc1: XXX<br />
* ga: XXX<br />
<br />
[[Category:Open_Items]]</div>Mhahttps://wiki.postgresql.org/index.php?title=PgCon_2019_Developer_Meeting&diff=33235PgCon 2019 Developer Meeting2019-04-08T11:43:38Z<p>Mha: /* RSVPs */</p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Tuesday 28 May, 2019 at the University of Ottawa, prior to pgCon 2019. In order to keep the numbers manageable, this meeting is by '''invitation only'''.<br />
<br />
The invitation list for the meeting has changed this year to include representatives from various project sub-teams, for example, packagers, the release team, Code of Conduct committee and more.<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 13.0 release cycle<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 be:<br />
<br />
* 9:00AM to 12PM<br />
* DMS TBC<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). Note that we can accommodate a '''maximum of 30'''!<br />
<br />
# Magnus Hagander<br />
# Amit Kapila<br />
# Alexander Korotkov<br />
# Dave Page<br />
<br />
<br />
The following people will not be in Ottawa, and do not plan to attend:<br />
<br />
* Christoph Berg<br />
* Andreas Scherbaum<br />
<br />
== Agenda Items ==<br />
<br />
* 13.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 />
|- <br />
|09:30 - 09:45<br />
|12.0 release and commitfest schedule<br />
|Dave Page<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<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 />
Note: This timetable is a rough guide only. Items will start as soon as the previous discussion is complete (breaks will not move however). Any remaining time before lunch may be used for Commitfest item triage or other activities.</div>Mhahttps://wiki.postgresql.org/index.php?title=FOSDEM/PGDay_2019_Developer_Meeting&diff=32954FOSDEM/PGDay 2019 Developer Meeting2019-01-09T15:29:37Z<p>Mha: /* RSVPs */</p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Thursday 31st January, 2019 at the Brussels Marriott Hotel, prior to FOSDEM/PGDay 2019. 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 10 and 11 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 />
This is a PostgreSQL Community event.<br />
<br />
== Meeting Goals ==<br />
<br />
* Review the progress of the 12.0 schedule, and formulate plans to address any issues<br />
* Address any proposed timing, policy, or procedure issues<br />
* Address any proposed [http://en.wikipedia.org/wiki/Wicked_problem Wicked problems]<br />
* Commitfest Triage<br />
<br />
== Time & Location ==<br />
<br />
The meeting will be:<br />
<br />
* 9:00AM to 5:00PM<br />
* Brussels Marriott Hotel<br />
<br />
Coffee, tea and snacks will be served starting at 8:45am. Lunch will be provided.<br />
<br />
== RSVPs ==<br />
<br />
The following people have RSVPed to the meeting (in alphabetical order, by surname) and will be attending:<br />
<br />
* Joe Conway<br />
* Andres Freund<br />
* Stephen Frost<br />
* Daniel Gustafsson<br />
* Devrim Gündüz<br />
* Magnus Hagander<br />
* Amit Langote<br />
* Thomas Munro<br />
* Dave Page<br />
* Masahiko Sawada<br />
* Tomas Vondra<br />
<br />
The following people have sent their apologies:<br />
<br />
* Peter Eisentraut<br />
* Etsuro Fujita<br />
* Peter Geoghegan<br />
* Kyotaro Horiguchi<br />
* Tatsuo Ishii<br />
* Amit Kapila<br />
* Jonathan Katz<br />
* Tom Lane<br />
* Noah Misch<br />
* Bruce Momjian<br />
* Craig Ringer<br />
* Simon Riggs, on holiday that week<br />
* Pavel Stehule<br />
<br />
==Agenda Items==<br />
<br />
Please add agenda items here!<br />
<br />
* <br />
<br />
==Agenda==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:10<br />
|Welcome and introductions<br />
|Dave<br />
<br />
|- <br />
|09:10 - 09:20<br />
|12.0 Release Review<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<br />
|Coffee break<br />
|All<br />
<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:30 - 13:30<br />
|Lunch<br />
|All<br />
<br />
|- <br />
|13:30 - 15:00<br />
|Commitfest Triage<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|15:00 - 15:30<br />
|Tea break<br />
|All<br />
<br />
|- <br />
|15:30 - 16:45<br />
|Commitfest Triage<br />
|All<br />
<br />
<br />
|- <br />
|16:45 - 17:00<br />
|Any other business<br />
|Dave<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|17:00<br />
|Finish<br />
|<br />
|}<br />
<br />
== Minutes ==</div>Mhahttps://wiki.postgresql.org/index.php?title=PGConf.ASIA2018_Developer_Unconference&diff=32870PGConf.ASIA2018 Developer Unconference2018-12-10T02:58:45Z<p>Mha: /* Notes */</p>
<hr />
<div>An Unconference-style event for active PostgreSQL developers will be held on 10 Dec, 2018 at Akihabara Convention Hall, as part of [http://www.pgconf.asia/EN/2018/ PGConf.ASIA 2018]. <br />
<br />
== Unconference Tokyo Round Time Table ==<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Okinawa<br />
!Hokkaido<br />
|- style="background-color:lightgray;"<br />
|10:30-10:50<br />
|colspan="2"|Voting<br />
<br />
|-<br />
|11:00-11:50<br />
| PostgreSQL and Data Analytics<br />
| Referential Integrity Using Statement Level Triggers<br />
<br />
|- style="background-color:lightgray;"<br />
|11:50 - 13:00 <br />
|colspan="2"|Lunch<br />
<br />
|-<br />
|13:00-13:50 <br />
|Shared Buffer Manager<br />
|Hypotehtical Partitioning<br />
<br />
|-<br />
|14:00-14:50 <br />
|Partition-wise JOIN and Visibility Map<br />
|Query Monitoring<br />
<br />
|-<br />
|15:00-15:50<br />
|Shared Catalog and Relation Cache<br />
|Built In Job Scheduler<br />
<br />
|-<br />
|16:00-16:50<br />
|Per-tablespace transparent encryption<br />
|Idle Connection Scaling<br />
<br />
|- style="background-color:lightgray;"<br />
|17:00 - <br />
|colspan="2"|Beer Elsewhere<br />
<br />
<br />
|}<br />
<br />
== Unconference minutes ==<br />
* TBD<br />
<br />
== Social Event ==<br />
* All attendees can join the social event.<br />
* Venue<br />
* TBD<br />
<br />
== Notes ==<br />
<br />
=== Statement level referential integrity ===<br />
<br />
Oracle-style import<br />
No way to invalidate then revalidate constraints<br />
Right thing also the last thing<br />
Checks fire once per row<br />
Kevin Grittner + Thomas Munro: statement-level triggers, transition tables<br />
benchmark: 98.x% faster<br />
no code, just a PL/PgSQL script<br />
REFERENCES: INSERT/UPDATE trigger on child, DELETE trigger on parent<br />
initial pass: LEFT OUTER JOIN<br />
code is already there!<br />
transition tables don't necessarily have names<br />
enforce constraints with a single table scan! important when _appending_ to a table<br />
* CreateFKCheckTrigger<br />
* SPI_register_triger_data<br />
very seldom more statements than rows<br />
issues with the error message: just show the first row? doesn't make things worse<br />
ignore failed rows server-side; report them so app can fix them (different thing)<br />
different rejection tables for every failure?<br />
Kevin Grittner: delta relations in ALTER triggers [pgsql-hackers]<br />
* commands/tablecmds.c<br />
* RI_Initial_Check<br />
are statement-level triggers also `Trigger *`?<br />
what does the benchmark look like for one-row-at-a-time? make the row count tunable?<br />
how to upgrade? find all row-level triggers and replace them<br />
not a concern with dump/restore, but pg_upgrade needs to skip the initial check<br />
triggers have PG-reserved names; use that to detect and upgrade triggers<br />
pg_upgrade creates empty cluster; maybe no need to skip check?<br />
all that's missing is the magic to convert the trigger<br />
no catalogs are binary-linked<br />
pg_dump/pg_restore dump standard SQL; no syntax changes<br />
switch from row-level to statement-level after X rows<br />
parallel query uses a queue already<br />
suggestion: have custom non-trigger mechanism<br />
<br />
== Reference ==<br />
* Past unconference events<br />
** [https://wiki.postgresql.org/wiki/Pgcon2013unconference PgCon 2013 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/Pgcon2014unconference PgCon 2014 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PgCon_2015_Developer_Unconference PgCon 2015 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference PgCon 2016 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PGConf.ASIA2016_Developer_Unconference PgConf.ASIA 2016 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PgCon_2017_Developer_Unconference PgCon 2017 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PGConf.ASIA2017_Developer_Unconference PgConf.ASIA 2017 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PgCon_2018_Developer_Unconference PgCon 2018 Developer Unconference]</div>Mhahttps://wiki.postgresql.org/index.php?title=PGConf.ASIA2018_Developer_Unconference&diff=32869PGConf.ASIA2018 Developer Unconference2018-12-10T02:12:37Z<p>Mha: /* Unconference Tokyo Round Time Table */</p>
<hr />
<div>An Unconference-style event for active PostgreSQL developers will be held on 10 Dec, 2018 at Akihabara Convention Hall, as part of [http://www.pgconf.asia/EN/2018/ PGConf.ASIA 2018]. <br />
<br />
== Unconference Tokyo Round Time Table ==<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Okinawa<br />
!Hokkaido<br />
|- style="background-color:lightgray;"<br />
|10:30-10:50<br />
|colspan="2"|Voting<br />
<br />
|-<br />
|11:00-11:50<br />
| PostgreSQL and Data Analytics<br />
| Referential Integrity Using Statement Level Triggers<br />
<br />
|- style="background-color:lightgray;"<br />
|11:50 - 13:00 <br />
|colspan="2"|Lunch<br />
<br />
|-<br />
|13:00-13:50 <br />
|Shared Buffer Manager<br />
|Hypotehtical Partitioning<br />
<br />
|-<br />
|14:00-14:50 <br />
|Partition-wise JOIN and Visibility Map<br />
|Query Monitoring<br />
<br />
|-<br />
|15:00-15:50<br />
|Shared Catalog and Relation Cache<br />
|Built In Job Scheduler<br />
<br />
|-<br />
|16:00-16:50<br />
|Per-tablespace transparent encryption<br />
|Idle Connection Scaling<br />
<br />
|- style="background-color:lightgray;"<br />
|17:00 - <br />
|colspan="2"|Beer Elsewhere<br />
<br />
<br />
|}<br />
<br />
== Unconference minutes ==<br />
* TBD<br />
<br />
== Social Event ==<br />
* All attendees can join the social event.<br />
* Venue<br />
* TBD<br />
<br />
== Notes ==<br />
* TBD<br />
<br />
== Reference ==<br />
* Past unconference events<br />
** [https://wiki.postgresql.org/wiki/Pgcon2013unconference PgCon 2013 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/Pgcon2014unconference PgCon 2014 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PgCon_2015_Developer_Unconference PgCon 2015 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Unconference PgCon 2016 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PGConf.ASIA2016_Developer_Unconference PgConf.ASIA 2016 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PgCon_2017_Developer_Unconference PgCon 2017 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PGConf.ASIA2017_Developer_Unconference PgConf.ASIA 2017 Developer Unconference]<br />
** [https://wiki.postgresql.org/wiki/PgCon_2018_Developer_Unconference PgCon 2018 Developer Unconference]</div>Mhahttps://wiki.postgresql.org/index.php?title=FOSDEM/PGDay_2019_Developer_Meeting&diff=32742FOSDEM/PGDay 2019 Developer Meeting2018-11-22T11:45:03Z<p>Mha: /* RSVPs */</p>
<hr />
<div>A meeting of the interested PostgreSQL developers is being planned for Thursday 31st January, 2019 at the Brussels Marriott Hotel, prior to FOSDEM/PGDay 2019. 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 10 and 11 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 />
This is a PostgreSQL Community event.<br />
<br />
== Meeting Goals ==<br />
<br />
* Review the progress of the 12.0 schedule, and formulate plans to address any issues<br />
* Address any proposed timing, policy, or procedure issues<br />
* Address any proposed [http://en.wikipedia.org/wiki/Wicked_problem Wicked problems]<br />
* Commitfest Triage<br />
<br />
== Time & Location ==<br />
<br />
The meeting will be:<br />
<br />
* 9:00AM to 5:00PM<br />
* Brussels Marriott Hotel<br />
<br />
Coffee, tea and snacks will be served starting at 8:45am. Lunch will be provided.<br />
<br />
== RSVPs ==<br />
<br />
The following people have RSVPed to the meeting (in alphabetical order, by surname) and will be attending:<br />
<br />
* Magnus Hagander<br />
* Dave Page<br />
<br />
The following people have sent their apologies:<br />
<br />
* Simon Riggs, on holiday that week<br />
<br />
==Agenda Items==<br />
<br />
Please add agenda items here!<br />
<br />
* <br />
<br />
==Agenda==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
!Time<br />
!Item<br />
!Presenter<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|09:00 - 09:10<br />
|Welcome and introductions<br />
|Dave<br />
<br />
|- <br />
|09:10 - 09:20<br />
|12.0 Release Review<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|10:30 - 11:00<br />
|Coffee break<br />
|All<br />
<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|12:30 - 13:30<br />
|Lunch<br />
|All<br />
<br />
|- <br />
|13:30 - 15:00<br />
|Commitfest Triage<br />
|All<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|15:00 - 15:30<br />
|Tea break<br />
|All<br />
<br />
|- <br />
|15:30 - 16:45<br />
|Commitfest Triage<br />
|All<br />
<br />
<br />
|- <br />
|16:45 - 17:00<br />
|Any other business<br />
|Dave<br />
<br />
|- style="font-style:italic;background-color:lightgray;"<br />
|17:00<br />
|Finish<br />
|<br />
|}<br />
<br />
== Minutes ==</div>Mhahttps://wiki.postgresql.org/index.php?title=Committers&diff=32385Committers2018-08-15T09:02:15Z<p>Mha: </p>
<hr />
<div>This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit or when added as a committer, oldest first; this isn't intended to imply anything about depth of contribution.<br />
<br />
* Bruce Momjian (momjian)<br />
* Tom Lane (tgl)<br />
* Michael Meskes (meskes)<br />
* Tatsuo Ishii (ishii)<br />
* Peter Eisentraut (petere)<br />
* Teodor Sigaev (teodor)<br />
* Joe Conway (joe)<br />
* Alvaro Herrera (alvherre)<br />
* Andrew Dunstan (adunstan)<br />
* Magnus Hagander (mha)<br />
* Heikki Linnakangas (heikki)<br />
* Robert Haas (rhaas)<br />
* Simon Riggs (sriggs)<br />
* Greg Stark (stark)<br />
* Kevin Grittner (kgrittn)<br />
* Jeff Davis (jdavis)<br />
* Stephen Frost (sfrost)<br />
* Fujii Masao (fujii)<br />
* Noah Misch (noah)<br />
* Andres Freund (andres)<br />
* Dean Rasheed (deanr)<br />
* Andrew Gierth (rhodiumtoad)<br />
* Alexander Korotkov (smagen)<br />
* Amit Kapila (amitkapila)<br />
* Tomas Vondra (fuzzycz)<br />
* Michael Paquier (michael-kun)<br />
* Thomas Munro (macdice)<br />
* Peter Geoghegan (pgeoghegan)<br />
* Etsuro Fujita (efujita)<br />
<br />
== Notes on the Commit Log ==<br />
<br />
Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole. <br />
<br />
== New Committers and Removing Committers ==<br />
<br />
New committers are added approximately annually by the Core Team. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:<br />
<br />
* several years of substantial contributions to the project<br />
* multiple and continuing code contributions<br />
* responsibility for maintenance of one or more areas of the codebase<br />
* track record of reviewing and helping other contributors with their patches<br />
* high quality code contributions which require very little revision or correction for commit<br />
* demonstrated understanding of the process and criteria for patch acceptance<br />
<br />
Generally, new committers are selected March or April and announced at pgCon.<br />
<br />
Committers who have become inactive and have not contributed significantly to the PostgreSQL project in several years are removed as committers. Again, the review process for this is approximately annual.<br />
<br />
[[Category:Community]]</div>Mhahttps://wiki.postgresql.org/index.php?title=Committers&diff=32033Committers2018-06-08T08:42:21Z<p>Mha: Protected "Committers" ([edit=sysop] (indefinite) [move=sysop] (indefinite))</p>
<hr />
<div>This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit or when added as a committer, oldest first; this isn't intended to imply anything about depth of contribution.<br />
<br />
* Bruce Momjian (momjian)<br />
* Tom Lane (tgl)<br />
* Michael Meskes (meskes)<br />
* Tatsuo Ishii (ishii)<br />
* Peter Eisentraut (petere)<br />
* Teodor Sigaev (teodor)<br />
* Joe Conway (joe)<br />
* Alvaro Herrera (alvherre)<br />
* Andrew Dunstan (adunstan)<br />
* Magnus Hagander (mha)<br />
* Heikki Linnakangas (heikki)<br />
* Robert Haas (rhaas)<br />
* Simon Riggs (sriggs)<br />
* Greg Stark (stark)<br />
* Kevin Grittner (kgrittn)<br />
* Jeff Davis (jdavis)<br />
* Stephen Frost (sfrost)<br />
* Fujii Masao (fujii)<br />
* Noah Misch (noah)<br />
* Andres Freund (andres)<br />
* Dean Rasheed (deanr)<br />
* Andrew Gierth (rhodiumtoad)<br />
* Alexander Korotkov (smagen)<br />
* Amit Kapila (amitkapila)<br />
* Tomas Vondra (fuzzycz)<br />
* Michael Paquier (michael-kun)<br />
* Thomas Munro (macdice)<br />
* Peter Geoghegan (pgeoghegan)<br />
<br />
<br />
== Notes on the Commit Log ==<br />
<br />
Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole. <br />
<br />
== New Committers and Removing Committers ==<br />
<br />
New committers are added approximately annually by the Core Team. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:<br />
<br />
* several years of substantial contributions to the project<br />
* multiple and continuing code contributions<br />
* responsibility for maintenance of one or more areas of the codebase<br />
* track record of reviewing and helping other contributors with their patches<br />
* high quality code contributions which require very little revision or correction for commit<br />
* demonstrated understanding of the process and criteria for patch acceptance<br />
<br />
Generally, new committers are selected March or April and announced at pgCon.<br />
<br />
Committers who have become inactive and have not contributed significantly to the PostgreSQL project in several years are removed as committers. Again, the review process for this is approximately annual.<br />
<br />
[[Category:Community]]</div>Mhahttps://wiki.postgresql.org/index.php?title=Committers&diff=32032Committers2018-06-08T08:41:59Z<p>Mha: </p>
<hr />
<div>This is the current list of people with access to push to the git repository with their user names. For technical details on how committing works, see [[Committing with Git]]. Note: This is just a list of people who currently have access to push to git; for information on current and previous contributors, see the [http://www.postgresql.org/community/contributors/ contributor profiles] section of the web site. Note: The names are listed here in order of first commit or when added as a committer, oldest first; this isn't intended to imply anything about depth of contribution.<br />
<br />
* Bruce Momjian (momjian)<br />
* Tom Lane (tgl)<br />
* Michael Meskes (meskes)<br />
* Tatsuo Ishii (ishii)<br />
* Peter Eisentraut (petere)<br />
* Teodor Sigaev (teodor)<br />
* Joe Conway (joe)<br />
* Alvaro Herrera (alvherre)<br />
* Andrew Dunstan (adunstan)<br />
* Magnus Hagander (mha)<br />
* Heikki Linnakangas (heikki)<br />
* Robert Haas (rhaas)<br />
* Simon Riggs (sriggs)<br />
* Greg Stark (stark)<br />
* Kevin Grittner (kgrittn)<br />
* Jeff Davis (jdavis)<br />
* Stephen Frost (sfrost)<br />
* Fujii Masao (fujii)<br />
* Noah Misch (noah)<br />
* Andres Freund (andres)<br />
* Dean Rasheed (deanr)<br />
* Andrew Gierth (rhodiumtoad)<br />
* Alexander Korotkov (smagen)<br />
* Amit Kapila (amitkapila)<br />
* Tomas Vondra (fuzzycz)<br />
* Michael Paquier (michael-kun)<br />
* Thomas Munro (macdice)<br />
* Peter Geoghegan (pgeoghegan)<br />
<br />
<br />
== Notes on the Commit Log ==<br />
<br />
Hundreds of developers have successfully contributed work to PostgreSQL over more than 20 years, many acting as individuals, though also many representing academic institutions and both user and vendor companies. Both the "Author" and "Committer" fields of such patches will reflect the committer. The actual author of a patch, if different, is generally listed in the commit message; reviewers or others who contributed ideas or otherwise helped with the patch may also be listed. Many patches, in the form in which they are committed, are the work of multiple people: original author or authors, reviewer(s), and/or committer. As a result, no simple analysis of duration or depth of contribution over time is possible from the commit log. The project operates a system of careful peer review and even committers have their work checked by other committers and the community as a whole. <br />
<br />
== New Committers and Removing Committers ==<br />
<br />
New committers are added approximately annually by the Core Team. Contributors to PostgreSQL are selected to be committers based on the following loose criteria:<br />
<br />
* several years of substantial contributions to the project<br />
* multiple and continuing code contributions<br />
* responsibility for maintenance of one or more areas of the codebase<br />
* track record of reviewing and helping other contributors with their patches<br />
* high quality code contributions which require very little revision or correction for commit<br />
* demonstrated understanding of the process and criteria for patch acceptance<br />
<br />
Generally, new committers are selected March or April and announced at pgCon.<br />
<br />
Committers who have become inactive and have not contributed significantly to the PostgreSQL project in several years are removed as committers. Again, the review process for this is approximately annual.<br />
<br />
[[Category:Community]]</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_11_Open_Items&diff=31845PostgreSQL 11 Open Items2018-04-15T13:34:50Z<p>Mha: /* Open Issues */</p>
<hr />
<div>== Open Issues ==<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1xY2LLBf4szkQPEQYnGMdGfcfYMxjfG38mqkcd1rj6ryQ@mail.gmail.com WARNING in parallel index creation]<br />
** Original commit (tentative): {{PgCommitURL|9da0cc35284bdbe8d442d732963303ff0e0a40bc}}<br />
<br />
* [https://www.postgresql.org/message-id/87po3a3n46.fsf@ansel.ydns.eu Failed assertion in create_gather_path]<br />
<br />
* [https://www.postgresql.org/message-id/87woxi24uw.fsf@ansel.ydns.eu expand_tuple segfaults]<br />
** coverage report shows it's completely untested, too<br />
<br />
* [https://www.postgresql.org/message-id/2b02f1e9-9812-9c41-972d-517bdc0f815d%40lab.ntt.co.jp Fix partition pruning for the cases where partition key is of array, enum, record, or range type]<br />
** [https://www.postgresql.org/message-id/c86a9849-ccd7-2e1f-94f2-a761b35ef47f%40lab.ntt.co.jp Patch exists]<br />
<br />
* [https://www.postgresql.org/message-id/CAKJS1f-tux=KdUz6ENJ9GHM_V2qgxysadYiOyQS9Ko9PTteVhQ@mail.gmail.com Run-time pruning and Parallel Append don't work properly together]<br />
** [https://www.postgresql.org/message-id/CAKJS1f-tux=KdUz6ENJ9GHM_V2qgxysadYiOyQS9Ko9PTteVhQ@mail.gmail.com Patch exists]<br />
<br />
* [https://www.postgresql.org/message-id/96cf4a6c-49ad-fa92-0d41-e4b911086dab%40lab.ntt.co.jp Handling of whole-row vars in ON CONFLICT on partitioned tables]<br />
** patch exists<br />
<br />
* [https://www.postgresql.org/message-id/d8ja7ubjnyp.fsf@dalvik.ping.uio.no JSONB PL/Perl transform bugs]<br />
<br />
* Covering indexes, some minor issues:<br />
** [https://www.postgresql.org/message-id/20180411075223.GB19732%40paquier.xyz Typos from the original patch]<br />
** [https://www.postgresql.org/message-id/20180411082020.GD19732%40paquier.xyz Fixes for the documentation]<br />
<br />
* [https://www.postgresql.org/message-id/flat/20180413030828.GD1552%40paquier.xyz#20180413030828.GD1552@paquier.xyz wal_consistency_checking reports an inconsistency on master branch]<br />
<br />
== Decisions to Recheck Mid-Beta ==<br />
<br />
* [https://www.postgresql.org/message-id/20180328212751.eskdxpljte6ga6wu@alap3.anarazel.de reconsider jit=on default shortly before release]<br />
* [https://www.postgresql.org/message-id/CAH2-Wzkkd_VY1E6wX=9L1t+YfKuRSWpi=NsqeoOd4EW+E638tg@mail.gmail.com Does the _bt_compare() call to _bt_check_natts() have acceptably low overhead, or should it just be an assertion?]<br />
<br />
== Older Bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/20180309075538.GD9376@paquier.xyz Fixes for missing schema qualifications]<br />
* [https://www.postgresql.org/message-id/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC=C2whnzBM8TAcv=stckYUw@mail.gmail.com Allocation done in critical section when initializing WAL]<br />
* [https://www.postgresql.org/message-id/AD7252BEFBCA3846A8D34ABCDA258D080120F025C6@EXMBX05.mailcloud.dk pg_dump misses public role on schema public]<br />
* [https://www.postgresql.org/message-id/20170117.193645.160386781.horiguchi.kyotaro@lab.ntt.co.jp Continued WAL record can prevent standby from startup]<br />
* [https://www.postgresql.org/message-id/flat/CAKJS1f-BL%2Br5FXSejDu%3D%2BMAvzRARaawRnQ_ZFtbv_o6tha9NJw%40mail.gmail.com#CAKJS1f-BL+r5FXSejDu=+MAvzRARaawRnQ_ZFtbv_o6tha9NJw@mail.gmail.com Partitions with bool partition keys]<br />
* [https://www.postgresql.org/message-id/3041e853-b1dd-a0c6-ff21-7cc5633bffd0%40lab.ntt.co.jp wrong memory context used in FmgrInfo's contained in PartitionKey]<br />
<br />
== Non-bugs ==<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 11beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/12085bc4-0bc6-0f3a-4c43-57fe0681772b@lab.ntt.co.jp relispartition for index partitions]<br />
** Bug fix: {{PgCommitURL|9e9befac4a2228ae8a5309900645ecd8ead69f53}}<br />
<br />
<br />
* [https://www.postgresql.org/message-id/CAGPqQf0W%2Bv-Ci_qNV_5R3A%3DZ9LsK4%2BjO7LzgddRncpp_rrnJqQ%40mail.gmail.com failure to validate default partition's constraint when attaching after4dba331cb3]<br />
** [https://www.postgresql.org/message-id/487870f2-d538-9d07-13e8-4ca390e27d18%40lab.ntt.co.jp Patch exists]<br />
** Bug fix: {{PgCommitURL|72cf7f310c0729a331f321fad39835ac886603dc}}<br />
<br />
* [https://www.postgresql.org/message-id/87in923lyw.fsf@ansel.ydns.eu Failed assertion on pfree() via perform_pruning_combine_step]<br />
** Original commit: {{PgCommitURL|9fdb675fc5d2de825414e05939727de8b120ae81}}<br />
** Bug fix: {{PgCommitURL|7ba6ee815dc90d4fab7226d343bf72aa28c9aa5c}}<br />
<br />
* [https://www.postgresql.org/message-id/CAH2-WzkryAPcQOHBJKuDKfni-HGFny31yjcbM-yp5HO-71iCdw@mail.gmail.com Parallel index workers don't have activity set]<br />
** Original commit: {{PgCommitURL|9da0cc35284bdbe8d442d732963303ff0e0a40bc}}<br />
** Bug fix: {{PgCommitURL|7de4a1bcc56f494acbd0d6e70781df877dc8ecb5}}<br />
<br />
* [https://www.postgresql.org/message-id/20180402065149.GC1908%40paquier.xyz check_ssl_key_file_permissions should be in be-secure-common.c]<br />
** Original commit: {{PgCommitURL|8a3d9425290ff5f6434990349886afae9e1c6008}}<br />
** [https://www.postgresql.org/message-id/20180402065149.GC1908%40paquier.xyz Patch exists]<br />
** Bug fix: {{PgCommitURL|2764d5dcfa84d240c901c20ec6e194f72d82b78a}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAFjFpRcOTHZSFfHNwhAe4DmS%2BqvWmqK_UW3QF3wG8e0pAKW0tA%40mail.gmail.com#CAFjFpRcOTHZSFfHNwhAe4DmS+qvWmqK_UW3QF3wG8e0pAKW0tA@mail.gmail.com Missing break statement after transformCallStmt in transformStmt]<br />
** Original commit: {{PgCommitURL|76b6aa41f41db66004b1c430f17a546d4102fbe7}}<br />
** Bug fix: {{PgCommitURL|13c7c65ec900a30bcddcb27f5fd138dcdbc2ca2e}}<br />
<br />
* [https://www.postgresql.org/message-id/CAKJS1f91kq1wfYR8rnRRfKtxyhU2woEA+=whd640UxMyU+O0EQ@mail.gmail.com Parallel index creation does not properly clean up after error]<br />
** Original commit: {{PgCommitURL|29d58fd3adae9057c3fd502393b2f131bc96eaf9}}<br />
** Bug fix: {{PgCommitURL|47cb9ca49a611fa518e1a0fe46526507c96a5612}}<br />
<br />
* [https://www.postgresql.org/message-id/30721.1519750231@sss.pgh.pa.us pg_proc.prokind change means we need server-version-dependent tab completion in psql]<br />
** [https://www.postgresql.org/message-id/24314.1520190408@sss.pgh.pa.us Proposed patch]<br />
<br />
* [https://www.postgresql.org/message-id/20180409010031.GA11599%40paquier.xyz "make -j 4 install" broken after running configure]<br />
** Bug fix: {{PgCommitURL|3b8f6e75f3c8c6d192621f21624cc8cee04ec3cb}}<br />
<br />
* [https://www.postgresql.org/message-id/152056616579.4966.583293218357089052@wrigleys.postgresql.org OpenTransientFile() should be paired with CloseTransientFile() rather than close()]<br />
** Bug fix: {{PgCommitURL|231bcd0803eb91c526d4e7522c993fa5ed71bd45}}<br />
<br />
* [https://www.postgresql.org/message-id/20180409051112.GC1740%40paquier.xyz Fix pg_rewind which can be run as root user]<br />
** Bug fix: {{PgCommitURL|5d5aeddabfe0b6b21f556c72a71e0454833d63e5}}<br />
<br />
* [https://www.postgresql.org/message-id/CAMyN-kA7aOJzBmrYFdXcc7Z0NmW+5jBaf_m=_-77uRNyKC9r=A@mail.gmail.com Fix for pg_stat_activity putting client hostaddr into appname field]<br />
** Bug fix: {{PgCommitURL|a820b4c32946c499a2d19846123840a0dad071b5}} and {{PgCommitURL|811969b218ac2e8030dfbbb05873344967461618}}<br />
<br />
* [https://www.postgresql.org/message-id/CAFj8pRCgQ5_O4YL4ZKC5=6Oi7DW_q4xB7==_iN2yRKq7+1Tv9Q@mail.gmail.com Missing support of named convention for procedures]<br />
** Bug fix: {{PgCommitURL|a8677e3ff6bb8ef78a9ba676faa647bba237b1c4}}<br />
<br />
* [https://www.postgresql.org/message-id/20180410042147.GB1552%40paquier.xyz Gotchas about pg_verify_checksums]<br />
<br />
* [https://www.postgresql.org/message-id/20180411001058.GJ26769%40paquier.xyz pg_verify_checksums does not check after all-zero'd pages]<br />
<br />
=== resolved before 11beta2 ===<br />
<br />
This lists the open items fixed between the release of 11 beta1 and 11 beta2. <br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
* feature freeze: 8th of April 2018<br />
* beta1: YYY<br />
* beta2: ZZZ<br />
<br />
[[Category:Open_Items]]</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_11_Open_Items&diff=31844PostgreSQL 11 Open Items2018-04-15T13:34:31Z<p>Mha: </p>
<hr />
<div>== Open Issues ==<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1xY2LLBf4szkQPEQYnGMdGfcfYMxjfG38mqkcd1rj6ryQ@mail.gmail.com WARNING in parallel index creation]<br />
** Original commit (tentative): {{PgCommitURL|9da0cc35284bdbe8d442d732963303ff0e0a40bc}}<br />
<br />
* [https://www.postgresql.org/message-id/87po3a3n46.fsf@ansel.ydns.eu Failed assertion in create_gather_path]<br />
<br />
* [https://www.postgresql.org/message-id/87woxi24uw.fsf@ansel.ydns.eu expand_tuple segfaults]<br />
** coverage report shows it's completely untested, too<br />
<br />
* [https://www.postgresql.org/message-id/2b02f1e9-9812-9c41-972d-517bdc0f815d%40lab.ntt.co.jp Fix partition pruning for the cases where partition key is of array, enum, record, or range type]<br />
** [https://www.postgresql.org/message-id/c86a9849-ccd7-2e1f-94f2-a761b35ef47f%40lab.ntt.co.jp Patch exists]<br />
<br />
* [https://www.postgresql.org/message-id/CAKJS1f-tux=KdUz6ENJ9GHM_V2qgxysadYiOyQS9Ko9PTteVhQ@mail.gmail.com Run-time pruning and Parallel Append don't work properly together]<br />
** [https://www.postgresql.org/message-id/CAKJS1f-tux=KdUz6ENJ9GHM_V2qgxysadYiOyQS9Ko9PTteVhQ@mail.gmail.com Patch exists]<br />
<br />
* [https://www.postgresql.org/message-id/96cf4a6c-49ad-fa92-0d41-e4b911086dab%40lab.ntt.co.jp Handling of whole-row vars in ON CONFLICT on partitioned tables]<br />
** patch exists<br />
<br />
<br />
* [https://www.postgresql.org/message-id/d8ja7ubjnyp.fsf@dalvik.ping.uio.no JSONB PL/Perl transform bugs]<br />
<br />
* Covering indexes, some minor issues:<br />
** [https://www.postgresql.org/message-id/20180411075223.GB19732%40paquier.xyz Typos from the original patch]<br />
** [https://www.postgresql.org/message-id/20180411082020.GD19732%40paquier.xyz Fixes for the documentation]<br />
<br />
* [https://www.postgresql.org/message-id/flat/20180413030828.GD1552%40paquier.xyz#20180413030828.GD1552@paquier.xyz wal_consistency_checking reports an inconsistency on master branch]<br />
<br />
== Decisions to Recheck Mid-Beta ==<br />
<br />
* [https://www.postgresql.org/message-id/20180328212751.eskdxpljte6ga6wu@alap3.anarazel.de reconsider jit=on default shortly before release]<br />
* [https://www.postgresql.org/message-id/CAH2-Wzkkd_VY1E6wX=9L1t+YfKuRSWpi=NsqeoOd4EW+E638tg@mail.gmail.com Does the _bt_compare() call to _bt_check_natts() have acceptably low overhead, or should it just be an assertion?]<br />
<br />
== Older Bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/20180309075538.GD9376@paquier.xyz Fixes for missing schema qualifications]<br />
* [https://www.postgresql.org/message-id/CAFiTN-u4BA8KXcQUWDPNgaKAjDXC=C2whnzBM8TAcv=stckYUw@mail.gmail.com Allocation done in critical section when initializing WAL]<br />
* [https://www.postgresql.org/message-id/AD7252BEFBCA3846A8D34ABCDA258D080120F025C6@EXMBX05.mailcloud.dk pg_dump misses public role on schema public]<br />
* [https://www.postgresql.org/message-id/20170117.193645.160386781.horiguchi.kyotaro@lab.ntt.co.jp Continued WAL record can prevent standby from startup]<br />
* [https://www.postgresql.org/message-id/flat/CAKJS1f-BL%2Br5FXSejDu%3D%2BMAvzRARaawRnQ_ZFtbv_o6tha9NJw%40mail.gmail.com#CAKJS1f-BL+r5FXSejDu=+MAvzRARaawRnQ_ZFtbv_o6tha9NJw@mail.gmail.com Partitions with bool partition keys]<br />
* [https://www.postgresql.org/message-id/3041e853-b1dd-a0c6-ff21-7cc5633bffd0%40lab.ntt.co.jp wrong memory context used in FmgrInfo's contained in PartitionKey]<br />
<br />
== Non-bugs ==<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 11beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/12085bc4-0bc6-0f3a-4c43-57fe0681772b@lab.ntt.co.jp relispartition for index partitions]<br />
** Bug fix: {{PgCommitURL|9e9befac4a2228ae8a5309900645ecd8ead69f53}}<br />
<br />
<br />
* [https://www.postgresql.org/message-id/CAGPqQf0W%2Bv-Ci_qNV_5R3A%3DZ9LsK4%2BjO7LzgddRncpp_rrnJqQ%40mail.gmail.com failure to validate default partition's constraint when attaching after4dba331cb3]<br />
** [https://www.postgresql.org/message-id/487870f2-d538-9d07-13e8-4ca390e27d18%40lab.ntt.co.jp Patch exists]<br />
** Bug fix: {{PgCommitURL|72cf7f310c0729a331f321fad39835ac886603dc}}<br />
<br />
* [https://www.postgresql.org/message-id/87in923lyw.fsf@ansel.ydns.eu Failed assertion on pfree() via perform_pruning_combine_step]<br />
** Original commit: {{PgCommitURL|9fdb675fc5d2de825414e05939727de8b120ae81}}<br />
** Bug fix: {{PgCommitURL|7ba6ee815dc90d4fab7226d343bf72aa28c9aa5c}}<br />
<br />
* [https://www.postgresql.org/message-id/CAH2-WzkryAPcQOHBJKuDKfni-HGFny31yjcbM-yp5HO-71iCdw@mail.gmail.com Parallel index workers don't have activity set]<br />
** Original commit: {{PgCommitURL|9da0cc35284bdbe8d442d732963303ff0e0a40bc}}<br />
** Bug fix: {{PgCommitURL|7de4a1bcc56f494acbd0d6e70781df877dc8ecb5}}<br />
<br />
* [https://www.postgresql.org/message-id/20180402065149.GC1908%40paquier.xyz check_ssl_key_file_permissions should be in be-secure-common.c]<br />
** Original commit: {{PgCommitURL|8a3d9425290ff5f6434990349886afae9e1c6008}}<br />
** [https://www.postgresql.org/message-id/20180402065149.GC1908%40paquier.xyz Patch exists]<br />
** Bug fix: {{PgCommitURL|2764d5dcfa84d240c901c20ec6e194f72d82b78a}}<br />
<br />
* [https://www.postgresql.org/message-id/flat/CAFjFpRcOTHZSFfHNwhAe4DmS%2BqvWmqK_UW3QF3wG8e0pAKW0tA%40mail.gmail.com#CAFjFpRcOTHZSFfHNwhAe4DmS+qvWmqK_UW3QF3wG8e0pAKW0tA@mail.gmail.com Missing break statement after transformCallStmt in transformStmt]<br />
** Original commit: {{PgCommitURL|76b6aa41f41db66004b1c430f17a546d4102fbe7}}<br />
** Bug fix: {{PgCommitURL|13c7c65ec900a30bcddcb27f5fd138dcdbc2ca2e}}<br />
<br />
* [https://www.postgresql.org/message-id/CAKJS1f91kq1wfYR8rnRRfKtxyhU2woEA+=whd640UxMyU+O0EQ@mail.gmail.com Parallel index creation does not properly clean up after error]<br />
** Original commit: {{PgCommitURL|29d58fd3adae9057c3fd502393b2f131bc96eaf9}}<br />
** Bug fix: {{PgCommitURL|47cb9ca49a611fa518e1a0fe46526507c96a5612}}<br />
<br />
* [https://www.postgresql.org/message-id/30721.1519750231@sss.pgh.pa.us pg_proc.prokind change means we need server-version-dependent tab completion in psql]<br />
** [https://www.postgresql.org/message-id/24314.1520190408@sss.pgh.pa.us Proposed patch]<br />
<br />
* [https://www.postgresql.org/message-id/20180409010031.GA11599%40paquier.xyz "make -j 4 install" broken after running configure]<br />
** Bug fix: {{PgCommitURL|3b8f6e75f3c8c6d192621f21624cc8cee04ec3cb}}<br />
<br />
* [https://www.postgresql.org/message-id/152056616579.4966.583293218357089052@wrigleys.postgresql.org OpenTransientFile() should be paired with CloseTransientFile() rather than close()]<br />
** Bug fix: {{PgCommitURL|231bcd0803eb91c526d4e7522c993fa5ed71bd45}}<br />
<br />
* [https://www.postgresql.org/message-id/20180409051112.GC1740%40paquier.xyz Fix pg_rewind which can be run as root user]<br />
** Bug fix: {{PgCommitURL|5d5aeddabfe0b6b21f556c72a71e0454833d63e5}}<br />
<br />
* [https://www.postgresql.org/message-id/CAMyN-kA7aOJzBmrYFdXcc7Z0NmW+5jBaf_m=_-77uRNyKC9r=A@mail.gmail.com Fix for pg_stat_activity putting client hostaddr into appname field]<br />
** Bug fix: {{PgCommitURL|a820b4c32946c499a2d19846123840a0dad071b5}} and {{PgCommitURL|811969b218ac2e8030dfbbb05873344967461618}}<br />
<br />
* [https://www.postgresql.org/message-id/CAFj8pRCgQ5_O4YL4ZKC5=6Oi7DW_q4xB7==_iN2yRKq7+1Tv9Q@mail.gmail.com Missing support of named convention for procedures]<br />
** Bug fix: {{PgCommitURL|a8677e3ff6bb8ef78a9ba676faa647bba237b1c4}}<br />
<br />
* [https://www.postgresql.org/message-id/20180410042147.GB1552%40paquier.xyz Gotchas about pg_verify_checksums]<br />
<br />
* [https://www.postgresql.org/message-id/20180411001058.GJ26769%40paquier.xyz pg_verify_checksums does not check after all-zero'd pages]<br />
<br />
=== resolved before 11beta2 ===<br />
<br />
This lists the open items fixed between the release of 11 beta1 and 11 beta2. <br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
* feature freeze: 8th of April 2018<br />
* beta1: YYY<br />
* beta2: ZZZ<br />
<br />
[[Category:Open_Items]]</div>Mhahttps://wiki.postgresql.org/index.php?title=NewsEventsApproval&diff=31676NewsEventsApproval2018-03-29T11:14:56Z<p>Mha: Protected "NewsEventsApproval" ([edit=sysop] (indefinite) [move=sysop] (indefinite))</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 />
* Starting at midnight UTC on the day of a PostgreSQL release, including any beta or release candidate (RC), no new announcement request will be approved until after midnight UTC 72 hours later. For example, if a new version of PostgreSQL is released on 2018-02-08, then no other announcements will be approved between 2018-02-08 0:00 UTC and 2018-02-11 0:00 UTC. Any announcements submitted *during* this time should have their timestamp updated once they are approved, so they don't end up looking like old once they do post.<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>Mhahttps://wiki.postgresql.org/index.php?title=NewsEventsApproval&diff=31675NewsEventsApproval2018-03-29T11:13:59Z<p>Mha: </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 />
* Starting at midnight UTC on the day of a PostgreSQL release, including any beta or release candidate (RC), no new announcement request will be approved until after midnight UTC 72 hours later. For example, if a new version of PostgreSQL is released on 2018-02-08, then no other announcements will be approved between 2018-02-08 0:00 UTC and 2018-02-11 0:00 UTC. Any announcements submitted *during* this time should have their timestamp updated once they are approved, so they don't end up looking like old once they do post.<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>Mhahttps://wiki.postgresql.org/index.php?title=PgCon_2018_Developer_Meeting&diff=31517PgCon 2018 Developer Meeting2018-02-26T10:27:27Z<p>Mha: /* 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 />
<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>Mhahttps://wiki.postgresql.org/index.php?title=@postgresql_Twitter_Account_Policy&diff=31426@postgresql Twitter Account Policy2018-01-19T11:13:18Z<p>Mha: </p>
<hr />
<div>This policy applies to the '''manual''' use of the @postgresql Twitter account.<br />
<br />
<br />
Tweets are allowed which relate to approved News & Events as defined in the [[NewsEventsApproval|News and Events Approval Policies]] (a.k.a. the -announce policy), provided that the tweets are:<br />
<br />
* Of a reasonable frequency (as defined by the moderators, with the following guidelines):<br />
** Tweets/Re-tweets about Core and "Family" News are not frequency-limited<br />
** Tweets/Re-tweets about Proprietary & External OSS Project News should not be more than weekly<br />
** Tweets/Re-tweets about the activity of a PostgreSQL recognized community conference or event should not be more than daily.<br />
** Tweets/Re-tweets about the activity of a particular Open Source & Database Conference or Event should not be more than weekly.<br />
** Tweets/Re-tweets about finding information contained on a website within the PostgreSQL infrastructure are not frequency limited.<br />
<br />
* Are not commercial in nature (Tweets about a given organization sponsoring a conference are ok, tweets which are attempting to solicit sponsorship for an event are not)<br />
<br />
<br />
In addition to approved News & Events, these kinds of Events may also be tweet'd about, following the same guidelines set forth above:<br />
<br />
* Local PostgreSQL User Group (PUG) meetings and related efforts to establish PUGs. PUGs are encouraged to have their own Twitter handle which @postgresql will retweets appropriate tweets from.<br />
<br />
* PostgreSQL Weekly news (weekly tweet highlighting the -announce post)<br />
<br />
* Tweets/Re-tweets are also allowed for acceptable blog posts, media coverage, and tweets about PostgreSQL, provided these are not commercial in nature, using the same guidelines as set forth in the [[Planet_PostgreSQL|Planet PostgreSQL policy]].<br />
<br />
<br />
Replies to mentions are also allowed when and if appropriate, per these guidelines:<br />
<br />
* Acceptable:<br />
** Answering a PostgreSQL-specific question to provide help<br />
** Providing a helpful suggestion or comment<br />
** Professional discussion regarding specific technical aspects of PostgreSQL as compared to other products or projects.<br />
<br />
* Not acceptable:<br />
** Off-topic tweets which are not related to PostgreSQL<br />
** Degrading or attacking other products, projects, or individuals.<br />
** Unprofessional behavior of any kind<br />
<br />
Tweets should follow the same guidelines as one would use when posting to the project mailing lists.</div>Mhahttps://wiki.postgresql.org/index.php?title=@postgresql_Twitter_Account_Policy&diff=31413@postgresql Twitter Account Policy2018-01-17T20:08:01Z<p>Mha: </p>
<hr />
<div>This policy applies to the '''manual''' use of the @postgresql Twitter account.<br />
<br />
<br />
Tweets are allowed which relate to approved News & Events as defined in the [[NewsEventsApproval|News and Events Approval Policies]] (a.k.a. the -announce policy), provided that the tweets are:<br />
<br />
* Of a reasonable frequency (as defined by the moderators, with the following guidelines):<br />
** Tweets/Re-tweets about Core and "Family" News are not frequency-limited<br />
** Tweets/Re-tweets about Proprietary & External OSS Project News should not be more than weekly<br />
** Tweets/Re-tweets about the activity of a PostgreSQL conference or event should not be more than daily.<br />
** Tweets/Re-tweets about the activity of a PostgreSQL recognized community conference or event should not be more than daily.<br />
** Tweets/Re-tweets about the activity of a particular Open Source & Database Conference or Event should not be more than weekly.<br />
** Tweets/Re-tweets about finding information contained on a website within the PostgreSQL infrastructure are not frequency limited.<br />
<br />
* Are not commercial in nature (Tweets about a given organization sponsoring a conference are ok, tweets which are attempting to solicit sponsorship for an event are not)<br />
<br />
<br />
In addition to approved News & Events, these kinds of Events may also be tweet'd about, following the same guidelines set forth above:<br />
<br />
* Local PostgreSQL User Group (PUG) meetings and related efforts to establish PUGs. PUGs are encouraged to have their own Twitter handle which @postgresql will retweets appropriate tweets from.<br />
<br />
* PostgreSQL Weekly news (weekly tweet highlighting the -announce post)<br />
<br />
* Tweets/Re-tweets are also allowed for acceptable blog posts, media coverage, and tweets about PostgreSQL, provided these are not commercial in nature, using the same guidelines as set forth in the [[Planet_PostgreSQL|Planet PostgreSQL policy]].<br />
<br />
<br />
Replies to mentions are also allowed when and if appropriate, per these guidelines:<br />
<br />
* Acceptable:<br />
** Answering a PostgreSQL-specific question to provide help<br />
** Providing a helpful suggestion or comment<br />
** Professional discussion regarding specific technical aspects of PostgreSQL as compared to other products or projects.<br />
<br />
* Not acceptable:<br />
** Off-topic tweets which are not related to PostgreSQL<br />
** Degrading or attacking other products, projects, or individuals.<br />
** Unprofessional behavior of any kind<br />
<br />
Tweets should follow the same guidelines as one would use when posting to the project mailing lists.</div>Mhahttps://wiki.postgresql.org/index.php?title=@postgresql_Twitter_Account_Policy&diff=31412@postgresql Twitter Account Policy2018-01-17T20:07:07Z<p>Mha: </p>
<hr />
<div>This policy applies to the '''manual''' use of the @postgresql Twitter account.<br />
<br />
<br />
Tweets are allowed which relate to approved News & Events as defined in the [[NewsEventsApproval|News and Events Approval Policies]] (a.k.a. the -announce policy), provided that the tweets are:<br />
<br />
* Of a reasonable frequency (as defined by the moderators, with the following guidelines):<br />
** Tweets/Re-tweets about Core and "Family" News are not frequency-limited<br />
** Tweets/Re-tweets about Proprietary & External OSS Project News should not be more than weekly<br />
** Tweets/Re-tweets about the activity of a PostgreSQL conference or event should not be more than daily.<br />
** Tweets/Re-tweets about the activity of a PostgreSQL recognized community conference or event should not be more than daily.<br />
** Tweets/Re-tweets about the activity of a particular Open Source & Database Conference or Event should not be more than weekly.<br />
** Tweets/Re-tweets about finding information contained on a website within the PostgreSQL infrastructure are not frequency limited.<br />
<br />
* Are not commercial in nature (Tweets about a given organization sponsoring a conference are ok, tweets which are attempting to solicit sponsorship for an event are not)<br />
<br />
<br />
In addition to approved News & Events, these kinds of Events may also be tweet'd about, following the same guidelines set forth above:<br />
<br />
* Local PostgreSQL User Group (PUG) meetings and related efforts to establish PUGs. PUGs are encouraged to have their own Twitter handle which @postgresql will retweets appropriate tweets from.<br />
<br />
* PostgreSQL Weekly news (weekly tweet highlighting the -announce post)<br />
<br />
Tweets/Re-tweets are also allowed for acceptable blog posts, media coverage, and tweets about PostgreSQL, provided these are not commercial in nature, using the same guidelines as set forth in the [[Planet_PostgreSQL|Planet PostgreSQL policy]].<br />
<br />
<br />
Replies to mentions are also allowed when and if appropriate, per these guidelines:<br />
<br />
* Acceptable:<br />
** Answering a PostgreSQL-specific question to provide help<br />
** Providing a helpful suggestion or comment<br />
** Professional discussion regarding specific technical aspects of PostgreSQL as compared to other products or projects.<br />
<br />
* Not acceptable:<br />
** Off-topic tweets which are not related to PostgreSQL<br />
** Degrading or attacking other products, projects, or individuals.<br />
** Unprofessional behavior of any kind<br />
<br />
Tweets should follow the same guidelines as one would use when posting to the project mailing lists.</div>Mhahttps://wiki.postgresql.org/index.php?title=PGLister:_How_to_Moderate&diff=31319PGLister: How to Moderate2017-12-19T12:57:54Z<p>Mha: /* Moderation Actions */</p>
<hr />
<div>{{Languages}}<br />
<br />
[https://lists.postgresql.org/ PGLister] is a mailing list management system designed to better [[PGLister_Announce | address the needs]] of the PostgreSQL community. PGLister is updated to work with recent improvements in email technology and spam filtering as well as provide an easy-to-use interface to manage list access. The guide below explains how a moderator can manage lists assigned for moderation.<br />
<br />
== Before you moderate for this first time ==<br />
<br />
In order to be assigned as a moderator to lists managed by [https://lists.postgresql.org/ PGLister], you must have logged into PGLister at least once. You can follow these steps to log in:<br />
<br />
# Visit [https://lists.postgresql.org/ PGLister] at [https://lists.postgresql.org/ https://lists.postgresql.org/]<br />
# Click on [https://lists.postgresql.org/manage/ Manage Subscriptions]. '''If your community account is already authenticated, then you will be logged into PGLister and redirected to the PGLister dashboard. You are now done.'''<br />
# If your account is not authenticated, you will be redirect to the community login page. Please log in with your community credentials here.<br />
## If you do not have a community account, you will need to register for one. Follow the steps to register a community account. When you are finished with sign up, return to Step 1 of this guide.<br />
# If you successfully authenticate your account, you will be redirect to the [https://lists.postgresql.org/manage/ PGLister Dashboard] where you can manage your PostgreSQL mailing list subscriptions as well as moderate lists.<br />
# If this is the first time you authenticated with PGLister and/or would like to request to be added as a moderator to a mailing list, please contact [mailto:sysadmins@postgresql.org sysadmins@postgresql.org] with your requests details.<br />
<br />
== Moderating Lists ==<br />
<br />
If you are a moderator of any list on PGLister, you will have access to the [https://lists.postgresql.org/moderate/ moderation dashboard]. You can find the link to the moderation dashboard underneath the "Manage lists" heading on the [https://lists.postgresql.org/manage/ PGLister Dashboard]. Click "Moderate / Manage Lists" to access to the [https://lists.postgresql.org/moderate/ moderation dashboard].<br />
<br />
Below will break down each section in the moderation dashboard and how to moderate the mailing lists you help manage.<br />
<br />
=== The "Moderation" Screen ===<br />
<br />
When mailing lists that you moderate have messages that require review, they will appear in the "Moderation" section of the moderation [https://lists.postgresql.org/moderate/ moderation dashboard]. As a moderator, you will also receive an email that provides several courses of action to take on the message. '''NOTE: THE EMAIL SENT TO MODERATORS REQUESTING MODERATION DOES NOT CONTAIN A MESSAGE PREVIEW.''' If you would like to preview the message before setting a course of action, you must visit the [https://lists.postgresql.org/moderate/ moderation dashboard] to view the message preview. Please see below for instructions on how to do so.<br />
<br />
==== Moderation Metadata ====<br />
<br />
The metadata on a message queued for moderation contains the following information:<br />
<br />
* Date: When the message was sent<br />
* List: Which list the message was sent to (e.g. "pgsql-announce")<br />
* Reason: The reason why the message is in the moderation queue (e.g. "sender is not a subscriber of any list)<br />
<br />
==== Moderation Message Info ====<br />
<br />
The data contained in the "Message" section on the moderation dashboard includes the following:<br />
<br />
* Sender: The email address ending the message<br />
* Subject: The subject of the message. If you click on "Subject," a popover box appears that contains a preview of the message. Based on the email client used to send the message, this can at times appear to be garbled text.<br />
* Message ID: Contains a URL that activates a popover with the message ID<br />
<br />
==== Moderation Actions ====<br />
<br />
The actions section determines what to do with the message. In other words, "Actions" comprises the moderator's decision with the message, such as whether or not it should be sent out to the list. Below is what each action does for a message:<br />
<br />
* '''Ignore''': This is the default action. Ignore is a no-op: it does not perform any action on the message.<br />
* '''Approve''': Approves the message to be sent to the list.<br />
* '''Whitelist''': Both approve the message and add the sender's email address to the whitelist of that mailing list. '''NOTE: This means that a sender can ALWAYS send messages to the mailing list that are automatically approved without any moderation.'''<br />
* '''Discard''': Removes the message from the moderation queue and does '''not''' send the message to the mailing list. The sender does '''not''' receive a notification that the message was not approved for sending. This is typically used for messages that are spam.<br />
* '''Reject''': Prompts the moderator to enter a reason for rejecting the message to be delivered to the sender and removes the message from the moderation queue. This action does '''not''' send the message to the mailing list. The sender receives a notification that the message was not approved for sending as well as the reason why it was rejected. ''Please be polite with your responses'': someone sending an email to the list may not be aware of the list policy, so try to point them to the correct reference.<br />
* '''Unsubscribe''': Unsubscribes the sender from the list. This requires the sender to be identified as an active subscriber of the list.<br />
* '''Reject unsub''': The same as ''reject'', except the reason is set to a pre-canned message with full instructions for how to use the List headers to unsubscribe from a message. This is the appropriate choice when an unsubscribe request is received from a sender who is not identified as a subscriber of the list.<br />
<br />
In order to finalize all the selected actions, a moderator must click '''Moderate''' at the bottom of the Moderation section.<br />
<br />
===== Moderation Actions for pgsql-announce =====<br />
<br />
Due to the large number of subscriptions to the pgsql-announce mailing list, a message sent to pgsql-announce must be approved by '''two''' moderators before it is sent through. This is to ensure that we respect the mailboxes of everyone subscribed to pgsql-announce and that a moderator does not accidentally approve a message that would be deemed as inappropriate for that list.<br />
<br />
==== Explaining the Moderation email ====<br />
<br />
It is also possible to moderate messages from an email sent to moderators of a list. You will probably want to see a preview of the message before applying a moderation action, but fortunately you can do this from the email. All actions are the same as [[#Moderation Actions|moderation actions]] described above, but as soon as you click on the URL, this action is taken. A few notes:<br />
<br />
* '''Preview''': Brings you to a preview of the message. This opens up a tab in your browser with the contents of the message.<br />
* '''Reject''': Reject is currently not supported from the moderation email. If you would like to provide a rejection reason for the message, you will have to view the moderation dashboard.<br />
<br />
=== List Management Overview ===<br />
<br />
The list management overview of the moderation screen is a list of the mailing lists that you moderate. If you click on one of the lists, you will be brought to the individual list management page.<br />
<br />
== List Management ==<br />
<br />
The list management section of PGLister enables a moderator to perform the following actions:<br />
<br />
* View which email addresses are subscribed to the list. This also allows a moderator to unsubscribe email addresses from a list<br />
* Subscribe new email addresses to the list<br />
* Whitelist email addresses that are always allowed to post messages to the list<br />
<br />
=== View/Unsubscribe ===<br />
<br />
The view/unsubscribe portion of the list manager allows a moderator to see who is subscribed to a mailing list and have the option of unsubscribing those email addresses.<br />
<br />
There is a box that allows for a moderator to search for an email address. If nothing is typed into the box, then all email addresses subscribed to that list are displayed in the next view. From there, a moderator can view the email addresses that are subscribed to the list as well as unsubscribe these particular email addresses.<br />
<br />
=== Subscribe ===<br />
<br />
The subscribe section allows a moderator to subscribe an email address to the list. If you are adding an email address using this method, please be sure that the owner of the email address has given you permission to do so as the email address will automatically be subscribed to the mailing list without any additional confirmation.<br />
<br />
=== Whitelist ===<br />
<br />
The whitelist section allows a moderator to manage email addresses that can always post to the particular email list without moderator approval. A moderator can also remove email addresses from the whitelist too. Please use this feature carefully. If you have any questions on how the whitelist works, please send an email to [mailto:sysadmins@postgresql.org sysadmins@postgresql.org].</div>Mhahttps://wiki.postgresql.org/index.php?title=PGLister_Announce&diff=31201PGLister Announce2017-11-21T16:08:15Z<p>Mha: /* Unsubscribing without a community account */</p>
<hr />
<div>{{Languages}}<br />
<br />
The PostgreSQL Infrastructure team will be migrating the project's mailing lists from "majordomo2" (ancient and unmaintained) to "PGLister", a newly developed mailing list system which better addresses the needs of the PostgreSQL community. PGLister is updated to work with recent improvements in email technology and spam filtering. While we have tried to make the changes as minimal as possible, everyone will notice the differences. Below we list the most significant changes.<br />
<br />
== Managing subscriptions and Unsubscribing ([https://lists.postgresql.org/manage here]) ==<br />
<br />
Note that some aspects of subscribing and unsubscribing from the lists change with the new system:<br />
<br />
* PGLister includes a web interface which is greatly improved from the old majordomo2 system. Users can log into the PGLister system using their regular [https://www.postgresql.org/account community accounts].<br />
* The URL for users to manage their subscriptions in PGLister is: [https://lists.postgresql.org/manage https://lists.postgresql.org/manage]<br />
* At this page, users can subscribe, unsubscribe, and adjust parameters associated with their mailing list subscriptions.<br />
* There is also an option at the above URL to have a test email sent from the mailing list system as if it were being sent from the list, to assist users with testing their filter settings.<br />
* List members who do not have a community account may [https://www.postgresql.org/account create an account] and then, through [https://lists.postgresql.org/manage the PGLister web interface], associate their email address(es) with their account.<br />
<br />
== Unsubscribing without a community account ==<br />
<br />
If you do not have a community account, or if you do not wish to use it, you can of course unsubscribe without it. There are two ways to do that:<br />
<br />
* Look in the headers of the email for the header List-Unsubscribe. This header has a link to it, starting with https://lists.postgresql.org/unsub/ and a unique key. Click this link, or copy/paste it into a web browser, and follow the instructions given to confirm the unsubscription.<br />
* Send an email to <list>-unsubscribe@lists.postgresql.org, for example pgsql-general-unsubscribe@lists.postgresql.org. The email must be sent from ''exactly'' the same address that is subscribed. An email with a confirmation link will be generated and sent back within a couple of minutes. Click the link to unsubscribe.<br />
<br />
Please note that if you are subscribed to multiple lists, you will need to unsubscribe from each one of them independently. The unsubscribe link will be different on the different list, and of course the email address contains the list name so it will also be different.<br />
<br />
== Email Filtering ==<br />
<br />
(The examples use pgsql-hackers, but all lists will be affected.)<br />
<br />
* The industry-standard email header <code>List-Id</code> will be set to <code><pgsql-hackers.lists.postgresql.org></code> and is the recommended way to filter messages.<br />
** Non-standard headers will no longer be set.<br />
* The <code>Subject: </code> will no longer be modified to have a <code>[HACKERS]</code> tag inserted.<br />
* See more below.<br />
<br />
== Changes and incompatibilities with majordomo2 ==<br />
<br />
(The examples use pgsql-hackers, but all lists will be affected.)<br />
<br />
* No adjustment of Subject: lines any longer<br />
** The "Subject:" header will no longer be changed to include the name of the list (for example, "[HACKERS]"). This change is to avoid breaking [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail DKIM] (a standard for preventing nefarious changes in email between the sender and the receiver). Not breaking DKIM signed messages will make it less likely that list emails will be classified as spam.<br />
** If you filter your email based on those "Subject:" header insertions, you will need to adjust your filtering rules. We recommend looking at the industry standard "List-Id:" header instead.<br />
<br />
* New email addresses for the lists, although existing email addresses will work for a while<br />
** For example, this means that pgsql-hackers@postgresql.org will change to be pgsql-hackers@'''lists'''.postgresql.org.<br />
** Having a flat namespace for mailing lists, user accounts, and other addresses has been a maintenance issue for the PostgreSQL Infrastructure team. It also prevents us from implementing DKIM on messages from postgresql.org. Moving the lists to "lists.postgresql.org" reduces this burden, allows us to implement DKIM, and allows additional flexibility for handling other lists in the future.<br />
** The existing list email addresses will work for some time, but eventually must be retired for us to realize the maintenance burden reduction.<br />
<br />
* Other email header changes<br />
** The old majordomo2 system used both non-standard and industry standard headers to provide information about which list a given message came from.<br />
** PGLister will use standard, industry-recognized headers to identify mailing list messages. The non-standard header "X-Mailing-List" will no longer be included. Any users whose filters are based on this non-standard header will need to adjust their filters.<br />
** The value of the headers will also be changing, to match the change of list names. The header "List-ID" will be changed from, eg, "List-ID: <pgsql-hackers.postgresql.org>" to "List-Id: <pgsql-hackers.lists.postgresql.org>". (Note that the 'd' is now lowercase also) Users who have filters defined to use this header will need to adjust their filters to account for this change.<br />
** Additional standard headers such as "List-Unsubscribe" will also be set and should work better than the current ones.<br />
** Certain email providers should be able to take advantage of these headers automatically to provide things such as an "Unsubscribe" button, but we cannot guarantee this as it depends on their systems.<br />
<br />
* No more email footers<br />
** The footer text inserted by the old majordomo2 system will no longer be included in each email (the footer is the text which starts with: "Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)"). Removing the footer is necessary to avoid breaking DKIM signed messages as they pass through our system.<br />
<br />
* Cross-posts no longer de-duplicated<br />
** Emails cross-posted to multiple lists will no longer be de-duped, so if posted to two lists the message will be delivered twice. Both copies will have the same message-id (and can be locally de-duplicated on that), but different envelope sender and recipient addresses.<br />
<br />
* The digest capability offered by majordomo2 will not be supported anymore<br />
** This was discussed with a few of the users who use digest and determined to be acceptable.<br />
** Using digest emails also caused problems when a user replies to the digest email.<br />
** There are no plans to implement digest capabilities in PGLister in the future.</div>Mhahttps://wiki.postgresql.org/index.php?title=PGLister_Announce&diff=31198PGLister Announce2017-11-20T20:29:11Z<p>Mha: /* Unsubscribing without a community account */</p>
<hr />
<div>{{Languages}}<br />
<br />
The PostgreSQL Infrastructure team will be migrating the project's mailing lists from "majordomo2" (ancient and unmaintained) to "PGLister", a newly developed mailing list system which better addresses the needs of the PostgreSQL community. PGLister is updated to work with recent improvements in email technology and spam filtering. While we have tried to make the changes as minimal as possible, everyone will notice the differences. Below we list the most significant changes.<br />
<br />
== Managing subscriptions and Unsubscribing ([https://lists.postgresql.org/manage here]) ==<br />
<br />
Note that some aspects of subscribing and unsubscribing from the lists change with the new system:<br />
<br />
* PGLister includes a web interface which is greatly improved from the old majordomo2 system. Users can log into the PGLister system using their regular [https://www.postgresql.org/account community accounts].<br />
* The URL for users to manage their subscriptions in PGLister is: [https://lists.postgresql.org/manage https://lists.postgresql.org/manage]<br />
* At this page, users can subscribe, unsubscribe, and adjust parameters associated with their mailing list subscriptions.<br />
* There is also an option at the above URL to have a test email sent from the mailing list system as if it were being sent from the list, to assist users with testing their filter settings.<br />
* List members who do not have a community account may [https://www.postgresql.org/account create an account] and then, through [https://lists.postgresql.org/manage the PGLister web interface], associate their email address(es) with their account.<br />
<br />
== Unsubscribing without a community account ==<br />
<br />
If you do not have a community account, or if you do not wish to use it, you can of course unsubscribe without it. There are two ways to do it:<br />
<br />
* Look in the headers of the email for the header List-Unsubscribe. This header has a link to it, starting with https://lists.postgresql.org/unsub/ and a unique key. Click this link, or copy/paste it into a web browser, and follow the instructions given to confirm the unsubscription.<br />
* Send an email to <list>-unsubscribe@lists.postgresql.org, for example pgsql-general-unsubscribe@lists.postgresql.org. The email must be sent from ''exactly'' the same address that is sunscribed. An email with a confirmation link will be generated and sent back within a couple of minutes. Click the link to unsubscribe.<br />
<br />
== Email Filtering ==<br />
<br />
(The examples use pgsql-hackers, but all lists will be affected.)<br />
<br />
* The industry-standard email header <code>List-Id</code> will be set to <code><pgsql-hackers.lists.postgresql.org></code> and is the recommended way to filter messages.<br />
** Non-standard headers will no longer be set.<br />
* The <code>Subject: </code> will no longer be modified to have a <code>[HACKERS]</code> tag inserted.<br />
* See more below.<br />
<br />
== Changes and incompatibilities with majordomo2 ==<br />
<br />
(The examples use pgsql-hackers, but all lists will be affected.)<br />
<br />
* No adjustment of Subject: lines any longer<br />
** The "Subject:" header will no longer be changed to include the name of the list (for example, "[HACKERS]"). This change is to avoid breaking [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail DKIM] (a standard for preventing nefarious changes in email between the sender and the receiver). Not breaking DKIM signed messages will make it less likely that list emails will be classified as spam.<br />
** If you filter your email based on those "Subject:" header insertions, you will need to adjust your filtering rules. We recommend looking at the industry standard "List-Id:" header instead.<br />
<br />
* New email addresses for the lists, although existing email addresses will work for a while<br />
** For example, this means that pgsql-hackers@postgresql.org will change to be pgsql-hackers@'''lists'''.postgresql.org.<br />
** Having a flat namespace for mailing lists, user accounts, and other addresses has been a maintenance issue for the PostgreSQL Infrastructure team. It also prevents us from implementing DKIM on messages from postgresql.org. Moving the lists to "lists.postgresql.org" reduces this burden, allows us to implement DKIM, and allows additional flexibility for handling other lists in the future.<br />
** The existing list email addresses will work for some time, but eventually must be retired for us to realize the maintenance burden reduction.<br />
<br />
* Other email header changes<br />
** The old majordomo2 system used both non-standard and industry standard headers to provide information about which list a given message came from.<br />
** PGLister will use standard, industry-recognized headers to identify mailing list messages. The non-standard header "X-Mailing-List" will no longer be included. Any users whose filters are based on this non-standard header will need to adjust their filters.<br />
** The value of the headers will also be changing, to match the change of list names. The header "List-ID" will be changed from, eg, "List-ID: <pgsql-hackers.postgresql.org>" to "List-Id: <pgsql-hackers.lists.postgresql.org>". (Note that the 'd' is now lowercase also) Users who have filters defined to use this header will need to adjust their filters to account for this change.<br />
** Additional standard headers such as "List-Unsubscribe" will also be set and should work better than the current ones.<br />
** Certain email providers should be able to take advantage of these headers automatically to provide things such as an "Unsubscribe" button, but we cannot guarantee this as it depends on their systems.<br />
<br />
* No more email footers<br />
** The footer text inserted by the old majordomo2 system will no longer be included in each email (the footer is the text which starts with: "Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)"). Removing the footer is necessary to avoid breaking DKIM signed messages as they pass through our system.<br />
<br />
* Cross-posts no longer de-duplicated<br />
** Emails cross-posted to multiple lists will no longer be de-duped, so if posted to two lists the message will be delivered twice. Both copies will have the same message-id (and can be locally de-duplicated on that), but different envelope sender and recipient addresses.<br />
<br />
* The digest capability offered by majordomo2 will not be supported anymore<br />
** This was discussed with a few of the users who use digest and determined to be acceptable.<br />
** Using digest emails also caused problems when a user replies to the digest email.<br />
** There are no plans to implement digest capabilities in PGLister in the future.</div>Mhahttps://wiki.postgresql.org/index.php?title=PGLister_Announce&diff=31197PGLister Announce2017-11-20T20:28:39Z<p>Mha: </p>
<hr />
<div>{{Languages}}<br />
<br />
The PostgreSQL Infrastructure team will be migrating the project's mailing lists from "majordomo2" (ancient and unmaintained) to "PGLister", a newly developed mailing list system which better addresses the needs of the PostgreSQL community. PGLister is updated to work with recent improvements in email technology and spam filtering. While we have tried to make the changes as minimal as possible, everyone will notice the differences. Below we list the most significant changes.<br />
<br />
== Managing subscriptions and Unsubscribing ([https://lists.postgresql.org/manage here]) ==<br />
<br />
Note that some aspects of subscribing and unsubscribing from the lists change with the new system:<br />
<br />
* PGLister includes a web interface which is greatly improved from the old majordomo2 system. Users can log into the PGLister system using their regular [https://www.postgresql.org/account community accounts].<br />
* The URL for users to manage their subscriptions in PGLister is: [https://lists.postgresql.org/manage https://lists.postgresql.org/manage]<br />
* At this page, users can subscribe, unsubscribe, and adjust parameters associated with their mailing list subscriptions.<br />
* There is also an option at the above URL to have a test email sent from the mailing list system as if it were being sent from the list, to assist users with testing their filter settings.<br />
* List members who do not have a community account may [https://www.postgresql.org/account create an account] and then, through [https://lists.postgresql.org/manage the PGLister web interface], associate their email address(es) with their account.<br />
<br />
== Unsubscribing without a community account ==<br />
<br />
If you do not have a community account, or if you do not wish to use it, you can of course unsubscribe without it. There are two ways to do it:<br />
<br />
* Look in the headers of the email for the header List-Unsubscribe. This header has a link to it, starting with https://lists.postgresql.org/unsub/ and a unique key. Click this link, or copy/paste it into a web browser, and follow the instructions given to confirm the unsubscription.<br />
* Send an email to <list>-unsubscribe@lists.postgresql.org, for example pgsql-general-unsubscribe@lists.postgresql.org. The email must be sent from *exactly* the same address that is sunscribed. An email with a confirmation link will be generated and sent back within a couple of minutes. Click the link to unsubscribe.<br />
<br />
== Email Filtering ==<br />
<br />
(The examples use pgsql-hackers, but all lists will be affected.)<br />
<br />
* The industry-standard email header <code>List-Id</code> will be set to <code><pgsql-hackers.lists.postgresql.org></code> and is the recommended way to filter messages.<br />
** Non-standard headers will no longer be set.<br />
* The <code>Subject: </code> will no longer be modified to have a <code>[HACKERS]</code> tag inserted.<br />
* See more below.<br />
<br />
== Changes and incompatibilities with majordomo2 ==<br />
<br />
(The examples use pgsql-hackers, but all lists will be affected.)<br />
<br />
* No adjustment of Subject: lines any longer<br />
** The "Subject:" header will no longer be changed to include the name of the list (for example, "[HACKERS]"). This change is to avoid breaking [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail DKIM] (a standard for preventing nefarious changes in email between the sender and the receiver). Not breaking DKIM signed messages will make it less likely that list emails will be classified as spam.<br />
** If you filter your email based on those "Subject:" header insertions, you will need to adjust your filtering rules. We recommend looking at the industry standard "List-Id:" header instead.<br />
<br />
* New email addresses for the lists, although existing email addresses will work for a while<br />
** For example, this means that pgsql-hackers@postgresql.org will change to be pgsql-hackers@'''lists'''.postgresql.org.<br />
** Having a flat namespace for mailing lists, user accounts, and other addresses has been a maintenance issue for the PostgreSQL Infrastructure team. It also prevents us from implementing DKIM on messages from postgresql.org. Moving the lists to "lists.postgresql.org" reduces this burden, allows us to implement DKIM, and allows additional flexibility for handling other lists in the future.<br />
** The existing list email addresses will work for some time, but eventually must be retired for us to realize the maintenance burden reduction.<br />
<br />
* Other email header changes<br />
** The old majordomo2 system used both non-standard and industry standard headers to provide information about which list a given message came from.<br />
** PGLister will use standard, industry-recognized headers to identify mailing list messages. The non-standard header "X-Mailing-List" will no longer be included. Any users whose filters are based on this non-standard header will need to adjust their filters.<br />
** The value of the headers will also be changing, to match the change of list names. The header "List-ID" will be changed from, eg, "List-ID: <pgsql-hackers.postgresql.org>" to "List-Id: <pgsql-hackers.lists.postgresql.org>". (Note that the 'd' is now lowercase also) Users who have filters defined to use this header will need to adjust their filters to account for this change.<br />
** Additional standard headers such as "List-Unsubscribe" will also be set and should work better than the current ones.<br />
** Certain email providers should be able to take advantage of these headers automatically to provide things such as an "Unsubscribe" button, but we cannot guarantee this as it depends on their systems.<br />
<br />
* No more email footers<br />
** The footer text inserted by the old majordomo2 system will no longer be included in each email (the footer is the text which starts with: "Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)"). Removing the footer is necessary to avoid breaking DKIM signed messages as they pass through our system.<br />
<br />
* Cross-posts no longer de-duplicated<br />
** Emails cross-posted to multiple lists will no longer be de-duped, so if posted to two lists the message will be delivered twice. Both copies will have the same message-id (and can be locally de-duplicated on that), but different envelope sender and recipient addresses.<br />
<br />
* The digest capability offered by majordomo2 will not be supported anymore<br />
** This was discussed with a few of the users who use digest and determined to be acceptable.<br />
** Using digest emails also caused problems when a user replies to the digest email.<br />
** There are no plans to implement digest capabilities in PGLister in the future.</div>Mhahttps://wiki.postgresql.org/index.php?title=Postgres_Open_2017&diff=30778Postgres Open 20172017-09-07T23:45:16Z<p>Mha: /* Cyril Magnin */</p>
<hr />
<div>Conference website: [http://2015.postgresopen.org/ PostgresOpen 2017]<br />
<br />
[https://postgresopen.org/events/feedback/pgopen2017/ Conference Feedback]<br />
<br />
Events shown for placeholding purposes. See the "Editing help" for instructions on how to add a link to your slides.<br />
<br />
== Wednesday September 6 (Tutorials) ==<br />
<br />
== Thursday September 7 ==<br />
=== Cyril Magnin ===<br />
* [https://www.hagander.net/talks/PostgreSQL_10.pdf A look at the Elephants trunk - PostgreSQL 10] (Magnus Hagander)<br />
* Postgres Window Magic (Bruce Momjian)<br />
* Schrödinger's Elephant (Josh Berkus)<br />
* PgBouncer and 20000 TPS at one node: advanced tuning, hacks and problem solving (Victor Yagofarov)<br />
* An ultimate guide to upgrading your PostgreSQL installation (Ilya Kosmodemiansky)<br />
<br />
=== Market Street ===<br />
* [http://anarazel.de/talks/pgopen-sf-2017-09-07/efficiency.pdf Improving postgres' efficiency] (Andres Freund)<br />
* [https://www.joeconway.com/presentations/SecurePostgreSQL-PGOpen2017.pdf Securing PostgreSQL -- Exploring the PostgreSQL STIG and Beyond] (Joe Conway)<br />
* Concurrency Deep-Dive (Tejas Manohar)<br />
* Human Beings Do Not Have a Primary Key (Christophe Pettus)<br />
* PostgreSQL BI Performance & News from XL project (Mark Wong)<br />
<br />
=== Mission ===<br />
* Get to know Google Cloud SQL (Alexis Guajardo, Brett Hesterberg)<br />
* Developing powerful and intelligent apps using the Azure managed PostgreSQL service (Sunil Kamath)<br />
* Monitoring 101 (Jason Yee)<br />
* Best practices of using a managed PostgreSQL in the cloud (Jignesh Shah)<br />
* Distributed COUNT(DISTINCT) with HyperLogLog on PostgreSQL (Burak Yucesoy)<br />
<br />
== Friday September 8 ==<br />
<br />
=== Cyril Magnin ===<br />
* PastgreSQL: Dead data tells all tales! (Samuel Elston, Srivathsava Rangarajan)<br />
* PanLex: Using PostgreSQL to implement a massive word-translation graph (David Kamholz)<br />
* Tuning PostgreSQL for High Write Workloads (Grant McAlister)<br />
* Replication based Multi-Master solutions and design patterns (Tom Kincaid)<br />
* How Postgres Could Index Itself (Andrew Kane)<br />
* Logical Replication.... LIVE! (Robert Treat)<br />
<br />
=== Market Street ===<br />
* The Immortal Postgres Web (Shaun Thomas)<br />
* Scaling a Saas application beyond a single Postgres with Citus. (Jesse H. Willett)<br />
* Scalable in-database machine learning with PL/Python (Srivatsan Ramanujam)<br />
* Enhancements to the bitemporal model support: integrity constraints (Boris Novikov, Chad Slaughter, Henrietta Dombrovskaya)<br />
* Beyond Foreign Data Wrappers: building a data warehouse from heterogeneous external data sources (Chad Slaughter)<br />
* PostgreSQL, REST API’s and Rapid Application Development for Legacy Data (Charles Finley)<br />
<br />
=== Mission ===<br />
* A Kubernetes Operator for PostgreSQL - Architecture and Design (Sarah Conway)<br />
* ETL Confessions (Corey Huinker)<br />
* PostgreSQL Security for Application Developers (Sehrope Sarkuni)<br />
* Your database migrations are bad and you should feel bad (Robert Lechte)<br />
* PostgreSQL as a distributed computing platform (Marco Slot)<br />
* PostgreSQL at Pandora (Stephen Rees)</div>Mhahttps://wiki.postgresql.org/index.php?title=PGLister_Announce&diff=30330PGLister Announce2017-06-07T13:41:09Z<p>Mha: /* PGLister Announcement */</p>
<hr />
<div>== PGLister Announcement ==<br />
<br />
The PostgreSQL Infrastructure team will be migrating the project's mailing lists from the existing system (an ancient and unmaintained piece of software called "majordomo2") to a newly developed mailing list system (known as "PGLister"), which better addresses the needs of the PostgreSQL community and is updated to work with recent improvements in email technology and spam filtering. These changes will impact certain aspects of the system but we are hopeful that these changes will have a minimal impact on users, although everyone will notice the differences. The changes below are the ones we expect to be most significant to users.<br />
<br />
'''Note that the pgsql-hackers email list is used in examples below, but this change applies to all project mailing lists.'''<br />
<br />
* No adjustment of Subject: lines any longer<br />
** The "Subject:" header will no longer be changed to include the name of the list (for example, "[HACKERS]"). This change is to avoid breaking [https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail DKIM] (a standard for preventing nefarious changes in email between the sender and the receiver by calculating a hash of certain headers and the body). Not breaking DKIM signed messages will make it less likely that emails sent through our mailing lists will be classified as spam.<br />
** If you filter your email based on those "Subject:" header insertions, you will need to adjust your filtering rules. We recommend looking at the industry standard "List-ID:" header instead.<br />
<br />
* New email addresses for the lists, although existing email addresses will work for a while<br />
** For example, this means that pgsql-hackers@postgresql.org will change to be pgsql-hackers@'''lists'''.postgresql.org.<br />
** Having a flat namespace that both lists and user accounts, as well as other addresses, live in has been a maintenance issue for the PostgreSQL Infrastructure team. It also prevents us from implementing DKIM on messages from postgresql.org. Moving the lists to "lists.postgresql.org" reduces this burden, allows us to implement DKIM, and allows additional flexibility for handling other lists in the future.<br />
** The existing list email addresses will work for some time, but eventually must be retired for us to realize the maintenance burden reduction.<br />
<br />
* Other email header changes<br />
** The old majordomo2 system used both non-standard and industry standard headers to provide information about which list a given message came from.<br />
** PGLister will use standard, industry-recognized headers to identify mailing list messages. The non-standard header "X-Mailing-List" will no longer be included. Any users whose filters are based on this non-standard header will need to adjust their filters.<br />
** The value of the headers will also be changing, to match the change of list names. The header "List-ID" will be changed from, eg, "List-ID: <pgsql-hackers.postgresql.org>" to "List-ID: <pgsql-hackers.lists.postgresql.org>". Users who have filters defined to use this header will need to adjust their filters to account for this change.<br />
** Certain email providers should be able to take advantage of these headers automatically to provide things such as an "Unsubscribe" button, but we cannot guarantee this as it depends on their systems.<br />
<br />
* Email footer removal<br />
** The footer text inserted by the old majordomo2 system will no longer be included in each email (the footer is the text which starts with: "Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)"). Removing the footer is necessary to avoid breaking DKIM signed messages as they pass through our system.<br />
<br />
* Cross-posts not de-duped<br />
** Emails cross-posted to multiple lists will no longer be de-duped, so if posted to two lists the message will be delivered twice. Both copies will have the same message-id (and can be locally de-duplicated on that), but different envelope sender and recipient addresses.<br />
<br />
* Managing subscriptions and unsubscribing<br />
** PGLister includes a web interface which is greatly improved from the old majordomo2 system. Users can log into the PGLister system using their regular [https://www.postgresql.org/account community accounts].<br />
** The URL for users to manage their subscriptions in PGLister is: [https://lists.postgresql.org/manage https://lists.postgresql.org/manage]<br />
** At this page, users can subscribe, unsubscribe, and adjust parameters associated with their mailing list subscriptions.<br />
** There is also an option at the above URL to have a test email sent from the mailing list system as if it were being sent from the list, to assist users with testing their filter settings.<br />
** List members who do not have a community account may [https://www.postgresql.org/account create an account] and then, through the PGLister web interface, associate their email address(es) with their account.<br />
<br />
* The digest capability offered by majordomo2 will not be supported anymore<br />
** This was discussed with a few of the users who use digest and determined to be acceptable.<br />
** Using digest emails also caused problems when a user replies to the digest email.<br />
** There are no plans to implement digest capabilities in PGLister in the future.</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_10_Open_Items&diff=30279PostgreSQL 10 Open Items2017-05-31T19:03:17Z<p>Mha: </p>
<hr />
<div>== Open Issues ==<br />
<br />
=== Logical Replication ===<br />
<br />
unless otherwise marked, original commit: {{PgCommitURL|665d1fa}} (principal author: Petr Jelinek; owner: Peter Eisentraut)<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoBYpyqTSw%2B%3DES%2BxXtRGMPKh%3DpKiqjNxZKnNUae0pSt9bg%40mail.gmail.com Dropping subscription may stuck if done during tablesync]<br />
** owner: RMT<br />
** Analyze deadlock issues with DROP SUBSCRIPTION and apply worker process<br />
** Avoid orphaned tablesync worker if apply worker exits before<br />
** Patch series exists<br />
<br />
* [https://www.postgresql.org/message-id/20170421014030.fdzvvvbrz4nckrow@alap3.anarazel.de Query handling in Walsender is somewhat broken]<br />
** original commit: {{PgCommitURL|7c4f524}} (principal author: Petr Jelinek; owner: Peter Eisentraut {{messageLink|20170530020128.GD135259@gust.leadboat.com|notified}})<br />
** patch was proposed<br />
<br />
* [https://www.postgresql.org/message-id/29009.1491936023@sss.pgh.pa.us Background worker display in pg_stat_activity (logical replication especially)]<br />
** {{messageLink|20170530020932.GA116176@gust.leadboat.com|notified}}<br />
<br />
* [https://www.postgresql.org/message-id/64530.1495454510@sss.pgh.pa.us need to widen prohibitions on publish/subscribe of system objects]<br />
** {{messageLink|20170530021450.GB116176@gust.leadboat.com|notified}}<br />
<br />
* [http://postgr.es/m/CA+q6zcXQqHqhiFR-eLvVk+x9CvPLvJotyqQ77Q1U_4Uj+BLW4g@mail.gmail.com Create subscription with `create_slot=false` and incorrect slot name] should ERROR<br />
** {{messageLink|20170530022604.GE116176@gust.leadboat.com|notified}}<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoB2ZbCCqOx%3DbgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA%40mail.gmail.com Replication status in logical replication]<br />
** {{messageLink|20170530025638.GF116176@gust.leadboat.com|notified}}<br />
** patch exists<br />
<br />
* [https://www.postgresql.org/message-id/2b89dc87-8093-013a-0b83-2bb4b0b04d56%40enterprisedb.com ALTER SUBSCRIPTION REFRESH and table sync worker]<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoBzQP%3DSs6dVtDrBUWG%2BiVmdoQB%3DjWnycd1ALesW%2BhpMoQ%40mail.gmail.com "create publication..all tables" ignore 'partition not supported' error]<br />
** patch exists<br />
<br />
=== Other ===<br />
<br />
* [http://postgr.es/m/CA+TgmoZzTBBAsEUh4MazAN7ga=8SsMC-Knp-6cetts9yNZUCcg@mail.gmail.com transition table behavior with inheritance appears broken]<br />
** original commit: {{PgCommitURL|5970271}} (principal author: Kevin Grittner; owner: Kevin Grittner, {{messageLink|20170506185437.GH843225@rfd.leadboat.com|notified}})<br />
** patch exists<br />
<br />
* [http://postgr.es/m/CAB7nPqQO9RijoeCYxY74v0eFq7jiLHWSy_eiidPqC1f1toFyfA@mail.gmail.com libpq misses cleanup of SASL context with sslmode=prefer]<br />
** original commit: {{PgCommitURL|505b5d2}} (principal author: Michael Paquier; owner: Heikki Linnakangas {{messageLink|20170530030447.GG116176@gust.leadboat.com|notified}})<br />
** patch exists<br />
<br />
* [http://postgr.es/m/CA+mi_8aZYLhuyQi1Jo0hO19opNZ2OEATEOM5fKApH7P6zTOZGg@mail.gmail.com Fix incorrect error message string in auth-scram.c] (author: Michael Paquier, Heikki Linnakangas; owner: Heikki Linnakangas)<br />
<br />
* [https://www.postgresql.org/message-id/21809.1495994606@sss.pgh.pa.us const-simplification of SRF calls now has user-visible effects]<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqSTsnK+b53s-NZUuTPosJmjbV+zKHV3zHr7K6ZKFMVY_A@mail.gmail.com Fix WAL receiver spinlock use].<br />
** original commit: {{PgCommitURL|b1a9bad}} (principal author: Michael Paquier; owner: Álvaro Herrera)<br />
** ready_to_display should be protected by the WAL sender's spinlock.<br />
** pg_stat_get_wal_receiver should look at the WAL receiver PID after taking a spin lock.<br />
<br />
== Decisions to Recheck Mid-Beta ==<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com Which synchronous replication method, priority or quorum, should be chosen when neither FIRST nor ANY is specified in synchronous_standby_names?]<br />
** original commit: {{PgCommitURL|3901fd7}} (principal author: Masahiko Sawada; owner: Fujii Masao)<br />
** Right now, a priority-based sync replication is chosen for keeping backward compatibility. However some hackers argued to change this decision so that a quorum commit is chosen because they think that most users prefer to a quorum.<br />
<br />
* [https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D1F6F5659%40G01JPEXMBYT05 Cannot connect to alternative hosts when non-socket level connection error occurs]<br />
** patch exists<br />
** This is a matter of prioritizing either of service continuity or configuration error detection. Continue considering what to do based on user feedback during beta period, other developers' opinions, and the solution using SQLSTATE.<br />
<br />
* Add migration instructions encouraging migration from MD5 to SCRAM once we know the state of drivers; see [https://www.postgresql.org/message-id/CA+Tgmob0HareNtnp1sV2ZjFVZ_1WkaWptey53hF5cfcLzYz3hA@mail.gmail.com post]<br />
<br />
== Older Bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/c2c7191b-5ca0-b37a-9e9d-4df15ffb554b%40lab.ntt.co.jp Oddity in EXPLAIN for foreign/custom join pushdown plans]<br />
** postgres_fdw produces incorrect aliases for joining relations shown in EXPLAIN for some join pushdown queries<br />
** [https://www.postgresql.org/message-id/b4b04e83-5eb4-7dd6-2951-32acadea4e7b@lab.ntt.co.jp low-priority issue; let's leave this for v10]<br />
** regression in v9.6, nothing changed from v9.6 beta to v10 beta<br />
<br />
* [https://www.postgresql.org/message-id/20170117.193645.160386781.horiguchi.kyotaro@lab.ntt.co.jp standby can fail to reconnect even with replication slots]<br />
** patch exists<br />
** present in 9.4 and later<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1wXkKUKBHWBYzET3D9OViyDg8DcVL-wKEqk2uyoMrzr_A@mail.gmail.com Crash recovery can leave everlasting empty pages]<br />
** The pages are actually empty but FSM says that they have no room for new data and ALL_FROZEN. ALL_FROZEN prevents autovacuum from fixing FSM.<br />
** regression in v9.6, nothing new in v10<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqR82_57C8O1+z-bUChhHpdjMec_omLfKwYdjAFjjcrBWg@mail.gmail.com Switch use of "encrypted" to "hash" for passwords in documentation]<br />
<br />
* [https://www.postgresql.org/message-id/4905.1492813727@sss.pgh.pa.us parallel query locks up if worker process fails to launch]<br />
** code is broken since birth, but do we really want to ship v10 like this?<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwEsttg9P9LOOavoc9d6VB1zVmYgfBk=Ljsk-UL9cEf-eA@mail.gmail.com logical replication and PANIC during shutdown checkpoint in publisher]<br />
** Also affects v9.4-v9.6 but v10 can trigger it from more places<br />
** major part fixed by commit 086221cf6b1727c2baed4703c582f657b7c5350e<br />
** remaining concern: HOT pruning during logical decoding might generate WAL (patch exists)<br />
<br />
* [https://www.postgresql.org/message-id/CAA4eK1JMHh_06gk5GFRkL2RYivwPAsS85zuvqOmG86MeOxFR1g%40mail.gmail.com retry shm attach for Windows to mitigate the impact of ASLR]<br />
** code is in the same state from previous releases, but it seems advisable to fix it for v10?<br />
<br />
== Non-bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/20170321135742.GB23103@e733.localdomain Errors with valgrind]<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqSP+MHqg=dKoNOZu75j2mGAEW622GYz45Mv2V_XOao-9g@mail.gmail.com CREATE/ALTER ROLE PASSWORD ('value' USING 'method')], extension of this DDL to enforce type of password without changing password_encryption.<br />
** Not Open-Item worthy, let's do this in v11 if it still feels worthwhile then.<br />
<br />
* [https://www.postgresql.org/message-id/CA+TgmoYrA8SK=KjkVbvKt8hG3Cqsjr-Hnmwa3WXqbziRuwKBLg@mail.gmail.com Declarative partitioning vs. information_schema, etc.]<br />
** include partitions in information_schema.tables, pg_tables, and psql's \d listing, etc?<br />
** firm support for status quo, lack of firm support for alternatives<br />
<br />
* [https://www.postgresql.org/message-id/071086d7-6462-f0e7-54ca-b633062e317c%40lab.ntt.co.jp Document that foreign table's partition constraint is not enforced locally]<br />
** Patch exists<br />
** documentation is correct, but this would add emphasis to a point<br />
<br />
* [https://postgr.es/m/CAGPqQf3joLrjmR2FmQzYURb-_TxhW78tXhgYm+C66wXNjWH9ww@mail.gmail.com Query fails when SRFs are part of FROM clause]<br />
** original commit: {{PgCommitURL|69f4b9c}} (principal author: Tom Lane; owner: Andres Freund {{messageLink|20170405064755.GA2702846@tornado.leadboat.com|notified}})<br />
** owner [https://www.postgresql.org/message-id/20170412225855.oklyfkbwj2dmbrpu@alap3.anarazel.de proposes] classifying this as a non-bug<br />
** Commit e240a65c7dfc5ad80ab757ecb1aa9b9032c7f8ae improved error reporting<br />
<br />
* [https://www.postgresql.org/message-id/a162fe00-5665-2a77-4b7a-9f7293f64db0%40lab.ntt.co.jp pg_dump should expand partitioned tables when specified using --table and --exclude options]<br />
** Patch exists<br />
** [http://postgr.es/m/CA+TgmoazyEb9mdL3yJkWRHHtcOFBzZDE_ESgq8iE22gPpdML-w@mail.gmail.com not really a bug, and should inheritance behavior also be changed?]<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqSKhOpEOeRQB4pTe5zSBiwbDsfM4jh0nFdcd6LjkMQ-Pg@mail.gmail.com Simplify password hook by removing password_type]<br />
** original commit: {{PgCommitURL|eb61136}} (principal author: Heikki Linnakangas; owner: Heikki Linnakangas {{messageLink|20170515040315.GQ843225@rfd.leadboat.com|notified}})<br />
** Not worth changing the hook signature.<br />
<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 10beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1zMLnH_i1-PVQ-biZzvNx7VcuatriquEnh7HNk6K8Ss3Q@mail.gmail.com PANIC in pg_commit_ts slru after crashes, 2PC restore code at fault]<br />
** Fixed by commit aa203e76004daaee3d70b19cc727ed17b87b3d3a<br />
** Fixed by commit ee01f7092fb6430ad9bb9bb1f42f19d22bcb9329<br />
<br />
* [https://www.postgresql.org/message-id/8a1d4662-9665-59d5-518d-45616b75f06a%40lab.ntt.co.jp COMMENT ON COLUMN fails for partitioned tables]<br />
** Fixed by commit 51175f3638524231405e674e40bde159b0b76727<br />
<br />
* [http://postgr.es/m/CAKJS1f-BmGo410bh5RSPZUvOO0LhmHL2NYmdrC_Jm8pk_FfyCA@mail.gmail.com Allowing extended stats on foreign and partitioned tables]<br />
** original commit: {{PgCommitURL|7b504eb}} (principal author: Tomas Vondra; owner: Alvaro Herrera {{messageLink|20170414055310.GE2870454@tornado.leadboat.com|notified}})<br />
** Fixed by commit 8c5cdb7f4f6e1d6a6104cb58ce4f23453891651b<br />
<br />
* [https://www.postgresql.org/message-id/12642.1491513976@sss.pgh.pa.us Partitioning optimization broke ConvertRowtypeExpr]<br />
** Fixed by commit 3f902354b08ac788600f0ae54fcbfc1d4e3ea765.<br />
<br />
* Integer overflow in enlargeStringInfo<br />
** {{messageLink|1706e85e-60d2-494e-8a64-9af1e1b2186e@manitou-mail.org|thinko in overflow logic}}<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1yURZZONoeLXhPsp2AkqR5MNAXiCiTVnrt2LGd6qD1b8w@mail.gmail.com pg_upgrade is broken because of renaming of pg_resetxlog to pg_resetwal]<br />
** Fixed by commit b877761.<br />
<br />
* [https://www.postgresql.org/message-id/flat/1803D792815FC24D871C00D17AE95905AC5FAE@g01jpexmbkw24#1803D792815FC24D871C00D17AE95905AC5FAE@g01jpexmbkw24 PQsendQuery fails when it should not if target_session_attrs is set to read-write]<br />
** Fixed by commit 1de0a4e.<br />
<br />
* [https://www.postgresql.org/message-id/CAM2+6=U72y2_Jni2p+meqTvvk=r_=Wd4orvzz5YL0b3WFx+gcA@mail.gmail.com Substantial bloat in postgres_fdw regression test runtime]<br />
** Fixed by commit aa7f593b1ffa9717bd5570174944c06c482d1c1f.<br />
<br />
* [https://www.postgresql.org/message-id/9f9dc7ae-14f0-4a25-5485-964d9bfc19bd%40lab.ntt.co.jp Error detail shown when partition not found]<br />
** Fixed by commit 5a73e17317e91912b2755f7960d5bf31d374cf31.<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoD%2BVO93zZ4ZQtZQb-jZ_wMko3OgGdx1MXO4T%2B8q_zHDDA%40mail.gmail.com DROP SUBSCRIPTION and ROLLBACK]<br />
** Fixed by commit 272adf4f9cd67df323ae57ff3dee238b649d3b73.<br />
<br />
* [https://www.postgresql.org/message-id/6c420206-45d7-3f56-8325-4bd7b76483ba%40lab.ntt.co.jp Dropping partitioned tables without CASCADE]<br />
** Fixed by commit 8b4d582d279d784616c228be58af1e39aa430402.<br />
<br />
* [https://www.postgresql.org/message-id/CAEepm=15e9L695yVCO-_OkBVbsPupyXqzYWzzDmj-bdJ6o2+Pw@mail.gmail.com pg_recvlogical.c doesn't build with --disable-integer-datetimes]<br />
** Fixed by commit b6aa17e0ae367afdcea07118e016111af4fa6bc3 and c29aff959dc64f7321062e7f33d8c6ec23db53d3<br />
<br />
* [https://www.postgresql.org/message-id/20170207201932.GH9812@tamriel.snowman.net pg_dump and PUBLICATIONS]<br />
** Fixed by commit 05227e0c345247c9e9ff91445850f414e2b0bb70<br />
<br />
* [https://www.postgresql.org/message-id/CA+TgmoYpwN0AkaCqhAEVuxtHqGkz=yJzgQxbvucEQMPE-tLkEA@mail.gmail.com simplehash performance regressions]<br />
** Fixed by commit d4c62a6b623d6eef88218158e9fa3cf974c6c7e5<br />
<br />
* [https://www.postgresql.org/message-id/CAGz5QCLJJ1NhVQjQSreF-UoQyVoN6Krg54gZrr5-Ha5PqP2ksw@mail.gmail.com exposing wait events for non-backends]<br />
** Fixed by commit fc70a4b0df38bda6a13941f1581f25fbb643c7f3<br />
<br />
* [https://www.postgresql.org/message-id/b3d37313-acf0-d8fd-783f-c32f7c0667e6@lab.ntt.co.jp Partitioning vs INSERT ON CONFLICT]<br />
** Fixed by commit 8355a011a0124bdf7ccbada206a967d427039553<br />
** [https://www.postgresql.org/message-id/ff3dc21d-7204-c09c-50ac-cf11a8c45c81%40lab.ntt.co.jp Crash when leaf partition has an index]<br />
*** Reverted by commit f05230752d53c4aa74cffa9b699983bbb6bcb118<br />
<br />
* [https://www.postgresql.org/message-id/c72cbc58-9866-0622-86c1-f01cc4064e73%40lab.ntt.co.jp Bug in list partitioning tuple-routing]<br />
** Fixed by commit 7ecb7143589f38d679bb566311dfa9be1a650fd5<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU%3D1w-9Qe%3DFf1o6bSaXpNO9wqpo7_9GL8_CVhw4BoVVHasqg%40mail.gmail.com segfault in hot_standby for hash indexes]<br />
** Fixed by commit c4c51541e22bf7f2da8ecf6986271687b0d7a90e<br />
<br />
* [https://www.postgresql.org/message-id/CAEepm%3D23%3DvGz%3DCgVurPxBGV6SeOJ7YxSaAJKr_aH%2Bf2cV4zrow%40mail.gmail.com attaching to DSA area that was already destroyed]<br />
** Fixed by commit fddf45b38097d14301d249fbeebca32e40233bd2<br />
<br />
* postgres_fdw, partitioned tables and IMPORT SCHEMA<br />
** [https://postgr.es/m/20170309141531.GD9812@tamriel.snowman.net postgres_fdw IMPORT SCHEMA and partitioned tables]<br />
** Fixed by commit f49bcd4ef3e9a75de210357a4d9bbe3e004db956<br />
<br />
* [https://www.postgresql.org/message-id/2b0d42f2-3a53-763b-c9c2-47139e4b1c2e@lab.ntt.co.jp Partitioning tables create a file on-disk, which remains empty and has no purpose. Those relations don't need any storage]<br />
** Fixed by commit c94e6942cefe7d20c5feed856e27f672734b1e2b<br />
<br />
* [https://www.postgresql.org/message-id/a6f99cdb-21e7-1d65-1381-91f2cfa156e2%40lab.ntt.co.jp Documentation improvements for partitioning]<br />
** Fixed by commit 8f18a880a5f138d4da94173d15514142331f8de6<br />
<br />
* [https://www.postgresql.org/message-id/6ecd6f17-0dcf-1de7-ded8-0de7db1ddc88%402ndquadrant.com crashes due to setting max_parallel_workers=0]<br />
** Fixed by commit 25dc142a49c60c3107480c487cd8444dc83f9bdf<br />
<br />
* [https://www.postgresql.org/message-id/CAE9k0P%3DV2LhtyeMXd295fhisp%3DNWUhRVJ9EZQCDowWiY9rSohQ%40mail.gmail.com Failed assertion in _hash_kill_items/MarkBufferDirtyHint]<br />
** Fixed by commit 93cd7684ee2bba227fa371daa81b88f25456dcb2<br />
<br />
* [https://www.postgresql.org/message-id/CAE9k0PnmPDXfvf8HDObme7q_Ewc4E26ukHXUBPySoOs0ObqqaQ%40mail.gmail.com inconsistent page found on STANDBY server]<br />
** Fixed by commit 75a1cbdc3cfca1e815da6dfa5d7e96d82a6b0725<br />
<br />
* [https://www.postgresql.org/message-id/CAA4eK1%2BVE_TDRLWpyeOf%2B7%2B6if68kgPNwO4guKo060rm_t3O5w%40mail.gmail.com page inspect to show appropriate type of page]<br />
** Fixed by commit 633e15ea0f1bf2e1d70441fe9da8781befebd6e9<br />
<br />
* [https://www.postgresql.org/message-id/20170321.192419.96677899.horiguchi.kyotaro%40lab.ntt.co.jp Logical replication between differrent encodings fails]<br />
** Fixed by commit 6f1b9aaae35bfabe2654a8e44ce226c91e7d8bd9<br />
<br />
* [https://www.postgresql.org/message-id/20170331185540.zmsue4ndvqtnayqw@alap3.anarazel.de improve test coverage of parallel explain analyze]<br />
** Fixed by commit b2ff37d43cc81348fd8e9d9c5fcc9dfadf790763<br />
<br />
* [https://www.postgresql.org/message-id/20170331184603.qcp7t4md5bzxbx32@alap3.anarazel.de improve test coverage of parallel bitmap scan]<br />
** Fixed by commit 5a5931533edd2b70bde1f069609f58998dd26fef<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqSByyEmAVLtEf1KxTRh=PWNKiWKEKQR=e1yGehz=wbymQ@mail.gmail.com SASLprep]<br />
** Fixed by commit 60f11b87a2349985230c08616fa8a34ffde934c8<br />
<br />
* [https://www.postgresql.org/message-id/CA+TgmoZfPOu62bR71bahf90ivOUxXpYOh0RqDiue0+dVVPNrWg@mail.gmail.com dsa.c needs a visit from the message style police]<br />
** Fixed by commit 5c4488478b182983f290a61fc8cf2ec83548622b<br />
<br />
* [https://www.postgresql.org/message-id/20170316085322.crffknkgee5s6air@alap3.anarazel.de Logical replication + EXEC_BACKEND + ASLR is broken]<br />
** Fixed by commit 0ef26bb394abedb2745bd838c26ecb3131682bda<br />
<br />
* [https://www.postgresql.org/message-id/b3a17254-6849-e542-2353-bde4e880b6a4%40lab.ntt.co.jp Reconsider the error detail shown when ExecConstraints() fails after tuple-routing]<br />
** original commit: {{PgCommitURL|f1b4c77}} (principal author: Amit Langote; owner: Robert Haas {{messageLink|20170409235426.GB2842536@tornado.leadboat.com|notified}})<br />
** Fixed by commit c0a8ae7be392aa09dd7e148ff662013e8e148893<br />
<br />
* [https://www.postgresql.org/message-id/13592.1490851519@sss.pgh.pa.us Broken locking design for accesses to pg_subscription_rel]<br />
** Fixed by commit 521fd4795e3ec3d0b263b62e5eb58e1557be9c86<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwHEs8jT_6DjYHYmsD2v-rOudstiBB_mtmZbR9Z2QfhCwQ@mail.gmail.com Both launcher and worker don't handle SIGHUP signal and cannot reload the configuration]<br />
** Fixed by commit 26ad194cb0a6b955e155d44fb52a74212ce85759<br />
<br />
* pg_dump and data durability, with addition of --no-sync option<br />
** original commit: {{PgCommitURL|96a7128}} (principal author: Michael Paquier; owner: Andrew Dunstan {{messageLink|20170405064941.GB2702846@tornado.leadboat.com|notified}})<br />
** [https://www.postgresql.org/message-id/CAB7nPqTUOpF792rDOnBkswZ%3DZgHwxdB01OQU2tAF1KU4iUuLrw%40mail.gmail.com Regression tests should use --no-sync as much as possible]<br />
** Fixed by commit 3820c63da8d0e59e2bd4476e91968f03be5dd041<br />
<br />
* [http://postgr.es/m/CAMkU=1zrQaPwBN+NcBd3pWCb=vWaiL=mmWfJjDJjh-a7eVr-Og@mail.gmail.com pgbench --progress-timestamp no longer works correctly]<br />
** original commit: {{PgCommitURL|1d63f7d}} (principal author: Tom Lane; owner: Tom Lane {{messageLink|20170411042352.GA2870454@tornado.leadboat.com|notified}})<br />
** Fixed by commit feffa0e0795a5a99324890a6dd548ba162ec104c<br />
<br />
* [https://www.postgresql.org/message-id/29588799-a8ce-b0a2-3dae-f39ff6d35922%40lab.ntt.co.jp Dropping a partition may cause deadlock]<br />
** {{PgCommitURL|f0e4475}} (principal author: Amit Langote; owner: Robert Haas {{messageLink|20170409235729.GA2842636@tornado.leadboat.com|notified}})<br />
** Fixed by commit 258cef12540fa1cb244881a0f019cefd698c809e<br />
<br />
* [https://www.postgresql.org/message-id/CAFiTN-suK%2BMod_noGy8LpmkSzgvzwhGfNZ0K6vf_gX6rkw2jxA%40mail.gmail.com Problem in Parallel Bitmap Heap Scan]<br />
** original commit: {{PgCommitURL|f35742c}} (principal author: Dilip Kumar; owner: Robert Haas {{messageLink|20170410031734.GB2845039@tornado.leadboat.com|notified}})<br />
** Fixed by commit 4c3b59abf4c476843bca23de7fb66d647627f30e<br />
<br />
* [https://www.postgresql.org/message-id/flat/24a143e0-c9bb-8f4f-1472-9d6faae4c92e%402ndquadrant.com#24a143e0-c9bb-8f4f-1472-9d6faae4c92e@2ndquadrant.com strange parallel query behavior after OOM crashes]<br />
** original commit: {{PgCommitURL|b460f5d}} (principal author: Julien Rouhaud; owner: Robert Haas {{messageLink|20170410031836.GC2845004@tornado.leadboat.com|notified}})<br />
** Fixed by commit 8ff518699f19dd0a5076f5090bac8400b8233f7f<br />
** See also commit 6599c9ac3340b6cd3d86a0a7f866b80a009fecab which attempts to catch other problems of this sort<br />
<br />
* [https://www.postgresql.org/message-id/52d9c443-ec78-5c8a-7a77-0f34aad12b82%40lab.ntt.co.jp RENAME RULE doesn't work with partitioned tables]<br />
** Fixed by commit 02af7857e5694b13c21401d1982ac21d31e27dee<br />
<br />
* [https://postgr.es/m/20170309144718.GE9812@tamriel.snowman.net sepgsql and partitioned tables]<br />
** {{messageLink|CA+TgmobTJnasxpRkJxGcHaz85LyqdXBKZRxP6pCCS-UkhcHUBQ@mail.gmail.com|feature request, not bug}}<br />
** implemented in {{PgCommitURL|25542d77dd549940468d1a932809feb9959d717d}}<br />
<br />
* [https://www.postgresql.org/message-id/b7578aaf-726e-61a1-0011-943e92ad08ee@2ndquadrant.com error handling in RegisterBackgroundWorker]<br />
** withdrawn<br />
<br />
* [https://www.postgresql.org/message-id/CA%2BTgmobYfFRtcXv1aoXD18%2BRkPU%3Duw39Ajqm1HWyh7V_8QYZ%3DA%40mail.gmail.com pgstathashindex() to handle unused pages in hash index]<br />
** original commit: {{PgCommitURL|e759854}} (principal author: Ashutosh Sharma; owner: Robert Haas {{messageLink|20170412062802.GB2870454@tornado.leadboat.com|notified}})<br />
** Fixed by commit 9cc27566c1a8d659c15b9eea2413dcc07a7a42c9<br />
<br />
* [https://www.postgresql.org/message-id/30972.1491937807@sss.pgh.pa.us Mishandling of non-parallel-safe initplans/subplans in a parallelized query]<br />
** original commit: {{PgCommitURL|5e6d8d2bb}}<br />
** Fixed by commit 16ebab68862bb5d3595b8c8df083f650d9d7cd20<br />
<br />
* [https://www.postgresql.org/message-id/20170217020415.GI9812@tamriel.snowman.net pg_dump and SUBSCRIPTIONS]<br />
** fixed by commits c31671f9b5f6eee9b6726baad2db1795c94839d1, a9254e675bde7dc2d976d207450c559d914c0dd6<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqS-aFg0iM3AQOJwKDv_0WkAedRjs1W2X8EixSz+sKBXCQ@mail.gmail.com Letting the client choose the protocol to use during a SASL exchange]<br />
** fixed by commit 4f3b87ab780b95c2cc8a591259baefaff4852037<br />
<br />
* [https://www.postgresql.org/message-id/E1cwSWo-0001hG-Rq@gemulon.postgresql.org Add overview of SCRAM to the FE/BE protocol documentation]. Mention that SASLprep is used on all passwords, UTF-8 or not.<br />
** fixed by commit 4f3b87ab780b95c2cc8a591259baefaff4852037<br />
<br />
* [https://www.postgresql.org/message-id/flat/CA%2BTgmoarXTa3F5ybQ98DtUDKVMUpg5JoDykPXUaEr9z_8OyYWQ%40mail.gmail.com add synchronous_commit control for logical apply]<br />
** fixed by commit 887227a1cc861d87ca0f175cf8bd1447554090eb<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwGA2tz-iQ90ofgX0Q1TuZLyr+GCX+T1=PE+ogUKVSRpZA@mail.gmail.com logical replication worker and statistics]<br />
** fixed by commit 139eb9673cb84c76f493af7e68301ae204199746<br />
<br />
* [https://www.postgresql.org/message-id/flat/alpine.DEB.2.20.1702161846410.29507@lancre/ web site CSS issues]<br />
** fixed in pgweb<br />
<br />
* [https://www.postgresql.org/message-id/flat/92ea7dd8-70b9-16c6-9327-e67e56209f33%40lab.ntt.co.jp publications vs inheritance]<br />
** fixed by commit 419a23b478ae760b797188341ddce5b41322684b<br />
<br />
* [https://www.postgresql.org/message-id/CAKJS1f9Kk0NF6Fg7TA%3DJUXsjpS9kX6NVu27pb5QDCpOYAvb-Og%40mail.gmail.com extended stats not friendly towards ANALYZE with subset of columns]<br />
** original commit: {{PgCommitURL|7b504eb}}<br />
** fixed by commit bf2a691e02d7766f185d9d8e0f092222a5c0a129<br />
<br />
* [https://www.postgresql.org/message-id/20170316085322.crffknkgee5s6air@alap3.anarazel.de Parallel Query + EXEC_BACKEND + ASLR is broken]<br />
** Problem in 9.6 and later<br />
** Fixed by commits 0ef26bb39 + 32470825d + a74740fbd<br />
<br />
* [https://www.postgresql.org/message-id/CAHE3wgj+2YpFyrg7SAV=-oqTpP2AggT-nRKbR3nkDAt0TA2V6A@mail.gmail.com Different table schema in logical replication crashes]<br />
** fixed by commit e6242c18a5bb08788e6c4cc773952fc8e2a6291a<br />
<br />
* {{messageLink|b081887e-1712-3aa4-7dbe-e012333d50e4@iki.fi|pg_hba.conf syntax}}<br />
** fixed by commit c727f120ff50f624a1ee3abe700d995c18314a0b<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com Improve the docs and comments for quorum-based sync replication]<br />
** original commit: {{PgCommitURL|3901fd7}} (principal author: Masahiko Sawada; owner: Fujii Masao {{messageLink|20170405064544.GA2702716@tornado.leadboat.com|notified}})<br />
** There will be still many source comments and documentations that we7c030783a5bd07cadffc2a1018bc33119a4c7505 need to update, for example, in high-availability.sgml. We need to check and update them throughly.<br />
<br />
* [https://www.postgresql.org/message-id/7064.1492022469@sss.pgh.pa.us Inadequate parallel-safety check for SubPlans]<br />
** original commit: {{PgCommitURL|5e6d8d2}} (principal author: Amit Kapila; owner: Robert Haas {{messageLink|20170416061825.GK2870454@tornado.leadboat.com|notified}})<br />
** fixed by commit 39151781c8cd2c8bf6057496426fb9c07178eda5<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqQP-+zbgMiDgFwtoUnQfBV9y86GABuKeEV21PQ_EZDC3A@mail.gmail.com CREATE/DROP SUBSCRIPTION, query cancellations and slot handling]<br />
** fixed by commit dcb39c3<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com synchronous_standby_names shows unused priority values]<br />
** original commit: {{PgCommitURL|3901fd7}} (principal author: Masahiko Sawada; owner: Fujii Masao {{messageLink|20170405064544.GA2702716@tornado.leadboat.com|notified}})<br />
** The priority value is assigned to each standby listed in s_s_names even in quorum commit though those priority values are not used at all. Users can see those priority values in pg_stat_replication. Isn't this confusing? If yes, it might be better to always assign 1 as the priority, for example.<br />
** Not a bug. Consensus against current design; no consensus on which replacement to adopt. Need to resolve that debate.<br />
** Fixed by commit 346199dcab4cfb2c023373fb3d859583b59810d7<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwGhhJyNDEb+GDbJ2iHQvyOqcdgqoH9wqvLt7VAGAnE3WA@mail.gmail.com tablesync patch broke the assumption that logical rep depends on?]<br />
** fixed by commit de4389712206d2686e09ad8d6dd112dc4b6c6d42<br />
<br />
* [https://www.postgresql.org/message-id/CAHE3wggjp964CpesavPaeZ3Lz-_1S6RwK_j=r+W8nhmkwdGmnQ@mail.gmail.com logical replication fixes]<br />
** fixed by commit e495c1683f2c243f6769b34a009cf9c28526b555 and following<br />
<br />
* [https://www.postgresql.org/message-id/6ed23d3d-c09d-4cbc-3628-0a8a32f750f4%40lab.ntt.co.jp Crash when partition column specified twice]<br />
** fixed by commit 504c2205abc7de67386f9c95630f38ee15626f07<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoDCnyRJDUY%3DESVVe68AukvOP2dFomTeBFpAd1TiFbjsGg%40mail.gmail.com Interval for launching the table sync worker]<br />
** fixed by commit e3cf708016ca6045dc1cd5a0768cfecf17caf3d1<br />
<br />
* [https://www.postgresql.org/message-id/8f6f6519-a807-7bf1-acf7-f045da4ce385%40lab.ntt.co.jp Dropping a partitioned table takes too long]<br />
** fixed by commit c1e0e7e1d790bf18c913e6a452dea811e858b554<br />
<br />
* [https://www.postgresql.org/message-id/CAKOSWN=hUQWwyCJS8a3gTTUkvMkeg2iwSCCs=df0OYxJ_6H0kA@mail.gmail.com Removing ADD GENERATED for identity columns]<br />
** owner proposes closing this as a non-bug<br />
** secondary issue fixed by commit e4fddfd49241dc8dfda354993bad8d5518df1873<br />
<br />
* [https://www.postgresql.org/message-id/4b498969-fd37-9c3d-3981-389507515cc6%40lab.ntt.co.jp UPDATE/DELETE statement-level triggers don't fire on partitioned tables]<br />
** {{messageLink|20170430080056.GD278614@rfd.leadboat.com|notified}}<br />
** fixed by commit e180c8aa8caf5c55a273d4a8e6092e77ff3cff10<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwFDWh_Qr-q_GEMpD+qH=vYPMdVqw=ZOSY3kX_Pna9R9SA@mail.gmail.com some review comments on logical rep code]<br />
** fixed by several commits, last is 9414e41ea703ea5fcc288bcf7dc000e53306896b<br />
<br />
* [https://www.postgresql.org/message-id/20170428.165432.60857995.horiguchi.kyotaro@lab.ntt.co.jp .pgpass's behavior has changed]<br />
** original commit: {{PgCommitURL|274bb2b}} (principal author: Robert Haas; owner: Robert Haas {{messageLink|20170430080928.GE278614@rfd.leadboat.com|notified}})<br />
** fixed by commit bdac9836d3b910c5fd592aaeaac3c2e2e1defcad<br />
<br />
* [http://postgr.es/m/20170428.170947.238404319.horiguchi.kyotaro@lab.ntt.co.jp disabling a subscription need not wake the launcher]<br />
** fixed by commit a99448ab4515aaadc17647e53633f418893f5adf<br />
<br />
* [https://www.postgresql.org/message-id/f994fc98-389f-4a46-d1bc-c42e05cb43ed@sigaev.ru Incorrect application of unique-inner join logic]<br />
** correctness issue fixed by commit 2057a58d1629ebffce694e3cef7f714571a88dd7<br />
** performance issue fixed by commit 92a43e4857d9682b93c9f755f453cc8fd7c66c81<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1wfBgFPbfAMYZQE78p=VhZX7nN86aWkp0QcCp=+KxZ=bg@mail.gmail.com \password and PQencryptPassword]<br />
** original commit: {{PgCommitURL|818fd4a}} (principal author: Michael Paquier; owner: Heikki Linnakangas, {{messageLink|20170410035323.GA2846583@tornado.leadboat.com|notified}})<br />
** fixed by commit 8f8b9be51fd788bb11276df89606bc653163524e<br />
<br />
* pg_dump and partitioned tables<br />
** original commit: {{PgCommitURL|f0e4475}} (principal author: Amit Langote; owner: Stephen Frost, [http://postgr.es/m/20170413150540.GQ9812@tamriel.snowman.net previously Robert Haas])<br />
** {{messageLink|20170409235057.GA2842536@tornado.leadboat.com|notified}}<br />
** [https://www.postgresql.org/message-id/7682253a-6f79-6a92-00aa-267c4c412870%40lab.ntt.co.jp pg_dump should not emit ALTER TABLE ONLY for a partitioned table in case of attribute changes and inheritable constraints]<br />
*** patch exists<br />
** [https://www.postgresql.org/message-id/20170217133251.GK9812%40tamriel.snowman.net pg_dump TAP tests around partitioning]<br />
** fixed by commit 44c528810a1eca52a7888ed74c08353d45331b00<br />
<br />
* [https://www.postgresql.org/message-id/E4978C3DF3524C03A6729DD1BDC723A9@tunaPC pgoutput is not built with MSVC]<br />
** fixed by commit 28d1c8ccc87128f9b0b937eae277473027c36b7e<br />
<br />
* [http://postgr.es/m/22cc402c-88eb-fa35-217f-0060db2c72f0@2ndquadrant.com Logical replication - TRAP: FailedAssertion in pgstat.c]<br />
** fixed by commit 9a591c1bccc5edeb06b979c59f39753982131181<br />
<br />
* [http://postgr.es/m/4c6d34e1-dc54-89eb-787e-4620f5fb56f9@enterprisedb.com ALTER SUBSCRIPTION doesn't check connection string validity]<br />
** fixed by commit fe974cc5a69903e9f53b36d6e2709fd3de0a1ac7<br />
<br />
* [https://www.postgresql.org/message-id/29431.1493730652@sss.pgh.pa.us Having DROP SLOT option on DROP SUBSCRIPTION is broken by design]<br />
** fixed by commit 013c1178fd0adefa0f68d5ce2d84e7ae6f9613a1<br />
<br />
* [http://postgr.es/m/CA+Tgmoa7ZnfNq2zBO9og7DAQDe7+FctR7WggGx2tbLXYeXHBFw@mail.gmail.com consider adding pg_dump --no-subscriptions]<br />
** fixed by commit 26aa1cf376f68b800b73c326edeea6d1996ec246<br />
<br />
* [https://www.postgresql.org/message-id/flat/9A2F6FEC-D510-4AD6-8082-A1021040C840%40postgrespro.ru Logical replication worker ApplyContext bloat]<br />
** fixed by commit 489b96e80b96c0eda02575347654e87968f2f5f4<br />
<br />
* [http://postgr.es/m/CAEepm=2xJFFpGM+N=gpWx-9Nft2q1oaFZX07_y23AHCrJQLt0g@mail.gmail.com Transition tables for triggers on foreign tables and views] are broken<br />
** fixed by commit 9e6104c6672dc948a430d1ee269b0c31bf5bc974<br />
<br />
* [http://postgr.es/m/CANEvxPoOodsb_ZJwgSOLpYic5s4-0pZOJWrWnRU-TpgV9KJQdA@mail.gmail.com assertion failure when rescanning transition table]<br />
** fixed by commit 304007d9f1f66fd37e50e5a5aa6f17400f1239f8<br />
<br />
* [http://postgr.es/m/CAEepm=0VR5W-N38eTkO_FqJbGqQ_ykbBRmzmvHyxDhy1p=0Csw@mail.gmail.com assertion failure for TRUNCATE triggers with transition tables]<br />
** fixed by commit 29fd3d9da0ff9e230ff051c1423871bd6eac377d<br />
<br />
* [https://www.postgresql.org/message-id/CAA4eK1LAo4DGwh+mi-G3U8Pj1WkBBeFL38xdCnUHJv1z4bZFkQ@mail.gmail.com Remove pre-10 compatibility code in hash index]<br />
** fixed by commit a5775991bb86d95939b3eb1173b88d8c5312962d<br />
<br />
* [http://postgr.es/m/CA+TgmoYe8_FZ9oNTxL-q42kUXGKCDrrG512qbyKAQw9ROBvQ9g@mail.gmail.com consider revising syntax to avoid NO prefixes] (NOCOPY, NOCONNECT, NOREFRESH, NODROP, NOPUBLISH)<br />
** fixed by commit b807f59828fbc02fea612e1cbc0066c6dfa3be9b<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqRrwQrnWx=JmiRp3ARPH+o3AaUCaJnNbqN9J5SK5T3wQg@mail.gmail.com pg_dump --no-publications]<br />
** fixed by commit 96e1cb4c0fb45dfca2d8b0a58693b94cbdaabe11<br />
<br />
* [https://www.postgresql.org/message-id/CAKJS1f8O0njDKe8ePFQ-LK5-EjwThsDws6ohJ-+c6nWK+oUxtg@mail.gmail.com Rename wal location functions to "lsn"]<br />
** Backward compatibility is already broken for most of these functions during the xlog to wal rename, and it'll likely be too late to change this once beta1 is out.<br />
** [https://www.postgresql.org/message-id/CAKJS1f8PadYT90CBYh9d%2BUXZxeo0jFOJYL3_RD%2Bv1mBgLOmfFQ%40mail.gmail.com patch exists]<br />
** fixed by commit d10c626de47d8b048b663471c7785603a2ec8641<br />
<br />
* [https://www.postgresql.org/message-id/1dfff343-c74d-042f-fee1-547253be0a40%40lab.ntt.co.jp incorrect multi-column range partition constraint]<br />
** fixed by commit f8bffe9e6d700fd34759a92e47930ce9ba7dcbd5; see also 1848b73d4576e30c89ba450ad9f169774a6819bf<br />
<br />
* [https://www.postgresql.org/message-id/flat/2a822515-82a2-6374-a131-1f99054cf5f6%402ndquadrant.com#2a822515-82a2-6374-a131-1f99054cf5f6@2ndquadrant.com Time based lag tracking for logical replication]<br />
** fixed by commit 024711bb544645c8b1061e9f02b261e2e336981d<br />
<br />
* [https://www.postgresql.org/message-id/51f65289-54f8-2256-d107-937d662d69f1%402ndquadrant.com snapshot builder has bugs]<br />
** fixed by commits 2bef06d51646058c6bb480fcdbffb1f0cc914fed, 56e19d938dd1457ae078304df1b9903509a0a2bf, 955a684e0401954a58e956535107bc4b7136d952 and 524dbc14335cde0b18745f05a9112436d212f061<br />
<br />
* [https://www.postgresql.org/message-id/20075.1494633784@sss.pgh.pa.us statistics objects fail to cope with ALTER COLUMN TYPE]<br />
** fixed by commit b5b0db19b895f033ada35bc7c337183be7356977<br />
<br />
* [https://www.postgresql.org/message-id/D992B4C2-8F80-4DE0-8348-6E0696C3F967@citusdata.com ALTER SEQUENCE RESTART is not concurrent-safe]<br />
** fixed by commit f8dc1985fd390774aab4ab0ba71036d6d5e631a9<br />
<br />
=== resolved before 10beta2 ===<br />
<br />
* [https://www.postgresql.org/message-id/flat/c0135b04-91d9-60ca-0544-16566f5eb187@enterprisedb.com synchronous_commit missing from tab completion of CREATE SUBSCRIPTION]<br />
** fixed by commit 0fbfb65d4bfd429651dc28faf3ad1846c965e18d<br />
<br />
* [https://www.postgresql.org/message-id/6bac159c-4ba0-c33f-d01f-33ba01a36105@enterprisedb.com we should disallow subscribing a foreign table]<br />
** fixed by commit 944dc0f9cec7c3d33648f41aaecfbd976106e975<br />
<br />
* [https://www.postgresql.org/message-id/flat/6af0f58c-243c-8110-9547-ebb504ccb457%40enterprisedb.com#6af0f58c-243c-8110-9547-ebb504ccb457@enterprisedb.com Server Crashes if try to provide slot_name='none' at the time of creating subscription]<br />
** fixed by commit 62345698513cbcb3c48a6dae414abf0f24fd163a<br />
<br />
* [https://www.postgresql.org/message-id/e736bf16-3393-02af-44fc-4722128a4b4f%40lab.ntt.co.jp Event triggers + table partitioning cause server crash in current master]<br />
** fixed by commit 3ec76ff1f2cf52e9b900349957b42d28128b7bc7<br />
<br />
* [https://www.postgresql.org/message-id/6b2fb5ff-40e1-fda3-3ce5-6723e9e5df61%40lab.ntt.co.jp Partitioned table Appends not coping with being referenced in subplans]<br />
** fixed by commit b522759508dae17535f8cd20598a50a409a97f4d<br />
<br />
* [https://www.postgresql.org/message-id/1803D792815FC24D871C00D17AE95905B1A34A@g01jpexmbkw24 If recovery.conf has target_session_attrs=read-write, the standby fails to start.]<br />
** fixed by commit aa41bc794c51a4d5c364cca014c199b1a00d26aa<br />
<br />
* [https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D1F6F5924%40G01JPEXMBYT05 connect_timeout behavior differs between the documentation and the program]<br />
** {{messageLink|20170515034511.GP843225@rfd.leadboat.com|notified}}<br />
** fixed by commit 5f374fe7a83304fd339789da22599bd102dac9e5<br />
<br />
* [https://www.postgresql.org/message-id/CAA4eK1Jidtagm7Q81q-WoegOVgkotv0OxvHOjFxcvFRP4X%3DmSw%40mail.gmail.com pg_upgrade support for hash indexes]<br />
** original commit: {{PgCommitURL|ea69a0d}} (principal author: Mithun Cy; owner: Robert Haas {{messageLink|20170515040837.GR843225@rfd.leadboat.com|notified}})<br />
** fixed by commit a95410e2ec39b6776381fd01198dc57a063e8185<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoBEKzQot24KhgW8_kTTi-SGLEM7Kh8EuW8Nj%3Dv46qvSBA%40mail.gmail.com Improvement in log message of logical replication worker]<br />
** fixed by commit 92ecb148e517704ec945dce513db71fee7790cfd<br />
<br />
* [http://postgr.es/m/CAB7nPqR0G5aF2_kc_LH29knVqwvmBc66TF5DicvpGVdke68nKw@mail.gmail.com Server ignores SASL mechanism name defined in SASLInitialResponse] (Author: Heikki Linnakangas; Owner: Heikki Linnakangas)<br />
** fixed by commit 505b5d2f8672f13c98dd744a6d421da14f59cd39<br />
<br />
* [http://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org Partition definition for money type looks broken] (principal author: Amit Langote ; owner: Robert Haas)<br />
** fixed by commit 76a3df6e5e621928fbf0cddf347e16a62e9433ec<br />
<br />
* [http://postgr.es/m/fbd1d566-bba0-a3de-d6d0-d3b1d7c24ff2@postgrespro.ru PATCH: recursive json_populate_record()] has bugs<br />
** fixed by commits e45c5be99d08d7bb6708d7bb1dd0f5d99798c6aa and 68cff231e3a3d0ca9988cf1fde5a3be53235b3bb<br />
<br />
* [https://www.postgresql.org/message-id/E1dFBEX-0004wt-8t@gemulon.postgresql.org lack of location support in outfuncs/readfuncs for partitioning node types]<br />
** fixed by commit 80f583ffe930b21d6e5c47be4342356e57851a9a<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1wOqi_W9gfXWVzMvugc9tJXVX+q_8tymOqWe6RwSgNPWw@mail.gmail.com ALTER PUBLICATION documentation: referenced first variant no longer exists]<br />
** fixed by commit 185364b161512806d23ca390f5b615666079699b<br />
<br />
* [https://www.postgresql.org/message-id/CABUevExShf2WWhmY6W7HSEYX669sLkcEUWLDPnzHpUamPaDUXA%40mail.gmail.com pg_basebackup generates non-unique slot names]<br />
** fixed by commit 2712da8b64b4e399a2666cce2c25329f4f834f2d<br />
<br />
== Challenges Carried over to PostgreSQL 11 ==<br />
<br />
* [https://www.postgresql.org/message-id/1700970.cRWpxnom9y@hammer.magicstack.net libpq connection failover: Use more efficient mechanism instead of SHOW transaction_read_only, add the ability to connect to the standby]<br />
** original commit: {{PgCommitURL|274bb2b3}} (principal author: Robert Haas; owner: Robert Haas)<br />
** Right now, libpq issues SHOW transaction_read_only upon each connection. This is inefficient, and we should use some GUC_REPORT variable to avoid this round-trip when connecting to PG10 or later. In addition, target_session_attrs=read-only should be available even in PG10 to meet the average expectation.<br />
** Robert is [https://www.postgresql.org/message-id/CA%2BTgmoYcWdbFkvsDkEPVgHL1y%2BbXidfu9JeXYJh6OQGJ%2BRAknQ%40mail.gmail.com skeptical about changing this now]<br />
** patch exists<br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
* feature freeze: April 7th<br />
* beta1: wrap May 15th, announce May 18th<br />
<br />
References:<br />
* [https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting#9:55_-_10:05_.09Next_Release_Schedule_.09All original schedule]<br />
* [https://www.postgresql.org/message-id/CA%2BTgmoZNLxizOkPy4WKdxwKo40Hz96v5jZ%3D07aLe93JW2dZmRA%40mail.gmail.com feature freeze moved]</div>Mhahttps://wiki.postgresql.org/index.php?title=PostgreSQL_10_Open_Items&diff=30278PostgreSQL 10 Open Items2017-05-31T16:26:52Z<p>Mha: /* Other */</p>
<hr />
<div>== Open Issues ==<br />
<br />
=== Logical Replication ===<br />
<br />
unless otherwise marked, original commit: {{PgCommitURL|665d1fa}} (principal author: Petr Jelinek; owner: Peter Eisentraut)<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoBYpyqTSw%2B%3DES%2BxXtRGMPKh%3DpKiqjNxZKnNUae0pSt9bg%40mail.gmail.com Dropping subscription may stuck if done during tablesync]<br />
** owner: RMT<br />
** Analyze deadlock issues with DROP SUBSCRIPTION and apply worker process<br />
** Avoid orphaned tablesync worker if apply worker exits before<br />
** Patch series exists<br />
<br />
* [https://www.postgresql.org/message-id/20170421014030.fdzvvvbrz4nckrow@alap3.anarazel.de Query handling in Walsender is somewhat broken]<br />
** original commit: {{PgCommitURL|7c4f524}} (principal author: Petr Jelinek; owner: Peter Eisentraut {{messageLink|20170530020128.GD135259@gust.leadboat.com|notified}})<br />
** patch was proposed<br />
<br />
* [https://www.postgresql.org/message-id/29009.1491936023@sss.pgh.pa.us Background worker display in pg_stat_activity (logical replication especially)]<br />
** {{messageLink|20170530020932.GA116176@gust.leadboat.com|notified}}<br />
<br />
* [https://www.postgresql.org/message-id/64530.1495454510@sss.pgh.pa.us need to widen prohibitions on publish/subscribe of system objects]<br />
** {{messageLink|20170530021450.GB116176@gust.leadboat.com|notified}}<br />
<br />
* [http://postgr.es/m/CA+q6zcXQqHqhiFR-eLvVk+x9CvPLvJotyqQ77Q1U_4Uj+BLW4g@mail.gmail.com Create subscription with `create_slot=false` and incorrect slot name] should ERROR<br />
** {{messageLink|20170530022604.GE116176@gust.leadboat.com|notified}}<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoB2ZbCCqOx%3DbgKMcLrAvs1V0ZMqzs7wBTuDySezTGtMZA%40mail.gmail.com Replication status in logical replication]<br />
** {{messageLink|20170530025638.GF116176@gust.leadboat.com|notified}}<br />
** patch exists<br />
<br />
* [https://www.postgresql.org/message-id/2b89dc87-8093-013a-0b83-2bb4b0b04d56%40enterprisedb.com ALTER SUBSCRIPTION REFRESH and table sync worker]<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoBzQP%3DSs6dVtDrBUWG%2BiVmdoQB%3DjWnycd1ALesW%2BhpMoQ%40mail.gmail.com "create publication..all tables" ignore 'partition not supported' error]<br />
** patch exists<br />
<br />
=== Other ===<br />
<br />
* [http://postgr.es/m/CA+TgmoZzTBBAsEUh4MazAN7ga=8SsMC-Knp-6cetts9yNZUCcg@mail.gmail.com transition table behavior with inheritance appears broken]<br />
** original commit: {{PgCommitURL|5970271}} (principal author: Kevin Grittner; owner: Kevin Grittner, {{messageLink|20170506185437.GH843225@rfd.leadboat.com|notified}})<br />
** patch exists<br />
<br />
* [http://postgr.es/m/CAB7nPqQO9RijoeCYxY74v0eFq7jiLHWSy_eiidPqC1f1toFyfA@mail.gmail.com libpq misses cleanup of SASL context with sslmode=prefer]<br />
** original commit: {{PgCommitURL|505b5d2}} (principal author: Michael Paquier; owner: Heikki Linnakangas {{messageLink|20170530030447.GG116176@gust.leadboat.com|notified}})<br />
** patch exists<br />
<br />
* [http://postgr.es/m/CA+mi_8aZYLhuyQi1Jo0hO19opNZ2OEATEOM5fKApH7P6zTOZGg@mail.gmail.com Fix incorrect error message string in auth-scram.c] (author: Michael Paquier, Heikki Linnakangas; owner: Heikki Linnakangas)<br />
<br />
* [https://www.postgresql.org/message-id/21809.1495994606@sss.pgh.pa.us const-simplification of SRF calls now has user-visible effects]<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqSTsnK+b53s-NZUuTPosJmjbV+zKHV3zHr7K6ZKFMVY_A@mail.gmail.com Fix WAL receiver spinlock use].<br />
** original commit: {{PgCommitURL|b1a9bad}} (principal author: Michael Paquier; owner: Álvaro Herrera)<br />
** ready_to_display should be protected by the WAL sender's spinlock.<br />
** pg_stat_get_wal_receiver should look at the WAL receiver PID after taking a spin lock.<br />
* [https://www.postgresql.org/message-id/CABUevExShf2WWhmY6W7HSEYX669sLkcEUWLDPnzHpUamPaDUXA%40mail.gmail.com pg_basebackup generates non-unique slot names]<br />
** original commit: {{PgCommitURL|e7b020f786bf3b344f81d70aa423525fd4f44dfa}} (author: Magnus Hagander; owner: Magnus Hagander)<br />
<br />
== Decisions to Recheck Mid-Beta ==<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com Which synchronous replication method, priority or quorum, should be chosen when neither FIRST nor ANY is specified in synchronous_standby_names?]<br />
** original commit: {{PgCommitURL|3901fd7}} (principal author: Masahiko Sawada; owner: Fujii Masao)<br />
** Right now, a priority-based sync replication is chosen for keeping backward compatibility. However some hackers argued to change this decision so that a quorum commit is chosen because they think that most users prefer to a quorum.<br />
<br />
* [https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D1F6F5659%40G01JPEXMBYT05 Cannot connect to alternative hosts when non-socket level connection error occurs]<br />
** patch exists<br />
** This is a matter of prioritizing either of service continuity or configuration error detection. Continue considering what to do based on user feedback during beta period, other developers' opinions, and the solution using SQLSTATE.<br />
<br />
* Add migration instructions encouraging migration from MD5 to SCRAM once we know the state of drivers; see [https://www.postgresql.org/message-id/CA+Tgmob0HareNtnp1sV2ZjFVZ_1WkaWptey53hF5cfcLzYz3hA@mail.gmail.com post]<br />
<br />
== Older Bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/c2c7191b-5ca0-b37a-9e9d-4df15ffb554b%40lab.ntt.co.jp Oddity in EXPLAIN for foreign/custom join pushdown plans]<br />
** postgres_fdw produces incorrect aliases for joining relations shown in EXPLAIN for some join pushdown queries<br />
** [https://www.postgresql.org/message-id/b4b04e83-5eb4-7dd6-2951-32acadea4e7b@lab.ntt.co.jp low-priority issue; let's leave this for v10]<br />
** regression in v9.6, nothing changed from v9.6 beta to v10 beta<br />
<br />
* [https://www.postgresql.org/message-id/20170117.193645.160386781.horiguchi.kyotaro@lab.ntt.co.jp standby can fail to reconnect even with replication slots]<br />
** patch exists<br />
** present in 9.4 and later<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1wXkKUKBHWBYzET3D9OViyDg8DcVL-wKEqk2uyoMrzr_A@mail.gmail.com Crash recovery can leave everlasting empty pages]<br />
** The pages are actually empty but FSM says that they have no room for new data and ALL_FROZEN. ALL_FROZEN prevents autovacuum from fixing FSM.<br />
** regression in v9.6, nothing new in v10<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqR82_57C8O1+z-bUChhHpdjMec_omLfKwYdjAFjjcrBWg@mail.gmail.com Switch use of "encrypted" to "hash" for passwords in documentation]<br />
<br />
* [https://www.postgresql.org/message-id/4905.1492813727@sss.pgh.pa.us parallel query locks up if worker process fails to launch]<br />
** code is broken since birth, but do we really want to ship v10 like this?<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwEsttg9P9LOOavoc9d6VB1zVmYgfBk=Ljsk-UL9cEf-eA@mail.gmail.com logical replication and PANIC during shutdown checkpoint in publisher]<br />
** Also affects v9.4-v9.6 but v10 can trigger it from more places<br />
** major part fixed by commit 086221cf6b1727c2baed4703c582f657b7c5350e<br />
** remaining concern: HOT pruning during logical decoding might generate WAL (patch exists)<br />
<br />
* [https://www.postgresql.org/message-id/CAA4eK1JMHh_06gk5GFRkL2RYivwPAsS85zuvqOmG86MeOxFR1g%40mail.gmail.com retry shm attach for Windows to mitigate the impact of ASLR]<br />
** code is in the same state from previous releases, but it seems advisable to fix it for v10?<br />
<br />
== Non-bugs ==<br />
<br />
* [https://www.postgresql.org/message-id/20170321135742.GB23103@e733.localdomain Errors with valgrind]<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqSP+MHqg=dKoNOZu75j2mGAEW622GYz45Mv2V_XOao-9g@mail.gmail.com CREATE/ALTER ROLE PASSWORD ('value' USING 'method')], extension of this DDL to enforce type of password without changing password_encryption.<br />
** Not Open-Item worthy, let's do this in v11 if it still feels worthwhile then.<br />
<br />
* [https://www.postgresql.org/message-id/CA+TgmoYrA8SK=KjkVbvKt8hG3Cqsjr-Hnmwa3WXqbziRuwKBLg@mail.gmail.com Declarative partitioning vs. information_schema, etc.]<br />
** include partitions in information_schema.tables, pg_tables, and psql's \d listing, etc?<br />
** firm support for status quo, lack of firm support for alternatives<br />
<br />
* [https://www.postgresql.org/message-id/071086d7-6462-f0e7-54ca-b633062e317c%40lab.ntt.co.jp Document that foreign table's partition constraint is not enforced locally]<br />
** Patch exists<br />
** documentation is correct, but this would add emphasis to a point<br />
<br />
* [https://postgr.es/m/CAGPqQf3joLrjmR2FmQzYURb-_TxhW78tXhgYm+C66wXNjWH9ww@mail.gmail.com Query fails when SRFs are part of FROM clause]<br />
** original commit: {{PgCommitURL|69f4b9c}} (principal author: Tom Lane; owner: Andres Freund {{messageLink|20170405064755.GA2702846@tornado.leadboat.com|notified}})<br />
** owner [https://www.postgresql.org/message-id/20170412225855.oklyfkbwj2dmbrpu@alap3.anarazel.de proposes] classifying this as a non-bug<br />
** Commit e240a65c7dfc5ad80ab757ecb1aa9b9032c7f8ae improved error reporting<br />
<br />
* [https://www.postgresql.org/message-id/a162fe00-5665-2a77-4b7a-9f7293f64db0%40lab.ntt.co.jp pg_dump should expand partitioned tables when specified using --table and --exclude options]<br />
** Patch exists<br />
** [http://postgr.es/m/CA+TgmoazyEb9mdL3yJkWRHHtcOFBzZDE_ESgq8iE22gPpdML-w@mail.gmail.com not really a bug, and should inheritance behavior also be changed?]<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqSKhOpEOeRQB4pTe5zSBiwbDsfM4jh0nFdcd6LjkMQ-Pg@mail.gmail.com Simplify password hook by removing password_type]<br />
** original commit: {{PgCommitURL|eb61136}} (principal author: Heikki Linnakangas; owner: Heikki Linnakangas {{messageLink|20170515040315.GQ843225@rfd.leadboat.com|notified}})<br />
** Not worth changing the hook signature.<br />
<br />
<br />
== Resolved Issues ==<br />
<br />
=== resolved before 10beta1 ===<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1zMLnH_i1-PVQ-biZzvNx7VcuatriquEnh7HNk6K8Ss3Q@mail.gmail.com PANIC in pg_commit_ts slru after crashes, 2PC restore code at fault]<br />
** Fixed by commit aa203e76004daaee3d70b19cc727ed17b87b3d3a<br />
** Fixed by commit ee01f7092fb6430ad9bb9bb1f42f19d22bcb9329<br />
<br />
* [https://www.postgresql.org/message-id/8a1d4662-9665-59d5-518d-45616b75f06a%40lab.ntt.co.jp COMMENT ON COLUMN fails for partitioned tables]<br />
** Fixed by commit 51175f3638524231405e674e40bde159b0b76727<br />
<br />
* [http://postgr.es/m/CAKJS1f-BmGo410bh5RSPZUvOO0LhmHL2NYmdrC_Jm8pk_FfyCA@mail.gmail.com Allowing extended stats on foreign and partitioned tables]<br />
** original commit: {{PgCommitURL|7b504eb}} (principal author: Tomas Vondra; owner: Alvaro Herrera {{messageLink|20170414055310.GE2870454@tornado.leadboat.com|notified}})<br />
** Fixed by commit 8c5cdb7f4f6e1d6a6104cb58ce4f23453891651b<br />
<br />
* [https://www.postgresql.org/message-id/12642.1491513976@sss.pgh.pa.us Partitioning optimization broke ConvertRowtypeExpr]<br />
** Fixed by commit 3f902354b08ac788600f0ae54fcbfc1d4e3ea765.<br />
<br />
* Integer overflow in enlargeStringInfo<br />
** {{messageLink|1706e85e-60d2-494e-8a64-9af1e1b2186e@manitou-mail.org|thinko in overflow logic}}<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1yURZZONoeLXhPsp2AkqR5MNAXiCiTVnrt2LGd6qD1b8w@mail.gmail.com pg_upgrade is broken because of renaming of pg_resetxlog to pg_resetwal]<br />
** Fixed by commit b877761.<br />
<br />
* [https://www.postgresql.org/message-id/flat/1803D792815FC24D871C00D17AE95905AC5FAE@g01jpexmbkw24#1803D792815FC24D871C00D17AE95905AC5FAE@g01jpexmbkw24 PQsendQuery fails when it should not if target_session_attrs is set to read-write]<br />
** Fixed by commit 1de0a4e.<br />
<br />
* [https://www.postgresql.org/message-id/CAM2+6=U72y2_Jni2p+meqTvvk=r_=Wd4orvzz5YL0b3WFx+gcA@mail.gmail.com Substantial bloat in postgres_fdw regression test runtime]<br />
** Fixed by commit aa7f593b1ffa9717bd5570174944c06c482d1c1f.<br />
<br />
* [https://www.postgresql.org/message-id/9f9dc7ae-14f0-4a25-5485-964d9bfc19bd%40lab.ntt.co.jp Error detail shown when partition not found]<br />
** Fixed by commit 5a73e17317e91912b2755f7960d5bf31d374cf31.<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoD%2BVO93zZ4ZQtZQb-jZ_wMko3OgGdx1MXO4T%2B8q_zHDDA%40mail.gmail.com DROP SUBSCRIPTION and ROLLBACK]<br />
** Fixed by commit 272adf4f9cd67df323ae57ff3dee238b649d3b73.<br />
<br />
* [https://www.postgresql.org/message-id/6c420206-45d7-3f56-8325-4bd7b76483ba%40lab.ntt.co.jp Dropping partitioned tables without CASCADE]<br />
** Fixed by commit 8b4d582d279d784616c228be58af1e39aa430402.<br />
<br />
* [https://www.postgresql.org/message-id/CAEepm=15e9L695yVCO-_OkBVbsPupyXqzYWzzDmj-bdJ6o2+Pw@mail.gmail.com pg_recvlogical.c doesn't build with --disable-integer-datetimes]<br />
** Fixed by commit b6aa17e0ae367afdcea07118e016111af4fa6bc3 and c29aff959dc64f7321062e7f33d8c6ec23db53d3<br />
<br />
* [https://www.postgresql.org/message-id/20170207201932.GH9812@tamriel.snowman.net pg_dump and PUBLICATIONS]<br />
** Fixed by commit 05227e0c345247c9e9ff91445850f414e2b0bb70<br />
<br />
* [https://www.postgresql.org/message-id/CA+TgmoYpwN0AkaCqhAEVuxtHqGkz=yJzgQxbvucEQMPE-tLkEA@mail.gmail.com simplehash performance regressions]<br />
** Fixed by commit d4c62a6b623d6eef88218158e9fa3cf974c6c7e5<br />
<br />
* [https://www.postgresql.org/message-id/CAGz5QCLJJ1NhVQjQSreF-UoQyVoN6Krg54gZrr5-Ha5PqP2ksw@mail.gmail.com exposing wait events for non-backends]<br />
** Fixed by commit fc70a4b0df38bda6a13941f1581f25fbb643c7f3<br />
<br />
* [https://www.postgresql.org/message-id/b3d37313-acf0-d8fd-783f-c32f7c0667e6@lab.ntt.co.jp Partitioning vs INSERT ON CONFLICT]<br />
** Fixed by commit 8355a011a0124bdf7ccbada206a967d427039553<br />
** [https://www.postgresql.org/message-id/ff3dc21d-7204-c09c-50ac-cf11a8c45c81%40lab.ntt.co.jp Crash when leaf partition has an index]<br />
*** Reverted by commit f05230752d53c4aa74cffa9b699983bbb6bcb118<br />
<br />
* [https://www.postgresql.org/message-id/c72cbc58-9866-0622-86c1-f01cc4064e73%40lab.ntt.co.jp Bug in list partitioning tuple-routing]<br />
** Fixed by commit 7ecb7143589f38d679bb566311dfa9be1a650fd5<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU%3D1w-9Qe%3DFf1o6bSaXpNO9wqpo7_9GL8_CVhw4BoVVHasqg%40mail.gmail.com segfault in hot_standby for hash indexes]<br />
** Fixed by commit c4c51541e22bf7f2da8ecf6986271687b0d7a90e<br />
<br />
* [https://www.postgresql.org/message-id/CAEepm%3D23%3DvGz%3DCgVurPxBGV6SeOJ7YxSaAJKr_aH%2Bf2cV4zrow%40mail.gmail.com attaching to DSA area that was already destroyed]<br />
** Fixed by commit fddf45b38097d14301d249fbeebca32e40233bd2<br />
<br />
* postgres_fdw, partitioned tables and IMPORT SCHEMA<br />
** [https://postgr.es/m/20170309141531.GD9812@tamriel.snowman.net postgres_fdw IMPORT SCHEMA and partitioned tables]<br />
** Fixed by commit f49bcd4ef3e9a75de210357a4d9bbe3e004db956<br />
<br />
* [https://www.postgresql.org/message-id/2b0d42f2-3a53-763b-c9c2-47139e4b1c2e@lab.ntt.co.jp Partitioning tables create a file on-disk, which remains empty and has no purpose. Those relations don't need any storage]<br />
** Fixed by commit c94e6942cefe7d20c5feed856e27f672734b1e2b<br />
<br />
* [https://www.postgresql.org/message-id/a6f99cdb-21e7-1d65-1381-91f2cfa156e2%40lab.ntt.co.jp Documentation improvements for partitioning]<br />
** Fixed by commit 8f18a880a5f138d4da94173d15514142331f8de6<br />
<br />
* [https://www.postgresql.org/message-id/6ecd6f17-0dcf-1de7-ded8-0de7db1ddc88%402ndquadrant.com crashes due to setting max_parallel_workers=0]<br />
** Fixed by commit 25dc142a49c60c3107480c487cd8444dc83f9bdf<br />
<br />
* [https://www.postgresql.org/message-id/CAE9k0P%3DV2LhtyeMXd295fhisp%3DNWUhRVJ9EZQCDowWiY9rSohQ%40mail.gmail.com Failed assertion in _hash_kill_items/MarkBufferDirtyHint]<br />
** Fixed by commit 93cd7684ee2bba227fa371daa81b88f25456dcb2<br />
<br />
* [https://www.postgresql.org/message-id/CAE9k0PnmPDXfvf8HDObme7q_Ewc4E26ukHXUBPySoOs0ObqqaQ%40mail.gmail.com inconsistent page found on STANDBY server]<br />
** Fixed by commit 75a1cbdc3cfca1e815da6dfa5d7e96d82a6b0725<br />
<br />
* [https://www.postgresql.org/message-id/CAA4eK1%2BVE_TDRLWpyeOf%2B7%2B6if68kgPNwO4guKo060rm_t3O5w%40mail.gmail.com page inspect to show appropriate type of page]<br />
** Fixed by commit 633e15ea0f1bf2e1d70441fe9da8781befebd6e9<br />
<br />
* [https://www.postgresql.org/message-id/20170321.192419.96677899.horiguchi.kyotaro%40lab.ntt.co.jp Logical replication between differrent encodings fails]<br />
** Fixed by commit 6f1b9aaae35bfabe2654a8e44ce226c91e7d8bd9<br />
<br />
* [https://www.postgresql.org/message-id/20170331185540.zmsue4ndvqtnayqw@alap3.anarazel.de improve test coverage of parallel explain analyze]<br />
** Fixed by commit b2ff37d43cc81348fd8e9d9c5fcc9dfadf790763<br />
<br />
* [https://www.postgresql.org/message-id/20170331184603.qcp7t4md5bzxbx32@alap3.anarazel.de improve test coverage of parallel bitmap scan]<br />
** Fixed by commit 5a5931533edd2b70bde1f069609f58998dd26fef<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqSByyEmAVLtEf1KxTRh=PWNKiWKEKQR=e1yGehz=wbymQ@mail.gmail.com SASLprep]<br />
** Fixed by commit 60f11b87a2349985230c08616fa8a34ffde934c8<br />
<br />
* [https://www.postgresql.org/message-id/CA+TgmoZfPOu62bR71bahf90ivOUxXpYOh0RqDiue0+dVVPNrWg@mail.gmail.com dsa.c needs a visit from the message style police]<br />
** Fixed by commit 5c4488478b182983f290a61fc8cf2ec83548622b<br />
<br />
* [https://www.postgresql.org/message-id/20170316085322.crffknkgee5s6air@alap3.anarazel.de Logical replication + EXEC_BACKEND + ASLR is broken]<br />
** Fixed by commit 0ef26bb394abedb2745bd838c26ecb3131682bda<br />
<br />
* [https://www.postgresql.org/message-id/b3a17254-6849-e542-2353-bde4e880b6a4%40lab.ntt.co.jp Reconsider the error detail shown when ExecConstraints() fails after tuple-routing]<br />
** original commit: {{PgCommitURL|f1b4c77}} (principal author: Amit Langote; owner: Robert Haas {{messageLink|20170409235426.GB2842536@tornado.leadboat.com|notified}})<br />
** Fixed by commit c0a8ae7be392aa09dd7e148ff662013e8e148893<br />
<br />
* [https://www.postgresql.org/message-id/13592.1490851519@sss.pgh.pa.us Broken locking design for accesses to pg_subscription_rel]<br />
** Fixed by commit 521fd4795e3ec3d0b263b62e5eb58e1557be9c86<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwHEs8jT_6DjYHYmsD2v-rOudstiBB_mtmZbR9Z2QfhCwQ@mail.gmail.com Both launcher and worker don't handle SIGHUP signal and cannot reload the configuration]<br />
** Fixed by commit 26ad194cb0a6b955e155d44fb52a74212ce85759<br />
<br />
* pg_dump and data durability, with addition of --no-sync option<br />
** original commit: {{PgCommitURL|96a7128}} (principal author: Michael Paquier; owner: Andrew Dunstan {{messageLink|20170405064941.GB2702846@tornado.leadboat.com|notified}})<br />
** [https://www.postgresql.org/message-id/CAB7nPqTUOpF792rDOnBkswZ%3DZgHwxdB01OQU2tAF1KU4iUuLrw%40mail.gmail.com Regression tests should use --no-sync as much as possible]<br />
** Fixed by commit 3820c63da8d0e59e2bd4476e91968f03be5dd041<br />
<br />
* [http://postgr.es/m/CAMkU=1zrQaPwBN+NcBd3pWCb=vWaiL=mmWfJjDJjh-a7eVr-Og@mail.gmail.com pgbench --progress-timestamp no longer works correctly]<br />
** original commit: {{PgCommitURL|1d63f7d}} (principal author: Tom Lane; owner: Tom Lane {{messageLink|20170411042352.GA2870454@tornado.leadboat.com|notified}})<br />
** Fixed by commit feffa0e0795a5a99324890a6dd548ba162ec104c<br />
<br />
* [https://www.postgresql.org/message-id/29588799-a8ce-b0a2-3dae-f39ff6d35922%40lab.ntt.co.jp Dropping a partition may cause deadlock]<br />
** {{PgCommitURL|f0e4475}} (principal author: Amit Langote; owner: Robert Haas {{messageLink|20170409235729.GA2842636@tornado.leadboat.com|notified}})<br />
** Fixed by commit 258cef12540fa1cb244881a0f019cefd698c809e<br />
<br />
* [https://www.postgresql.org/message-id/CAFiTN-suK%2BMod_noGy8LpmkSzgvzwhGfNZ0K6vf_gX6rkw2jxA%40mail.gmail.com Problem in Parallel Bitmap Heap Scan]<br />
** original commit: {{PgCommitURL|f35742c}} (principal author: Dilip Kumar; owner: Robert Haas {{messageLink|20170410031734.GB2845039@tornado.leadboat.com|notified}})<br />
** Fixed by commit 4c3b59abf4c476843bca23de7fb66d647627f30e<br />
<br />
* [https://www.postgresql.org/message-id/flat/24a143e0-c9bb-8f4f-1472-9d6faae4c92e%402ndquadrant.com#24a143e0-c9bb-8f4f-1472-9d6faae4c92e@2ndquadrant.com strange parallel query behavior after OOM crashes]<br />
** original commit: {{PgCommitURL|b460f5d}} (principal author: Julien Rouhaud; owner: Robert Haas {{messageLink|20170410031836.GC2845004@tornado.leadboat.com|notified}})<br />
** Fixed by commit 8ff518699f19dd0a5076f5090bac8400b8233f7f<br />
** See also commit 6599c9ac3340b6cd3d86a0a7f866b80a009fecab which attempts to catch other problems of this sort<br />
<br />
* [https://www.postgresql.org/message-id/52d9c443-ec78-5c8a-7a77-0f34aad12b82%40lab.ntt.co.jp RENAME RULE doesn't work with partitioned tables]<br />
** Fixed by commit 02af7857e5694b13c21401d1982ac21d31e27dee<br />
<br />
* [https://postgr.es/m/20170309144718.GE9812@tamriel.snowman.net sepgsql and partitioned tables]<br />
** {{messageLink|CA+TgmobTJnasxpRkJxGcHaz85LyqdXBKZRxP6pCCS-UkhcHUBQ@mail.gmail.com|feature request, not bug}}<br />
** implemented in {{PgCommitURL|25542d77dd549940468d1a932809feb9959d717d}}<br />
<br />
* [https://www.postgresql.org/message-id/b7578aaf-726e-61a1-0011-943e92ad08ee@2ndquadrant.com error handling in RegisterBackgroundWorker]<br />
** withdrawn<br />
<br />
* [https://www.postgresql.org/message-id/CA%2BTgmobYfFRtcXv1aoXD18%2BRkPU%3Duw39Ajqm1HWyh7V_8QYZ%3DA%40mail.gmail.com pgstathashindex() to handle unused pages in hash index]<br />
** original commit: {{PgCommitURL|e759854}} (principal author: Ashutosh Sharma; owner: Robert Haas {{messageLink|20170412062802.GB2870454@tornado.leadboat.com|notified}})<br />
** Fixed by commit 9cc27566c1a8d659c15b9eea2413dcc07a7a42c9<br />
<br />
* [https://www.postgresql.org/message-id/30972.1491937807@sss.pgh.pa.us Mishandling of non-parallel-safe initplans/subplans in a parallelized query]<br />
** original commit: {{PgCommitURL|5e6d8d2bb}}<br />
** Fixed by commit 16ebab68862bb5d3595b8c8df083f650d9d7cd20<br />
<br />
* [https://www.postgresql.org/message-id/20170217020415.GI9812@tamriel.snowman.net pg_dump and SUBSCRIPTIONS]<br />
** fixed by commits c31671f9b5f6eee9b6726baad2db1795c94839d1, a9254e675bde7dc2d976d207450c559d914c0dd6<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqS-aFg0iM3AQOJwKDv_0WkAedRjs1W2X8EixSz+sKBXCQ@mail.gmail.com Letting the client choose the protocol to use during a SASL exchange]<br />
** fixed by commit 4f3b87ab780b95c2cc8a591259baefaff4852037<br />
<br />
* [https://www.postgresql.org/message-id/E1cwSWo-0001hG-Rq@gemulon.postgresql.org Add overview of SCRAM to the FE/BE protocol documentation]. Mention that SASLprep is used on all passwords, UTF-8 or not.<br />
** fixed by commit 4f3b87ab780b95c2cc8a591259baefaff4852037<br />
<br />
* [https://www.postgresql.org/message-id/flat/CA%2BTgmoarXTa3F5ybQ98DtUDKVMUpg5JoDykPXUaEr9z_8OyYWQ%40mail.gmail.com add synchronous_commit control for logical apply]<br />
** fixed by commit 887227a1cc861d87ca0f175cf8bd1447554090eb<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwGA2tz-iQ90ofgX0Q1TuZLyr+GCX+T1=PE+ogUKVSRpZA@mail.gmail.com logical replication worker and statistics]<br />
** fixed by commit 139eb9673cb84c76f493af7e68301ae204199746<br />
<br />
* [https://www.postgresql.org/message-id/flat/alpine.DEB.2.20.1702161846410.29507@lancre/ web site CSS issues]<br />
** fixed in pgweb<br />
<br />
* [https://www.postgresql.org/message-id/flat/92ea7dd8-70b9-16c6-9327-e67e56209f33%40lab.ntt.co.jp publications vs inheritance]<br />
** fixed by commit 419a23b478ae760b797188341ddce5b41322684b<br />
<br />
* [https://www.postgresql.org/message-id/CAKJS1f9Kk0NF6Fg7TA%3DJUXsjpS9kX6NVu27pb5QDCpOYAvb-Og%40mail.gmail.com extended stats not friendly towards ANALYZE with subset of columns]<br />
** original commit: {{PgCommitURL|7b504eb}}<br />
** fixed by commit bf2a691e02d7766f185d9d8e0f092222a5c0a129<br />
<br />
* [https://www.postgresql.org/message-id/20170316085322.crffknkgee5s6air@alap3.anarazel.de Parallel Query + EXEC_BACKEND + ASLR is broken]<br />
** Problem in 9.6 and later<br />
** Fixed by commits 0ef26bb39 + 32470825d + a74740fbd<br />
<br />
* [https://www.postgresql.org/message-id/CAHE3wgj+2YpFyrg7SAV=-oqTpP2AggT-nRKbR3nkDAt0TA2V6A@mail.gmail.com Different table schema in logical replication crashes]<br />
** fixed by commit e6242c18a5bb08788e6c4cc773952fc8e2a6291a<br />
<br />
* {{messageLink|b081887e-1712-3aa4-7dbe-e012333d50e4@iki.fi|pg_hba.conf syntax}}<br />
** fixed by commit c727f120ff50f624a1ee3abe700d995c18314a0b<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com Improve the docs and comments for quorum-based sync replication]<br />
** original commit: {{PgCommitURL|3901fd7}} (principal author: Masahiko Sawada; owner: Fujii Masao {{messageLink|20170405064544.GA2702716@tornado.leadboat.com|notified}})<br />
** There will be still many source comments and documentations that we7c030783a5bd07cadffc2a1018bc33119a4c7505 need to update, for example, in high-availability.sgml. We need to check and update them throughly.<br />
<br />
* [https://www.postgresql.org/message-id/7064.1492022469@sss.pgh.pa.us Inadequate parallel-safety check for SubPlans]<br />
** original commit: {{PgCommitURL|5e6d8d2}} (principal author: Amit Kapila; owner: Robert Haas {{messageLink|20170416061825.GK2870454@tornado.leadboat.com|notified}})<br />
** fixed by commit 39151781c8cd2c8bf6057496426fb9c07178eda5<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqQP-+zbgMiDgFwtoUnQfBV9y86GABuKeEV21PQ_EZDC3A@mail.gmail.com CREATE/DROP SUBSCRIPTION, query cancellations and slot handling]<br />
** fixed by commit dcb39c3<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com synchronous_standby_names shows unused priority values]<br />
** original commit: {{PgCommitURL|3901fd7}} (principal author: Masahiko Sawada; owner: Fujii Masao {{messageLink|20170405064544.GA2702716@tornado.leadboat.com|notified}})<br />
** The priority value is assigned to each standby listed in s_s_names even in quorum commit though those priority values are not used at all. Users can see those priority values in pg_stat_replication. Isn't this confusing? If yes, it might be better to always assign 1 as the priority, for example.<br />
** Not a bug. Consensus against current design; no consensus on which replacement to adopt. Need to resolve that debate.<br />
** Fixed by commit 346199dcab4cfb2c023373fb3d859583b59810d7<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwGhhJyNDEb+GDbJ2iHQvyOqcdgqoH9wqvLt7VAGAnE3WA@mail.gmail.com tablesync patch broke the assumption that logical rep depends on?]<br />
** fixed by commit de4389712206d2686e09ad8d6dd112dc4b6c6d42<br />
<br />
* [https://www.postgresql.org/message-id/CAHE3wggjp964CpesavPaeZ3Lz-_1S6RwK_j=r+W8nhmkwdGmnQ@mail.gmail.com logical replication fixes]<br />
** fixed by commit e495c1683f2c243f6769b34a009cf9c28526b555 and following<br />
<br />
* [https://www.postgresql.org/message-id/6ed23d3d-c09d-4cbc-3628-0a8a32f750f4%40lab.ntt.co.jp Crash when partition column specified twice]<br />
** fixed by commit 504c2205abc7de67386f9c95630f38ee15626f07<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoDCnyRJDUY%3DESVVe68AukvOP2dFomTeBFpAd1TiFbjsGg%40mail.gmail.com Interval for launching the table sync worker]<br />
** fixed by commit e3cf708016ca6045dc1cd5a0768cfecf17caf3d1<br />
<br />
* [https://www.postgresql.org/message-id/8f6f6519-a807-7bf1-acf7-f045da4ce385%40lab.ntt.co.jp Dropping a partitioned table takes too long]<br />
** fixed by commit c1e0e7e1d790bf18c913e6a452dea811e858b554<br />
<br />
* [https://www.postgresql.org/message-id/CAKOSWN=hUQWwyCJS8a3gTTUkvMkeg2iwSCCs=df0OYxJ_6H0kA@mail.gmail.com Removing ADD GENERATED for identity columns]<br />
** owner proposes closing this as a non-bug<br />
** secondary issue fixed by commit e4fddfd49241dc8dfda354993bad8d5518df1873<br />
<br />
* [https://www.postgresql.org/message-id/4b498969-fd37-9c3d-3981-389507515cc6%40lab.ntt.co.jp UPDATE/DELETE statement-level triggers don't fire on partitioned tables]<br />
** {{messageLink|20170430080056.GD278614@rfd.leadboat.com|notified}}<br />
** fixed by commit e180c8aa8caf5c55a273d4a8e6092e77ff3cff10<br />
<br />
* [https://www.postgresql.org/message-id/CAHGQGwFDWh_Qr-q_GEMpD+qH=vYPMdVqw=ZOSY3kX_Pna9R9SA@mail.gmail.com some review comments on logical rep code]<br />
** fixed by several commits, last is 9414e41ea703ea5fcc288bcf7dc000e53306896b<br />
<br />
* [https://www.postgresql.org/message-id/20170428.165432.60857995.horiguchi.kyotaro@lab.ntt.co.jp .pgpass's behavior has changed]<br />
** original commit: {{PgCommitURL|274bb2b}} (principal author: Robert Haas; owner: Robert Haas {{messageLink|20170430080928.GE278614@rfd.leadboat.com|notified}})<br />
** fixed by commit bdac9836d3b910c5fd592aaeaac3c2e2e1defcad<br />
<br />
* [http://postgr.es/m/20170428.170947.238404319.horiguchi.kyotaro@lab.ntt.co.jp disabling a subscription need not wake the launcher]<br />
** fixed by commit a99448ab4515aaadc17647e53633f418893f5adf<br />
<br />
* [https://www.postgresql.org/message-id/f994fc98-389f-4a46-d1bc-c42e05cb43ed@sigaev.ru Incorrect application of unique-inner join logic]<br />
** correctness issue fixed by commit 2057a58d1629ebffce694e3cef7f714571a88dd7<br />
** performance issue fixed by commit 92a43e4857d9682b93c9f755f453cc8fd7c66c81<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1wfBgFPbfAMYZQE78p=VhZX7nN86aWkp0QcCp=+KxZ=bg@mail.gmail.com \password and PQencryptPassword]<br />
** original commit: {{PgCommitURL|818fd4a}} (principal author: Michael Paquier; owner: Heikki Linnakangas, {{messageLink|20170410035323.GA2846583@tornado.leadboat.com|notified}})<br />
** fixed by commit 8f8b9be51fd788bb11276df89606bc653163524e<br />
<br />
* pg_dump and partitioned tables<br />
** original commit: {{PgCommitURL|f0e4475}} (principal author: Amit Langote; owner: Stephen Frost, [http://postgr.es/m/20170413150540.GQ9812@tamriel.snowman.net previously Robert Haas])<br />
** {{messageLink|20170409235057.GA2842536@tornado.leadboat.com|notified}}<br />
** [https://www.postgresql.org/message-id/7682253a-6f79-6a92-00aa-267c4c412870%40lab.ntt.co.jp pg_dump should not emit ALTER TABLE ONLY for a partitioned table in case of attribute changes and inheritable constraints]<br />
*** patch exists<br />
** [https://www.postgresql.org/message-id/20170217133251.GK9812%40tamriel.snowman.net pg_dump TAP tests around partitioning]<br />
** fixed by commit 44c528810a1eca52a7888ed74c08353d45331b00<br />
<br />
* [https://www.postgresql.org/message-id/E4978C3DF3524C03A6729DD1BDC723A9@tunaPC pgoutput is not built with MSVC]<br />
** fixed by commit 28d1c8ccc87128f9b0b937eae277473027c36b7e<br />
<br />
* [http://postgr.es/m/22cc402c-88eb-fa35-217f-0060db2c72f0@2ndquadrant.com Logical replication - TRAP: FailedAssertion in pgstat.c]<br />
** fixed by commit 9a591c1bccc5edeb06b979c59f39753982131181<br />
<br />
* [http://postgr.es/m/4c6d34e1-dc54-89eb-787e-4620f5fb56f9@enterprisedb.com ALTER SUBSCRIPTION doesn't check connection string validity]<br />
** fixed by commit fe974cc5a69903e9f53b36d6e2709fd3de0a1ac7<br />
<br />
* [https://www.postgresql.org/message-id/29431.1493730652@sss.pgh.pa.us Having DROP SLOT option on DROP SUBSCRIPTION is broken by design]<br />
** fixed by commit 013c1178fd0adefa0f68d5ce2d84e7ae6f9613a1<br />
<br />
* [http://postgr.es/m/CA+Tgmoa7ZnfNq2zBO9og7DAQDe7+FctR7WggGx2tbLXYeXHBFw@mail.gmail.com consider adding pg_dump --no-subscriptions]<br />
** fixed by commit 26aa1cf376f68b800b73c326edeea6d1996ec246<br />
<br />
* [https://www.postgresql.org/message-id/flat/9A2F6FEC-D510-4AD6-8082-A1021040C840%40postgrespro.ru Logical replication worker ApplyContext bloat]<br />
** fixed by commit 489b96e80b96c0eda02575347654e87968f2f5f4<br />
<br />
* [http://postgr.es/m/CAEepm=2xJFFpGM+N=gpWx-9Nft2q1oaFZX07_y23AHCrJQLt0g@mail.gmail.com Transition tables for triggers on foreign tables and views] are broken<br />
** fixed by commit 9e6104c6672dc948a430d1ee269b0c31bf5bc974<br />
<br />
* [http://postgr.es/m/CANEvxPoOodsb_ZJwgSOLpYic5s4-0pZOJWrWnRU-TpgV9KJQdA@mail.gmail.com assertion failure when rescanning transition table]<br />
** fixed by commit 304007d9f1f66fd37e50e5a5aa6f17400f1239f8<br />
<br />
* [http://postgr.es/m/CAEepm=0VR5W-N38eTkO_FqJbGqQ_ykbBRmzmvHyxDhy1p=0Csw@mail.gmail.com assertion failure for TRUNCATE triggers with transition tables]<br />
** fixed by commit 29fd3d9da0ff9e230ff051c1423871bd6eac377d<br />
<br />
* [https://www.postgresql.org/message-id/CAA4eK1LAo4DGwh+mi-G3U8Pj1WkBBeFL38xdCnUHJv1z4bZFkQ@mail.gmail.com Remove pre-10 compatibility code in hash index]<br />
** fixed by commit a5775991bb86d95939b3eb1173b88d8c5312962d<br />
<br />
* [http://postgr.es/m/CA+TgmoYe8_FZ9oNTxL-q42kUXGKCDrrG512qbyKAQw9ROBvQ9g@mail.gmail.com consider revising syntax to avoid NO prefixes] (NOCOPY, NOCONNECT, NOREFRESH, NODROP, NOPUBLISH)<br />
** fixed by commit b807f59828fbc02fea612e1cbc0066c6dfa3be9b<br />
<br />
* [https://www.postgresql.org/message-id/CAB7nPqRrwQrnWx=JmiRp3ARPH+o3AaUCaJnNbqN9J5SK5T3wQg@mail.gmail.com pg_dump --no-publications]<br />
** fixed by commit 96e1cb4c0fb45dfca2d8b0a58693b94cbdaabe11<br />
<br />
* [https://www.postgresql.org/message-id/CAKJS1f8O0njDKe8ePFQ-LK5-EjwThsDws6ohJ-+c6nWK+oUxtg@mail.gmail.com Rename wal location functions to "lsn"]<br />
** Backward compatibility is already broken for most of these functions during the xlog to wal rename, and it'll likely be too late to change this once beta1 is out.<br />
** [https://www.postgresql.org/message-id/CAKJS1f8PadYT90CBYh9d%2BUXZxeo0jFOJYL3_RD%2Bv1mBgLOmfFQ%40mail.gmail.com patch exists]<br />
** fixed by commit d10c626de47d8b048b663471c7785603a2ec8641<br />
<br />
* [https://www.postgresql.org/message-id/1dfff343-c74d-042f-fee1-547253be0a40%40lab.ntt.co.jp incorrect multi-column range partition constraint]<br />
** fixed by commit f8bffe9e6d700fd34759a92e47930ce9ba7dcbd5; see also 1848b73d4576e30c89ba450ad9f169774a6819bf<br />
<br />
* [https://www.postgresql.org/message-id/flat/2a822515-82a2-6374-a131-1f99054cf5f6%402ndquadrant.com#2a822515-82a2-6374-a131-1f99054cf5f6@2ndquadrant.com Time based lag tracking for logical replication]<br />
** fixed by commit 024711bb544645c8b1061e9f02b261e2e336981d<br />
<br />
* [https://www.postgresql.org/message-id/51f65289-54f8-2256-d107-937d662d69f1%402ndquadrant.com snapshot builder has bugs]<br />
** fixed by commits 2bef06d51646058c6bb480fcdbffb1f0cc914fed, 56e19d938dd1457ae078304df1b9903509a0a2bf, 955a684e0401954a58e956535107bc4b7136d952 and 524dbc14335cde0b18745f05a9112436d212f061<br />
<br />
* [https://www.postgresql.org/message-id/20075.1494633784@sss.pgh.pa.us statistics objects fail to cope with ALTER COLUMN TYPE]<br />
** fixed by commit b5b0db19b895f033ada35bc7c337183be7356977<br />
<br />
* [https://www.postgresql.org/message-id/D992B4C2-8F80-4DE0-8348-6E0696C3F967@citusdata.com ALTER SEQUENCE RESTART is not concurrent-safe]<br />
** fixed by commit f8dc1985fd390774aab4ab0ba71036d6d5e631a9<br />
<br />
=== resolved before 10beta2 ===<br />
<br />
* [https://www.postgresql.org/message-id/flat/c0135b04-91d9-60ca-0544-16566f5eb187@enterprisedb.com synchronous_commit missing from tab completion of CREATE SUBSCRIPTION]<br />
** fixed by commit 0fbfb65d4bfd429651dc28faf3ad1846c965e18d<br />
<br />
* [https://www.postgresql.org/message-id/6bac159c-4ba0-c33f-d01f-33ba01a36105@enterprisedb.com we should disallow subscribing a foreign table]<br />
** fixed by commit 944dc0f9cec7c3d33648f41aaecfbd976106e975<br />
<br />
* [https://www.postgresql.org/message-id/flat/6af0f58c-243c-8110-9547-ebb504ccb457%40enterprisedb.com#6af0f58c-243c-8110-9547-ebb504ccb457@enterprisedb.com Server Crashes if try to provide slot_name='none' at the time of creating subscription]<br />
** fixed by commit 62345698513cbcb3c48a6dae414abf0f24fd163a<br />
<br />
* [https://www.postgresql.org/message-id/e736bf16-3393-02af-44fc-4722128a4b4f%40lab.ntt.co.jp Event triggers + table partitioning cause server crash in current master]<br />
** fixed by commit 3ec76ff1f2cf52e9b900349957b42d28128b7bc7<br />
<br />
* [https://www.postgresql.org/message-id/6b2fb5ff-40e1-fda3-3ce5-6723e9e5df61%40lab.ntt.co.jp Partitioned table Appends not coping with being referenced in subplans]<br />
** fixed by commit b522759508dae17535f8cd20598a50a409a97f4d<br />
<br />
* [https://www.postgresql.org/message-id/1803D792815FC24D871C00D17AE95905B1A34A@g01jpexmbkw24 If recovery.conf has target_session_attrs=read-write, the standby fails to start.]<br />
** fixed by commit aa41bc794c51a4d5c364cca014c199b1a00d26aa<br />
<br />
* [https://www.postgresql.org/message-id/0A3221C70F24FB45833433255569204D1F6F5924%40G01JPEXMBYT05 connect_timeout behavior differs between the documentation and the program]<br />
** {{messageLink|20170515034511.GP843225@rfd.leadboat.com|notified}}<br />
** fixed by commit 5f374fe7a83304fd339789da22599bd102dac9e5<br />
<br />
* [https://www.postgresql.org/message-id/CAA4eK1Jidtagm7Q81q-WoegOVgkotv0OxvHOjFxcvFRP4X%3DmSw%40mail.gmail.com pg_upgrade support for hash indexes]<br />
** original commit: {{PgCommitURL|ea69a0d}} (principal author: Mithun Cy; owner: Robert Haas {{messageLink|20170515040837.GR843225@rfd.leadboat.com|notified}})<br />
** fixed by commit a95410e2ec39b6776381fd01198dc57a063e8185<br />
<br />
* [https://www.postgresql.org/message-id/CAD21AoBEKzQot24KhgW8_kTTi-SGLEM7Kh8EuW8Nj%3Dv46qvSBA%40mail.gmail.com Improvement in log message of logical replication worker]<br />
** fixed by commit 92ecb148e517704ec945dce513db71fee7790cfd<br />
<br />
* [http://postgr.es/m/CAB7nPqR0G5aF2_kc_LH29knVqwvmBc66TF5DicvpGVdke68nKw@mail.gmail.com Server ignores SASL mechanism name defined in SASLInitialResponse] (Author: Heikki Linnakangas; Owner: Heikki Linnakangas)<br />
** fixed by commit 505b5d2f8672f13c98dd744a6d421da14f59cd39<br />
<br />
* [http://postgr.es/m/20170524024550.29935.14396@wrigleys.postgresql.org Partition definition for money type looks broken] (principal author: Amit Langote ; owner: Robert Haas)<br />
** fixed by commit 76a3df6e5e621928fbf0cddf347e16a62e9433ec<br />
<br />
* [http://postgr.es/m/fbd1d566-bba0-a3de-d6d0-d3b1d7c24ff2@postgrespro.ru PATCH: recursive json_populate_record()] has bugs<br />
** fixed by commits e45c5be99d08d7bb6708d7bb1dd0f5d99798c6aa and 68cff231e3a3d0ca9988cf1fde5a3be53235b3bb<br />
<br />
* [https://www.postgresql.org/message-id/E1dFBEX-0004wt-8t@gemulon.postgresql.org lack of location support in outfuncs/readfuncs for partitioning node types]<br />
** fixed by commit 80f583ffe930b21d6e5c47be4342356e57851a9a<br />
<br />
* [https://www.postgresql.org/message-id/CAMkU=1wOqi_W9gfXWVzMvugc9tJXVX+q_8tymOqWe6RwSgNPWw@mail.gmail.com ALTER PUBLICATION documentation: referenced first variant no longer exists]<br />
** fixed by commit 185364b161512806d23ca390f5b615666079699b<br />
<br />
== Challenges Carried over to PostgreSQL 11 ==<br />
<br />
* [https://www.postgresql.org/message-id/1700970.cRWpxnom9y@hammer.magicstack.net libpq connection failover: Use more efficient mechanism instead of SHOW transaction_read_only, add the ability to connect to the standby]<br />
** original commit: {{PgCommitURL|274bb2b3}} (principal author: Robert Haas; owner: Robert Haas)<br />
** Right now, libpq issues SHOW transaction_read_only upon each connection. This is inefficient, and we should use some GUC_REPORT variable to avoid this round-trip when connecting to PG10 or later. In addition, target_session_attrs=read-only should be available even in PG10 to meet the average expectation.<br />
** Robert is [https://www.postgresql.org/message-id/CA%2BTgmoYcWdbFkvsDkEPVgHL1y%2BbXidfu9JeXYJh6OQGJ%2BRAknQ%40mail.gmail.com skeptical about changing this now]<br />
** patch exists<br />
<br />
== Important Dates ==<br />
<br />
Current schedule:<br />
* feature freeze: April 7th<br />
* beta1: wrap May 15th, announce May 18th<br />
<br />
References:<br />
* [https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting#9:55_-_10:05_.09Next_Release_Schedule_.09All original schedule]<br />
* [https://www.postgresql.org/message-id/CA%2BTgmoZNLxizOkPy4WKdxwKo40Hz96v5jZ%3D07aLe93JW2dZmRA%40mail.gmail.com feature freeze moved]</div>Mha