I experimented with running "make check" on ARM64 under a reasonably
bleeding-edge valgrind (3.16.0). One thing I ran into is that
regress.c's test_atomic_ops fails; valgrind shows the stack trace
fun:__aarch64_cas8_acq_rel
fun:pg_atomic_compare_exchange_u64_impl
I wrote:
> Noah Misch writes:
>> Apparently, valgrind-3.15.0 doesn't complain about undefined input
>> to _mm_crc32_u* functions. We should not be surprised if Valgrind gains the
>> features necessary to complain about the other implementations.
> Perhaps it already has ... I wonder if anyone's
Thomas Munro writes:
> Yeah, I wasn't planning on changing anything in backbranches. It
> sounds like we're OK with doing this for 13. Here's a version with a
> few more changes:
Looks pretty good to me. I attach a delta patch with a few more
proposed adjustments. Notably, I made the wording
On Sun, Jun 7, 2020 at 4:39 AM Magnus Hagander wrote:>
> Oh they absolutely will. But most likely they will also use an older version
> of PostgreSQL because that's what their enterprise product supports. And
> we're not talking about removing the documentation from the old version (I'm
>
I wrote:
> So I'm content to fix this by removing the check for useshrplib.
Having said that ... it does not appear to me that the Debian perl
maintainer foresaw all the consequences of this change, so I went
ahead and filed some push-back at
Noah Misch writes:
> I meant that PostgreSQL's ./configure must get the same answers, and it does
> (should have posted this instead of what I did post):
Ah, that looks good. I suppose that we can generally expect that the
ldflags output will look like "-L/some/path -lperl ...", and whether
or
On Sat, Jun 06, 2020 at 08:38:13PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Sat, Jun 06, 2020 at 07:11:51PM -0400, Tom Lane wrote:
> >> I wonder whether we could just drop the configure-time
> >> test for useshrplib.
>
> > Losing that would not hurt much. This solution relies on all
Noah Misch writes:
> On Sat, Jun 06, 2020 at 07:11:51PM -0400, Tom Lane wrote:
>> I wonder whether we could just drop the configure-time
>> test for useshrplib.
> Losing that would not hurt much. This solution relies on all other Perl
> configure tests getting the same answer from /usr/bin/perl
On Sat, Jun 06, 2020 at 07:11:51PM -0400, Tom Lane wrote:
> I wrote:
> > A bit of searching turned up this:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798626
>
> BTW, as far as I can tell from the underlying discussion at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962138
>
I wrote:
> A bit of searching turned up this:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798626
BTW, as far as I can tell from the underlying discussion at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962138
there was no actual change in the existence of the shared
library, but what
Noah Misch writes:
> On Sat, Jun 06, 2020 at 06:38:47PM -0400, Tom Lane wrote:
>> Noah Misch writes:
>>> The Debian Sid buildfarm members have dozens of failures over the last day,
>>> because the latest Perl packages caused "perl -V:useshrplib" to report
>>> false.
>> Has anyone filed a bug
On Sat, Jun 06, 2020 at 06:38:47PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > The Debian Sid buildfarm members have dozens of failures over the last day,
> > because the latest Perl packages caused "perl -V:useshrplib" to report
> > false.
>
> Has anyone filed a bug report?
Not me.
Noah Misch writes:
> The Debian Sid buildfarm members have dozens of failures over the last day,
> because the latest Perl packages caused "perl -V:useshrplib" to report false.
Has anyone filed a bug report?
regards, tom lane
The Debian Sid buildfarm members have dozens of failures over the last day,
because the latest Perl packages caused "perl -V:useshrplib" to report false.
On thorntail, for some reason, "perl5.30-sparc64-linux-gnu -V:useshrplib" does
return true. I've added PERL=perl5.30-sparc64-linux-gnu to
Peter Eisentraut writes:
> I'm also wondering whether this is fully correct. Would it be possible for
> the
> argument types of the operator/function to differ from the left arg/right arg
> types? (Perhaps binary compatible?)
pg_amop.h specifies that
* The primary key for this table is .
On 2020-03-31 08:48, Michael Paquier wrote:
On Mon, Mar 30, 2020 at 05:00:01PM +0300, Alexey Kondratov wrote:
What do think about adding following sanity check into xlogarchive.c?
+#ifdef FRONTEND
+#error "This file is not expected to be compiled for frontend code"
+#endif
It would prevent
I'm somewhat confused by the selection and order of the output columns
produced by the new psql commands \dAo and \dAp (access method operators
and functions, respectively). Currently, you get
\dAo
AM | Operator family | Operator
-+-+--
gin |
On Sat, Jun 6, 2020 at 6:35 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 2020-06-06 17:14, Tom Lane wrote:
> >> Let's hope PG13 isn't that late -- the end of Extended Lifecycle
> Support is
> >> June 30, 2024 for RHEL 6. (It*enters* ELS around the time of pg 13).
> > ELS
On 2020-06-06 17:14, Tom Lane wrote:
Let's hope PG13 isn't that late -- the end of Extended Lifecycle Support is
June 30, 2024 for RHEL 6. (It*enters* ELS around the time of pg 13).
ELS basically means that they aren't going to take down the existing
website information about RHEL6 just yet.
Andres Freund writes:
> On 2020-06-03 18:41:28 -0400, Tom Lane wrote:
>> * pqSendSome() is responsible not only for pushing out data, but for
>> calling pqReadData in any situation where it can't get rid of the data
>> promptly. 1f39a1c06 overlooked that requirement, and the upshot is
>> that we
Magnus Hagander writes:
> On Sat, Jun 6, 2020 at 4:41 PM Tom Lane wrote:
>> So I concur with dropping all this stuff, and while we're at it I'd vote
>> for getting rid of the oom_adj para. RHEL6 will be fully EOL around the
>> time PG13 comes out, so I don't believe anyone's making brand new
On Sat, Jun 6, 2020 at 4:41 PM Tom Lane wrote:
> Peter Eisentraut writes:
> > On 2020-06-06 06:57, Thomas Munro wrote:
> >> We're carrying a bunch of obsolete and in one case insecure advice on
> >> kernel settings. Here's an attempt to clean some of that up.
>
> > These changes seem sensible
Peter Eisentraut writes:
> On 2020-06-06 06:57, Thomas Munro wrote:
>> We're carrying a bunch of obsolete and in one case insecure advice on
>> kernel settings. Here's an attempt to clean some of that up.
> These changes seem sensible to me.
+1
>> HP-UX:
>> * Drop advice for v10. 11.x came
Hello,
This patch was marked as ready for committer, but clearly there's an
ongoin discussion about what should be the default behavoir, if this
breaks existing apps etc. So I've marked it as "needs review" and moved
it to the next CF.
The issue is that root (aka Tom) seems to be against the
On Wed, Jun 03, 2020 at 08:22:29PM +0800, 李杰(慎追) wrote:
> Partitioning is necessary for very large tables.
> However, I found that postgresql does not support create index concurrently
> on partitioned tables.
> The document show that we need to create an index on each partition
> individually
> On Fri, Jun 05, 2020 at 12:26:15PM +1200, David Rowley wrote:
> On Mon, 25 May 2020 at 19:14, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> >
> > > On Mon, May 25, 2020 at 06:34:30AM +1200, David Rowley wrote:
> > > The difference will be that you'd be setting some distinct_uniquekeys
> > > in
On 2020-06-06 06:57, Thomas Munro wrote:
We're carrying a bunch of obsolete and in one case insecure advice on
kernel settings. Here's an attempt to clean some of that up.
These changes seem sensible to me.
HP-UX:
* Drop advice for v10. 11.x came out 23 years ago.
We still have a
27 matches
Mail list logo
