Thread: 2020-05-14 Press Release Draft

Hi,

Attached is a draft of the press release for the 2020-05-14 cumulative
update. Please let me know your feedback by 2020-05-13 :)

Thanks,

Jonathan

At Sun, 10 May 2020 22:08:46 -0400, "Jonathan S. Katz" <jkatz@postgresql.org> wrote in 
> Attached is a draft of the press release for the 2020-05-14 cumulative
> update. Please let me know your feedback by 2020-05-13 :)

Thank you.  I found a typo in it.

> * Ensure that a detatched partition has triggers that come from its former
> parent removed.

s/detatched/detached/ ?

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

On Mon, 11 May 2020 at 14:09, Jonathan S. Katz <jkatz@postgresql.org> wrote:
> Attached is a draft of the press release for the 2020-05-14 cumulative
> update. Please let me know your feedback by 2020-05-13 :)

Hi,

Thanks for drafting those up.

For:

* Several fixes for GENERATED columns, including an issue where it was possible
to crash or corrupt data in a table when the output of the generated column was
the exact copy of a physical column on the table.

I think it's important to include the "or if the expression called a
function which could, in certain cases, return its own input".

The reason I think that's important is because there's likely no
legitimate case for having the expression an exact copy of the column.

David

On Sun, May 10, 2020 at 10:08:46PM -0400, Jonathan S. Katz wrote:
> * Ensure that a detatched partition has triggers that come from its former
> parent removed.

I would have said: "fix for issue which prevented/precluded detaching
partitions which have inherited ROW triggers"

> * Several fixes for `REINDEX CONCURRENTLY`, particular with dealing with issue
>  when a `REINDEX CONCURRENTLY` operation fails.

".. in particular relating to an issue ..."

> * Avoid scanning irrelevant timelines during archive recovery, which can
> eliminate attempts to fetch nonexistent WAL files from archive storage.

I feel like this is phrased backwards.  The goal is to avoid (attempting to)
fetch nonextant WALs, and the mechanism is by skipping timelines.  Maybe:

 * Avoid attempting to fetch nonexistent WAL files from archive storage during
 * recovery by skipping irrelevant timelines.

-- 
Justin

Hi,

On 5/10/20 10:08 PM, Jonathan S. Katz wrote:
> Hi,
>
> Attached is a draft of the press release for the 2020-05-14 cumulative
> update. Please let me know your feedback by 2020-05-13 :)

Thank you for the feedback. As per usual, I applied some combination of
{all, some, none}.

Please see v2.

Thanks again for the review!

Jonathan