https://github.com/postgres/postgres
- HEAD
- refs/heads/REL2_0B
- refs/heads/REL6_4
- refs/heads/REL6_5_PATCHES
- refs/heads/REL7_0_PATCHES
- refs/heads/REL7_1_STABLE
- refs/heads/REL7_2_STABLE
- refs/heads/REL7_3_STABLE
- refs/heads/REL7_4_STABLE
- refs/heads/REL8_0_STABLE
- refs/heads/REL8_1_STABLE
- refs/heads/REL8_2_STABLE
- refs/heads/REL8_3_STABLE
- refs/heads/REL8_4_STABLE
- refs/heads/REL8_5_ALPHA1_BRANCH
- refs/heads/REL8_5_ALPHA2_BRANCH
- refs/heads/REL8_5_ALPHA3_BRANCH
- refs/heads/REL9_0_ALPHA4_BRANCH
- refs/heads/REL9_0_ALPHA5_BRANCH
- refs/heads/REL9_0_STABLE
- refs/heads/REL9_1_STABLE
- refs/heads/REL9_2_STABLE
- refs/heads/REL9_3_STABLE
- refs/heads/REL9_4_STABLE
- refs/heads/REL9_5_STABLE
- refs/heads/REL9_6_STABLE
- refs/heads/REL_10_STABLE
- refs/heads/REL_11_STABLE
- refs/heads/REL_12_STABLE
- refs/heads/REL_13_STABLE
- refs/heads/REL_14_STABLE
- refs/heads/REL_15_STABLE
- refs/heads/REL_16_STABLE
- refs/heads/Release_1_0_3
- refs/heads/WIN32_DEV
- refs/heads/ecpg_big_bison
- refs/heads/master
- refs/tags/PG95-1_01
- refs/tags/PG95-1_08
- refs/tags/PG95-1_09
- refs/tags/REL2_0
- refs/tags/REL6_1
- refs/tags/REL6_1_1
- refs/tags/REL6_2
- refs/tags/REL6_2_1
- refs/tags/REL6_3
- refs/tags/REL6_3_2
- refs/tags/REL6_4_2
- refs/tags/REL6_5
- refs/tags/REL6_5_1
- refs/tags/REL6_5_2
- refs/tags/REL6_5_3
- refs/tags/REL7_0
- refs/tags/REL7_0_2
- refs/tags/REL7_0_3
- refs/tags/REL7_1
- refs/tags/REL7_1_1
- refs/tags/REL7_1_2
- refs/tags/REL7_1_3
- refs/tags/REL7_1_BETA
- refs/tags/REL7_1_BETA2
- refs/tags/REL7_1_BETA3
- refs/tags/REL7_2
- refs/tags/REL7_2_1
- refs/tags/REL7_2_2
- refs/tags/REL7_2_3
- refs/tags/REL7_2_4
- refs/tags/REL7_2_5
- refs/tags/REL7_2_6
- refs/tags/REL7_2_7
- refs/tags/REL7_2_8
- refs/tags/REL7_2_BETA1
- refs/tags/REL7_2_BETA2
- refs/tags/REL7_2_BETA3
- refs/tags/REL7_2_BETA4
- refs/tags/REL7_2_BETA5
- refs/tags/REL7_2_RC1
- refs/tags/REL7_2_RC2
- refs/tags/REL7_3
- refs/tags/REL7_3_1
- refs/tags/REL7_3_10
- refs/tags/REL7_3_11
- refs/tags/REL7_3_12
- refs/tags/REL7_3_13
- refs/tags/REL7_3_14
- refs/tags/REL7_3_15
- refs/tags/REL7_3_16
- refs/tags/REL7_3_17
- refs/tags/REL7_3_18
- refs/tags/REL7_3_19
- refs/tags/REL7_3_2
- refs/tags/REL7_3_20
- refs/tags/REL7_3_21
- refs/tags/REL7_3_3
- refs/tags/REL7_3_4
- refs/tags/REL7_3_5
- refs/tags/REL7_3_6
- refs/tags/REL7_3_7
- refs/tags/REL7_3_8
- refs/tags/REL7_3_9
- refs/tags/REL7_4
- refs/tags/REL7_4_1
- refs/tags/REL7_4_10
- refs/tags/REL7_4_11
- refs/tags/REL7_4_12
- refs/tags/REL7_4_13
- refs/tags/REL7_4_14
- refs/tags/REL7_4_15
- refs/tags/REL7_4_16
- refs/tags/REL7_4_17
- refs/tags/REL7_4_18
- refs/tags/REL7_4_19
- refs/tags/REL7_4_2
- refs/tags/REL7_4_20
- refs/tags/REL7_4_21
- refs/tags/REL7_4_22
- refs/tags/REL7_4_23
- refs/tags/REL7_4_24
- refs/tags/REL7_4_25
- refs/tags/REL7_4_26
- refs/tags/REL7_4_27
- refs/tags/REL7_4_28
- refs/tags/REL7_4_29
- refs/tags/REL7_4_3
- refs/tags/REL7_4_30
- refs/tags/REL7_4_4
- refs/tags/REL7_4_5
- refs/tags/REL7_4_6
- refs/tags/REL7_4_7
- refs/tags/REL7_4_8
- refs/tags/REL7_4_9
- refs/tags/REL7_4_BETA1
- refs/tags/REL7_4_BETA2
- refs/tags/REL7_4_BETA3
- refs/tags/REL7_4_BETA4
- refs/tags/REL7_4_BETA5
- refs/tags/REL7_4_RC1
- refs/tags/REL7_4_RC2
- refs/tags/REL8_0_0
- refs/tags/REL8_0_0BETA1
- refs/tags/REL8_0_0BETA2
- refs/tags/REL8_0_0BETA3
- refs/tags/REL8_0_0BETA4
- refs/tags/REL8_0_0BETA5
- refs/tags/REL8_0_0RC1
- refs/tags/REL8_0_0RC2
- refs/tags/REL8_0_0RC3
- refs/tags/REL8_0_0RC4
- refs/tags/REL8_0_0RC5
- refs/tags/REL8_0_1
- refs/tags/REL8_0_10
- refs/tags/REL8_0_11
- refs/tags/REL8_0_12
- refs/tags/REL8_0_13
- refs/tags/REL8_0_14
- refs/tags/REL8_0_15
- refs/tags/REL8_0_16
- refs/tags/REL8_0_17
- refs/tags/REL8_0_18
- refs/tags/REL8_0_19
- refs/tags/REL8_0_2
- refs/tags/REL8_0_20
- refs/tags/REL8_0_21
- refs/tags/REL8_0_22
- refs/tags/REL8_0_23
- refs/tags/REL8_0_24
- refs/tags/REL8_0_25
- refs/tags/REL8_0_26
- refs/tags/REL8_0_3
- refs/tags/REL8_0_4
- refs/tags/REL8_0_5
- refs/tags/REL8_0_6
- refs/tags/REL8_0_7
- refs/tags/REL8_0_8
- refs/tags/REL8_0_9
- refs/tags/REL8_1_0
- refs/tags/REL8_1_0BETA1
- refs/tags/REL8_1_0BETA2
- refs/tags/REL8_1_0BETA3
- refs/tags/REL8_1_0BETA4
- refs/tags/REL8_1_0RC1
- refs/tags/REL8_1_1
- refs/tags/REL8_1_10
- refs/tags/REL8_1_11
- refs/tags/REL8_1_12
- refs/tags/REL8_1_13
- refs/tags/REL8_1_14
- refs/tags/REL8_1_15
- refs/tags/REL8_1_16
- refs/tags/REL8_1_17
- refs/tags/REL8_1_18
- refs/tags/REL8_1_19
- refs/tags/REL8_1_2
- refs/tags/REL8_1_20
- refs/tags/REL8_1_21
- refs/tags/REL8_1_22
- refs/tags/REL8_1_23
- refs/tags/REL8_1_3
- refs/tags/REL8_1_4
- refs/tags/REL8_1_5
- refs/tags/REL8_1_6
- refs/tags/REL8_1_7
- refs/tags/REL8_1_8
- refs/tags/REL8_1_9
- refs/tags/REL8_2_0
- refs/tags/REL8_2_1
- refs/tags/REL8_2_10
- refs/tags/REL8_2_11
- refs/tags/REL8_2_12
- refs/tags/REL8_2_13
- refs/tags/REL8_2_14
- refs/tags/REL8_2_15
- refs/tags/REL8_2_16
- refs/tags/REL8_2_17
- refs/tags/REL8_2_18
- refs/tags/REL8_2_19
- refs/tags/REL8_2_2
- refs/tags/REL8_2_20
- refs/tags/REL8_2_21
- refs/tags/REL8_2_22
- refs/tags/REL8_2_23
- refs/tags/REL8_2_3
- refs/tags/REL8_2_4
- refs/tags/REL8_2_5
- refs/tags/REL8_2_6
- refs/tags/REL8_2_7
- refs/tags/REL8_2_8
- refs/tags/REL8_2_9
- refs/tags/REL8_2_BETA1
- refs/tags/REL8_2_BETA2
- refs/tags/REL8_2_BETA3
- refs/tags/REL8_2_RC1
- refs/tags/REL8_3_0
- refs/tags/REL8_3_1
- refs/tags/REL8_3_10
- refs/tags/REL8_3_11
- refs/tags/REL8_3_12
- refs/tags/REL8_3_13
- refs/tags/REL8_3_14
- refs/tags/REL8_3_15
- refs/tags/REL8_3_16
- refs/tags/REL8_3_17
- refs/tags/REL8_3_18
- refs/tags/REL8_3_19
- refs/tags/REL8_3_2
- refs/tags/REL8_3_20
- refs/tags/REL8_3_21
- refs/tags/REL8_3_22
- refs/tags/REL8_3_23
- refs/tags/REL8_3_3
- refs/tags/REL8_3_4
- refs/tags/REL8_3_5
- refs/tags/REL8_3_6
- refs/tags/REL8_3_7
- refs/tags/REL8_3_8
- refs/tags/REL8_3_9
- refs/tags/REL8_3_BETA1
- refs/tags/REL8_3_BETA2
- refs/tags/REL8_3_BETA3
- refs/tags/REL8_3_BETA4
- refs/tags/REL8_3_RC1
- refs/tags/REL8_3_RC2
- refs/tags/REL8_4_0
- refs/tags/REL8_4_1
- refs/tags/REL8_4_10
- refs/tags/REL8_4_11
- refs/tags/REL8_4_12
- refs/tags/REL8_4_13
- refs/tags/REL8_4_14
- refs/tags/REL8_4_15
- refs/tags/REL8_4_16
- refs/tags/REL8_4_17
- refs/tags/REL8_4_18
- refs/tags/REL8_4_19
- refs/tags/REL8_4_2
- refs/tags/REL8_4_20
- refs/tags/REL8_4_21
- refs/tags/REL8_4_22
- refs/tags/REL8_4_3
- refs/tags/REL8_4_4
- refs/tags/REL8_4_5
- refs/tags/REL8_4_6
- refs/tags/REL8_4_7
- refs/tags/REL8_4_8
- refs/tags/REL8_4_9
- refs/tags/REL8_4_BETA1
- refs/tags/REL8_4_BETA2
- refs/tags/REL8_4_RC1
- refs/tags/REL8_4_RC2
- refs/tags/REL8_5_ALPHA1
- refs/tags/REL8_5_ALPHA2
- refs/tags/REL8_5_ALPHA3
- refs/tags/REL9_0_0
- refs/tags/REL9_0_1
- refs/tags/REL9_0_10
- refs/tags/REL9_0_11
- refs/tags/REL9_0_12
- refs/tags/REL9_0_13
- refs/tags/REL9_0_14
- refs/tags/REL9_0_15
- refs/tags/REL9_0_16
- refs/tags/REL9_0_17
- refs/tags/REL9_0_18
- refs/tags/REL9_0_19
- refs/tags/REL9_0_2
- refs/tags/REL9_0_20
- refs/tags/REL9_0_21
- refs/tags/REL9_0_22
- refs/tags/REL9_0_23
- refs/tags/REL9_0_3
- refs/tags/REL9_0_4
- refs/tags/REL9_0_5
- refs/tags/REL9_0_6
- refs/tags/REL9_0_7
- refs/tags/REL9_0_8
- refs/tags/REL9_0_9
- refs/tags/REL9_0_ALPHA4
- refs/tags/REL9_0_ALPHA5
- refs/tags/REL9_0_BETA1
- refs/tags/REL9_0_BETA2
- refs/tags/REL9_0_BETA3
- refs/tags/REL9_0_BETA4
- refs/tags/REL9_0_RC1
- refs/tags/REL9_1_0
- refs/tags/REL9_1_1
- refs/tags/REL9_1_10
- refs/tags/REL9_1_11
- refs/tags/REL9_1_12
- refs/tags/REL9_1_13
- refs/tags/REL9_1_14
- refs/tags/REL9_1_15
- refs/tags/REL9_1_16
- refs/tags/REL9_1_17
- refs/tags/REL9_1_18
- refs/tags/REL9_1_19
- refs/tags/REL9_1_2
- refs/tags/REL9_1_20
- refs/tags/REL9_1_21
- refs/tags/REL9_1_22
- refs/tags/REL9_1_23
- refs/tags/REL9_1_24
- refs/tags/REL9_1_3
- refs/tags/REL9_1_4
- refs/tags/REL9_1_5
- refs/tags/REL9_1_6
- refs/tags/REL9_1_7
- refs/tags/REL9_1_8
- refs/tags/REL9_1_9
- refs/tags/REL9_1_ALPHA1
- refs/tags/REL9_1_ALPHA2
- refs/tags/REL9_1_ALPHA3
- refs/tags/REL9_1_ALPHA4
- refs/tags/REL9_1_ALPHA5
- refs/tags/REL9_1_BETA1
- refs/tags/REL9_1_BETA2
- refs/tags/REL9_1_BETA3
- refs/tags/REL9_1_RC1
- refs/tags/REL9_2_0
- refs/tags/REL9_2_1
- refs/tags/REL9_2_10
- refs/tags/REL9_2_11
- refs/tags/REL9_2_12
- refs/tags/REL9_2_13
- refs/tags/REL9_2_14
- refs/tags/REL9_2_15
- refs/tags/REL9_2_16
- refs/tags/REL9_2_17
- refs/tags/REL9_2_18
- refs/tags/REL9_2_19
- refs/tags/REL9_2_2
- refs/tags/REL9_2_20
- refs/tags/REL9_2_21
- refs/tags/REL9_2_22
- refs/tags/REL9_2_23
- refs/tags/REL9_2_24
- refs/tags/REL9_2_3
- refs/tags/REL9_2_4
- refs/tags/REL9_2_5
- refs/tags/REL9_2_6
- refs/tags/REL9_2_7
- refs/tags/REL9_2_8
- refs/tags/REL9_2_9
- refs/tags/REL9_2_BETA1
- refs/tags/REL9_2_BETA2
- refs/tags/REL9_2_BETA3
- refs/tags/REL9_2_BETA4
- refs/tags/REL9_2_RC1
- refs/tags/REL9_3_0
- refs/tags/REL9_3_1
- refs/tags/REL9_3_10
- refs/tags/REL9_3_11
- refs/tags/REL9_3_12
- refs/tags/REL9_3_13
- refs/tags/REL9_3_14
- refs/tags/REL9_3_15
- refs/tags/REL9_3_16
- refs/tags/REL9_3_17
- refs/tags/REL9_3_18
- refs/tags/REL9_3_19
- refs/tags/REL9_3_2
- refs/tags/REL9_3_20
- refs/tags/REL9_3_21
- refs/tags/REL9_3_22
- refs/tags/REL9_3_23
- refs/tags/REL9_3_24
- refs/tags/REL9_3_25
- refs/tags/REL9_3_3
- refs/tags/REL9_3_4
- refs/tags/REL9_3_5
- refs/tags/REL9_3_6
- refs/tags/REL9_3_7
- refs/tags/REL9_3_8
- refs/tags/REL9_3_9
- refs/tags/REL9_3_BETA1
- refs/tags/REL9_3_BETA2
- refs/tags/REL9_3_RC1
- refs/tags/REL9_4_0
- refs/tags/REL9_4_1
- refs/tags/REL9_4_10
- refs/tags/REL9_4_11
- refs/tags/REL9_4_12
- refs/tags/REL9_4_13
- refs/tags/REL9_4_14
- refs/tags/REL9_4_15
- refs/tags/REL9_4_16
- refs/tags/REL9_4_17
- refs/tags/REL9_4_18
- refs/tags/REL9_4_19
- refs/tags/REL9_4_2
- refs/tags/REL9_4_20
- refs/tags/REL9_4_21
- refs/tags/REL9_4_22
- refs/tags/REL9_4_23
- refs/tags/REL9_4_24
- refs/tags/REL9_4_25
- refs/tags/REL9_4_26
- refs/tags/REL9_4_3
- refs/tags/REL9_4_4
- refs/tags/REL9_4_5
- refs/tags/REL9_4_6
- refs/tags/REL9_4_7
- refs/tags/REL9_4_8
- refs/tags/REL9_4_9
- refs/tags/REL9_4_BETA1
- refs/tags/REL9_4_BETA2
- refs/tags/REL9_4_BETA3
- refs/tags/REL9_4_RC1
- refs/tags/REL9_5_0
- refs/tags/REL9_5_1
- refs/tags/REL9_5_10
- refs/tags/REL9_5_11
- refs/tags/REL9_5_12
- refs/tags/REL9_5_13
- refs/tags/REL9_5_14
- refs/tags/REL9_5_15
- refs/tags/REL9_5_16
- refs/tags/REL9_5_17
- refs/tags/REL9_5_18
- refs/tags/REL9_5_19
- refs/tags/REL9_5_2
- refs/tags/REL9_5_20
- refs/tags/REL9_5_21
- refs/tags/REL9_5_22
- refs/tags/REL9_5_23
- refs/tags/REL9_5_24
- refs/tags/REL9_5_25
- refs/tags/REL9_5_3
- refs/tags/REL9_5_4
- refs/tags/REL9_5_5
- refs/tags/REL9_5_6
- refs/tags/REL9_5_7
- refs/tags/REL9_5_8
- refs/tags/REL9_5_9
- refs/tags/REL9_5_ALPHA1
- refs/tags/REL9_5_ALPHA2
- refs/tags/REL9_5_BETA1
- refs/tags/REL9_5_BETA2
- refs/tags/REL9_5_RC1
- refs/tags/REL9_6_0
- refs/tags/REL9_6_1
- refs/tags/REL9_6_10
- refs/tags/REL9_6_11
- refs/tags/REL9_6_12
- refs/tags/REL9_6_13
- refs/tags/REL9_6_14
- refs/tags/REL9_6_15
- refs/tags/REL9_6_16
- refs/tags/REL9_6_17
- refs/tags/REL9_6_18
- refs/tags/REL9_6_19
- refs/tags/REL9_6_2
- refs/tags/REL9_6_20
- refs/tags/REL9_6_21
- refs/tags/REL9_6_22
- refs/tags/REL9_6_23
- refs/tags/REL9_6_24
- refs/tags/REL9_6_3
- refs/tags/REL9_6_4
- refs/tags/REL9_6_5
- refs/tags/REL9_6_6
- refs/tags/REL9_6_7
- refs/tags/REL9_6_8
- refs/tags/REL9_6_9
- refs/tags/REL9_6_BETA1
- refs/tags/REL9_6_BETA2
- refs/tags/REL9_6_BETA3
- refs/tags/REL9_6_BETA4
- refs/tags/REL9_6_RC1
- refs/tags/REL_10_0
- refs/tags/REL_10_1
- refs/tags/REL_10_10
- refs/tags/REL_10_11
- refs/tags/REL_10_12
- refs/tags/REL_10_13
- refs/tags/REL_10_14
- refs/tags/REL_10_15
- refs/tags/REL_10_16
- refs/tags/REL_10_17
- refs/tags/REL_10_18
- refs/tags/REL_10_19
- refs/tags/REL_10_2
- refs/tags/REL_10_20
- refs/tags/REL_10_21
- refs/tags/REL_10_22
- refs/tags/REL_10_23
- refs/tags/REL_10_3
- refs/tags/REL_10_4
- refs/tags/REL_10_5
- refs/tags/REL_10_6
- refs/tags/REL_10_7
- refs/tags/REL_10_8
- refs/tags/REL_10_9
- refs/tags/REL_10_BETA1
- refs/tags/REL_10_BETA2
- refs/tags/REL_10_BETA3
- refs/tags/REL_10_BETA4
- refs/tags/REL_10_RC1
- refs/tags/REL_11_0
- refs/tags/REL_11_1
- refs/tags/REL_11_10
- refs/tags/REL_11_11
- refs/tags/REL_11_12
- refs/tags/REL_11_13
- refs/tags/REL_11_14
- refs/tags/REL_11_15
- refs/tags/REL_11_16
- refs/tags/REL_11_17
- refs/tags/REL_11_18
- refs/tags/REL_11_19
- refs/tags/REL_11_2
- refs/tags/REL_11_20
- refs/tags/REL_11_21
- refs/tags/REL_11_22
- refs/tags/REL_11_3
- refs/tags/REL_11_4
- refs/tags/REL_11_5
- refs/tags/REL_11_6
- refs/tags/REL_11_7
- refs/tags/REL_11_8
- refs/tags/REL_11_9
- refs/tags/REL_11_BETA1
- refs/tags/REL_11_BETA2
- refs/tags/REL_11_BETA3
- refs/tags/REL_11_BETA4
- refs/tags/REL_11_RC1
- refs/tags/REL_12_0
- refs/tags/REL_12_1
- refs/tags/REL_12_10
- refs/tags/REL_12_11
- refs/tags/REL_12_12
- refs/tags/REL_12_13
- refs/tags/REL_12_14
- refs/tags/REL_12_15
- refs/tags/REL_12_16
- refs/tags/REL_12_17
- refs/tags/REL_12_18
- refs/tags/REL_12_2
- refs/tags/REL_12_3
- refs/tags/REL_12_4
- refs/tags/REL_12_5
- refs/tags/REL_12_6
- refs/tags/REL_12_7
- refs/tags/REL_12_8
- refs/tags/REL_12_9
- refs/tags/REL_12_BETA1
- refs/tags/REL_12_BETA2
- refs/tags/REL_12_BETA3
- refs/tags/REL_12_BETA4
- refs/tags/REL_12_RC1
- refs/tags/REL_13_0
- refs/tags/REL_13_1
- refs/tags/REL_13_10
- refs/tags/REL_13_11
- refs/tags/REL_13_12
- refs/tags/REL_13_13
- refs/tags/REL_13_14
- refs/tags/REL_13_2
- refs/tags/REL_13_3
- refs/tags/REL_13_4
- refs/tags/REL_13_5
- refs/tags/REL_13_6
- refs/tags/REL_13_7
- refs/tags/REL_13_8
- refs/tags/REL_13_9
- refs/tags/REL_13_BETA1
- refs/tags/REL_13_BETA2
- refs/tags/REL_13_BETA3
- refs/tags/REL_13_RC1
- refs/tags/REL_14_0
- refs/tags/REL_14_1
- refs/tags/REL_14_10
- refs/tags/REL_14_11
- refs/tags/REL_14_2
- refs/tags/REL_14_3
- refs/tags/REL_14_4
- refs/tags/REL_14_5
- refs/tags/REL_14_6
- refs/tags/REL_14_7
- refs/tags/REL_14_8
- refs/tags/REL_14_9
- refs/tags/REL_14_BETA1
- refs/tags/REL_14_BETA2
- refs/tags/REL_14_BETA3
- refs/tags/REL_14_RC1
- refs/tags/REL_15_0
- refs/tags/REL_15_1
- refs/tags/REL_15_2
- refs/tags/REL_15_3
- refs/tags/REL_15_4
- refs/tags/REL_15_5
- refs/tags/REL_15_6
- refs/tags/REL_15_BETA1
- refs/tags/REL_15_BETA2
- refs/tags/REL_15_BETA3
- refs/tags/REL_15_BETA4
- refs/tags/REL_15_RC1
- refs/tags/REL_15_RC2
- refs/tags/REL_16_0
- refs/tags/REL_16_1
- refs/tags/REL_16_2
- refs/tags/REL_16_BETA1
- refs/tags/REL_16_BETA2
- refs/tags/REL_16_BETA3
- refs/tags/REL_16_RC1
- refs/tags/Release_1_0_2
- refs/tags/Release_2_0
- refs/tags/Release_2_0_0
- refs/tags/release-6-3
No releases to show
Take a new snapshot of a software origin
If the archived software origin currently browsed is not synchronized with its upstream version (for instance when new commits have been issued), you can explicitly request Software Heritage to take a new snapshot of it.
Use the form below to proceed. Once a request has been submitted and accepted, it will be processed as soon as possible. You can then check its processing state by visiting this dedicated page.Processing "take a new snapshot" request ...
Permalinks
To reference or cite the objects present in the Software Heritage archive, permalinks based on SoftWare Hash IDentifiers (SWHIDs) must be used.
Select below a type of object currently browsed in order to display its associated SWHID and permalink.
Revision | Author | Date | Message | Commit Date |
---|---|---|---|---|
2fbecb6 | Tom Lane | 05 August 2019, 21:16:54 UTC | Stamp 10.10. | 05 August 2019, 21:16:54 UTC |
f61bc00 | Tom Lane | 05 August 2019, 15:49:14 UTC | Last-minute updates for release notes. Security: CVE-2019-10208, CVE-2019-10209 | 05 August 2019, 15:49:14 UTC |
2062007 | Noah Misch | 05 August 2019, 14:48:41 UTC | Require the schema qualification in pg_temp.type_name(arg). Commit aa27977fe21a7dfa4da4376ad66ae37cb8f0d0b5 introduced this restriction for pg_temp.function_name(arg); do likewise for types created in temporary schemas. Programs that this breaks should add "pg_temp." schema qualification or switch to arg::type_name syntax. Back-patch to 9.4 (all supported versions). Reviewed by Tom Lane. Reported by Tom Lane. Security: CVE-2019-10208 | 05 August 2019, 14:48:45 UTC |
5e32ae9 | Peter Eisentraut | 05 August 2019, 13:44:33 UTC | Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 361643d9eb7a2585dfcfc73838fee5a9940db6eb | 05 August 2019, 13:44:33 UTC |
e733adc | Michael Paquier | 05 August 2019, 05:30:27 UTC | Fix tab completion for ALTER LANGUAGE in psql OWNER_TO was used for the completion, which is not a supported grammar, but OWNER TO is. This error has been introduced by d37b816, so backpatch down to 9.6. Author: Alexander Lakhin Discussion: https://postgr.es/m/7ab243e0-116d-3e44-d120-76b3df7abefd@gmail.com Backpatch-through: 9.6 | 05 August 2019, 05:30:27 UTC |
670f2a4 | Tom Lane | 04 August 2019, 21:08:41 UTC | Release notes for 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24. | 04 August 2019, 21:08:41 UTC |
cb00744 | Michael Paquier | 01 August 2019, 00:38:14 UTC | Fix handling of previous password hooks in passwordcheck When piling up loading of modules using check_password_hook_type, loading passwordcheck would remove any trace of a previously-loaded hook. Unloading the module would also cause previous hooks to be entirely gone. Reported-by: Rafael Castro Author: Michael Paquier Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/15932-78f48f9ef166778c@postgresql.org Backpatch-through: 9.4 | 01 August 2019, 00:38:14 UTC |
7615afa | Tom Lane | 31 July 2019, 19:42:50 UTC | Fix pg_dump's handling of dependencies for custom opclasses. Since pg_dump doesn't treat the member operators and functions of operator classes/families (that is, the pg_amop and pg_amproc entries, not the underlying operators/functions) as separate dumpable objects, it missed their dependency information. I think this was safe when the code was designed, because the default object sorting rule emits operators and functions before opclasses, and there were no dependency types that could mess that up. However, the introduction of range types in 9.2 broke it: now a type can have a dependency on an opclass, allowing dependency rules to push the opclass before the type and hence before custom operators. Lacking any information showing that it shouldn't do so, pg_dump emitted the objects in the wrong order. Fix by teaching getDependencies() to translate pg_depend entries for pg_amop/amproc rows to look like dependencies for their parent opfamily. I added a regression test for this in HEAD/v12, but not further back; life is too short to fight with 002_pg_dump.pl. Per bug #15934 from Tom Gottfried. Back-patch to all supported branches. Discussion: https://postgr.es/m/15934-58b8c8ab7a09ea15@postgresql.org | 31 July 2019, 19:42:50 UTC |
35fc44b | Heikki Linnakangas | 30 July 2019, 18:14:14 UTC | Print WAL position correctly in pg_rewind error message. This has been wrong ever since pg_rewind was added. The if-branch just above this, where we print the same error with an extra message supplied by XLogReadRecord() got this right, but the variable name was wrong in the else-branch. As a consequence, the error printed the WAL position as 0/0 if there was an error reading a WAL file. Backpatch to 9.5, where pg_rewind was added. | 30 July 2019, 18:14:45 UTC |
859b300 | Tomas Vondra | 30 July 2019, 17:17:12 UTC | Don't build extended statistics on inheritance trees When performing ANALYZE on inheritance trees, we collect two samples for each relation - one for the relation alone, and one for the inheritance subtree (relation and its child relations). And then we build statistics on each sample, so for each relation we get two sets of statistics. For regular (per-column) statistics this works fine, because the catalog includes a flag differentiating statistics built from those two samples. But we don't have such flag in the extended statistics catalogs, and we ended up updating the same row twice, triggering this error: ERROR: tuple already updated by self The simplest solution is to disable extended statistics on inheritance trees, which is what this commit is doing. In the future we may need to do something similar to per-column statistics, but that requires adding a flag to the catalog - and that's not backpatchable. Moreover, the current selectivity estimation code only works with individual relations, so building statistics on inheritance trees would be pointless anyway. Author: Tomas Vondra Backpatch-to: 10- Discussion: https://postgr.es/m/20190618231233.GA27470@telsasoft.com Reported-by: Justin Pryzby | 30 July 2019, 17:48:39 UTC |
af41ab5 | Tom Lane | 29 July 2019, 22:49:04 UTC | Fix busted logic for parallel lock grouping in TopoSort(). A "break" statement erroneously left behind by commit a1c1af2a1 caused TopoSort to do the wrong thing if a lock's wait list contained multiple members of the same locking group. Because parallel workers don't normally need any locks not already taken by their leader, this is very hard --- maybe impossible --- to hit in production. Still, if it did happen, the queries involved in an otherwise-resolvable deadlock would block until canceled. In addition to removing the bogus "break", add an Assert showing that the conflicting uses of the beforeConstraints[] array (for both counts and flags) don't overlap, and add some commentary explaining why not; because it's not obvious without explanation, IMHO. Original report and patch from Rui Hai Jiang; additional assert and commentary by me. Back-patch to 9.6 where the bug came in. Discussion: https://postgr.es/m/CAEri+mLd3bpHLyW+a9pSe1y=aEkeuJpwBSwvo-+m4n7-ceRmXw@mail.gmail.com | 29 July 2019, 22:49:04 UTC |
e9ecf73 | Michael Paquier | 28 July 2019, 13:02:39 UTC | Doc: Fix event trigger firing table The table has not been updated for some commands introduced in recent releases, so refresh it. While on it, reorder entries alphabetically. Backpatch all the way down for all the commands which have gone missing. Reported-by: Jeremy Smith Discussion: https://postgr.es/m/15883-afff0ea3cc2dbbb6@postgresql.org Backpatch-through: 9.4 | 28 July 2019, 13:02:39 UTC |
52608f3 | Alvaro Herrera | 26 July 2019, 21:46:40 UTC | Don't uselessly escape a string that doesn't need escaping Per gripe from Ian Barwick Co-authored-by: Ian Barwick <ian@2ndquadrant.com> Discussion: https://postgr.es/m/CABvVfJWNnNKb8cHsTLhkTsvL1+G6BVcV+57+w1JZ61p8YGPdWQ@mail.gmail.com | 26 July 2019, 21:46:40 UTC |
46c1932 | Tom Lane | 26 July 2019, 19:17:03 UTC | Fix possible lockup in pgbench with -R. pgbench would sometimes get stuck waiting forever after its last client thread terminated, due to failing to check for there being nothing more to wait for. Bug introduced during refactoring in v10 (I didn't bother to try to assign blame to a specific commit). It's already repaired in HEAD/v12 thanks to commit 3bac77c48, but v10 and v11 need this fix. Fabien Coelho, per report from Tomas Vondra; reviewed by Yoshikazu Imai Discussion: https://postgr.es/m/cc5d76c1-6144-bbed-ad1b-961d13d88f3b@2ndquadrant.com | 26 July 2019, 19:17:03 UTC |
55862b2 | Tom Lane | 26 July 2019, 17:07:08 UTC | Tweak our special-case logic for the IANA "Factory" timezone. pg_timezone_names() tries to avoid showing the "Factory" zone in the view, mainly because that has traditionally had a very long "abbreviation" such as "Local time zone must be set--see zic manual page", so that showing it messes up psql's formatting of the whole view. Since tzdb version 2016g, IANA instead uses the abbreviation "-00", which is sane enough that there's no reason to discriminate against it. On the other hand, it emerges that FreeBSD and possibly other packagers are so wedded to backwards compatibility that they hack the IANA data to keep the old spelling --- and not just that old spelling, but even older spellings that IANA used back in the stone age. This caused the filter logic to fail to suppress "Factory" at all on such platforms, though the formatting problem is definitely real in that case. To solve both problems, get rid of the hard-wired assumption about exactly what Factory's abbreviation is, and instead reject abbreviations exceeding 31 characters. This will allow Factory to appear in the view if and only if it's using the modern abbreviation. In passing, simplify the code we add to zic.c to support "zic -P" to remove its now-obsolete hacks to not print the Factory zone's abbreviation. Unlike pg_timezone_names(), there's no reason for that code to support old/nonstandard timezone data. Since we generally prefer to keep timezone-related behavior the same in all branches, and since this is arguably a bug fix, back-patch to all supported branches. Discussion: https://postgr.es/m/3961.1564086915@sss.pgh.pa.us | 26 July 2019, 17:07:08 UTC |
ae9b91b | Tom Lane | 26 July 2019, 16:45:32 UTC | Avoid choosing "localtime" or "posixrules" as TimeZone during initdb. Some platforms create a file named "localtime" in the system timezone directory, making it a copy or link to the active time zone file. If Postgres is built with --with-system-tzdata, initdb will see that file as an exact match to localtime(3)'s behavior, and it may decide that "localtime" is the most preferred spelling of the active zone. That's a very bad choice though, because it's neither informative, nor portable, nor stable if someone changes the system timezone setting. Extend the preference logic added by commit e3846a00c so that we will prefer any other zone file that matches localtime's behavior over "localtime". On the same logic, also discriminate against "posixrules", which is another not-really-a-zone file that is often present in the timezone directory. (Since we install "posixrules" but not "localtime", this change can affect the behavior of Postgres with or without --with-system-tzdata.) Note that this change doesn't prevent anyone from choosing these pseudo-zones if they really want to (i.e., by setting TZ for initdb, or modifying the timezone GUC later on). It just prevents initdb from preferring these zone names when there are multiple matches to localtime's behavior. Since we generally prefer to keep timezone-related behavior the same in all branches, and since this is arguably a bug fix, back-patch to all supported branches. Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us | 26 July 2019, 16:46:03 UTC |
fa85411 | Tom Lane | 26 July 2019, 15:59:00 UTC | Fix loss of fractional digits for large values in cash_numeric(). Money values exceeding about 18 digits (depending on lc_monetary) could be inaccurately converted to numeric, due to select_div_scale() deciding it didn't need to compute any fractional digits. Force its hand by setting the dscale of one division input to equal the number of fractional digits we need. In passing, rearrange the logic to not do useless work in locales where money values are considered integral. Per bug #15925 from Slawomir Chodnicki. Back-patch to all supported branches. Discussion: https://postgr.es/m/15925-da9953e2674bb5c8@postgresql.org | 26 July 2019, 15:59:00 UTC |
ed304d1 | Tom Lane | 25 July 2019, 18:42:02 UTC | Fix syntax error in commit 20e99cddd. Per buildfarm. | 25 July 2019, 18:42:16 UTC |
cb65b45 | Tom Lane | 25 July 2019, 16:10:55 UTC | Fix failures to ignore \r when reading Windows-style newlines. libpq failed to ignore Windows-style newlines in connection service files. This normally wasn't a problem on Windows itself, because fgets() would convert \r\n to just \n. But if libpq were running inside a program that changes the default fopen mode to binary, it would see the \r's and think they were data. In any case, it's project policy to ignore \r in text files unconditionally, because people sometimes try to use files with DOS-style newlines on Unix machines, where the C library won't hide that from us. Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of the line. In HEAD, go a little further and make it ignore all trailing whitespace, to match what it's always done with leading whitespace. In HEAD, also run around and fix up everyplace where we have newline-chomping code to make all those places look consistent and uniformly drop \r. It is not clear whether any of those changes are fixing live bugs. Most of the non-cosmetic changes are in places that are reading popen output, and the jury is still out as to whether popen on Windows can return \r\n. (The Windows-specific code in pipe_read_line seems to think so, but our lack of support for this elsewhere suggests maybe it's not a problem in practice.) Hence, I desisted from applying those changes to back branches, except in run_ssl_passphrase_command() which is new enough and little-tested enough that we'd probably not have heard about any problems there. Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha. Back-patch the parseServiceFile() change to all supported branches, and the run_ssl_passphrase_command() change to v11 where that was added. Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org | 25 July 2019, 16:11:21 UTC |
165f4ee | Andrew Dunstan | 25 July 2019, 15:24:23 UTC | Honor MSVC WindowsSDKVersion if set Add a line to the project file setting the target SDK. Otherwise, in for example VS2017, if the default but optional 8.1 SDK is not installed the build will fail. Patch from Peifeng Qiu, slightly edited by me. Discussion: https://postgr.es/m/CABmtVJhw1boP_bd4=b3Qv5YnqEdL696NtHFi2ruiyQ6mFHkeQQ@mail.gmail.com Backpatch to all live branches. | 25 July 2019, 15:39:45 UTC |
5c3d472 | Tom Lane | 25 July 2019, 15:02:43 UTC | Fix contrib/sepgsql test policy to work with latest SELinux releases. As of Fedora 30, it seems that the system-provided macros for setting up user privileges in SELinux policies don't grant the ability to read /etc/passwd, as they formerly did. This restriction breaks psql (which tries to use getpwuid() to obtain the user name it's running under) and thereby the contrib/sepgsql regression test. Add explicit specifications that we need the right to read /etc/passwd. Mike Palmiotto, per a report from me. Back-patch to all supported branches. Discussion: https://postgr.es/m/23856.1563381159@sss.pgh.pa.us | 25 July 2019, 15:03:13 UTC |
183cd8c | Michael Paquier | 24 July 2019, 22:55:37 UTC | Fix failure with pgperlcritic from the TAP test of synchronous replication Oversight in 7d81bdc, which introduced a new routine in perl lacking a return clause. Per buildfarm member crake. Backpatch down to 9.6 like its parent. Reported-by: Andrew Dunstan Discussion: https://postgr.es/m/16da29fa-d504-1380-7095-40de586dc038@2ndQuadrant.com Backpatch-through: 9.6 | 24 July 2019, 22:55:37 UTC |
3808cf2 | Tom Lane | 24 July 2019, 22:14:27 UTC | Fix infelicities in describeOneTableDetails' partitioned-table handling. describeOneTableDetails issued a partition-constraint-fetching query for every table, even ones it knows perfectly well are not partitions. To add insult to injury, it then proceeded to leak the empty PGresult if the table wasn't a partition. Doing that a lot of times might amount to a meaningful leak, so this seems like a back-patchable bug. Fix that, and also fix a related PGresult leak in the partition-parent case (though that leak would occur only if we got no row, which is unexpected). Minor code beautification too, to make this code look more like the pre-existing code around it. Back-patch the whole change into v12. However, the fact that we already know whether the table is a partition dates only to commit 1af25ca0c; back-patching the relevant changes from that is probably more churn than is justified in released branches. Hence, in v11 and v10, just do the minimum to fix the PGresult leaks. Noted while messing around with adjacent code for yesterday's \d improvements. | 24 July 2019, 22:14:27 UTC |
ba7359d | Michael Paquier | 24 July 2019, 07:02:23 UTC | Fix build of documentation Oversight in 1c42346, which has incorrectly shaped a <xref> markup. Only v10 and v9.6 got broken. Reported-by: Stefan Kaltenbrunner Discussion: https://postgr.es/m/675cde90-a8dc-faeb-4701-d35a89ee06a2@kaltenbrunner.cc | 24 July 2019, 07:02:23 UTC |
1c42346 | Michael Paquier | 24 July 2019, 02:26:33 UTC | Doc: Clarify interactions of pg_receivewal with remote_apply Using pg_receivewal with synchronous_commit = remote_apply set in the backend is incompatible if pg_receivewal is a synchronous standby as it never applies WAL, so document this problem and solutions to it. Backpatch to 9.6, where remote_apply has been added. Author: Robert Haas, Jesper Pedersen Reviewed-by: Laurenz Albe, Álvaro Herrera, Michael Paquier Discussion: https://postgr.es/m/1427a2d3-1e51-9335-1931-4f8853d90d5e@redhat.com Backpatch-through: 9.6 | 24 July 2019, 02:26:33 UTC |
46fb7ff | Michael Paquier | 24 July 2019, 01:54:32 UTC | Improve stability of TAP test for synchronous replication Slow buildfarm machines have run into issues with this TAP test caused by a race condition related to the startup of a set of standbys, where it is possible to finish with an unexpected order in the WAL sender array of the primary. This closes the race condition by making sure that any standby started is registered into the WAL sender array of the primary before starting the next one based on lookups of pg_stat_replication. Backpatch down to 9.6 where the test has been introduced. Author: Michael Paquier Reviewed-by: Álvaro Herrera, Noah Misch Discussion: https://postgr.es/m/20190617055145.GB18917@paquier.xyz Backpatch-through: 9.6 | 24 July 2019, 01:54:32 UTC |
7ac7bf5 | Tom Lane | 22 July 2019, 21:14:22 UTC | Make pg_upgrade's test.sh less chatty. Remove "set -x", and pass "-A trust" to initdb explicitly, to suppress almost all of the noise this script used to emit on stderr. Back-patch of commit eb9812f27 into all active branches. Discussion: https://postgr.es/m/21766.1558397960@sss.pgh.pa.us Discussion: https://postgr.es/m/20190722193459.GA14241@alvherre.pgsql | 22 July 2019, 21:14:22 UTC |
0e1deaa | Tom Lane | 22 July 2019, 18:55:23 UTC | Install dependencies to prevent dropping partition key columns. The logic in ATExecDropColumn that rejects dropping partition key columns is quite an inadequate defense, because it doesn't execute in cases where a column needs to be dropped due to cascade from something that only the column, not the whole partitioned table, depends on. That leaves us with a badly broken partitioned table; even an attempt to load its relcache entry will fail. We really need to have explicit pg_depend entries that show that the column can't be dropped without dropping the whole table. Hence, add those entries. In v12 and HEAD, bump catversion to ensure that partitioned tables will have such entries. We can't do that in released branches of course, so in v10 and v11 this patch affords protection only to partitioned tables created after the patch is installed. Given the lack of field complaints (this bug was found by fuzz-testing not by end users), that's probably good enough. In passing, fix ATExecDropColumn and ATPrepAlterColumnType messages to be more specific about which partition key column they're complaining about. Per report from Manuel Rigger. Back-patch to v10 where partitioned tables were added. Discussion: https://postgr.es/m/CA+u7OA4JKCPFrdrAbOs7XBiCyD61XJxeNav4LefkSmBLQ-Vobg@mail.gmail.com Discussion: https://postgr.es/m/31920.1562526703@sss.pgh.pa.us | 22 July 2019, 18:55:23 UTC |
8a4fa29 | Tom Lane | 19 July 2019, 18:48:57 UTC | Silence compiler warning, hopefully. Absorb commit e5e04c962a5d12eebbf867ca25905b3ccc34cbe0 from upstream IANA code, in hopes of silencing warnings from MSVC about negating a bool value. Discussion: https://postgr.es/m/20190719035347.GJ1859@paquier.xyz | 19 July 2019, 18:49:15 UTC |
b0a7e0f | Jeff Davis | 18 July 2019, 23:49:25 UTC | Fix error in commit e6feef57. I was careless passing a datum directly to DATE_NOT_FINITE without calling DatumGetDateADT() first. Backpatch-through: 9.4 | 18 July 2019, 23:49:25 UTC |
955089d | Jeff Davis | 18 July 2019, 23:49:10 UTC | Fix daterange canonicalization for +/- infinity. The values 'infinity' and '-infinity' are a part of the DATE type itself, so a bound of the date 'infinity' is not the same as an unbounded/infinite range. However, it is still wrong to try to canonicalize such values, because adding or subtracting one has no effect. Fix by treating 'infinity' and '-infinity' the same as unbounded ranges for the purposes of canonicalization (but not other purposes). Backpatch to all versions because it is inconsistent with the documented behavior. Note that this could be an incompatibility for applications relying on the behavior contrary to the documentation. Author: Laurenz Albe Reviewed-by: Thomas Munro Discussion: https://postgr.es/m/77f24ea19ab802bc9bc60ddbb8977ee2d646aec1.camel%40cybertec.at Backpatch-through: 9.4 | 18 July 2019, 23:49:10 UTC |
53256e8 | Tom Lane | 17 July 2019, 23:15:21 UTC | Update time zone data files to tzdata release 2019b. Brazil no longer observes DST. Historical corrections for Palestine, Hong Kong, and Italy. | 17 July 2019, 23:15:48 UTC |
ccc323b | Tom Lane | 17 July 2019, 22:26:24 UTC | Sync our copy of the timezone library with IANA release tzcode2019b. A large fraction of this diff is just due to upstream's somewhat random decision to rename a bunch of internal variables and struct fields. However, there is an interesting new feature in zic: it's grown a "-b slim" option that emits zone files without 32-bit data and other backwards-compatibility hacks. We should consider whether we wish to enable that. | 17 July 2019, 22:26:24 UTC |
583025c | Tom Lane | 16 July 2019, 22:17:47 UTC | Fix thinko in construction of old_conpfeqop list. This should lappend the OIDs, not lcons them; the existing code produced a list in reversed order. This is harmless for single-key FKs or FKs where all the key columns are of the same type, which probably explains how it went unnoticed. But if those conditions are not met, ATAddForeignKeyConstraint would make the wrong decision about whether an existing FK needs to be revalidated. I think it would almost always err in the safe direction by revalidating a constraint that didn't need it. You could imagine scenarios where the pfeqop check was fooled by swapping the types of two FK columns in one ALTER TABLE, but that case would probably be rejected by other tests, so it might be impossible to get to the worst-case scenario where an FK should be revalidated and isn't. (And even then, it's likely to be fine, unless there are weird inconsistencies in the equality behavior of the replacement types.) However, this is a performance bug at least. Noted while poking around to see whether lcons calls could be converted to lappend. This bug is old, dating to commit cb3a7c2b9, so back-patch to all supported branches. | 16 July 2019, 22:17:47 UTC |
f68060c | Bruce Momjian | 16 July 2019, 00:57:24 UTC | doc: mention pg_reload_conf() for reloading the config file Reported-by: Ian Barwick Discussion: https://postgr.es/m/538950ec-b86a-1650-6078-beb7091c09c2@2ndquadrant.com Backpatch-through: 9.4 | 16 July 2019, 00:57:24 UTC |
15f2f27 | Thomas Munro | 14 July 2019, 02:19:54 UTC | Fix documentation for pgbench tpcb-like. We choose a random value for delta, not balance. Back-patch to 9.6 where the mistake arrived. Author: Fabien Coelho Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081752210.5867@lancre | 14 July 2019, 02:25:45 UTC |
4fea343 | Michael Paquier | 10 July 2019, 06:15:11 UTC | Fix variable initialization when using buffering build with GiST This can cause valgrind to complain, as the flag marking a buffer as a temporary copy was not getting initialized. While on it, fill in with zeros newly-created buffer pages. This does not matter when loading a block from a temporary file, but it makes the push of an index tuple into a new buffer page safer. This has been introduced by 1d27dcf, so backpatch all the way down to 9.4. Author: Alexander Lakhin Discussion: https://postgr.es/m/15899-0d24fb273b3dd90c@postgresql.org Backpatch-through: 9.4 | 10 July 2019, 06:15:11 UTC |
72b5267 | Thomas Munro | 09 July 2019, 22:16:02 UTC | Pass QueryEnvironment down to EvalPlanQual's EState. Otherwise the executor can't see trigger transition tables during EPQ evaluation. Fixes bug #15900 and almost certainly also #15720. Back-patch to 10, where trigger transition tables landed. Author: Alex Aktsipetrov Reviewed-by: Thomas Munro, Tom Lane Discussion: https://postgr.es/m/15900-bc482754fe8d7415%40postgresql.org Discussion: https://postgr.es/m/15720-38c2b29e5d720187%40postgresql.org | 09 July 2019, 22:16:02 UTC |
a5407d1 | Peter Eisentraut | 08 July 2019, 12:28:42 UTC | doc: Clarify logical replication documentation Document that the data types of replicated tables do not need to match. The documentation previously claimed that they had to match. Author: Robert Treat <rob@xzilla.net> Discussion: https://www.postgresql.org/message-id/flat/CAJSLCQ13==D8Ka2YLyctTm0Y+8MhGYcX_zj7fU0rqRzhcV++3w@mail.gmail.com | 08 July 2019, 12:29:11 UTC |
232019b | David Rowley | 03 July 2019, 11:46:06 UTC | Don't remove surplus columns from GROUP BY for inheritance parents d4c3a156c added code to remove columns that were not part of a table's PRIMARY KEY constraint from the GROUP BY clause when all the primary key columns were present in the group by. This is fine to do since we know that there will only be one row per group coming from this relation. However, the logic failed to consider inheritance parent relations. These can have child relations without a primary key, but even if they did, they could duplicate one of the parent's rows or one from another child relation. In this case, those additional GROUP BY columns are required. Fix this by disabling the optimization for inheritance parent tables. In v11 and beyond, partitioned tables are fine since partitions cannot overlap and before v11 partitioned tables could not have a primary key. Reported-by: Manuel Rigger Discussion: http://postgr.es/m/CA+u7OA7VLKf_vEr6kLF3MnWSA9LToJYncgpNX2tQ-oWzYCBQAw@mail.gmail.com Backpatch-through: 9.6 | 03 July 2019, 11:46:06 UTC |
0ce8e49 | Michael Paquier | 02 July 2019, 23:58:04 UTC | Add support for Visual Studio 2019 in build scripts This adjusts the documentation and the scripts related to the versions of Windows SDK supported. Author: Haribabu Kommi Reviewed-by: Andrew Dunstan, Juan José Santamaría Flecha, Michael Paquier Discussion: https://postgr.es/m/CAJrrPGcfqXhfPyMrny9apoDU7M1t59dzVAvoJ9AeAh5BJi+UzA@mail.gmail.com Backpatch-through: 9.4 | 02 July 2019, 23:58:04 UTC |
90434e6 | Tom Lane | 02 July 2019, 17:35:14 UTC | Fix tab completion of "SET variable TO|=" to not offer bogus completions. Don't think that the context "UPDATE tab SET var =" is a GUC-setting command. If we have "SET var =" but the "var" is not a known GUC variable, don't offer any completions. The most likely explanation is that we've misparsed the context and it's not really a GUC-setting command. Per gripe from Ken Tanzer. Back-patch to 9.6. The issue exists further back, but before 9.6 the code looks very different and it doesn't actually know whether the "var" name matches anything, so I desisted from trying to fix it. Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com | 02 July 2019, 17:35:14 UTC |
cd9d489 | Noah Misch | 01 July 2019, 00:34:17 UTC | Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType. UBSan complains about this. Instead, cast to a suitable type requiring only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast between AnyArrayType and ArrayType, so this doesn't introduce a new assumption. Back-patch to 9.5, where AnyArrayType was introduced. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190629210334.GA1244217@rfd.leadboat.com | 01 July 2019, 00:34:20 UTC |
a1637ca | Andrew Gierth | 30 June 2019, 22:49:25 UTC | Repair logic for reordering grouping sets optimization. The logic in reorder_grouping_sets to order grouping set elements to match a pre-specified sort ordering was defective, resulting in unnecessary sort nodes (though the query output would still be correct). Repair, simplifying the code a little, and add a test. Per report from Richard Guo, though I didn't use their patch. Original bug seems to have been my fault. Backpatch back to 9.5 where grouping sets were introduced. Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2LsWw0WO1A@mail.gmail.com | 30 June 2019, 22:49:25 UTC |
69da8c1 | Thomas Munro | 27 June 2019, 23:11:26 UTC | Fix misleading comment in nodeIndexonlyscan.c. The stated reason for acquiring predicate locks on heap pages hasn't existed since commit c01262a8, so fix the comment. Perhaps in a later release we'll also be able to change the code to use tuple locks. Back-patch all the way. Reviewed-by: Ashwin Agrawal Discussion: https://postgr.es/m/CAEepm%3D2GK3FVdnt5V3d%2Bh9njWipCv_fNL%3DwjxyUhzsF%3D0PcbNg%40mail.gmail.com | 28 June 2019, 05:16:44 UTC |
0161e52 | Tomas Vondra | 27 June 2019, 16:14:25 UTC | Update reference to sampling algorithm in analyze.c Commit 83e176ec1 moved row sampling functions from analyze.c to utils/misc/sampling.c, but failed to update comment referring to the sampling algorithm from Jeff Vitter's paper. Correct the comment by pointing to utils/misc/sampling.c. Author: Etsuro Fujita Discussion: https://postgr.es/m/CAPmGK154gp%2BQd%3DcorQOv%2BPmbyVyZBjp_%2Bhb766UJeD1e_ie6XQ%40mail.gmail.com | 27 June 2019, 16:15:05 UTC |
a559805 | Michael Paquier | 26 June 2019, 14:05:06 UTC | Add support for OpenSSL 1.1.0 and newer versions in MSVC scripts Up to now, the MSVC build scripts are able to support only one fixed version of OpenSSL, and they lacked logic to detect the version of OpenSSL a given compilation of Postgres is linking to (currently 1.0.2, the latest LTS of upstream which will be EOL'd at the end of 2019). This commit adds more logic to detect the version of OpenSSL used by a build and makes use of it to add support for compilation with OpenSSL 1.1.0 which requires a new set of compilation flags to work properly. The supported OpenSSL installers have changed their library layer with various library renames with the upgrade to 1.1.0, making the logic a bit more complicated. The scripts are now able to adapt to the new world order. Reported-by: Sergey Pashkov Author: Juan José Santamaría Flecha, Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/15789-8fc75dea3c5a17c8@postgresql.org Backpatch-through: 9.4 | 26 June 2019, 14:05:06 UTC |
8093144 | Tom Lane | 26 June 2019, 03:19:31 UTC | Follow the rule that regression-test-created roles are named "regress_xxx". contrib/amcheck didn't get the memo either. | 26 June 2019, 03:19:31 UTC |
131e545 | Michael Paquier | 25 June 2019, 02:16:04 UTC | Fix thinkos in LookupFuncName() for function name lookups This could trigger valgrind failures when doing ambiguous function name lookups when no arguments are provided by the caller. The problem has been introduced in aefeb68, so backpatch to v10. HEAD is fine thanks to the refactoring done in bfb456c1. Reported-by: Alexander Lakhin Author: Alexander Lakhin, Michael Paquier Discussion: https://postgr.es/m/3d068be5-f617-a5ee-99f6-458a407bfd65@gmail.com Backpatch-through: 10 | 25 June 2019, 02:16:04 UTC |
956611e | Thomas Munro | 24 June 2019, 21:29:53 UTC | Don't unset MAKEFLAGS in non-GNU Makefile. It's useful to be able to pass down options like -s and -j. Back-patch to 9.5, like commit a76200de. Discussion: https://postgr.es/m/CA%2BhUKG%2Be1M8-BbL%3DPqhTp6oO6XPO6%2Bs9WGQMLfbuZ%3DG9CtzyXg%40mail.gmail.com | 24 June 2019, 21:40:54 UTC |
cb8962c | Tom Lane | 24 June 2019, 20:43:05 UTC | Further fix ALTER COLUMN TYPE's handling of indexes and index constraints. This patch reverts all the code changes of commit e76de8861, which turns out to have been seriously misguided. We can't wait till later to compute the definition string for an index; we must capture that before applying the data type change for any column it depends on, else ruleutils.c will deliverr wrong/misleading results. (This fine point was documented nowhere, of course.) I'd also managed to forget that ATExecAlterColumnType executes once per ALTER COLUMN TYPE clause, not once per statement; which resulted in the code being basically completely broken for any case in which multiple ALTER COLUMN TYPE clauses are applied to a table having non-constraint indexes that must be rebuilt. Through very bad luck, none of the existing test cases nor the ones added by e76de8861 caught that, but of course it was soon found in the field. The previous patch also had an implicit assumption that if a constraint's index had a dependency on a table column, so would the constraint --- but that isn't actually true, so it didn't fix such cases. Instead of trying to delete unneeded index dependencies later, do the is-there-a-constraint lookup immediately on seeing an index dependency, and switch to remembering the constraint if so. In the unusual case of multiple column dependencies for a constraint index, this will result in duplicate constraint lookups, but that's not that horrible compared to all the other work that happens here. Besides, such cases did not work at all before, so it's hard to argue that they're performance-critical for anyone. Per bug #15865 from Keith Fiske. As before, back-patch to all supported branches. Discussion: https://postgr.es/m/15865-17940eacc8f8b081@postgresql.org | 24 June 2019, 20:43:05 UTC |
05399b1 | Tom Lane | 23 June 2019, 00:31:50 UTC | Fix spinlock assembly code for MIPS so it works on MIPS r6. Original MIPS-I processors didn't have the LL/SC instructions (nor any other userland synchronization primitive). If the build toolchain targets that ISA variant by default, as an astonishingly large fraction of MIPS platforms still do, the assembler won't take LL/SC without coercion in the form of a ".set mips2" instruction. But we issued that unconditionally, making it an ISA downgrade for chips later than MIPS2. That breaks things for the latest MIPS r6 ISA, which encodes these instructions differently. Adjust the code so we don't change ISA level if it's >= 2. Note that this patch doesn't change what happens on an actual MIPS-I processor: either the kernel will emulate these instructions transparently, or you'll get a SIGILL failure. That tradeoff seemed fine in 2002 when this code was added (cf 3cbe6b247), and it's even more so today when MIPS-I is basically extinct. But let's add a comment about that. YunQiang Su (with cosmetic adjustments by me). Back-patch to all supported branches. Discussion: https://postgr.es/m/15844-8f62fe7e163939b3@postgresql.org | 23 June 2019, 00:31:50 UTC |
6121ba9 | Noah Misch | 22 June 2019, 03:34:23 UTC | Consolidate methods for translating a Perl path to a Windows path. This fixes some TAP suites when using msys Perl and a builddir located in an msys mount point other than "/". For example, builddir=/c/pg exhibited the problem, since /c/pg falls in mount point "/c". Back-patch to 9.6, where tests first started to perform such translations. In back branches, offer both new and old APIs. Reviewed by Andrew Dunstan. Discussion: https://postgr.es/m/20190610045838.GA238501@rfd.leadboat.com | 22 June 2019, 03:58:42 UTC |
df098c3 | Thomas Munro | 20 June 2019, 22:57:07 UTC | Remove obsolete comments about sempahores from proc.c. Commit 6753333f switched from a semaphore-based wait to a latch-based wait for ProcSleep()/ProcWakeup(), but left behind some stray references to semaphores. Back-patch to 9.5. Reviewed-by: Daniel Gustafsson, Michael Paquier Discussion: https://postgr.es/m/CA+hUKGLs5H6zhmgTijZ1OaJvC1sG0=AFXc1aHuce32tKiQrdEA@mail.gmail.com | 20 June 2019, 22:57:55 UTC |
0772d8a | Alvaro Herrera | 18 June 2019, 22:23:16 UTC | Avoid spurious deadlocks when upgrading a tuple lock This puts back reverted commit de87a084c0a5, with some bug fixes. When two (or more) transactions are waiting for transaction T1 to release a tuple-level lock, and transaction T1 upgrades its lock to a higher level, a spurious deadlock can be reported among the waiting transactions when T1 finishes. The simplest example case seems to be: T1: select id from job where name = 'a' for key share; Y: select id from job where name = 'a' for update; -- starts waiting for T1 Z: select id from job where name = 'a' for key share; T1: update job set name = 'b' where id = 1; Z: update job set name = 'c' where id = 1; -- starts waiting for T1 T1: rollback; At this point, transaction Y is rolled back on account of a deadlock: Y holds the heavyweight tuple lock and is waiting for the Xmax to be released, while Z holds part of the multixact and tries to acquire the heavyweight lock (per protocol) and goes to sleep; once T1 releases its part of the multixact, Z is awakened only to be put back to sleep on the heavyweight lock that Y is holding while sleeping. Kaboom. This can be avoided by having Z skip the heavyweight lock acquisition. As far as I can see, the biggest downside is that if there are multiple Z transactions, the order in which they resume after T1 finishes is not guaranteed. Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't work there (because isolationtester is not smart enough), so I'm not going to risk it. Author: Oleksii Kliukin Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com Discussion: https://postgr.es/m/2815.1560521451@sss.pgh.pa.us | 18 June 2019, 22:23:16 UTC |
cb4cb74 | Tom Lane | 17 June 2019, 21:18:49 UTC | Stamp 10.9. | 17 June 2019, 21:18:49 UTC |
8339895 | Tom Lane | 17 June 2019, 14:53:45 UTC | Last-minute updates for release notes. Security: CVE-2019-10164 | 17 June 2019, 14:53:45 UTC |
435a2bf | Peter Eisentraut | 17 June 2019, 13:00:56 UTC | Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 18b2987be55cfb9eaf7059e9d4e017642c40a2a8 | 17 June 2019, 13:32:45 UTC |
d72a7e4 | Michael Paquier | 17 June 2019, 13:14:09 UTC | Fix buffer overflow when processing SCRAM final message in libpq When a client connects to a rogue server sending specifically-crafted messages, this can suffice to execute arbitrary code as the operating system account used by the client. While on it, fix one error handling when decoding an incorrect salt included in the first message received from server. Author: Michael Paquier Reviewed-by: Jonathan Katz, Heikki Linnakangas Security: CVE-2019-10164 Backpatch-through: 10 | 17 June 2019, 13:14:09 UTC |
90adc16 | Michael Paquier | 17 June 2019, 12:48:34 UTC | Fix buffer overflow when parsing SCRAM verifiers in backend Any authenticated user can overflow a stack-based buffer by changing the user's own password to a purpose-crafted value. This often suffices to execute arbitrary code as the PostgreSQL operating system account. This fix is contributed by multiple folks, based on an initial analysis from Tom Lane. This issue has been introduced by 68e61ee, so it was possible to make use of it at authentication time. It became more easily to trigger after ccae190 which has made the SCRAM parsing more strict when changing a password, in the case where the client passes down a verifier already hashed using SCRAM. Back-patch to v10 where SCRAM has been introduced. Reported-by: Alexander Lakhin Author: Jonathan Katz, Heikki Linnakangas, Michael Paquier Security: CVE-2019-10164 Backpatch-through: 10 | 17 June 2019, 12:48:34 UTC |
93d4484 | Alvaro Herrera | 17 June 2019, 02:24:20 UTC | Revert "Avoid spurious deadlocks when upgrading a tuple lock" This reverts commits 3da73d6839dc and de87a084c0a5. This code has some tricky corner cases that I'm not sure are correct and not properly tested anyway, so I'm reverting the whole thing for next week's releases (reintroducing the deadlock bug that we set to fix). I'll try again afterwards. Discussion: https://postgr.es/m/E1hbXKQ-0003g1-0C@gemulon.postgresql.org | 17 June 2019, 02:24:20 UTC |
0e45e52 | Tom Lane | 16 June 2019, 19:39:08 UTC | Release notes for 10.9, 9.6.14, 9.5.18, 9.4.23. (11.4 notes are already done.) | 16 June 2019, 19:39:08 UTC |
2913a89 | Andrew Gierth | 15 June 2019, 17:15:23 UTC | Prefer timezone name "UTC" over alternative spellings. tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate zone with its own abbreviation. Unfortunately, our code for choosing a timezone in initdb has an arbitrary preference for names earlier in the alphabet, and so it would choose the spelling "UCT" over "UTC" when the system is running on a UTC zone. Commit 23bd3cec6 was backpatched in order to address this issue, but that code helps only when /etc/localtime exists as a symlink, and does nothing to help on systems where /etc/localtime is a copy of a zone file (as is the standard setup on FreeBSD and probably some other platforms too) or when /etc/localtime is simply absent (giving UTC as the default). Accordingly, add a preference for the spelling "UTC", such that if multiple zone names have equally good content matches, we prefer that name before applying the existing arbitrary rules. Also add a slightly lower preference for "Etc/UTC"; lower because that preserves the previous behaviour of choosing the shorter name, but letting us still choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does not (not common, but I've seen it happen). Backpatch all the way, because the tzdb change that sparked this issue is in those branches too. | 15 June 2019, 17:18:03 UTC |
7446397 | Alvaro Herrera | 14 June 2019, 15:33:40 UTC | Silence compiler warning Introduced in de87a084c0a5. | 14 June 2019, 15:33:40 UTC |
8de574a | Tom Lane | 14 June 2019, 15:25:13 UTC | Attempt to identify system timezone by reading /etc/localtime symlink. On many modern platforms, /etc/localtime is a symlink to a file within the IANA database. Reading the symlink lets us find out the name of the system timezone directly, without going through the brute-force search embodied in scan_available_timezones(). This shortens the runtime of initdb by some tens of ms, which is helpful for the buildfarm, and it also allows us to reliably select the same zone name the system was actually configured for, rather than possibly choosing one of IANA's many zone aliases. (For example, in a system configured for "Asia/Tokyo", the brute-force search would not choose that name but its alias "Japan", on the grounds of the latter string being shorter. More surprisingly, "Navajo" is preferred to either "America/Denver" or "US/Mountain", as seen in an old complaint from Josh Berkus.) If /etc/localtime doesn't exist, or isn't a symlink, or we can't make sense of its contents, or the contents match a zone we know but that zone doesn't match the observed behavior of localtime(), fall back to the brute-force search. Also, tweak initdb so that it prints the zone name it selected. In passing, replace the last few references to the "Olson" database in code comments with "IANA", as that's been our preferred term since commit b2cbced9e. Back-patch of commit 23bd3cec6. The original intention was to not back-patch, since this can result in cosmetic behavioral changes --- for example, on my own workstation initdb now chooses "America/New_York", where it used to prefer "US/Eastern" which is equivalent and shorter. However, our hand has been more or less forced by tzdb update 2019a, which made the "UCT" zone fully equivalent to "UTC". Our old code now prefers "UCT" on the grounds of it being alphabetically first, and that's making nobody happy. Choosing the alias indicated by /etc/localtime is a more defensible behavior. (Users who don't like the results can always force the decision by setting the TZ environment variable before running initdb.) Patch by me, per a suggestion from Robert Haas; review by Michael Paquier Discussion: https://postgr.es/m/7408.1525812528@sss.pgh.pa.us Discussion: https://postgr.es/m/20190604085735.GD24018@msg.df7cb.de | 14 June 2019, 15:25:13 UTC |
14a91a8 | Alvaro Herrera | 13 June 2019, 21:28:24 UTC | Avoid spurious deadlocks when upgrading a tuple lock When two (or more) transactions are waiting for transaction T1 to release a tuple-level lock, and transaction T1 upgrades its lock to a higher level, a spurious deadlock can be reported among the waiting transactions when T1 finishes. The simplest example case seems to be: T1: select id from job where name = 'a' for key share; Y: select id from job where name = 'a' for update; -- starts waiting for X Z: select id from job where name = 'a' for key share; T1: update job set name = 'b' where id = 1; Z: update job set name = 'c' where id = 1; -- starts waiting for X T1: rollback; At this point, transaction Y is rolled back on account of a deadlock: Y holds the heavyweight tuple lock and is waiting for the Xmax to be released, while Z holds part of the multixact and tries to acquire the heavyweight lock (per protocol) and goes to sleep; once X releases its part of the multixact, Z is awakened only to be put back to sleep on the heavyweight lock that Y is holding while sleeping. Kaboom. This can be avoided by having Z skip the heavyweight lock acquisition. As far as I can see, the biggest downside is that if there are multiple Z transactions, the order in which they resume after X finishes is not guaranteed. Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't work there (because isolationtester is not smart enough), so I'm not going to risk it. Author: Oleksii Kliukin Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com | 13 June 2019, 21:28:24 UTC |
945ae92 | Tom Lane | 13 June 2019, 14:53:17 UTC | Mark ReplicationSlotCtl as PGDLLIMPORT. Also MyReplicationSlot, in branches where it wasn't already. This was discussed in the thread that resulted in c572599c6, but for some reason nobody pulled the trigger. Now that we have another request for the same thing, we should just do it. Craig Ringer Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com Discussion: https://postgr.es/m/345138875.20190611151943@cybertec.at | 13 June 2019, 14:53:17 UTC |
0f2b234 | Etsuro Fujita | 13 June 2019, 08:59:12 UTC | postgres_fdw: Account for triggers in non-direct remote UPDATE planning. Previously, in postgresPlanForeignModify, we planned an UPDATE operation on a foreign table so that we transmit only columns that were explicitly targets of the UPDATE, so as to avoid unnecessary data transmission, but if there were BEFORE ROW UPDATE triggers on the foreign table, those triggers might change values for non-target columns, in which case we would miss sending changed values for those columns. Prevent optimizing away transmitting all columns if there are BEFORE ROW UPDATE triggers on the foreign table. This is an oversight in commit 7cbe57c34 which added triggers on foreign tables, so apply the patch all the way back to 9.4 where that came in. Author: Shohei Mochizuki Reviewed-by: Amit Langote Discussion: https://postgr.es/m/201905270152.x4R1q3qi014550@toshiba.co.jp | 13 June 2019, 08:59:12 UTC |
909a92e | Tom Lane | 13 June 2019, 02:54:46 UTC | Doc: improve description of allowed spellings for Boolean input. datatype.sgml failed to explain that boolin() accepts any unique prefix of the basic input strings. Indeed it was actively misleading because it called out a few minimal prefixes without mentioning that there were more valid inputs. I also felt that it wasn't doing anybody any favors by conflating SQL key words, valid Boolean input, and string literals containing valid Boolean input. Rewrite in hopes of reducing the confusion. Per bug #15836 from Yuming Wang, as diagnosed by David Johnston. Back-patch to supported branches. Discussion: https://postgr.es/m/15836-656fab055735f511@postgresql.org | 13 June 2019, 02:54:46 UTC |
30d3df0 | Tom Lane | 12 June 2019, 23:42:39 UTC | Fix incorrect printing of queries with duplicated join names. Given a query in which multiple JOIN nodes used the same alias (which'd necessarily be in different sub-SELECTs), ruleutils.c would assign the JOIN nodes distinct aliases for clarity ... but then it forgot to print the modified aliases when dumping the JOIN nodes themselves. This results in a dump/reload hazard for views, because the emitted query is flat-out incorrect: Vars will be printed with table names that have no referent. This has been wrong for a long time, so back-patch to all supported branches. Philip Dubé Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com | 12 June 2019, 23:43:10 UTC |
1bbcbfa | David Rowley | 12 June 2019, 22:35:47 UTC | doc: Fix grammatical error in partitioning docs Reported-by: Amit Langote Discussion: https://postgr.es/m/CA+HiwqGZFkKi0TkBGYpr2_5qrRAbHZoP47AP1BRLUOUkfQdy_A@mail.gmail.com Backpatch-through: 10 | 12 June 2019, 22:35:47 UTC |
ac8f2e1 | Tom Lane | 12 June 2019, 21:29:48 UTC | In walreceiver, don't try to do ereport() in a signal handler. This is quite unsafe, even for the case of ereport(FATAL) where we won't return control to the interrupted code, and despite this code's use of a flag to restrict the areas where we'd try to do it. It's possible for example that we interrupt malloc or free while that's holding a lock that's meant to protect against cross-thread interference. Then, any attempt to do malloc or free within ereport() will result in a deadlock, preventing the walreceiver process from exiting in response to SIGTERM. We hypothesize that this explains some hard-to-reproduce failures seen in the buildfarm. Hence, get rid of the immediate-exit code in WalRcvShutdownHandler, as well as the logic associated with WalRcvImmediateInterruptOK. Instead, we need to take care that potentially-blocking operations in the walreceiver's data transmission logic (libpqwalreceiver.c) will respond reasonably promptly to the process's latch becoming set and then call ProcessWalRcvInterrupts. Much of the needed code for that was already present in libpqwalreceiver.c. I refactored things a bit so that all the uses of PQgetResult use latch-aware waiting, but didn't need to do much more. These changes should be enough to ensure that libpqwalreceiver.c will respond promptly to SIGTERM whenever it's waiting to receive data. In principle, it could block for a long time while waiting to send data too, and this patch does nothing to guard against that. I think that that hazard is mostly theoretical though: such blocking should occur only if we fill the kernel's data transmission buffers, and we don't generally send enough data to make that happen without waiting for input. If we find out that the hazard isn't just theoretical, we could fix it by using PQsetnonblocking, but that would require more ticklish changes than I care to make now. Back-patch of commit a1a789eb5. This problem goes all the way back to the origins of walreceiver; but given the substantial reworking the module received during the v10 cycle, it seems unsafe to assume that our testing on HEAD validates this patch for pre-v10 branches. And we'd need to back-patch some prerequisite patches (at least 597a87ccc and its followups, maybe other things), increasing the risk of problems. Given the dearth of field reports matching this problem, it's not worth much risk. Hence back-patch to v10 and v11 only. Patch by me; thanks to Thomas Munro for review. Discussion: https://postgr.es/m/20190416070119.GK2673@paquier.xyz | 12 June 2019, 21:29:48 UTC |
2981e5a | Tom Lane | 12 June 2019, 16:29:24 UTC | Fix ALTER COLUMN TYPE failure with a partial exclusion constraint. ATExecAlterColumnType failed to consider the possibility that an index that needs to be rebuilt might be a child of a constraint that needs to be rebuilt. We missed this so far because usually a constraint index doesn't have a direct dependency on its table, just on the constraint object. But if there's a WHERE clause, then dependency analysis of the WHERE clause results in direct dependencies on the column(s) mentioned in WHERE. This led to trying to drop and rebuild both the constraint and its underlying index. In v11/HEAD, we successfully drop both the index and the constraint, and then try to rebuild both, and of course the second rebuild hits a duplicate-index-name problem. Before v11, it fails with obscure messages about a missing relation OID, due to trying to drop the index twice. This is essentially the same kind of problem noted in commit 20bef2c31: the possible dependency linkages are broader than what ATExecAlterColumnType was designed for. It was probably OK when written, but it's certainly been broken since the introduction of partial exclusion constraints. Fix by adding an explicit check for whether any of the indexes-to-be-rebuilt belong to any of the constraints-to-be-rebuilt, and ignoring any that do. In passing, fix a latent bug introduced by commit 8b08f7d48: in get_constraint_index() we must "continue" not "break" when rejecting a relation of a wrong relkind. This is harmless today because we don't expect that code path to be taken anyway; but if there ever were any relations to be ignored, the existing coding would have an extremely undesirable dependency on the order of pg_depend entries. Also adjust a couple of obsolete comments. Per bug #15835 from Yaroslav Schekin. Back-patch to all supported branches. Discussion: https://postgr.es/m/15835-32d9b7a76c06a7a9@postgresql.org | 12 June 2019, 16:29:42 UTC |
56a9325 | Michael Paquier | 12 June 2019, 02:31:00 UTC | Fix handling of COMMENT for domain constraints For a non-superuser, changing a comment on a domain constraint was leading to a cache lookup failure as the code tried to perform the ownership lookup on the constraint OID itself, thinking that it was a type, but this check needs to happen on the type the domain constraint relies on. As the type a domain constraint relies on can be guessed directly based on the constraint OID, first fetch its type OID and perform the ownership on it. This is broken since 7eca575, which has split the handling of comments for table constraints and domain constraints, so back-patch down to 9.5. Reported-by: Clemens Ladisch Author: Daniel Gustafsson, Michael Paquier Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/15833-808e11904835d26f@postgresql.org Backpatch-through: 9.5 | 12 June 2019, 02:31:00 UTC |
6e1dc84 | David Rowley | 11 June 2019, 20:09:28 UTC | doc: Add best practises section to partitioning docs A few questionable partitioning designs have been cropping up lately around the mailing lists. Generally, these cases have been partitioning using too many partitions which have caused performance or OOM problems for the users. Since we have very little else to guide users into good design, here we add a new section to the partitioning documentation with some best practise guidelines for good design. Reviewed-by: Justin Pryzby, Amit Langote, Alvaro Herrera Discussion: https://postgr.es/m/CAKJS1f-2rx+E9mG3xrCVHupefMjAp1+tpczQa9SEOZWyU7fjEA@mail.gmail.com Backpatch-through: 10 | 11 June 2019, 20:09:28 UTC |
b6f5689 | Tom Lane | 11 June 2019, 17:33:08 UTC | Fix conversion of JSON strings to JSON output columns in json_to_record(). json_to_record(), when an output column is declared as type json or jsonb, should emit the corresponding field of the input JSON object. But it got this slightly wrong when the field is just a string literal: it failed to escape the contents of the string. That typically resulted in syntax errors if the string contained any double quotes or backslashes. jsonb_to_record() handles such cases correctly, but I added corresponding test cases for it too, to prevent future backsliding. Improve the documentation, as it provided only a very hand-wavy description of the conversion rules used by these functions. Per bug report from Robert Vollmert. Back-patch to v10 where the error was introduced (by commit cf35346e8). Note that PG 9.4 - 9.6 also get this case wrong, but differently so: they feed the de-escaped contents of the string literal to json[b]_in. That behavior is less obviously wrong, so possibly it's being depended on in the field, so I won't risk trying to make the older branches behave like the newer ones. Discussion: https://postgr.es/m/D6921B37-BD8E-4664-8D5F-DB3525765DCD@vllmrt.net | 11 June 2019, 17:33:08 UTC |
52ad5fc | Andres Freund | 11 June 2019, 06:20:48 UTC | Don't access catalogs to validate GUCs when not connected to a DB. Vignesh found this bug in the check function for default_table_access_method's check hook, but that was just copied from older GUCs. Investigation by Michael and me then found the bug in further places. When not connected to a database (e.g. in a walsender connection), we cannot perform (most) GUC checks that need database access. Even when only shared tables are needed, unless they're nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed without pg_class etc. being present. Fix by extending the existing IsTransactionState() checks to also check for MyDatabaseOid. Reported-By: Vignesh C, Michael Paquier, Andres Freund Author: Vignesh C, Andres Freund Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com Backpatch: 9.4- | 11 June 2019, 06:36:48 UTC |
1eb8a5e | Alvaro Herrera | 10 June 2019, 22:56:23 UTC | Make pg_dump emit ATTACH PARTITION instead of PARTITION OF (reprise) Using PARTITION OF can result in column ordering being changed from the database being dumped, if the partition uses a column layout different from the parent's. It's not pg_dump's job to editorialize on table definitions, so this is not acceptable; back-patch all the way back to pg10, where partitioned tables where introduced. This change also ensures that partitions end up in the correct tablespace, if different from the parent's; this is an oversight in ca4103025dfe (in pg12 only). Partitioned indexes (in pg11) don't have this problem, because they're already created as independent indexes and attached to their parents afterwards. This change also has the advantage that the partition is restorable from the dump (as a standalone table) even if its parent table isn't restored. The original commits (3b23552ad8bb in branch master) failed to cover subsidiary column elements correctly, such as NOT NULL constraint and CHECK constraints, as reported by Rushabh Lathia (initially as a failure to restore serial columns). They were reverted. This recapitulation commit fixes those problems. Add some pg_dump tests to verify these things more exhaustively, including constraints with legacy-inheritance tables, which were not tested originally. In branches 10 and 11, add a local constraint to the pg_dump test partition that was added by commit 2d7eeb1b1492 to master. Author: Álvaro Herrera, David Rowley Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com Discussion: https://postgr.es/m/20190423185007.GA27954@alvherre.pgsql Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com | 10 June 2019, 22:56:23 UTC |
589f91f | Alexander Korotkov | 10 June 2019, 17:14:19 UTC | Fix operator naming in pg_trgm GUC option descriptions Descriptions of pg_trgm GUC options have % replaced with %% like it was a printf-like format. But that's not needed since they are just plain strings. This commit fixed that. Backpatch to last supported version since this error present from the beginning. Reported-by: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoAgPKODUsu9gqUFiNqEOAqedStxJ-a0sapsJXWWAVp%3Dxg%40mail.gmail.com Backpatch-through: 9.4 | 10 June 2019, 17:24:00 UTC |
9ee98cc | Alexander Korotkov | 10 June 2019, 16:38:13 UTC | Add docs of missing GUC to pgtrgm.sgml be8a7a68 introduced pg_trgm.strict_word_similarity_threshold GUC, but missed docs for that. This commit fixes that. Discussion: https://postgr.es/m/fc907f70-448e-fda3-3aa4-209a59597af0%402ndquadrant.com Author: Ian Barwick Reviewed-by: Masahiko Sawada, Michael Paquier Backpatch-through: 9.6 | 10 June 2019, 17:24:00 UTC |
7c2122f | Alexander Korotkov | 10 June 2019, 16:28:47 UTC | Fix docs indentation in pgtrgm.sgml 5871b884 introduced pg_trgm.word_similarity_threshold GUC, but its documentation contains wrong indentation. This commit fixes that. Backpatch for easier backpatching of other documentation fixes. Discussion: https://postgr.es/m/4c735d30-ab59-fc0e-45d8-f90eb5ed3855%402ndquadrant.com Author: Ian Barwick Backpatch-through: 9.6 | 10 June 2019, 17:24:00 UTC |
88ca787 | Heikki Linnakangas | 07 June 2019, 09:44:01 UTC | Fix copy-pasto in freeing memory on error in vacuumlo. It's harmless to call PQfreemem() with a NULL argument, so the only consequence was that if allocating 'schema' failed, but allocating 'table' or 'field' succeeded, we would leak a bit of memory. That's highly unlikely to happen, so this is just academical, but let's get it right. Per bug #15838 from Timur Birsh. Backpatch back to 9.5, where the PQfreemem() calls were introduced. Discussion: https://www.postgresql.org/message-id/15838-3221652c72c5e69d@postgresql.org | 07 June 2019, 09:44:01 UTC |
fac1ed2 | Amit Kapila | 07 June 2019, 00:05:31 UTC | Fix inconsistency in comments atop ExecParallelEstimate. When this code was initially introduced in commit d1b7c1ff, the structure used was SharedPlanStateInstrumentation, but later when it got changed to Instrumentation structure in commit b287df70, we forgot to update the comment. Reported-by: Wu Fei Author: Wu Fei Reviewed-by: Amit Kapila Backpatch-through: 9.6 Discussion: https://postgr.es/m/52E6E0843B9D774C8C73D6CF64402F0562215EB2@G08CNEXMBPEKD02.g08.fujitsu.local | 07 June 2019, 00:05:31 UTC |
974a286 | Tom Lane | 04 June 2019, 01:25:43 UTC | Mark a few parallelism-related variables with PGDLLIMPORT. Back-patch commit 09a65f5a2 into the 9.6 and 10 branches. Needed to support back-patch of commit 2cd4e8357 on Windows. Discussion: http://postgr.es/m/20190604011354.GD1529@paquier.xyz | 04 June 2019, 01:25:43 UTC |
ba38967 | Tom Lane | 03 June 2019, 22:06:04 UTC | Fix contrib/auto_explain to not cause problems in parallel workers. A parallel worker process should not be making any decisions of its own about whether to auto-explain. If the parent session process passed down flags asking for instrumentation data, do that, otherwise not. Trying to enable instrumentation anyway leads to bugs like the "could not find key N in shm TOC" failure reported in bug #15821 from Christian Hofstaedtler. We can implement this cheaply by piggybacking on the existing logic for not doing anything when we've chosen not to sample a statement. While at it, clean up some tin-eared coding related to the sampling feature, including an off-by-one error that meant that asking for 1.0 sampling rate didn't actually result in sampling every statement. Although the specific case reported here only manifested in >= v11, I believe that related misbehaviors can be demonstrated in any version that has parallel query; and the off-by-one error is certainly there back to 9.6 where that feature was added. So back-patch to 9.6. Discussion: https://postgr.es/m/15821-5eb422e980594075@postgresql.org | 03 June 2019, 22:06:04 UTC |
5b8c93c | Michael Paquier | 01 June 2019, 19:34:02 UTC | Fix documentation of check_option in information_schema.views Support of CHECK OPTION for updatable views has been added in 9.4, but the documentation of information_schema never got the call even if the information displayed is correct. Author: Gilles Darold Discussion: https://postgr.es/m/75d07704-6c74-4f26-656a-10045c01a17e@darold.net Backpatch-through: 9.4 | 01 June 2019, 19:34:02 UTC |
683c17b | Tom Lane | 31 May 2019, 16:34:54 UTC | Fix C++ incompatibilities in plpgsql's header files. Rename some exposed parameters so that they don't conflict with C++ reserved words. Back-patch to all supported versions. George Tarasov Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru | 31 May 2019, 16:34:54 UTC |
39c9efc | Tomas Vondra | 30 May 2019, 14:16:12 UTC | Make error logging in extended statistics more consistent Most errors reported in extended statistics are internal issues, and so should use elog(). The MCV list code was already following this rule, but the functional dependencies and ndistinct coefficients were using a mix of elog() and ereport(). Fix this by changing most places to elog(), with the exception of input functions. This is a mostly cosmetic change, it makes the life a little bit easier for translators, as elog() messages are not translated. So backpatch to PostgreSQL 10, where extended statistics were introduced. Author: Tomas Vondra Backpatch-through: 10 where extended statistics were added Discussion: https://postgr.es/m/20190503154404.GA7478@alvherre.pgsql | 30 May 2019, 15:06:35 UTC |
b31d88b | Noah Misch | 29 May 2019, 02:28:36 UTC | MSVC: Add "use File::Path qw(rmtree)". My back-patch of commit 10b72deafea5972edcafb9eb3f97154f32ccd340 added calls to File::Path::rmtree(), but v10 and older had not been importing that symbol. Back-patch to v10, 9.6 and 9.5. | 29 May 2019, 02:28:36 UTC |
c44e9bc | Noah Misch | 28 May 2019, 19:59:00 UTC | In the pg_upgrade test suite, don't write to src/test/regress. When this suite runs installcheck, redirect file creations from src/test/regress to src/bin/pg_upgrade/tmp_check/regress. This closes a race condition in "make -j check-world". If the pg_upgrade suite wrote to a given src/test/regress/results file in parallel with the regular src/test/regress invocation writing it, a test failed spuriously. Even without parallelism, in "make -k check-world", the suite finishing second overwrote the other's regression.diffs. This revealed test "largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too. Buildfarm client REL_10, released fifty-four days ago, supports saving regression.diffs from its new location. When an older client reports a pg_upgradeCheck failure, it will no longer include regression.diffs. Back-patch to 9.5, where pg_upgrade moved to src/bin. Reviewed (in earlier versions) by Andrew Dunstan. Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com | 28 May 2019, 20:00:16 UTC |
8e2b41e | Noah Misch | 28 May 2019, 19:58:30 UTC | In the pg_upgrade test suite, remove and recreate "tmp_check". This allows "vcregress upgradecheck" to pass twice in immediate succession, and it's more like how $(prove_check) works. Back-patch to 9.5, where pg_upgrade moved to src/bin. Discussion: https://postgr.es/m/20190520012436.GA1480421@rfd.leadboat.com | 28 May 2019, 19:58:34 UTC |
9ba3915 | Andres Freund | 23 May 2019, 21:46:57 UTC | pg_upgrade: Make test.sh's installcheck use to-be-upgraded version's bindir. On master (after 700538) the old version's installed psql was used - even when the old version might not actually be installed / might be installed into a temporary directory. As commonly the case when just executing make check for pg_upgrade, as $oldbindir is just the current version's $bindir. In the back branches, with --install specified, psql from the new version's temporary installation was used, without --install (e.g for NO_TEMP_INSTALL, cf 47b3c26642), the new version's installed psql was used (which might or might not exist). Author: Andres Freund Discussion: https://postgr.es/m/20190522175150.c26f4jkqytahajdg@alap3.anarazel.de | 23 May 2019, 21:49:59 UTC |
99efd8d | Andrew Gierth | 23 May 2019, 14:26:01 UTC | Fix array size allocation for HashAggregate hash keys. When there were duplicate columns in the hash key list, the array sizes could be miscomputed, resulting in access off the end of the array. Adjust the computation to ensure the array is always large enough. (I considered whether the duplicates could be removed in planning, but I can't rule out the possibility that duplicate columns might have different hash functions assigned. Simpler to just make sure it works at execution time regardless.) Bug apparently introduced in fc4b3dea2 as part of narrowing down the tuples stored in the hashtable. Reported by Colm McHugh of Salesforce, though I didn't use their patch. Backpatch back to version 10 where the bug was introduced. Discussion: https://postgr.es/m/CAFeeJoKKu0u+A_A9R9316djW-YW3-+Gtgvy3ju655qRHR3jtdA@mail.gmail.com | 23 May 2019, 14:39:17 UTC |
2ccebcd | Michael Paquier | 23 May 2019, 01:48:29 UTC | Fix ordering of GRANT commands in pg_dumpall for tablespaces This uses a method similar to 68a7c24f and now b8c6014 (applied for database creation), which guarantees that GRANT commands using the WITH GRANT OPTION are dumped in a way so as cascading dependencies are respected. Note that tablespaces do not have support for initial privileges via pg_init_privs, so the same method needs to be applied again. It would be nice to merge all the logic generating ACL queries in dumps under the same banner, but this requires extending the support of pg_init_privs to objects that cannot use it yet, so this is left as future work. Discussion: https://postgr.es/m/20190522071555.GB1278@paquier.xyz Author: Michael Paquier Reviewed-by: Nathan Bossart Backpatch-through: 9.6 | 23 May 2019, 01:48:29 UTC |
0c2a5a8 | Michael Paquier | 22 May 2019, 05:48:30 UTC | Fix ordering of GRANT commands in pg_dumpall for database creation This uses a method similar to 68a7c24f, which guarantees that GRANT commands using the WITH GRANT OPTION are dumped in a way so as cascading dependencies are respected. As databases do not have support for initial privileges via pg_init_privs, we need to repeat again the same ACL reordering method. ACL for databases have been moved from pg_dumpall to pg_dump in v11, so this impacts pg_dump for v11 and above, and pg_dumpall for v9.6 and v10. Discussion: https://postgr.es/m/15788-4e18847520ebcc75@postgresql.org Author: Nathan Bossart Reviewed-by: Haribabu Kommi Backpatch-through: 9.6 | 22 May 2019, 05:48:30 UTC |
7f920b8 | Michael Paquier | 20 May 2019, 00:48:37 UTC | Fix some grammar in documentation of spgist and pgbench Discussion: https://postgr.es/m/92961161-9b49-e42f-0a72-d5d47e0ed4de@postgrespro.ru Author: Liudmila Mantrova Reviewed-by: Jonathan Katz, Tom Lane, Michael Paquier Backpatch-through: 9.4 | 20 May 2019, 00:48:37 UTC |
e0a39a1 | Noah Misch | 19 May 2019, 22:24:42 UTC | Revert "In the pg_upgrade test suite, don't write to src/test/regress." This reverts commit bd1592e8570282b1650af6b8eede0016496daecd. It had multiple defects. Discussion: https://postgr.es/m/12717.1558304356@sss.pgh.pa.us | 19 May 2019, 22:24:46 UTC |
422584c | Noah Misch | 19 May 2019, 21:36:44 UTC | In the pg_upgrade test suite, don't write to src/test/regress. When this suite runs installcheck, redirect file creations from src/test/regress to src/bin/pg_upgrade/tmp_check/regress. This closes a race condition in "make -j check-world". If the pg_upgrade suite wrote to a given src/test/regress/results file in parallel with the regular src/test/regress invocation writing it, a test failed spuriously. Even without parallelism, in "make -k check-world", the suite finishing second overwrote the other's regression.diffs. This revealed test "largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too. Buildfarm client REL_10, released forty-five days ago, supports saving regression.diffs from its new location. When an older client reports a pg_upgradeCheck failure, it will no longer include regression.diffs. Back-patch to 9.5, where pg_upgrade moved to src/bin. Reviewed by Andrew Dunstan. Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com | 19 May 2019, 21:37:23 UTC |
0459596 | Andres Freund | 14 May 2019, 18:45:40 UTC | Add isolation test for INSERT ON CONFLICT speculative insertion failure. This path previously was not reliably covered. There was some heuristic coverage via insert-conflict-toast.spec, but that test is not deterministic, and only tested for a somewhat specific bug. Backpatch, as this is a complicated and otherwise untested code path. Unfortunately 9.5 cannot handle two waiting sessions, and thus cannot execute this test. Triggered by a conversion with Melanie Plageman. Author: Andres Freund Discussion: https://postgr.es/m/CAAKRu_a7hbyrk=wveHYhr4LbcRnRCG=yPUVoQYB9YO1CdUBE9Q@mail.gmail.com Backpatch: 9.5- | 14 May 2019, 18:54:06 UTC |
d7bf9ad | Heikki Linnakangas | 14 May 2019, 10:09:28 UTC | Fix comment on when HOT update is possible. The conditions listed in this comment have changed several times, and at some point the thing that the "if so" referred to was negated. The text was OK up to 9.6. It was differently wrong in v10, v11 and master, so fix in all those versions. | 14 May 2019, 10:09:28 UTC |