On Sat, Jul 2, 2022 at 9:38 AM Andres Freund wrote:
Thanks for the review,
> I'm not feeling inspired by "locator", tbh. But I don't really have a great
> alternative, so ...
>
>
> On 2022-07-01 16:12:01 +0530, Dilip Kumar wrote:
> > From f07ca9ef19e64922c6ee410707e93773d1a01d7c Mon Sep 17 00:00
On Sat, Jul 2, 2022 at 4:53 AM Dilip Kumar wrote:
> > I'm doubtful it's a good idea to start dropping at the first segment. I'm
> > fairly certain that there's smgrexists() checks in some places, and they'll
> > now stop working, even if there are later segments that remained, e.g.
> > because
>
On Fri, Jul 1, 2022 at 7:14 PM Justin Pryzby wrote:
> I noticed this during beta1, but dismissed the issue when it wasn't easily
> reproducible. Now, I saw the same problem while upgrading from beta1 to
> beta2,
> so couldn't dismiss it. It turns out that LOs are lost if VACUUM FULL was
> run.
On Fri, Jul 1, 2022 at 5:12 PM Nathan Bossart wrote:
> > I have some hesitations about this approach. On the positive side, I
> > believe it's fully backward compatible, and that's something to like.
> > On the negative side, I've always felt that the role-level properties
> > - [NO]INHERIT, [NO]C
On Sat, Jul 2, 2022 at 8:51 AM Amit Kapila wrote:
>
> On Fri, Jul 1, 2022 at 10:22 PM vignesh C wrote:
> >
> > On Wed, Jun 29, 2022 at 3:25 PM houzj.f...@fujitsu.com
> > wrote:
> > >
> >
> > Thanks for the updated patch.
> > Few comments on 0002 patch:
> > 1) When we create a subscription for a
On Sat, Jul 02, 2022 at 08:34:04AM -0400, Robert Haas wrote:
> On Fri, Jul 1, 2022 at 7:14 PM Justin Pryzby wrote:
> > I noticed this during beta1, but dismissed the issue when it wasn't easily
> > reproducible. Now, I saw the same problem while upgrading from beta1 to
> > beta2,
> > so couldn't
On Sat, Jul 02, 2022 at 08:34:04AM -0400, Robert Haas wrote:
> On Fri, Jul 1, 2022 at 7:14 PM Justin Pryzby wrote:
> > I noticed this during beta1, but dismissed the issue when it wasn't easily
> > reproducible. Now, I saw the same problem while upgrading from beta1 to
> > beta2,
> > so couldn't
Peter Eisentraut writes:
> To summarize:
> - Autoconf 2.71 has been out for 1.5 years.
> - It is available in many recently updated OSs.
> - It allows us to throw away several workarounds.
> Hence:
>> Currently, I think early PG16 might be good time to do this update.
In preparation for reviewing
Hello, Simon.
Sorry for calling you directly, but you know the subject better than
anyone else. It is related to your work from 2010 - replacing
KnownAssignedXidsHash with the KnownAssignedXids array.
I have added additional optimization to the data structure you
implemented. Initially, it was ca
I wrote:
> So that explains part of it: most of the failures are down to using
> Apple's hoary m4 instead of the one from MacPorts. We could usefully
> warn about that in our own docs, perhaps.
Hmm. I have just spent a very frustrating hour trying, and failing,
to build any version of GNU m4 fro
Hi,
(sorry for sending this twice to you Noah, forgot -hackers the first time
round)
We've had a bunch of changes to manually deal with our alignment code not
understanding AIX alignment.
commit f3b421da5f4addc95812b9db05a24972b8fd9739
Author: Peter Eisentraut
Date: 2016-12-21 12:00:00 -0500
On Fri, 2022-07-01 at 15:33 -0700, Nathan Bossart wrote:
> On Fri, Jul 01, 2022 at 03:24:27PM -0700, Jeff Davis wrote:
> > + ereport(DEBUG1, errmsg("executing extension update
> > script from version '%s' to '%s'", from_version, version));
>
> nitpick: I would suggest "executing extensio
Noah Misch writes:
> I had expected to use pthread_once() for the newlocale() call, but there would
> be no useful way to report failure and try again later. Instead, I called
> newlocale() while ECPGconnect() holds connections_mutex. See log message and
> comments for details. I tested "./conf
On Sat, Jul 2, 2022 at 11:34 AM Andres Freund wrote:
> Personally I think we should just drop AIX. The amount of effort to keep it
> working is substantial due to being quite different from other unices ([2]),
> the is
> very outdated, the whole ecosystem is barely on lifesupport ([3]). And all o
Peter Geoghegan writes:
> I tend to agree about dropping AIX. But I wonder if there is an
> argument against that proposal that doesn't rely on AIX being relevant
> to at least one user. Has supporting AIX ever led to the discovery of
> a bug that didn't just affect AIX?
Searching the commit log
Hi,
On 2022-07-02 14:23:08 +0530, Dilip Kumar wrote:
> > > + if (ShmemVariableCache->relnumbercount == 0)
> > > + {
> > > +
> > > XLogPutNextRelFileNumber(ShmemVariableCache->nextRelFileNumber +
> > > +
> > > VAR_RF
Hey Alexander,
> But I think we can support strict inequalities too (e.g.
less and greater without equals). Could you please make it a bool
argument equal_matches?
Sure, an argument is a good idea to keep the code shorter.
> Could you please extract this change as a separate patch.
Done!
On T
Hi,
On 2022-07-02 11:54:16 -0700, Peter Geoghegan wrote:
> I tend to agree about dropping AIX. But I wonder if there is an
> argument against that proposal that doesn't rely on AIX being relevant
> to at least one user. Has supporting AIX ever led to the discovery of
> a bug that didn't just affec
On Thu Jun 9, 2022 at 11:57 AM EDT, David G. Johnston wrote:
> Reposting this to its own thread.
>
> https://www.postgresql.org/message-id/flat/CAKFQuwby1aMsJDMeibaBaohgoaZhivAo4WcqHC1%3D9-GDZ3TSng%40mail.gmail.com
>
> doc: make unique non-null join selectivity example match the prose
>
> T
On Sat, Jul 2, 2022 at 12:22 PM Tom Lane wrote:
> Now, it's certainly possible that AIX is the only surviving platform
> that hasn't adopted bug-compatible-with-glibc interpretations of
> POSIX. But I think the standard is the standard, and we ought to
> stay within it. So I find value in these
Peter Geoghegan writes:
> Maybe it is still worth hanging on to AIX support for the time being,
> but it would be nice to have some idea of where we *will* finally draw
> the line. If the complaints from Andres aren't a good enough reason
> now, then what other hypothetical reasons might be good e
Hi,
On 2022-07-02 16:34:35 -0400, Tom Lane wrote:
> Agreed. But I think that this sort of thing is better driven by
> "when there's no longer anyone willing to do the legwork" than
> by project policy. IOW, we'll stop when Noah gets tired of doing
> it (and no one steps up to take his place).
I
Andres Freund writes:
> What made me look at this issue right now is that the alignment issue lead the
> 56bit relfilenode patch to move the relfilenode field to the start of pg_class
> (ahead of the oid),
Agreed, up with that we should not put. However ...
> because a 64bit value cannot be aft
On Fri, Jun 24, 2022 at 11:45:22AM +0100, Simon Riggs wrote:
> On Thu, 23 Jun 2022 at 18:15, Nathan Bossart wrote:
>> I'm grateful for the discussion in this thread so far, but I'm not seeing a
>> clear path forward.
>
> +1 to add the new auxiliary process.
I went ahead and put together a new pa
On Sat, Jul 02, 2022 at 08:45:50AM -0400, Robert Haas wrote:
> I don't think there is a whole lot of point in replacing role-level
> flags with predefined roles that work exactly the same way. Maybe
> there is some point, but I'm not excited about it. The problem with
> these settings in my opinion
Hi,
On 2022-07-02 15:05:54 -0700, Nathan Bossart wrote:
> + /* Obtain requested tasks */
> + SpinLockAcquire(&CustodianShmem->cust_lck);
> + flags = CustodianShmem->cust_flags;
> + CustodianShmem->cust_flags = 0;
> + SpinLockRelease(&Cust
On Fri, Jul 1, 2022 at 09:56:17AM -0700, Peter Geoghegan wrote:
> On Fri, Jul 1, 2022 at 9:41 AM Bruce Momjian wrote:
> > > It might be worth explaining the shift directly in the release notes.
> > > The new approach is simpler and makes a lot more sense -- why should
> > > the relfrozenxid be cl
>
> Okay, thanks Bruce.
--
Peter Geoghegan
On Sat, Jul 2, 2022 at 6:16 PM Nathan Bossart wrote:
> I was thinking that when DEFAULT was removed, pg_dump would just need to
> generate WITH INHERIT TRUE/FALSE based on the value of rolinherit for older
> versions. Using the role-level property as the default for future grants
> seems a viable
On Sat, Jul 02, 2022 at 02:53:34PM -0400, Tom Lane wrote:
> This looks solid to me. The only nit I can find to pick is that I'd
> have added one more comment, along the lines of
>
> diff --git a/src/interfaces/ecpg/ecpglib/connect.c
> b/src/interfaces/ecpg/ecpglib/connect.c
> index 9f958b822c..9
Noah Misch writes:
> Thanks for reviewing. Pushed with that comment. prairiedog complains[1]:
> ld: common symbols not allowed with MH_DYLIB output format with the
> -multi_module option
> connect.o definition of common _ecpg_clocale (size 4)
Blah.
> I bet this would fix it:
> -locale_t
On Sat, Jul 02, 2022 at 11:37:08PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > Thanks for reviewing. Pushed with that comment. prairiedog complains[1]:
> > ld: common symbols not allowed with MH_DYLIB output format with the
> > -multi_module option
> > connect.o definition of common _ec
Noah Misch writes:
> On Sat, Jul 02, 2022 at 11:37:08PM -0400, Tom Lane wrote:
>> Do you want me to test it on prairiedog?
> Sure, if it's easy enough. If not, I'm 87% sure it will suffice.
On it now, but it'll take a few minutes :-(
regards, tom lane
I wrote:
> On it now, but it'll take a few minutes :-(
Confirmed that either initializing ecpg_clocale or adding -fno-common
allows the ecpglib build to succeed. (Testing it beyond that would
require another hour or so to build the rest of the system, so I won't.)
As I said, I was already leanin
34 matches
Mail list logo
