On Sat, Feb 8, 2020 at 12:05 PM Tom Lane wrote:
>
> Fujii Masao writes:
> > On Sat, Feb 8, 2020 at 11:08 AM Tom Lane wrote:
> >> Personally I'd keep SO_TYPE_TIDSCAN physically adjacent to the other
> >> SO_TYPE_xxxSCAN entries in the list, but of course that's just cosmetic.
>
> > +1. So I will
Revert recent change of ScanOption values and renumber SO_TYPE_TIDSCAN.
Commit 598b466e80 in v12 renumbered ScanOption enum values to add
the option for Tid scan. But the change of the codes assigned to
the existing values caused an ABI break and may break some extensions
depending on them. This s
Fujii Masao writes:
> On Sat, Feb 8, 2020 at 11:08 AM Tom Lane wrote:
>> Personally I'd keep SO_TYPE_TIDSCAN physically adjacent to the other
>> SO_TYPE_xxxSCAN entries in the list, but of course that's just cosmetic.
> +1. So I will apply the latest patch (adding SO_TYPE_TIDSCAN just after
> SO
On Sat, Feb 8, 2020 at 11:08 AM Tom Lane wrote:
>
> Fujii Masao writes:
> > On Sat, Feb 8, 2020 at 10:04 AM Tom Lane wrote:
> >> I think it's okay to add a new value of ScanOption; what you can't
> >> do is change the codes assigned to the existing values. So I'd
> >> just revert those code cha
Fujii Masao writes:
> On Sat, Feb 8, 2020 at 10:04 AM Tom Lane wrote:
>> I think it's okay to add a new value of ScanOption; what you can't
>> do is change the codes assigned to the existing values. So I'd
>> just revert those code changes and give SO_TYPE_TIDSCAN a value
>> that's out-of-order.
On Sat, Feb 8, 2020 at 10:04 AM Tom Lane wrote:
>
> Fujii Masao writes:
> > On Sat, Feb 8, 2020 at 4:25 AM Tom Lane wrote:
> >> AFAICS, this patch has caused an ABI break in v12. Do we really
> >> believe that no extension references the values of the ScanOptions
> >> enum?
>
> > Yes, you are r
Fujii Masao writes:
> On Sat, Feb 8, 2020 at 4:25 AM Tom Lane wrote:
>> AFAICS, this patch has caused an ABI break in v12. Do we really
>> believe that no extension references the values of the ScanOptions
>> enum?
> Yes, you are right. Some extensions may depend on it.
> It's better not to add
On Sat, Feb 8, 2020 at 4:25 AM Tom Lane wrote:
>
> Fujii Masao writes:
> > Fix bug in Tid scan.
>
> AFAICS, this patch has caused an ABI break in v12. Do we really
> believe that no extension references the values of the ScanOptions
> enum?
Yes, you are right. Some extensions may depend on it.
First-draft release notes for 12.2.
As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.
Branch
--
REL_12_STABLE
Details
---
https://git.postgresql.org/pg/commitdiff/388d4351f78dfa6082922074127d496e6f525033
Modifi
Fix failure to create FKs correctly in partitions
On a multi-level partioned table, when adding a partition not directly
connected to the root table, foreign key constraints referencing the
root were not cloned to the new partition, leading to the FK being
possibly inadvertently violated later on.
Fix failure to create FKs correctly in partitions
On a multi-level partioned table, when adding a partition not directly
connected to the root table, foreign key constraints referencing the
root were not cloned to the new partition, leading to the FK being
possibly inadvertently violated later on.
Fix TRUNCATE .. CASCADE on partitions
When running TRUNCATE CASCADE on a child of a partitioned table
referenced by another partitioned table, the truncate was not applied to
partitions of the referencing table; this could leave rows violating the
constraint in the referencing partitioned table.
Fix TRUNCATE .. CASCADE on partitions
When running TRUNCATE CASCADE on a child of a partitioned table
referenced by another partitioned table, the truncate was not applied to
partitions of the referencing table; this could leave rows violating the
constraint in the referencing partitioned table.
Fujii Masao writes:
> Fix bug in Tid scan.
AFAICS, this patch has caused an ABI break in v12. Do we really
believe that no extension references the values of the ScanOptions
enum?
regards, tom lane
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Thu, Feb 06, 2020 at 09:44:07AM -0500, Stephen Frost wrote:
> > Erm- no, with -Ft + untar-as-root they get owned by "postgres", NOT the
> > original user. That's what I was pointing out up-thread (since it seems
> > to be confusing- a
Alexander Korotkov writes:
> Fix page modification outside of critical section in GIN
> By oversight 52ac6cd2d0 makes ginDeletePage() sets pd_prune_xid of page to be
> deleted before entering the critical section. It appears that only versions
> 11
> and later were affected by this oversight.
I
Fix bug in Tid scan.
Commit 147e3722f7 changed Tid scan so that it calls table_beginscan()
and uses the scan option for seq scan. This change caused two issues.
(1) The change caused Tid scan to take a predicate lock on the entire
relation in serializable transaction even when relation-lev
Fix bug in Tid scan.
Commit 147e3722f7 changed Tid scan so that it calls table_beginscan()
and uses the scan option for seq scan. This change caused two issues.
(1) The change caused Tid scan to take a predicate lock on the entire
relation in serializable transaction even when relation-lev
18 matches
Mail list logo
