Hi,
On 2021-12-22 22:34:45 +0900, Masahiko Sawada wrote:
> I've attached an updated patch. Please review it.
Sorry for dropping the ball on this again :(. I've pushed the fix with some
very minor polishing.
> > The attached detects that bug, but I'm not sure it's worth expending
> > test time,
Hi,
On 2022-02-14 14:36:12 -0800, Andres Freund wrote:
> On 2022-02-14 15:45:40 -0500, Tom Lane wrote:
> > I tried to replicate the problem described in [1] about logical
> > replication from a v14 source DB to a v11 target. It fails as
> > described there; I've not yet tracked down why, but it l
Hi,
On 2022-02-14 18:32:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I do however not think it's a good idea to commit something generating
> > something like the existing node functions vs going for a metadata based
> > approach at dealing with node functions. That aspect of my patchset
On Mon, Feb 14, 2022 at 7:59 PM Nathan Bossart wrote:
> I think it's possible to avoid overflow in justify_interval() in some cases
> by pre-justifying the days. I've attached a patch to demonstrate.
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
Good catch, I didn't think
Andres Freund writes:
> On 2022-02-14 18:32:21 -0500, Tom Lane wrote:
>> I think that finishing out and committing this patch is a fine step
>> on the way to that.
> I think most of gen_node_support.pl would change - a lot of that is generating
> the node functions, which would not be needed anym
Hi,
On 2022-02-14 12:45:08 -0500, Robert Haas wrote:
> On Mon, Feb 14, 2022 at 12:34 PM Tom Lane wrote:
> > * If we institute a policy that all GUCs should be PGDLLIMPORT'd,
> > how will we enforce that new patches follow that? I don't want to be
> > endlessly going back and adding forgotten PGD
On Tue, Feb 15, 2022 at 2:09 PM Ranier Vilela wrote:
> Em seg., 14 de fev. de 2022 às 21:58, Justin Pryzby
> escreveu:
>> On Mon, Feb 14, 2022 at 09:19:54PM -0300, Ranier Vilela wrote:
>> > I've reported this issue, but without success in fixing it.
>>
>> It'd be helpful to provide a link to the
Hi,
On 2022-02-14 20:47:33 -0500, Tom Lane wrote:
> I think that most of the intellectual content in this patch is getting
> the data source nailed down, ie putting the annotations into the *nodes.h
> files and building the code to parse that. I don't have a problem
> with throwing away and rewri
At Mon, 14 Feb 2022 20:14:11 +0530, Ashutosh Sharma
wrote in
> No, I haven't tried to compare archive recovery to PITR or vice versa,
> instead I was trying to compare crash recovery with PITR. The message
> you're emitting says just before entering into the archive recovery is
> - "reached end-
Hi,
On February 14, 2022 12:48:12 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> On 2022-02-14 14:18:58 -0500, Tom Lane wrote:
>>> Well, it's mid-February. Do we have a python2-removal patch
>>> that's ready to go?
>
>> I can refresh mine. Iit might be good to first reapply
>> f201da39edc -
At Mon, 14 Feb 2022 17:20:16 -0800, Andres Freund wrote in
> Hi,
>
> On 2021-12-22 22:34:45 +0900, Masahiko Sawada wrote:
> > I've attached an updated patch. Please review it.
>
> Sorry for dropping the ball on this again :(. I've pushed the fix with some
> very minor polishing.
Thanks!
> > >
Hi,
On 2022-02-14 14:54:41 +0530, Amit Kapila wrote:
> On Fri, Feb 11, 2022 at 4:27 PM Amit Kapila wrote:
> >
> > On Fri, Feb 11, 2022 at 12:00 PM tanghy.f...@fujitsu.com
> > wrote:
> > >
> > > Attached the patches which fixed the above two comments and the first
> > > comment in
> > > my previ
On Tue, Feb 15, 2022 at 3:42 AM Tom Lane wrote:
>
> In [1] there's a complaint that if you try to logically replicate
> a partitioned table from v13-or-later to v12-or-earlier, you get
> "table XXX not found on publisher", which is pretty confusing
> because the publisher certainly does have such
Andres Freund writes:
> On February 14, 2022 12:48:12 PM PST, Tom Lane wrote:
>> We could I guess, but does it really buy anything? I'm sure that
>> some of the buildfarm still hasn't updated their Python installation,
>> but it'll be about the same failure we'd get from the final patch.
> I gu
Amit Kapila writes:
> On Tue, Feb 15, 2022 at 3:42 AM Tom Lane wrote:
>> ... Maybe the error message
>> could be bikeshedded ... is "non-table relation" terminology
>> that we use in user-facing messages?
> The other option could be "logical replication source relation
> \"%s.%s\" is not a tabl
On Sat, Feb 12, 2022 at 08:50:41PM -0800, Andres Freund wrote:
> On 2022-01-18 11:20:16 +0900, Michael Paquier wrote:
>> +# required for 002_pg_upgrade.pl
>> +REGRESS_SHLIB=$(abs_top_builddir)/src/test/regress/regress$(DLSUFFIX)
>> +export REGRESS_SHLIB
>
> It seems weird to propagate this into mu
On Fri, Feb 4, 2022 at 4:58 AM Robert Haas wrote:
> As I said
> before, I know TRUNCATE has been an issue in the past, and if that's
> not already fixed in v14, we should. If there's other stuff, we should
> fix that too.
The failsafe mode does disable truncation as of v14:
commit 60f1f09ff4430
On Mon, Feb 14, 2022 at 8:04 PM John Naylor
wrote:
> The failsafe mode does disable truncation as of v14:
>
> commit 60f1f09ff44308667ef6c72fbafd68235e55ae27
> Author: Peter Geoghegan
> Date: Tue Apr 13 12:58:31 2021 -0700
>
> Don't truncate heap when VACUUM's failsafe is in effect.
That's tru
On Mon, Feb 14, 2022 at 08:35:43PM -0500, Joseph Koshakow wrote:
> Good catch, I didn't think about that. Though if you are pre-justifying
> the days, then I don't think it's possible for the second addition to
> days to overflow. The maximum amount the days field could be after
> the first justifi
On Mon, Feb 14, 2022 at 10:53:04AM +0900, Michael Paquier wrote:
> A last thing, that has been mentioned by Andres upthread, is that we
> should be able to remove the extra commands run with --version in the
> tests of pg_basebackup, as of the attached. I have not done that yet,
> as it seems bett
On Tue, Feb 15, 2022 at 12:09 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 14 Feb 2022 17:20:16 -0800, Andres Freund wrote
> in
> > Hi,
> >
> > On 2021-12-22 22:34:45 +0900, Masahiko Sawada wrote:
> > > I've attached an updated patch. Please review it.
> >
> > Sorry for dropping the ball on this agai
On Thu, Feb 3, 2022 at 2:35 PM Masahiko Sawada wrote:
>
> On Thu, Feb 3, 2022 at 1:48 PM David G. Johnston
> wrote:
> >
> > On Wednesday, February 2, 2022, Masahiko Sawada
> > wrote:
> >>
> >> and have other error
> >> information in pg_stat_subscription_workers view.
> >
> >
> > What benefit i
On Tues, Feb 08, 2022 at 17:18 PM Kuroda, Hayato
wrote:
> I applied your patch and confirmed that codes passed regression test.
> I put a short reviewing:
Thanks for your test and review.
> ```
> + static int skipped_changes_count = 0;
> + /*
> + * Conservatively, at least 150,000 c
On Monday, February 14, 2022 8:58 PM Amit Kapila
wrote:
> On Thu, Jan 6, 2022 at 11:23 AM osumi.takami...@fujitsu.com
> wrote:
> >
> > Kindly have a look at the attached v16.
> >
>
> Few comments:
Hi, thank you for checking the patch !
> =
> 1.
> @@ -3594,13 +3698,29 @@ ApplyWorker
On Tue, Feb 15, 2022 at 11:22 AM Peter Geoghegan wrote:
>
> On Mon, Feb 14, 2022 at 8:04 PM John Naylor
> wrote:
> > The failsafe mode does disable truncation as of v14:
> >
> > commit 60f1f09ff44308667ef6c72fbafd68235e55ae27
> > Author: Peter Geoghegan
> > Date: Tue Apr 13 12:58:31 2021 -0700
(This needs rebasing)
At Wed, 9 Feb 2022 00:52:48 +, Jacob Champion wrote
in
> On Mon, 2022-02-07 at 17:29 +0900, Kyotaro Horiguchi wrote:
> > I feel this should be a part of 0001. (But the patches will be
> > finally merged so maybe no need to bother moving it).
>
> Okay. I can move it e
On Wed, Jan 19, 2022 at 11:32 AM John Naylor
wrote:
> I don't have anything really profound to say here, but in the last
> year I did on a couple occasions recommend clients to raise
> hash_mem_multiplier to 2.0 to fix performance problems.
I would like to push ahead with an increase in the defau
On Mon, Feb 14, 2022 at 11:12 AM Bharath Rupireddy
wrote:
> > FWIW, docs need to hold to a higher standard than code comments.
>
> Thanks. In general, I agree that the docs and error/log messages
> (user-facing) need to be of higher standard, but at the same time code
> comments too IMHO. Because
101 - 128 of 128 matches
Mail list logo
