On Mon, Aug 8, 2022 at 9:29 PM Önder Kalacı wrote:
>
> Hi,
>
> Thanks for the feedback, see my reply below.
>
>> >
>> > It turns out that we already invalidate the relevant entries in
>> > LogicalRepRelMap/LogicalRepPartMap when "ANALYZE" (or VACUUM) updates any
>> > of the statistics in
Hi peter,
Sorry to bother, but I notice that you are one of the most active
committers, can you pls take a look at this thread.
Thanks!
On Wed, Aug 10, 2022 at 11:32 PM Junwang Zhao wrote:
>
> when parsing command-line options, the -f option support disabling
> 8 scan and join methods, o, b
On Fri, Aug 12, 2022 at 06:22:01PM -0400, Bruce Momjian wrote:
> On Mon, Jan 10, 2022 at 12:19:28AM +0800, Wei Sun wrote:
> > Hi,
> >
> > Some time ago,the following patch clean up error handling in pg_basebackup's
> > walmethods.c.
> > https://github.com/postgres/postgres/commit/248c3a9
> >
> >
Thomas Munro writes:
> I'm curious, though... if we used compiler builtins, would
> -march/-mcpu etc know about this kind of thing, for people who wanted
> to compile on ancient hardware, or, I guess more interestingly, newer
> tricks that we haven't got around to learning about yet?
No idea,
On Mon, Jan 10, 2022 at 12:19:28AM +0800, Wei Sun wrote:
> Hi,
>
> Some time ago,the following patch clean up error handling in pg_basebackup's
> walmethods.c.
> https://github.com/postgres/postgres/commit/248c3a9
>
> This patch keep the error state in the DirectoryMethodData struct,
> in most
On Sat, Aug 13, 2022 at 8:08 AM Tom Lane wrote:
> I wrote:
> > I see that prairiedog was the only buildfarm animal failing the
> > HAVE_PPC_LWARX_MUTEX_HINT test, and it seems pretty unlikely that
> > there are any assemblers remaining in the wild that can't parse that.
>
> Actually, after
I wrote:
> I see that prairiedog was the only buildfarm animal failing the
> HAVE_PPC_LWARX_MUTEX_HINT test, and it seems pretty unlikely that
> there are any assemblers remaining in the wild that can't parse that.
Actually, after further investigation and testing, I think we could
drop the
On Fri, Aug 12, 2022 at 12:48 PM Bruce Momjian wrote:
> On Mon, Jul 18, 2022 at 08:04:12PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2022-07-18 19:47:39 -0700, David G. Johnston wrote:
> > > On Thu, Jul 14, 2022 at 4:31 PM Andres Freund
> wrote:
> > > > It might make sense to still say
On Mon, Jul 18, 2022 at 08:04:12PM -0700, Andres Freund wrote:
> Hi,
>
> On 2022-07-18 19:47:39 -0700, David G. Johnston wrote:
> > On Thu, Jul 14, 2022 at 4:31 PM Andres Freund wrote:
> > > It might make sense to still say semi-accurate, but adjust the explanation
> > > to
> > > say that stats
Continuing the project of removing dead configure tests ...
I see that prairiedog was the only buildfarm animal failing the
HAVE_PPC_LWARX_MUTEX_HINT test, and it seems pretty unlikely that
there are any assemblers remaining in the wild that can't parse that.
(I've confirmed that
Hi,
On 2022-08-12 18:08:00 +0200, Peter Eisentraut wrote:
> > At the moment there's three suites differentiating by the type of test:
> > 'pg_regress', 'isolation' and 'tap'. There's also a separate "axis" of
> > suites,
> > describing what's being tested, e.g. 'main', 'test_decoding',
On 11.08.22 06:04, Andres Freund wrote:
At the moment there's three suites differentiating by the type of test:
'pg_regress', 'isolation' and 'tap'. There's also a separate "axis" of suites,
describing what's being tested, e.g. 'main', 'test_decoding', 'recovery' etc.
That currently works out
Hi,
>
> FYI, I noticed that v5 causes cfbot failure in [1].
> Could you please fix it in the next version ?
>
Thanks for letting me know!
>
> [19:44:38.420] execReplication.c: In function
> ‘RelationFindReplTupleByIndex’:
> [19:44:38.420] execReplication.c:186:24: error: ‘eq’ may be used
>
Hi,
I got a coredump when using hash join on a Postgres derived Database(Greenplum
DB).
And I find a way to reproduce it on Postgres.
Root cause:
In ExecChooseHashTableSize(), commit b154ee63bb uses func pg_nextpower2_size_t
whose param must not be 0.
```
sbuckets =
On Mon, Jul 18, 2022 at 11:16:15PM -0400, Bruce Momjian wrote:
> On Mon, Jul 18, 2022 at 07:39:55PM -0700, David G. Johnston wrote:
> > On Mon, Jul 18, 2022 at 6:27 PM Japin Li wrote:
> >
> >
> > +0.90
> >
> > Consider changing:
> >
> > "makes any base backups taken before this unusable"
> >
John Naylor writes:
> This is really a straw-man proposal, since I'm not volunteering to do
> the work, or suggest anybody else should do the same. That being the
> case, it seems we should just go ahead with Justin's patch for
> consistency. Possibly we could also change the messages to say
Hi,
On 8/12/22 12:28 AM, Jacob Champion wrote:
On Wed, Aug 10, 2022 at 10:48 PM Drouvot, Bertrand wrote:
What do you think about adding a second field in ClientConnectionInfo
for the auth method (as suggested by Michael upthread)?
Sure -- without a followup patch, it's not really tested,
On Mon, Jul 18, 2022 at 04:40:15PM -0400, Bruce Momjian wrote:
> > Also, I'm thinking to change, on the same page (description):
> >
> > "Dropping an extension causes its component objects,"
> >
> > to be:
> >
> > "Dropping an extension causes its member objects,"
> >
> > I'm not sure why I
On Thu, Aug 11, 2022 at 2:15 PM Robert Haas wrote:
> As far as I know, this 0001 addresses all outstanding comments and
> fixes the reported bug.
>
> Does anyone think otherwise?
If they do, they're keeping quiet, so I committed this and
back-patched it to v15.
Regarding 0002 -- should it,
On Fri, 5 Aug 2022 at 17:51, Justin Pryzby wrote:
> On Tue, Jul 26, 2022 at 08:11:04AM -0400, Dave Cramer wrote:
> > Attached patch to correct these deficiencies.
>
> You sent a patch to be applied on top of the first patch, but cfbot doesn't
> know that, so it says the patch doesn't apply.
>
On Tue, Aug 9, 2022 at 1:31 AM Zheng Li wrote:
>
> Hello,
>
> Logical replication of DDL commands support is being worked on in [1].
> However, global object commands are quite different from other
> non-global object DDL commands and need to be handled differently. For
> example, global object
On Fri, Aug 12, 2022, at 3:59 AM, John Naylor wrote:
> This is really a straw-man proposal, since I'm not volunteering to do
> the work, or suggest anybody else should do the same. That being the
> case, it seems we should just go ahead with Justin's patch for
> consistency. Possibly we could also
On 2022-Aug-12, Simon Riggs wrote:
> Sorry, but I disagree with this chunk in the latest commit,
> specifically, changing the MATCHED from after to before the NOT
> MATCHED clause.
>
> The whole point of the second example was to demonstrate that the
> order of the MATCHED/NOT MATCHED clauses
On Fri, 12 Aug 2022 at 12:20, Alvaro Herrera wrote:
> On 2022-Jul-18, Justin Pryzby wrote:
>
> > On Fri, Jul 15, 2022 at 03:43:41PM -0500, Justin Pryzby wrote:
> > > Should that sentence be removed from MERGE ?
> >
> > Also, I think these examples should be more similar.
>
> Agreed, done.
On 2022-Jul-15, Justin Pryzby wrote:
> Should that sentence be removed from MERGE ?
Removed
On 2022-Jul-18, Justin Pryzby wrote:
> On Fri, Jul 15, 2022 at 03:43:41PM -0500, Justin Pryzby wrote:
> > Should that sentence be removed from MERGE ?
>
> Also, I think these examples should be more
On Tue, Aug 9, 2022 at 1:52 AM Zheng Li wrote:
>
> > In general, I agree with your comment below that we can work on this
> > after we have some more concrete plans/discussions. I think we can
> > probably consider this when we have more discussion around the
> > publication commands for the DDL
Here are some review comments for v20-0004:
(This completes my reviews of the v20* patch set. Sorry, the reviews
are time consuming, so I am lagging slightly behind the latest posted
version)
==
1. doc/src/sgml/ref/create_subscription.sgml
@@ -245,6 +245,11 @@ CREATE SUBSCRIPTION
On Wed, Aug 10, 2022 at 10:39 AM Masahiko Sawada wrote:
>
> On Fri, Aug 5, 2022 at 10:39 AM shiy.f...@fujitsu.com
> wrote:
>
> Thank you for the comments. I've attached updated version patches.
> Please review them.
>
Pushed.
--
With Regards,
Amit Kapila.
On Fri, Aug 12, 2022 at 7:15 PM Peter Eisentraut
wrote:
> On 11.08.22 12:02, Thomas Munro wrote:
> > * The concept of a no-Unix-socket build is removed. We should be
> > able to do that now, right? Peter E seemed to say approximately that
> > in the commit message for 797129e5. Or is there a
On Fri, Aug 12, 2022 at 5:14 AM Andres Freund wrote:
> On 2022-08-11 10:52:51 -0400, Tom Lane wrote:
> > Thomas Munro writes:
> > > The most interesting things to say about these ones are:
> > > * The concept of a no-Unix-socket build is removed. We should be
> > > able to do that now, right?
On 27.07.22 01:58, David G. Johnston wrote:
Admittedly I'm still getting my head around reading pointer-using code
(I get the general concept but haven't had to code them)
- lockrelid = palloc(sizeof(*lockrelid));
+ lockrelid = palloc_ptrtype(lockrelid);
// This definitely seems like an
On 26.07.22 23:32, Tom Lane wrote:
1. Do we really want distinct names for the frontend and backend
versions of the macros? Particularly since you're layering the
frontend ones over pg_malloc, which has exit-on-OOM behavior?
I think we've found that notational discrepancies between frontend
and
On 11.08.22 12:02, Thomas Munro wrote:
* The concept of a no-Unix-socket build is removed. We should be
able to do that now, right? Peter E seemed to say approximately that
in the commit message for 797129e5. Or is there a thought that a new
operating system might show up that doesn't have
On Thu, Aug 4, 2022 at 11:09 AM Tom Lane wrote:
>
> clock_gettime is required by SUSv2 (1997), so I have to admit that
> macOS 10.4 doesn't have a lot of excuse not to have it. In any case,
> prairiedog is just sitting there doing its thing until I find cycles
> to install a newer OS. If you
On 11.08.22 19:19, Tom Lane wrote:
Andres Freund writes:
On 2022-08-11 10:52:51 -0400, Tom Lane wrote:
-- I won't be too surprised if we get pushback on that after 15.0 is out.
From what angle?
If I knew that, it'd be because we'd already received the pushback.
I'm just suspicious that
I wrote:
> On Thu, Aug 4, 2022 at 8:41 PM Tom Lane wrote:
> >
> > John Naylor writes:
>
> > > RepOriginId is a typedef for uint16, so this can't print the wrong answer,
> > > but it is inconsistent with other uses. So it seems we don't need to
> > > backpatch this one?
> >
> > Um ... if it's
Here are some review comments for v20-0003:
(Sorry - the reviews are time consuming, so I am lagging slightly
behind the latest posted version)
==
1.
1a.
There are a few comment modifications in this patch (e.g. changing
FROM "in an apply background worker" TO "using an apply background
Starting a new thread to control clutter. [was: Re: [RFC] building
postgres with meson]
motivation:
https://www.postgresql.org/message-id/20220810171935.7k5zgnjwqzalzmtm%40awork3.anarazel.de
On Thu, Aug 11, 2022 at 11:07 AM Andres Freund wrote:
> I think we should consider compiling it
38 matches
Mail list logo
