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.![swh spinner](/static/img/swh-spinner.gif)
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 |
---|---|---|---|---|
d8ca7ff | Marc G. Fournier | 31 October 2008, 02:49:03 UTC | tag 8.1.15 | 31 October 2008, 02:49:03 UTC |
09df79e | Tom Lane | 30 October 2008, 22:23:11 UTC | Update back-branch release notes. | 30 October 2008, 22:23:11 UTC |
7266a78 | Peter Eisentraut | 30 October 2008, 19:23:08 UTC | Translation updates | 30 October 2008, 19:23:08 UTC |
11b6ddd | Tom Lane | 30 October 2008, 13:17:16 UTC | Update time zone data files to tzdata release 2008i (DST law changes in Argentina, Brazil, Mauritius, Syria). | 30 October 2008, 13:17:16 UTC |
b0a29b6 | Peter Eisentraut | 30 October 2008, 12:24:19 UTC | Missing space in error message | 30 October 2008, 12:24:19 UTC |
1b0c30f | Tom Lane | 27 October 2008, 19:37:42 UTC | Install a more robust solution for the problem of infinite error-processing recursion when we are unable to convert a localized error message to the client's encoding. We've been over this ground before, but as reported by Ibrar Ahmed, it still didn't work in the case of conversion failures for the conversion-failure message itself :-(. Fix by installing a "circuit breaker" that disables attempts to localize this message once we get into recursion trouble. Patch all supported branches, because it is in fact broken in all of them; though I had to add some missing translations to the older branches in order to expose the failure in the particular test case I was using. | 27 October 2008, 19:37:42 UTC |
f4d4bc8 | Tom Lane | 25 October 2008, 03:32:58 UTC | Fix an old bug in after-trigger handling: AfterTriggerEndQuery took the address of afterTriggers->query_stack[afterTriggers->query_depth] and hung onto it through all its firings of triggers. However, if a trigger causes sufficiently many nested query executions, query_stack will get repalloc'd bigger, leaving AfterTriggerEndQuery --- and hence afterTriggerInvokeEvents --- using a stale pointer. So far as I can find, the only consequence of this error is to stomp on a couple of words of already-freed memory; which would lead to a failure only if that chunk had already gotten re-allocated for something else. So it's hard to exhibit a simple failure case, but this is surely a bug. I noticed this while working on my recent patch to reduce pending-trigger space usage. The present patch is mighty ugly, because it requires making afterTriggerInvokeEvents know about all the possible event lists it might get called on. Fortunately, this is only needed in back branches because CVS HEAD avoids the problem in a different way: afterTriggerInvokeEvents only touches the passed AfterTriggerEventList pointer once at startup. Back branches are stable enough that wiring in knowledge of all possible call usages doesn't seem like a killer problem. Back-patch to 8.0. 7.4's trigger code is completely different and doesn't seem to have the problem (it doesn't even use repalloc). | 25 October 2008, 03:32:58 UTC |
b5f5c89 | Teodor Sigaev | 22 October 2008, 12:56:25 UTC | Fix GiST's killing tuple: GISTScanOpaque->curpos wasn't correctly set. As result, killtuple() marks as dead wrong tuple on page. Bug was introduced by me while fixing possible duplicates during GiST index scan. | 22 October 2008, 12:56:25 UTC |
feb4596 | Teodor Sigaev | 17 October 2008, 17:41:16 UTC | Fix small bug in headline generation. Patch from Sushant Sinha <sushant354@gmail.com> http://archives.postgresql.org/pgsql-hackers/2008-07/msg00785.php | 17 October 2008, 17:41:16 UTC |
95402c3 | Tom Lane | 16 October 2008, 13:23:41 UTC | Fix SPI_getvalue and SPI_getbinval to range-check the given attribute number according to the TupleDesc's natts, not the number of physical columns in the tuple. The previous coding would do the wrong thing in cases where natts is different from the tuple's column count: either incorrectly report error when it should just treat the column as null, or actually crash due to indexing off the end of the TupleDesc's attribute array. (The second case is probably not possible in modern PG versions, due to more careful handling of inheritance cases than we once had. But it's still a clear lack of robustness here.) The incorrect error indication is ignored by all callers within the core PG distribution, so this bug has no symptoms visible within the core code, but it might well be an issue for add-on packages. So patch all the way back. | 16 October 2008, 13:23:41 UTC |
3b25d16 | Tom Lane | 10 October 2008, 21:46:56 UTC | Fix COPY documentation to not imply that HEADER can be used outside CSV mode. Per gripe from Bill Thoen. | 10 October 2008, 21:46:56 UTC |
77aa915 | Michael Meskes | 10 October 2008, 12:19:32 UTC | Optional arguments should be optional. | 10 October 2008, 12:19:32 UTC |
3e5ed16 | Tom Lane | 09 October 2008, 16:35:25 UTC | Fix overly tense optimization of PLpgSQL_func_hashkey: we must represent the isTrigger state explicitly, not rely on nonzero-ness of trigrelOid to indicate trigger-hood, because trigrelOid will be left zero when compiling for validation. The (useless) function hash entry built by the validator was able to match an ordinary non-trigger call later in the same session, thereby bypassing the check that is supposed to prevent such a call. Per report from Alvaro. It might be worth suppressing the useless hash entry altogether, but that's a bigger change than I want to consider back-patching. Back-patch to 8.0. 7.4 doesn't have the problem because it doesn't have validation mode. | 09 October 2008, 16:35:25 UTC |
1abe8ea | Heikki Linnakangas | 07 October 2008, 11:16:01 UTC | When a relation is moved to another tablespace, we can't assume that we can use the old relfilenode in the new tablespace. There might be another relation in the new tablespace with the same relfilenode, so we must generate a fresh relfilenode in the new tablespace. The 8.3 patch to let deleted relation files linger as zero-length files until the next checkpoint made this more obvious: moving a relation from one table space another, and then back again, caused a collision with the lingering file. Back-patch to 8.1. The issue is present in 8.0 as well, but it doesn't seem worth fixing there, because we didn't have protection from OID collisions after OID wraparound before 8.1. Report by Guillaume Lelarge. | 07 October 2008, 11:16:01 UTC |
aaa0d6b | Tom Lane | 02 October 2008, 13:47:56 UTC | Fix improper display of fractional seconds in interval values when using --enable-integer-datetimes and a non-ISO datestyle. Ron Mayer | 02 October 2008, 13:47:56 UTC |
38c8ab2 | Tom Lane | 30 September 2008, 13:14:21 UTC | Recent patches to pg_ctl broke "pg_ctl restart" for the case where no command-line options had been given to the postmaster; and just plain broke it altogether in 8.1 and 8.0. Per report from KaiGai Kohei. | 30 September 2008, 13:14:21 UTC |
cd311af | Tom Lane | 24 September 2008, 16:53:07 UTC | Fix more problems with rewriter failing to set Query.hasSubLinks when inserting a SubLink expression into a rule query. We missed cases where the original query contained a sub-SELECT in a function in FROM, a multi-row VALUES list, or a RETURNING list. Per bug #4434 from Dean Rasheed and subsequent investigation. Back-patch to 8.1; older releases don't have the issue because they didn't try to be smart about setting hasSubLinks only when needed. | 24 September 2008, 16:53:07 UTC |
00f3091 | Marc G. Fournier | 19 September 2008, 03:19:16 UTC | tag for 8.1.14 | 19 September 2008, 03:19:16 UTC |
81dcd77 | Tom Lane | 19 September 2008, 02:45:44 UTC | Update back-branch release notes. | 19 September 2008, 02:45:44 UTC |
ec7d885 | Tom Lane | 17 September 2008, 14:19:02 UTC | Update time zone data files to tzdata release 2008f (DST law changes in Argentina, Bahamas, Brazil, Mauritius, Morocco, Pakistan, Palestine, Paraguay). | 17 September 2008, 14:19:02 UTC |
839ed8b | Tom Lane | 16 September 2008, 01:56:49 UTC | Widen the nLocks counts in local lock tables from int to int64. This forestalls potential overflow when the same table (or other object, but usually tables) is accessed by very many successive queries within a single transaction. Per report from Michael Milligan. Back-patch to 8.0, which is as far back as the patch conveniently applies. There have been no reports of overflow in pre-8.3 releases, but clearly the risk existed all along. (Michael's report suggests that 8.3 may consume lock counts faster than prior releases, but with no test case to look at it's hard to be sure about that. Widening the counts seems a good future-proofing measure in any event.) | 16 September 2008, 01:56:49 UTC |
74da120 | Tom Lane | 01 September 2008, 22:30:55 UTC | Fix plpgsql's exec_move_row() to supply valid type OIDs to exec_assign_value() whenever possible, as per bug report from Oleg Serov. While at it, reorder the operations in the RECORD case to avoid possible palloc failure while the variable update is only partly complete. Back-patch as far as 8.1. Although the code of the particular function is similar in 8.0, 8.0's support for composite fields in rows is sufficiently broken elsewhere that it doesn't seem worth fixing this. | 01 September 2008, 22:30:55 UTC |
a76e185 | Tom Lane | 26 August 2008, 00:03:36 UTC | Fix pg_dump docs to acknowledge that you can use -Z with plain text output. Pointed out by Daniel Migowski. | 26 August 2008, 00:03:36 UTC |
4040629 | Teodor Sigaev | 23 August 2008, 10:43:58 UTC | Fix possible duplicate tuples while GiST scan. Now page is processed at once and ItemPointers are collected in memory. Remove tuple's killing by killtuple() if tuple was moved to another page - it could produce unaceptable overhead. Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support. | 23 August 2008, 10:43:58 UTC |
7e93085 | Tom Lane | 16 August 2008, 02:25:23 UTC | Fix pg_dump/pg_restore's ExecuteSqlCommand() to behave suitably if PQexec returns NULL instead of a PGresult. The former coding would fail, which is OK, but it neglected to give you the PQerrorMessage that might tell you why. In the oldest branches, there was another problem: it'd sometimes report PQerrorMessage from the wrong connection. | 16 August 2008, 02:25:23 UTC |
7a9b6cd | Tom Lane | 08 August 2008, 17:01:34 UTC | Install checks in executor startup to ensure that the tuples produced by an INSERT or UPDATE will match the target table's current rowtype. In pre-8.3 releases inconsistency can arise with stale cached plans, as reported by Merlin Moncure. (We patched the equivalent hazard on the SELECT side in Feb 2007; I'm not sure why we thought there was no risk on the insertion side.) In 8.3 and HEAD this problem should be impossible due to plan cache invalidation management, but it seems prudent to make the check anyway. Back-patch as far as 8.0. 7.x versions lack ALTER COLUMN TYPE, so there seems no way to abuse a stale plan comparably. | 08 August 2008, 17:01:34 UTC |
5d46ee4 | Tom Lane | 05 August 2008, 21:28:48 UTC | Do not allow Unique nodes to be scanned backwards. The code claimed that it would work, but in fact it didn't return the same rows when moving backwards as when moving forwards. This would have no visible effect in a DISTINCT query (at least assuming the column datatypes use a strong definition of equality), but it gave entirely wrong answers for DISTINCT ON queries. | 05 August 2008, 21:28:48 UTC |
a3a8f23 | Tom Lane | 28 July 2008, 18:45:05 UTC | Update 8.1 and 8.0 plpython to work with Python 2.5. This backports several fixes made during the 8.2 development cycle, but not backported at the time for lack of confidence in the new coding. I didn't touch 7.4 because it has more problems than this: the configure probe for Python fails. | 28 July 2008, 18:45:05 UTC |
2381102 | Tom Lane | 10 July 2008, 01:17:52 UTC | Fix mis-calculation of extParam/allParam sets for plan nodes, as seen in bug #4290. The fundamental bug is that masking extParam by outer_params, as finalize_plan had been doing, caused us to lose the information that an initPlan depended on the output of a sibling initPlan. On reflection the best thing to do seemed to be not to try to adjust outer_params for this case but get rid of it entirely. The only thing it was really doing for us was to filter out param IDs associated with SubPlan nodes, and that can be done (with greater accuracy) while processing individual SubPlan nodes in finalize_primnode. This approach was vindicated by the discovery that the masking method was hiding a second bug: SS_finalize_plan failed to remove extParam bits for initPlan output params that were referenced in the main plan tree (it only got rid of those referenced by other initPlans). It's not clear that this caused any real problems, given the limited use of extParam by the executor, but it's certainly not what was intended. I originally thought that there was also a problem with needing to include indirect dependencies on external params in initPlans' param sets, but it turns out that the executor handles this correctly so long as the depended-on initPlan is earlier in the initPlans list than the one using its output. That seems a bit of a fragile assumption, but it is true at the moment, so I just documented it in some code comments rather than making what would be rather invasive changes to remove the assumption. Back-patch to 8.1. Previous versions don't have the case of initPlans referring to other initPlans' outputs, so while the existing logic is still questionable for them, there are not any known bugs to be fixed. So I'll refrain from changing them for now. | 10 July 2008, 01:17:52 UTC |
33da69f | Tom Lane | 08 July 2008, 22:18:02 UTC | Fix performance bug in write_syslog(): the code to preferentially break the log message at newlines cost O(N^2) for very long messages with few or no newlines. For messages in the megabyte range this became the dominant cost. Per gripe from Achilleas Mantzios. Patch all the way back, since this is a safe change with no portability risks. I am also thinking of increasing PG_SYSLOG_LIMIT, but that should be done separately. | 08 July 2008, 22:18:02 UTC |
848268c | Tom Lane | 07 July 2008, 20:25:22 UTC | Fix estimate_num_groups() to assume that GROUP BY expressions yielding boolean results always contribute two groups, regardless of the expression contents. This is very substantially more accurate than the regular heuristic for certain boolean tests like "col IS NULL". Per gripe from Sam Mason. Back-patch to all supported releases, since the behavior of estimate_num_groups() hasn't changed all that much since 7.4. | 07 July 2008, 20:25:22 UTC |
a2fde11 | Tom Lane | 07 July 2008, 18:10:12 UTC | Fix AT TIME ZONE (in all three variants) so that we first try to interpret the timezone argument as a timezone abbreviation, and only try it as a full timezone name if that fails. The zic database has four zones (CET, EET, MET, WET) that are full daylight-savings zones and yet have names that are the same as their abbreviations for standard time, resulting in ambiguity. In the timestamp input functions we resolve the ambiguity by preferring the abbreviation, and AT TIME ZONE should work the same way. (No functionality is lost because the zic database also has other names for these zones, eg Europe/Zurich.) Per gripe from Jaromir Talir. Backpatch to 8.1. Older releases did not have the issue because AT TIME ZONE only accepted abbreviations not zone names. (Thus, this patch also arguably fixes a compatibility botch introduced at 8.1: in ambiguous cases we now behave the same as 8.0 did.) | 07 July 2008, 18:10:12 UTC |
4d72579 | Tom Lane | 01 July 2008, 03:41:18 UTC | Fix identify_system_timezone() so that it tests the behavior of the system timezone setting in the current year and for 100 years back, rather than always examining years 1904-2004. The original coding would have problems distinguishing zones whose behavior diverged only after 2004; which is a situation we will surely face sometime, if it's not out there already. In passing, also prevent selection of the dummy "Factory" timezone, even if that's exactly what the system is using. Reporting time as GMT seems better than that. | 01 July 2008, 03:41:18 UTC |
289654c | Bruce Momjian | 27 June 2008, 01:53:09 UTC | Fix 'pg_ctl reload' to properly preserve postmaster commend-line arguments on restart. Patch to releases 8.0 - 8.3.X. | 27 June 2008, 01:53:09 UTC |
6ac2529 | Tom Lane | 17 June 2008, 00:53:04 UTC | Clean up a number of bogosities around pltcl's handling of the Tcl "result": 1. Directly reading interp->result is deprecated in Tcl 8.0 and later; you're supposed to use Tcl_GetStringResult. This code finally broke with Tcl 8.5, because Tcl_GetVar can now have side-effects on interp->result even though it preserves the logical state of the result. (There's arguably a Tcl issue here, because Tcl_GetVar could invalidate the pointer result of a just-preceding Tcl_GetStringResult, but I doubt the Tcl guys will see it as a bug.) 2. We were being sloppy about the encoding of the result: some places would push database-encoding data into the Tcl result, which should not happen, and we were assuming that any error result coming back from Tcl was in the database encoding, which is not a good assumption. 3. There were a lot of calls of Tcl_SetResult that uselessly specified TCL_VOLATILE for constant strings. This is only a minor performance issue, but I fixed it in passing since I had to look at all the calls anyway. #2 is a live bug regardless of which Tcl version you are interested in, so back-patch even to branches that are unlikely to be used with Tcl 8.5. I went back as far as 8.0, which is as far as the patch applied easily; 7.4 was using a different error processing scheme that has got its own problems :-( | 17 June 2008, 00:53:04 UTC |
28afd8d | Tom Lane | 10 June 2008, 18:09:08 UTC | Create a script to handle stamping release version numbers into files, replacing the tedious and error-prone manual process we've been using. | 10 June 2008, 18:09:08 UTC |
562755e | Tom Lane | 09 June 2008, 19:34:24 UTC | Fix datetime input functions to correctly detect integer overflow when running on a 64-bit platform ... strtol() will happily return 64-bit output in that case. Per bug #4231 from Geoff Tolley. | 09 June 2008, 19:34:24 UTC |
2de08aa | Marc G. Fournier | 09 June 2008, 01:17:34 UTC | tag 8.1.13 | 09 June 2008, 01:17:34 UTC |
638aa5a | Tom Lane | 08 June 2008, 22:14:47 UTC | Stamp 8.1.13 (except for configure.in/configure) | 08 June 2008, 22:14:47 UTC |
083bb0f | Tom Lane | 08 June 2008, 21:46:38 UTC | Update release notes for ALTER AGGREGATE fix. | 08 June 2008, 21:46:38 UTC |
7603ca1 | Tom Lane | 08 June 2008, 21:10:05 UTC | ALTER AGGREGATE OWNER seems to have been missed by the last couple of patches that dealt with object ownership. It wasn't updating pg_shdepend nor adjusting the aggregate's ACL. In 8.2 and up, fix this permanently by making it use AlterFunctionOwner_oid. In 8.1, the function code wasn't factored that way, so just copy and paste. | 08 June 2008, 21:10:05 UTC |
a869011 | Tom Lane | 07 June 2008, 22:11:09 UTC | Update release notes for 8.3.3 et al. | 07 June 2008, 22:11:09 UTC |
7521bda | Tom Lane | 06 June 2008, 17:59:53 UTC | Fix pg_get_ruledef() so that negative numeric constants are parenthesized. This is needed because :: casting binds more tightly than minus, so for example -1::integer is not the same as (-1)::integer, and there are cases where the difference is important. In particular this caused a failure in SELECT DISTINCT ... ORDER BY ... where expressions that should have matched were seen as different by the parser; but I suspect that there could be other cases where failure to parenthesize leads to subtler semantic differences in reloaded rules. Per report from Alexandr Popov. | 06 June 2008, 17:59:53 UTC |
5766e91 | Tom Lane | 06 June 2008, 05:33:39 UTC | Remove link that pre-8.2 doc tools don't support. | 06 June 2008, 05:33:39 UTC |
4611fc9 | Marc G. Fournier | 06 June 2008, 04:10:51 UTC | tag for 8.1.12 | 06 June 2008, 04:10:51 UTC |
7ac3f84 | Tom Lane | 05 June 2008, 23:56:05 UTC | Stamp 8.1.12 (except for configure.in/configure) | 05 June 2008, 23:56:05 UTC |
84a43fc | Tom Lane | 05 June 2008, 23:37:16 UTC | Translation updates. | 05 June 2008, 23:37:16 UTC |
59b67db | Michael Meskes | 05 June 2008, 06:25:23 UTC | Added SQL symbol for variable names here too. | 05 June 2008, 06:25:23 UTC |
0660700 | Tom Lane | 04 June 2008, 03:16:35 UTC | Draft release notes for upcoming back-branch updates. | 04 June 2008, 03:16:35 UTC |
e275a81 | Tom Lane | 01 June 2008, 18:23:22 UTC | Update time zone data files to tzdata release 2008c (DST law changes in Morocco, Iraq, Choibalsan, Pakistan, Syria, Cuba, Argentina/San_Luis). | 01 June 2008, 18:23:22 UTC |
32184bf | Tom Lane | 28 May 2008, 00:45:59 UTC | Improve GRANT documentation to point out that UPDATE and DELETE typically require SELECT privilege as well, since you normally need to read existing column values within such commands. This behavior is according to spec, but we'd never documented it before. Per gripe from Volkan Yazici. | 28 May 2008, 00:45:59 UTC |
290d4b3 | Tom Lane | 27 May 2008, 21:13:39 UTC | Back-patch the 8.3 fix that prohibits TRUNCATE, CLUSTER, and REINDEX when the current transaction has any open references to the target relation or index (implying it has an active query using the relation). Also back-patch the 8.2 fix that prohibits TRUNCATE and CLUSTER when there are pending AFTER-trigger events. Per suggestion from Heikki. | 27 May 2008, 21:13:39 UTC |
48ecee1 | Tom Lane | 26 May 2008, 18:54:50 UTC | Fix an old corner-case bug in set_config_option: push_old_value has to be called before, not after, calling the assign_hook if any. This is because push_old_value might fail (due to palloc out-of-memory), and in that case there would be no stack entry to tell transaction abort to undo the GUC assignment. Of course the actual assignment to the GUC variable hasn't happened yet --- but the assign_hook might have altered subsidiary state. Without a stack entry we won't call it again to make it undo such actions. So this is necessary to make the world safe for assign_hooks with side effects. Per a discussion a couple weeks ago with Magnus. Back-patch to 8.0. 7.x did not have the problem because it did not have allocatable stacks of GUC values. | 26 May 2008, 18:54:50 UTC |
04bd1fc | Tom Lane | 25 May 2008, 21:51:23 UTC | Adjust timestamp regression tests to prevent two low-probability failure cases. Recent buildfarm experience shows that it is sometimes possible to execute several SQL commands in less time than the granularity of Windows' not-very-high-resolution gettimeofday(), leading to a failure because the tests expect the value of now() to change and it doesn't. Also, it was recognized some time ago that the same area of the tests could fail if local midnight passes between the insertion and the checking of the values for 'yesterday', 'tomorrow', etc. Clean all this up per ideas from myself and Greg Stark. There remains a window for failure if the transaction block is entered exactly at local midnight (so that 'now' and 'today' have the same value), but that seems low-probability enough to live with. Since the point of this change is mostly to eliminate buildfarm noise, back-patch to all versions we are still actively testing. | 25 May 2008, 21:51:23 UTC |
f8ddee0 | Heikki Linnakangas | 19 May 2008, 18:17:21 UTC | Remove arbitrary 10MB limit on two-phase state file size. It's not that hard to go beoynd 10MB, as demonstrated by Gavin Sharry's example of dropping a schema with ~25000 objects. The really bogus thing about the limit was that it was enforced when a state file file was read in, not when it was written, so you would end up with a prepared transaction that you can't commit or abort, and the only recourse was to shut down the server and remove the file by hand. Raise the limit to MaxAllocSize, and enforce it also when a state file is written. We could've removed the limit altogether, but reading in a file larger than MaxAllocSize would fail anyway because we read it into a palloc'd buffer. Backpatch down to 8.1, where 2PC and this issue was introduced. | 19 May 2008, 18:17:21 UTC |
5b4150a | Magnus Hagander | 13 May 2008, 20:53:58 UTC | Don't try to close negative file descriptors, since this can cause crashes on certain platforms. In particular, the MSVC runtime is known to do this. Fixes bug #4162, reported and diagnosed by Javier Pimas | 13 May 2008, 20:53:58 UTC |
6f28e87 | Tom Lane | 09 May 2008, 22:37:47 UTC | Fix an ancient oversight in change_varattnos_of_a_node: it neglected to update varoattno along with varattno. This resulted in having Vars that were not seen as equal(), causing inheritance of the "same" constraint from different parent relations to fail. An example is create table pp1 (f1 int check (f1>0)); create table cc1 (f2 text, f3 int) inherits (pp1); create table cc2(f4 float) inherits(pp1,cc1); Backpatch as far as 7.4. (The test case still fails in 7.4, for reasons that I don't feel like investigating at the moment.) This is a backpatch commit only. The fix will be applied in HEAD as part of the upcoming pg_constraint patch. | 09 May 2008, 22:37:47 UTC |
773f5cc | Tom Lane | 08 May 2008, 17:11:41 UTC | Fix contrib/xml2 makefile to not override CFLAGS. | 08 May 2008, 17:11:41 UTC |
1fb9814 | Tom Lane | 24 April 2008, 20:18:15 UTC | Fix ALTER TABLE ADD COLUMN ... PRIMARY KEY so that the new column is correctly checked to see if it's been initialized to all non-nulls. The implicit NOT NULL constraint was not being checked during the ALTER (in fact, not even if there was an explicit NOT NULL too), because ATExecAddColumn neglected to set the flag needed to make the test happen. This has been broken since the capability was first added, in 8.0. Brendan Jurd, per a report from Kaloyan Iliev. | 24 April 2008, 20:18:15 UTC |
0f13071 | Magnus Hagander | 22 April 2008, 09:26:39 UTC | Replace developer FAQ with a reference to the wiki, which is where it now lives (per discussion). Leave the other FAQs alone for now. | 22 April 2008, 09:26:39 UTC |
3cf4913 | Magnus Hagander | 21 April 2008, 09:45:05 UTC | Add link to major version release notes at the top of the minor version ones, to make it clear to users just browsing the notes that there are a lot more changes available from whatever version they are at than what's in the minor version release notes. | 21 April 2008, 09:45:05 UTC |
52441ad | Tom Lane | 11 April 2008, 22:53:16 UTC | Fix several datatype input functions that were allowing unused bytes in their results to contain uninitialized, unpredictable values. While this was okay as far as the datatypes themselves were concerned, it's a problem for the parser because occurrences of the "same" literal might not be recognized as equal by datumIsEqual (and hence not by equal()). It seems sufficient to fix this in the input functions since the only critical use of equal() is in the parser's comparisons of ORDER BY and DISTINCT expressions. Per a trouble report from Marc Cousin. Patch all the way back. Interestingly, array_in did not have the bug before 8.2, which may explain why the issue went unnoticed for so long. | 11 April 2008, 22:53:16 UTC |
a0f770d | Michael Meskes | 10 April 2008, 10:46:34 UTC | Fixed bug in PGTYPEStimestamp_sub that used pointers instead of the values to substract. | 10 April 2008, 10:46:34 UTC |
19d2625 | Tom Lane | 05 April 2008, 01:58:42 UTC | Defend against JOINs having more than 32K columns altogether. We cannot currently support this because we must be able to build Vars referencing join columns, and varattno is only 16 bits wide. Perhaps this should be improved in future, but considering that it never came up before, I'm not sure the problem is worth much effort. Per bug #4070 from Marcello Ceschia. The problem seems largely academic in 8.0 and 7.4, because they have (different) O(N^2) performance issues with such wide joins, but back-patch all the way anyway. | 05 April 2008, 01:58:42 UTC |
80dc9a8 | Tom Lane | 31 March 2008, 01:32:48 UTC | Fix a number of places that were making file-type tests infelicitously. The places that did, eg, (statbuf.st_mode & S_IFMT) == S_IFDIR were correct, but there is no good reason not to use S_ISDIR() instead, especially when that's what the other 90% of our code does. The places that did, eg, (statbuf.st_mode & S_IFDIR) were flat out *wrong* and would fail in various platform-specific ways, eg a symlink could be mistaken for a regular file on most Unixen. The actual impact of this is probably small, since the problem cases seem to always involve symlinks or sockets, which are unlikely to be found in the directories that PG code might be scanning. But it's clearly trouble waiting to happen, so patch all the way back anyway. (There seem to be no occurrences of the mistake in 7.4.) | 31 March 2008, 01:32:48 UTC |
207f469 | Tom Lane | 26 March 2008, 01:19:23 UTC | Fix core dump in contrib/xml2's xpath_table() when the input query returns a NULL value. Per bug #4058. | 26 March 2008, 01:19:23 UTC |
1b304e8 | Tom Lane | 25 March 2008, 19:31:40 UTC | Adjust DatumGetBool macro so that it isn't fooled by garbage in the Datum to the left of the actual bool value. While in most cases there won't be any, our support for old-style user-defined functions violates the C spec to the extent of calling functions that might return char or short through a function pointer declared to return "char *", which we then coerce to Datum. It is not surprising that the result might contain garbage high-order bits ... what is surprising is that we didn't see such cases long ago. Per report from Magnus. This is a back-patch of a change that was made in HEAD almost exactly a year ago. I had refrained from back-patching at the time, but now we find that this is *necessary* for contrib to work with gcc 4.3. | 25 March 2008, 19:31:40 UTC |
242d0f9 | Heikki Linnakangas | 20 March 2008, 10:38:34 UTC | Add the missing cyrillic "Yo" characters ('e' and 'E' with two dots) to the ISO_8859-5 <-> MULE_INTERNAL conversion tables. This was discovered when trying to convert a string containing those characters from ISO_8859-5 to Windows-1251, because we use MULE_INTERNAL/KOI8R as an intermediate encoding between those two. While the missing "Yo" was just an omission in the conversion tables, there are a few other characters like the "Numero" sign ("No" as a single character) that exists in all the other cyrillic encodings (win1251, ISO_8859-5 and cp866), but not in KOI8R. Added comments about that. Patch by Sergey Burladyan. Back-patch to 7.4. | 20 March 2008, 10:38:34 UTC |
c249e9e | Tom Lane | 19 March 2008, 02:41:00 UTC | Fix regexp substring matching (substring(string from pattern)) for the corner case where there is a match to the pattern overall but the user has specified a parenthesized subexpression and that subexpression hasn't got a match. An example is substring('foo' from 'foo(bar)?'). This should return NULL, since (bar) isn't matched, but it was mistakenly returning the whole-pattern match instead (ie, 'foo'). Per bug #4044 from Rui Martins. This has been broken since the beginning; patch in all supported versions. The old behavior was sufficiently inconsistent that it's impossible to believe anyone is depending on it. | 19 March 2008, 02:41:00 UTC |
9d2e161 | Tom Lane | 13 March 2008, 19:22:04 UTC | Update to tzdata 2008a distribution (Chilean DST law change). | 13 March 2008, 19:22:04 UTC |
e8051df | Tom Lane | 12 March 2008, 20:12:14 UTC | Fix LISTEN/NOTIFY race condition reported by Laurent Birtz, by postponing pg_listener modifications commanded by LISTEN and UNLISTEN until the end of the current transaction. This allows us to hold the ExclusiveLock on pg_listener until after commit, with no greater risk of deadlock than there was before. Aside from fixing the race condition, this gets rid of a truly ugly kludge that was there before, namely having to ignore HeapTupleBeingUpdated failures during NOTIFY. There is a small potential incompatibility, which is that if a transaction issues LISTEN or UNLISTEN and then looks into pg_listener before committing, it won't see any resulting row insertion or deletion, where before it would have. It seems unlikely that anyone would be depending on that, though. This patch also disallows LISTEN and UNLISTEN inside a prepared transaction. That case had some pretty undesirable properties already, such as possibly allowing pg_listener entries to be made for PIDs no longer present, so disallowing it seems like a better idea than trying to maintain the behavior. | 12 March 2008, 20:12:14 UTC |
77f5afc | Tom Lane | 10 March 2008, 21:50:40 UTC | Use -fwrapv in CFLAGS if we are using a version of gcc that accepts this flag. This prevents compiler optimizations that assume overflow won't occur, which breaks numerous overflow tests that we need to have working. It is known that gcc 4.3 causes problems and possible that 4.1 does. Per my proposal of some time ago and a recent report from Kris Jurka. Backpatch as far as 8.0, which is as far as the patch conveniently goes. 7.x was pretty short of overflow tests anyway, so it may not matter there, even assuming that anyone cares whether 7.x builds on recent gcc. | 10 March 2008, 21:50:40 UTC |
8576a07 | Tom Lane | 07 March 2008, 15:59:23 UTC | Change hashscan.c to keep its list of active hash index scans in TopMemoryContext, rather than scattered through executor per-query contexts. This poses no danger of memory leak since the ResourceOwner mechanism guarantees release of no-longer-needed items. It is needed because the per-query context might already be released by the time we try to clean up the hash scan list. Report by ykhuang, diagnosis by Heikki. Back-patch to 8.0, where the ResourceOwner-based cleanup was introduced. The given test case does not fail before 8.2, probably because we rearranged transaction abort processing somehow; but this coding is undoubtedly risky so I'll patch 8.0 and 8.1 anyway. | 07 March 2008, 15:59:23 UTC |
712d0ee | Alvaro Herrera | 05 March 2008, 21:20:50 UTC | Add support for dlopen on recent NetBSD/MIPS, per Rémi Zara. | 05 March 2008, 21:20:50 UTC |
f40d8b5 | Tom Lane | 27 February 2008, 17:44:41 UTC | If RelationBuildDesc() fails to open a critical system index, PANIC with a relevant error message instead of just dumping core. Odd that nobody reported this before Darren Reed. | 27 February 2008, 17:44:41 UTC |
bac65d5 | Tom Lane | 25 February 2008, 23:21:22 UTC | Fix datetime input to behave correctly for Feb 29 in years BC. Formerly, DecodeDate attempted to verify the day-of-the-month exactly, but it was under the misapprehension that it would know whether we were looking at a BC year or not. In reality this check can't be made until the calling function (eg DecodeDateTime) has processed all the fields. So, split the BC adjustment and validity checks out into a new function ValidateDate that is called only after processing all the fields. In passing, this patch makes DecodeTimeOnly work for BC inputs, which it never did before. (The historical veracity of all this is nonexistent, of course, but if we're going to say we support proleptic Gregorian calendar then we should do it correctly. In any case the unpatched code is broken because it could emit dates that it would then reject on re-inputting.) Per report from Bernd Helmle. Back-patch as far as 8.0; in 7.x we were not using our own calendar support and so this seems a bit too risky to put into 7.4. | 25 February 2008, 23:21:22 UTC |
f004ac1 | Tom Lane | 24 February 2008, 05:22:22 UTC | Use our own getopt() and getopt_long() on Solaris, because that platform's versions don't handle long options the way we want. Per Zdenek Kotala. | 24 February 2008, 05:22:22 UTC |
0f6acc4 | Tom Lane | 23 February 2008, 19:23:51 UTC | Avoid trying to print a NULL char pointer in --describe-config. On some platforms this works, but on some it crashes. Zdenek Kotala | 23 February 2008, 19:23:51 UTC |
f6b6c24 | Tom Lane | 20 February 2008, 22:18:35 UTC | Fix mistakes in pg_ctl's code for "start -w" that tries to cope with non-default settings for the postmaster's port number. The code to parse command line options and postgresql.conf entries wasn't quite right about whitespace or quotes, and it was coded in a not-very-readable way too. Per bug #3969 from Itagaki Takahiro, though this is more extensive than his proposed patch (which fixed only the whitespace problem). This code has been broken since it was put in in 8.0, so patch all the way back. | 20 February 2008, 22:18:35 UTC |
63df2c7 | Tom Lane | 20 February 2008, 17:44:26 UTC | Put a CHECK_FOR_INTERRUPTS call into the loops that try to find a unique new OID or new relfilenode. If the existing OIDs are sufficiently densely populated, this could take a long time (perhaps even be an infinite loop), so it seems wise to allow the system to respond to a cancel interrupt here. Per a gripe from Jacky Leng. Backpatch as far as 8.1. Older versions just fail on OID collision, instead of looping. | 20 February 2008, 17:44:26 UTC |
e242961 | Tom Lane | 11 February 2008, 19:14:45 UTC | Repair VACUUM FULL bug introduced by HOT patch: the original way of calculating a page's initial free space was fine, and should not have been "improved" by letting PageGetHeapFreeSpace do it. VACUUM FULL is going to reclaim LP_DEAD line pointers later, so there is no need for a guard against the page being too full of line pointers, and having one risks rejecting pages that are perfectly good move destinations. This also exposed a second bug, which is that the empty_end_pages logic assumed that any page with no live tuples would get entered into the fraged_pages list automatically (by virtue of having more free space than the threshold in the do_frag calculation). This assumption certainly seems risky when a low fillfactor has been chosen, and even without tunable fillfactor I think it could conceivably fail on a page with many unused line pointers. So fix the code to force do_frag true when notup is true, and patch this part of the fix all the way back. Per report from Tomas Szepe. | 11 February 2008, 19:14:45 UTC |
4af5e12 | Tom Lane | 07 February 2008, 21:08:16 UTC | Some variants of ALTER OWNER tried to make the "object" field of the statement be a list of bare C strings, rather than String nodes, which is what they need to be for copyfuncs/equalfuncs to work. Fortunately these node types never go out to disk (if they did, we'd likely have noticed the problem sooner), so we can just fix it without creating a need for initdb. This bug has been there since 8.0, but 8.3 exposes it in a more common code path (Parse messages) than prior releases did. Per bug #3940 from Vladimir Kokovic. | 07 February 2008, 21:08:16 UTC |
08cf860 | Andrew Dunstan | 22 January 2008, 20:41:39 UTC | Work around for perl 5.10 bug - fix due to perl hacker Simon Cozens. | 22 January 2008, 20:41:39 UTC |
d3c7bd6 | Alvaro Herrera | 17 January 2008, 23:47:07 UTC | Backpatch my fix of rev 1.48 to avoid a division-by-zero error in the cost-limit vacuum code. Per trouble report from Joshua Drake. | 17 January 2008, 23:47:07 UTC |
78f53d5 | Tom Lane | 14 January 2008, 18:46:33 UTC | Fix an ancient oversight in libpq's handling of V3-protocol COPY OUT mode: we need to be able to swallow NOTICE messages, and potentially also ParameterStatus messages (although the latter would be a bit weird), without exiting COPY OUT state. Fix it, and adjust the protocol documentation to emphasize the need for this. Per off-list report from Alexander Galler. | 14 January 2008, 18:46:33 UTC |
307a677 | Tom Lane | 06 January 2008, 01:03:31 UTC | A long time ago, Peter pointed out that ruleutils.c didn't dump simple constant ORDER/GROUP BY entries properly: http://archives.postgresql.org/pgsql-hackers/2001-04/msg00457.php The original solution to that was in fact no good, as demonstrated by today's report from Martin Pitt: http://archives.postgresql.org/pgsql-bugs/2008-01/msg00027.php We can't use the column-number-reference format for a constant that is a resjunk targetlist entry, a case that was unfortunately not thought of in the original discussion. What we can do instead (which did not work at the time, but does work in 7.3 and up) is to emit the constant with explicit ::typename decoration, even if it otherwise wouldn't need it. This is sufficient to keep the parser from thinking it's a column number reference, and indeed is probably what the user must have done to get such a thing into the querytree in the first place. | 06 January 2008, 01:03:31 UTC |
d419ce4 | Tom Lane | 03 January 2008, 21:41:24 UTC | Stamp release 8.1.11. Security: CVE-2007-4769, CVE-2007-4772, CVE-2007-6067, CVE-2007-6600, CVE-2007-6601 | 03 January 2008, 21:41:24 UTC |
bf4d342 | Tom Lane | 03 January 2008, 21:35:49 UTC | Update release notes for security releases. Security: CVE-2007-4769, CVE-2007-4772, CVE-2007-6067, CVE-2007-6600, CVE-2007-6601 | 03 January 2008, 21:35:49 UTC |
148bd52 | Tom Lane | 03 January 2008, 21:28:30 UTC | The original patch to disallow non-passworded connections to non-superusers failed to cover all the ways in which a connection can be initiated in dblink. Plug the remaining holes. Also, disallow transient connections in functions for which that feature makes no sense (because they are only sensible as part of a sequence of operations on the same connection). Joe Conway Security: CVE-2007-6601 | 03 January 2008, 21:28:30 UTC |
46cf9c2 | Tom Lane | 03 January 2008, 21:24:26 UTC | Make standard maintenance operations (including VACUUM, ANALYZE, REINDEX, and CLUSTER) execute as the table owner rather than the calling user, using the same privilege-switching mechanism already used for SECURITY DEFINER functions. The purpose of this change is to ensure that user-defined functions used in index definitions cannot acquire the privileges of a superuser account that is performing routine maintenance. While a function used in an index is supposed to be IMMUTABLE and thus not able to do anything very interesting, there are several easy ways around that restriction; and even if we could plug them all, there would remain a risk of reading sensitive information and broadcasting it through a covert channel such as CPU usage. To prevent bypassing this security measure, execution of SET SESSION AUTHORIZATION and SET ROLE is now forbidden within a SECURITY DEFINER context. Thanks to Itagaki Takahiro for reporting this vulnerability. Security: CVE-2007-6600 | 03 January 2008, 21:24:26 UTC |
8b1de3b | Tom Lane | 03 January 2008, 20:48:57 UTC | Fix assorted security-grade bugs in the regex engine. All of these problems are shared with Tcl, since it's their code to begin with, and the patches have been copied from Tcl 8.5.0. Problems: CVE-2007-4769: Inadequate check on the range of backref numbers allows crash due to out-of-bounds read. CVE-2007-4772: Infinite loop in regex optimizer for pattern '($|^)*'. CVE-2007-6067: Very slow optimizer cleanup for regex with a large NFA representation, as well as crash if we encounter an out-of-memory condition during NFA construction. Part of the response to CVE-2007-6067 is to put a limit on the number of states in the NFA representation of a regex. This seems needed even though the within-the-code problems have been corrected, since otherwise the code could try to use very large amounts of memory for a suitably-crafted regex, leading to potential DOS by driving the system into swap, activating a kernel OOM killer, etc. Although there are certainly plenty of ways to drive the system into effective DOS with poorly-written SQL queries, these problems seem worth treating as security issues because many applications might accept regex search patterns from untrustworthy sources. Thanks to Will Drewry of Google for reporting these problems. Patches by Will Drewry and Tom Lane. Security: CVE-2007-4769, CVE-2007-4772, CVE-2007-6067 | 03 January 2008, 20:48:57 UTC |
5ddd11b | Tom Lane | 02 January 2008, 22:05:21 UTC | Insert ARST into the list of known timezone abbreviations. | 02 January 2008, 22:05:21 UTC |
af3de80 | Magnus Hagander | 02 January 2008, 19:53:19 UTC | Fix invalid ipv6 address in example. Per doc comment 7211. | 02 January 2008, 19:53:19 UTC |
a634642 | Tom Lane | 01 January 2008, 20:45:25 UTC | Update time zone data files to tzdata release 2007k. | 01 January 2008, 20:45:25 UTC |
8cc2397 | Bruce Momjian | 31 December 2007, 17:28:12 UTC | Provide a more helpful error message when there is an autoconf version mismatch; backpatch. | 31 December 2007, 17:28:12 UTC |
5a351b6 | Tom Lane | 18 December 2007, 00:04:22 UTC | Make path_recv() and poly_recv() reject paths/polygons containing no points. The zero-point case is sensible so far as the data structure is concerned, so maybe we ought to allow it sometime; but right now the textual input routines for these types don't allow it, and it seems that not all the functions for the types are prepared to cope. Report and patch by Merlin Moncure. | 18 December 2007, 00:04:22 UTC |
3c92d5f | Tom Lane | 01 December 2007, 17:58:54 UTC | Suppress compiler warnings in recent plperl patch. Avoid uselessly expensive lookup of the well-known OID of textout(). | 01 December 2007, 17:58:54 UTC |
63276b7 | Andrew Dunstan | 01 December 2007, 15:39:49 UTC | Workaround for perl problem where evaluating UTF8 regexes can cause implicit loading of modules, thereby breaking Safe rules. We compile and call a tiny perl function on trusted interpreter init, after which the problem does not occur. | 01 December 2007, 15:39:49 UTC |
f575dfc | Peter Eisentraut | 26 November 2007, 12:27:03 UTC | Require a specific Autoconf version, instead of a lower bound only. | 26 November 2007, 12:27:03 UTC |
4bf3801 | Alvaro Herrera | 23 November 2007, 01:47:12 UTC | Fix buggy usage of vsnprintf in PL/Python by removing it altogether, instead relying on stringinfo.c. This fixes a problem reported by Marko Kreen, but I didn't use his patch, per subsequent discussion. | 23 November 2007, 01:47:12 UTC |