Justin Pryzby writes:
> It's of no concern, but I was curious why this one wasn't included:
> commit 72aea955d49712a17c08748aa9abcbcf98c32fc5
> Author: Thomas Munro
> Date: Fri Jan 6 16:38:46 2023 +1300
> Fix pg_truncate() on Windows.
> Commit 57faaf376 added pg_truncate(const ch
On Fri, Feb 03, 2023 at 02:32:39PM -0500, Tom Lane wrote:
> ... at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c
>
> As usual, please send corrections/comments by Sunday.
It's of no concern, but I was curious why this one wasn't i
On 2/5/23 9:39 PM, Tom Lane wrote:
Prevent clobbering of cached parsetrees for utility statements in
SQL functions (Tom Lane, Daniel Gustafsson)
If a SQL-language function executes the same utility command more
than once within a single calling
"Jonathan S. Katz" writes:
> On 2/5/23 3:01 PM, Tom Lane wrote:
>> Fair. I was trying to avoid committing to specific consequences.
>> The assertion failure seen in the original report (#17702) wouldn't
>> occur for typical users, but they might see crashes or "unexpected node
>> type" failures.
On 2/5/23 3:01 PM, Tom Lane wrote:
"Jonathan S. Katz" writes:
On Feb 4, 2023, at 10:24 AM, Tom Lane wrote:
“Prevent clobbering of cached parsetrees…Bad things could happen if…”
While I chuckled over the phrasing, I’m left to wonder what the “bad things”
are, in case I
need to check an old
Thomas Munro writes:
> On Mon, Feb 6, 2023 at 8:57 AM Tom Lane wrote:
>> Also, aren't shared tuplestores used in more places than just
>> parallel hash join? I mentioned that as an example, not an
>> exhaustive list of trouble spots.
> Shared file sets (= a directory of temp files with automati
On Mon, Feb 6, 2023 at 8:57 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2023-Feb-03, Tom Lane wrote:
> >> Fix edge-case data corruption in shared tuplestores (Dmitry Astapov)
>
> > I think this sounds really scary, because people are going to think that
> > their stored data can get
I wrote:
> Alvaro Herrera writes:
>> I think this sounds really scary, because people are going to think that
>> their stored data can get corrupted -- they don't necessarily know what
>> a "shared tuplestore" is. Maybe "Avoid query failures in parallel hash
>> joins" as headline?
Maybe less sca
"Jonathan S. Katz" writes:
> On Feb 4, 2023, at 10:24 AM, Tom Lane wrote:
>> “Prevent clobbering of cached parsetrees…Bad things could happen if…”
> While I chuckled over the phrasing, I’m left to wonder what the “bad things”
> are, in case I
> need to check an older version to see if I’m susce
Alvaro Herrera writes:
> On 2023-Feb-03, Tom Lane wrote:
>> Fix edge-case data corruption in shared tuplestores (Dmitry Astapov)
> I think this sounds really scary, because people are going to think that
> their stored data can get corrupted -- they don't necessarily know what
> a "shared t
On 2023-Feb-03, Tom Lane wrote:
> ... at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c
>
> As usual, please send corrections/comments by Sunday.
Fix edge-case data corruption in shared tuplestores (Dmitry Astapov)
If
> On Feb 4, 2023, at 10:24 AM, Tom Lane wrote:
>
> ... at
>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f282b026787da69d88a35404cf62f1cc21cfbb7c
>
> As usual, please send corrections/comments by Sunday.
While reviewing for the release announcement, I noticed this (a
On 8/8/19 2:45 PM, Alvaro Herrera wrote:
> On 2019-Aug-08, Jonathan S. Katz wrote:
>
>> On 8/8/19 2:40 PM, Alvaro Herrera wrote:
>>> On 2019-Aug-08, Jonathan S. Katz wrote:
>>>
I modified the copy of the announcement on the website to include the
pg_upgrade option.
https://www.
On 2019-Aug-08, Jonathan S. Katz wrote:
> On 8/8/19 2:40 PM, Alvaro Herrera wrote:
> > On 2019-Aug-08, Jonathan S. Katz wrote:
> >
> >> I modified the copy of the announcement on the website to include the
> >> pg_upgrade option.
> >>
> >> https://www.postgresql.org/about/news/1960/
> >
> > Ooh,
On 8/8/19 2:40 PM, Alvaro Herrera wrote:
> On 2019-Aug-08, Jonathan S. Katz wrote:
>
>> I modified the copy of the announcement on the website to include the
>> pg_upgrade option.
>>
>> https://www.postgresql.org/about/news/1960/
>
> Ooh, had I thought you were going to do that, I would have told
On 2019-Aug-08, Jonathan S. Katz wrote:
> I modified the copy of the announcement on the website to include the
> pg_upgrade option.
>
> https://www.postgresql.org/about/news/1960/
Ooh, had I thought you were going to do that, I would have told you
about the item ending in a comma :-)
--
Álvar
On 8/8/19 2:15 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> On 2019-Aug-04, Jonathan S. Katz wrote:
>>> * Ensure that partition key columns will not be dropped as the result of an
>>> "indirect drop," such as from a cascade from dropping the key column's data
>>> type (e.g. a custom data type).
Alvaro Herrera writes:
> On 2019-Aug-04, Jonathan S. Katz wrote:
>> * Ensure that partition key columns will not be dropped as the result of an
>> "indirect drop," such as from a cascade from dropping the key column's data
>> type (e.g. a custom data type). This fix is applied only to newly create
I realize that this has now been sent, but I wanted to comment on one
item:
On 2019-Aug-04, Jonathan S. Katz wrote:
> * Ensure that partition key columns will not be dropped as the result of an
> "indirect drop," such as from a cascade from dropping the key column's data
> type (e.g. a custom dat
On 8/4/19 11:08 AM, Jonathan S. Katz wrote:
> On 8/4/19 10:52 AM, Tom Lane wrote:
>> "Jonathan S. Katz" writes:
>>> Perhaps instead of "June" it could be the specific version number (which
>>> could cause some pain with the back branching?) or the "2019-06-20" release?
>>
>> Putting in all the ver
On 8/4/19 10:52 AM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> Perhaps instead of "June" it could be the specific version number (which
>> could cause some pain with the back branching?) or the "2019-06-20" release?
>
> Putting in all the version numbers seems like a mess, but specifying
> 2
"Jonathan S. Katz" writes:
> Perhaps instead of "June" it could be the specific version number (which
> could cause some pain with the back branching?) or the "2019-06-20" release?
Putting in all the version numbers seems like a mess, but specifying
2019-06-20 would work --- or we could say "the
On 8/2/19 3:21 PM, Tom Lane wrote:
> See
> https://git.postgresql.org/pg/commitdiff/082c9f5f761ced18a6f014f2638096f6a8228164
>
> Please send comments/corrections before Sunday.
While working on the PR, I noticed this line:
"This fixes a regression introduced in June's minor releases..."
Perhaps
23 matches
Mail list logo
