Dean Rasheed writes:
> On Wed, 14 Aug 2024 at 07:31, Joel Jacobson wrote:
>> I think this is acceptable, since it produces more correct results.
> Thanks for checking. I did a bit more testing myself and didn't see
> any problems, so I have committed both these patches.
About a dozen buildfarm
Hello, everyone!
This patch set addresses the issues discussed in this thread.
The main idea behind this fix is that it is safe to consider indisready
indexes alongside indisvalid indexes as arbiter indexes. However, it's
crucial that at least one fully valid index is present.
Why is it necessar
The list of acknowledgments for the PG17 release notes has been
committed. You can see it here:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/release-17.sgml;h=08a479807ca2933668dede22e4e6f464b937ee45;hb=refs/heads/REL_17_STABLE#l3229
As usual, please check for prob
On Sat, Aug 24, 2024 at 9:47 PM Peter Eisentraut wrote:
>
> On 24.08.24 14:49, Junwang Zhao wrote:
> > What I haven't addressed is that the repo still uses specific local
> > paths, I think
> > this is ok since the code is not going into the core.
>
> I'm not among the target users of this, but I
On 24/08/2024 11:42, Peter Eisentraut wrote:
Here is a patch to replace a getpwuid() call in the backend, for
thread-safety.
This is AFAICT the only call in the getpw*() family that needs to be
dealt with.
(There is also a getgrnam() call, but that is called very early in the
postmaster, before
On 24.08.24 14:49, Junwang Zhao wrote:
What I haven't addressed is that the repo still uses specific local
paths, I think
this is ok since the code is not going into the core.
I'm not among the target users of this, but I imagine that that would
significantly reduce the utility of this for eve
Sorry again.
The link to letter - -
https://www.postgresql.org/message-id/759292d5-cb51-4b12-89fa-576c1d9b374d%40postgrespro.ru
Patch -
https://www.postgresql.org/message-id/attachment/162897/v28-Transform-OR-clauses-to-ANY-expression.patch
On 24.08.2024 16:23, Alexander Korotkov wrote:
O
On Sat, Aug 24, 2024 at 4:08 PM Alena Rybakina
wrote:
> On 23.08.2024 19:38, Alexander Korotkov wrote:
> > Hi, Alena!
> >
> > On Fri, Aug 23, 2024 at 5:06 PM Alena Rybakina
> > wrote:
> >> To be fair, I fixed this before [0] by selecting the appropriate group
> >> of "or" expressions to transform
On 23.08.2024 19:38, Alexander Korotkov wrote:
Hi, Alena!
On Fri, Aug 23, 2024 at 5:06 PM Alena Rybakina
wrote:
To be fair, I fixed this before [0] by selecting the appropriate group
of "or" expressions to transform them to "ANY" expression and then
checking for compatibility with the index co
Hi hackers,
On Sun, Aug 4, 2024 at 10:12 PM Andrew Dunstan wrote:
>
>
> On 2024-08-03 Sa 10:13 PM, Junwang Zhao wrote:
> > On Sat, Aug 3, 2024 at 7:30 PM Andrew Dunstan wrote:
> >>
> >> On 2024-08-02 Fr 2:45 PM, Peter Eisentraut wrote:
> >>> On 01.08.24 23:38, Andrew Dunstan wrote:
> Not to
On Wed, Aug 21, 2024 at 11:37 AM Nathan Bossart
wrote:
>
> Hm. It seems pretty clear that removing -fwrapv won't be happening
anytime
> soon. I don't mind trying to fix a handful of cases from time to time,
but
> unless there's a live bug, I'm probably not going to treat this stuff as
> high pri
On Sat, 24 Aug 2024 at 08:26, Joel Jacobson wrote:
>
> On Sat, Aug 24, 2024, at 01:35, Joel Jacobson wrote:
> > On Sat, Aug 24, 2024, at 00:00, Joel Jacobson wrote:
> >> Since statistical tools that rely on normal distributions can't be used,
> >> let's look at the individual measurements for (var
Here is a patch to replace a getpwuid() call in the backend, for
thread-safety.
This is AFAICT the only call in the getpw*() family that needs to be
dealt with.
(There is also a getgrnam() call, but that is called very early in the
postmaster, before multiprocessing, so we can leave that as
On Sat, Aug 24, 2024, at 01:35, Joel Jacobson wrote:
> On Sat, Aug 24, 2024, at 00:00, Joel Jacobson wrote:
>> Since statistical tools that rely on normal distributions can't be used,
>> let's look at the individual measurements for (var1ndigits=3, var2ndigits=3)
>> since that seems to be the bigge
14 matches
Mail list logo