Обсуждение: First-draft release notes for next week's releases
... are committed at https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5996cfc4665735a7e6e8d473bd66e8b11e320bbb Please send comments/corrections by Sunday. regards, tom lane
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: https://www.postgresql.org/message-id/7B44397E-5E0A-462F-8148-1C444640FA0B%40simply.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 > > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=5996cfc4665735a7e6e8d473bd66e8b11e320bbb > 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: > https://www.postgresql.org/message-id/7B44397E-5E0A-462F-8148-1C444640FA0B%40simply.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, 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. 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