First-draft release notes for next week's releases
On Fri, Feb 8, 2019 at 5:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Please send comments/corrections by Sunday.
Note that "Fix deadlock in GIN vacuum introduced by 218f51584d5"
(which is commit fd83c83d on the master branch) is not that far from
being a complete revert of a v10 feature (this appears as "Reduce page
locking during vacuuming of GIN indexes" in the v10 release notes).
Perhaps that's something that needs to be pointed out directly, as
happened with the the recheck_on_update issue in the last point
release. We may even need to revise the v10 release notes.
--
Peter Geoghegan
Peter Geoghegan <pg@bowt.ie> writes:
Note that "Fix deadlock in GIN vacuum introduced by 218f51584d5"
(which is commit fd83c83d on the master branch) is not that far from
being a complete revert of a v10 feature (this appears as "Reduce page
locking during vacuuming of GIN indexes" in the v10 release notes).
Yeah, I saw that in the commit message, but didn't really think that
the release note entry needed to explain it that way. Could be
argued differently though.
We may even need to revise the v10 release notes.
Perhaps just remove that item from the 10.0 notes?
regards, tom lane
On Fri, Feb 8, 2019 at 6:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yeah, I saw that in the commit message, but didn't really think that
the release note entry needed to explain it that way. Could be
argued differently though.
I'm pretty confident that somebody is going to miss this
functionality, if this account of how the patch helped Yandex is
anything to go by:
/messages/by-id/7B44397E-5E0A-462F-8148-1C444640FA0B@simply.name
We may even need to revise the v10 release notes.
Perhaps just remove that item from the 10.0 notes?
The wording could be changed to reflect the current reality within
GIN. It's still useful that posting trees are only locked when there
are pages to be deleted.
--
Peter Geoghegan
On Sat, Feb 9, 2019 at 6:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
... are committed at
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
+Branch: master [0464fdf07] 2019-01-21 20:08:52 -0300
+Branch: REL_11_STABLE [123cc697a] 2019-01-21 19:59:07 -0300
+-->
+ <para>
+ Create or delete foreign key enforcement triggers correctly when
+ attaching or detaching a partition in a a partitioned table that
+ has a foreign-key constraint (Amit Langote, Álvaro Herrera)
+ </para>
+ </listitem>It seems like there is a typo in the above sentence. /a a
partitioned/a partitioned
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
Amit Kapila <amit.kapila16@gmail.com> writes:
On Sat, Feb 9, 2019 at 6:49 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: + Create or delete foreign key enforcement triggers correctly when + attaching or detaching a partition in a a partitioned table that + has a foreign-key constraint (Amit Langote, Álvaro Herrera)
It seems like there is a typo in the above sentence. /a a
partitioned/a partitioned
Ooops, obviously my eyes had glazed over by the time I went back to
proofread. Thanks for catching that.
regards, tom lane
El 9/2/19 a las 4:19, Tom Lane escribió:
Please send comments/corrections by Sunday.
+ tuple deletion WAL record (Stas Kelvish)
-- a typo in his surname, should be Kelvich.
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Peter Geoghegan <pg@bowt.ie> writes:
On Fri, Feb 8, 2019 at 6:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yeah, I saw that in the commit message, but didn't really think that
the release note entry needed to explain it that way. Could be
argued differently though.
I'm pretty confident that somebody is going to miss this
functionality, if this account of how the patch helped Yandex is
anything to go by:
/messages/by-id/7B44397E-5E0A-462F-8148-1C444640FA0B@simply.name
Ugh. Well, hopefully somebody will find a less buggy solution
in the future.
We may even need to revise the v10 release notes.
Perhaps just remove that item from the 10.0 notes?
The wording could be changed to reflect the current reality within
GIN. It's still useful that posting trees are only locked when there
are pages to be deleted.
The v10 release notes just say
Reduce page locking during vacuuming of <acronym>GIN</acronym> indexes
(Andrey Borodin)
so it doesn't seem like there's any difference at that level of detail.
But I'll expand the new release note, say
This change partially reverts a performance improvement, introduced
in version 10, that attempted to reduce the number of index pages
locked during deletion of a GIN posting tree page. That's now been
found to lead to deadlocks, so we've removed it pending closer
analysis.
regards, tom lane
On Sun, Feb 10, 2019 at 10:05 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Peter Geoghegan <pg@bowt.ie> writes:
On Fri, Feb 8, 2019 at 6:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
The v10 release notes just say
Reduce page locking during vacuuming of <acronym>GIN</acronym> indexes
(Andrey Borodin)so it doesn't seem like there's any difference at that level of detail.
But I'll expand the new release note, sayThis change partially reverts a performance improvement, introduced
in version 10, that attempted to reduce the number of index pages
locked during deletion of a GIN posting tree page. That's now been
found to lead to deadlocks, so we've removed it pending closer
analysis.
That plan seems sensible to me. The wording looks good, too.
--
Peter Geoghegan
On Sat, Feb 09, 2019 at 02:26:03PM +0300, Alexander Kuzmenkov wrote:
El 9/2/19 a las 4:19, Tom Lane escribió:
Please send comments/corrections by Sunday.
+ tuple deletion WAL record (Stas Kelvish)
-- a typo in his surname, should be Kelvich.
You are right, the commit message is the origin of the mistake. My
apologies.
--
Michael