Patch update without merge conflicts.
MartinFrom 0ecffcf3ed2eb59d045941b69bb86a34b93f3391 Mon Sep 17 00:00:00 2001
From: Martin Kalcher
Date: Sun, 17 Jul 2022 18:06:04 +0200
Subject: [PATCH v3] Introduce array_shuffle() and array_sample()
* array_shuffle() shuffles the elements of an array.
*
On Mon, Jul 18, 2022 at 10:39 AM Andrew Dunstan wrote:
> On 2022-07-18 Mo 10:33, Justin Pryzby wrote:
> > It's easy to use CREATE TABLE..LIKE + ALTER..ATTACH PARTITION to avoid
> > acquiring a strong lock when creating a new partition.
> > But it's also easy to forget.
> >
> > commit
Hi,
On Wed, Aug 3, 2022 at 2:01 PM John Naylor wrote:
>
>
> On Tue, Aug 2, 2022 at 11:53 PM Nathan Bossart
> wrote:
> > I did a bit of cross-checking, and AFAICT this is a reasonable starting
> > point. emmintrin.h appears to be sufficient for one of my patches that
> > makes use of SSE2
Thomas Munro writes:
> It may be madness to try to work around this, but I wonder if we could
> use a static local variable that we update with atomic compare
> exhange, inside PG_SIGNAL_HANDLER_ENTRY(), and
> PG_SIGNAL_HANDLER_EXIT() macros that do nothing on every other system.
> On entry, if
On Thu, Aug 4, 2022 at 4:16 PM Thomas Munro wrote:
> On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby wrote:
> > [train wreck]
>
> Oh my, so I'm getting the impression we might actually be totally
> unstable on Cygwin. Which surprises me because ... wait a minute ...
> lorikeet isn't even running
On Thu, Aug 4, 2022 at 3:43 PM Andres Freund wrote:
> > We retain a HAVE_SHM_OPEN macro, because it's clearer to readers than
> > something like !defined(WIN32).
>
> I don't like these. I don't find them clearer - if we really just assume this
> to be the case on windows, it's easier to
On Wed, Aug 3, 2022 at 12:11 AM Robert Haas wrote:
>
> On Tue, Aug 2, 2022 at 3:25 AM Bharath Rupireddy
> wrote:
> > ereport_startup_progress infrastructure added by commit 9ce346e [1]
> > will be super-useful for reporting progress of any long-running server
> > operations, not just the startup
Hi,
On 2022-08-04 16:16:06 +1200, Thomas Munro wrote:
> Ok, that's slightly reassuring, so maybe we *can* fix this, but I'm
> one step closer to what Tom said, re wasting developer time...
It might be worth checking whether the cygwin installer, which at some point
at least allowed installing
On Thu, Aug 4, 2022 at 4:09 PM Tom Lane wrote:
> Andres Freund writes:
> >> XXX This can only be committed once prairedog is decommissioned, because
> >> macOS 10.4 didn't have clock_gettime().
>
> > Maybe put it later in the queue?
>
> clock_gettime is required by SUSv2 (1997), so I have to
On Thu, Aug 4, 2022 at 3:38 PM Justin Pryzby wrote:
> [train wreck]
Oh my, so I'm getting the impression we might actually be totally
unstable on Cygwin. Which surprises me because ... wait a minute ...
lorikeet isn't even running most of the tests. So... we don't really
know the degree to
On Thu, Jul 28, 2022 at 11:56 AM Fujii Masao
wrote:
>
>
>
> On 2022/07/27 10:36, Kyotaro Horiguchi wrote:
> > At Tue, 26 Jul 2022 18:33:04 +0900, Fujii Masao
> > wrote in
> >>> I'm not sure the two are similar with each other. The new function
> >>> pgfdw_exec_pre_commit() looks like a merger
On Thu, Aug 4, 2022 at 12:18 AM Justin Pryzby wrote:
>
> On Wed, Aug 03, 2022 at 11:26:43AM -0700, Andres Freund wrote:
> > Hm. This looks more like an issue of DROP DATABASE not being interruptible.
> > I
> > suspect this isn't actually related to STRATEGY wal_log and could likely be
> >
Andres Freund writes:
>> XXX This can only be committed once prairedog is decommissioned, because
>> macOS 10.4 didn't have clock_gettime().
> Maybe put it later in the queue?
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
Hi,
On 2022-07-28 17:23:19 -0500, Justin Pryzby wrote:
> On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> > > > XXX This should use a canned Docker image with all the right packages
> > > > installed
> > >
> > > Has anyone tried using non-canned images ? It sounds like this could
On Mon, Aug 1, 2022 at 9:52 PM Önder Kalacı wrote:
>
> Hi,
>
> As far as I can see, the following is the answer to the only remaining open
> discussion in this thread. Let me know if anything is missed.
>
>> (b) it appears to me that the patch decides
>> >> which index to use the first time it
On Wed, Jul 13, 2022 at 8:59 PM Amit Langote wrote:
> On Sat, Jul 9, 2022 at 1:15 AM Robert Haas wrote:
> Thanks for taking a look at this. I'll try to respond to other points
> in a separate email, but I wanted to clarify something about below:
>
> > I find my ego slightly wounded by the
Hi,
Can we get a few more of these committed soon? It's all tests that I need to
sync with the meson stuff, and I'd rather get it over with :). And it reduces
the set of tests that need to be compared... Or is there a blocker (leaving
the prairedog one aside)?
On 2022-08-03 14:25:01 +1200,
On Fri, Jul 29, 2022 at 10:04:04AM +1200, Thomas Munro wrote:
> > > XXX We would never want this to run by default in CI, but it'd be nice
> > > to be able to ask for it with ci-os-only! (See commented out line)
> > > only_if: $CIRRUS_CHANGE_MESSAGE =~ '.*\nci-os-only:[^\n]*cygwin.*'
> >
> >
On Wed, Aug 3, 2022 at 4:23 PM Alvaro Herrera wrote:
>
> On 2022-Aug-03, Amit Kapila wrote:
>
> > Thanks for the report and Thanks Michael for including me. I am just
> > redirecting it to -hackers so that others involved in this feature
> > also can share their views.
>
> I'm sorry, but our
On Sun, Jul 31, 2022 at 11:17 AM Tom Lane wrote:
> Thomas Munro writes:
> > I noticed this is a 32 bit FBSD system. Is it running on UFS, perhaps
> > on slow storage? Are soft updates enabled (visible as options in
> > output of "mount")?
>
> It's an ancient (2006) mac mini with 5400RPM
On Thu, Aug 4, 2022 at 11:09 AM Michael Paquier wrote:
>
> On Wed, Aug 03, 2022 at 12:58:04PM +0200, Alvaro Herrera wrote:
> > On 2022-Aug-01, Tom Lane wrote:
> >> One idea for avoiding confusion is to legislate that we won't
> >> use tabs at all in this file (which we could enforce via
> >>
Hi,
On 2022-08-03 21:52:04 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Another potential cleanup is the fallback for strtoll/strtoull.
>
> +1, I suspect the alternate spellings are dead.
Looks like that includes systems where there's no declaration for strtoll,
strtoull. The test was
On Thu, Aug 04, 2022 at 10:09:27AM +0900, Michael Paquier wrote:
> On Wed, Aug 03, 2022 at 12:58:04PM +0200, Alvaro Herrera wrote:
> > On 2022-Aug-01, Tom Lane wrote:
> >> One idea for avoiding confusion is to legislate that we won't
> >> use tabs at all in this file (which we could enforce via
>
I noticed that this says:
[01:01:45.657] sqlda.pgc: In function 'dump_sqlda':
[01:01:45.657] sqlda.pgc:45:33: warning: format '%d' expects argument
of type 'int', but argument 3 has type 'long long int' [-Wformat=]
[01:01:45.657] 45 | "name sqlda descriptor: '%s' value %I64d\n",
[01:01:45.657] |
Andres Freund writes:
> Another potential cleanup is the fallback for strtoll/strtoull.
+1, I suspect the alternate spellings are dead.
regards, tom lane
On Wed, Aug 3, 2022 at 10:21 AM Amit Kapila wrote:
>
> Pushed this one and now I'll look at your other patch.
>
I have pushed the second patch as well after making minor changes in
the comments. Alvaro [1] and Tom [2] suggest to back-patch this and
they sound reasonable to me. Will you be able
Hi,
Another potential cleanup is the fallback for strtoll/strtoull. Some of the
spellings were introduced because of "ancient HPUX":
commit 06f66cff9e0b93db81db1595156b2aff8ba1786e
Author: Tom Lane
Date: 2018-05-19 14:22:18 -0400
Support platforms where strtoll/strtoull are spelled
On Thu, Aug 04, 2022 at 09:24:24AM +1200, Thomas Munro wrote:
> On Thu, Aug 4, 2022 at 3:30 AM Justin Pryzby wrote:
> > On Thu, Dec 09, 2021 at 12:10:23PM +1300, Thomas Munro wrote:
> > > This adds 2 whole minutes to the recovery check, when running with the
> > > Windows serial-only scripts on
On Wed, Aug 03, 2022 at 12:58:04PM +0200, Alvaro Herrera wrote:
> On 2022-Aug-01, Tom Lane wrote:
>> One idea for avoiding confusion is to legislate that we won't
>> use tabs at all in this file (which we could enforce via
>> .gitattributes, I think).
>
> +1.
That's not the first time this 4- or
On Thu, Aug 4, 2022 at 3:01 AM Alvaro Herrera wrote:
> On 2022-Aug-02, Amit Langote wrote:
> > Regarding the patch, I agree that storing the recurse flag rather than
> > overwriting subtype might be better.
> >
> > + boolexecTimeRecursion; /* set by ATPrepCmd if ATExecCmd must
> > +
"Jonathan S. Katz" writes:
> I did rule out wanting to do the "xid + $X" check after reviewing some
> of the output. I think that both $X could end up varying, and it really
> feels like a bandaid.
It is that. I wouldn't feel comfortable with $X less than 100 or so,
which is probably sloppy
On 8/3/22 2:08 PM, Peter Geoghegan wrote:
On Wed, Aug 3, 2022 at 1:47 PM Tom Lane wrote:
Again, this seems to me to be breaking the test's real-world applicability
for a (false?) sense of stability.
I agree.
A lot of the VACUUM test flappiness issues we've had to deal with in
the past now
On Thu, Aug 4, 2022 at 12:42 AM Robert Treat wrote:
>
> On Wed, Aug 3, 2022 at 11:15 AM Junwang Zhao wrote:
> >
> > Attachment is a corrected version based on Tom's suggestion.
> >
> > Thanks.
> >
> > On Wed, Aug 3, 2022 at 9:56 PM Tom Lane wrote:
> > >
> > > Erikjan Rijkers writes:
> > > > I
On Wed, 3 Aug 2022 at 23:57, Tom Lane wrote:
>
> Matthias van de Meent writes:
> > I don't have a current version of the SQL spec, but one preliminary
> > version of SQL:2012 I retrieved via the wiki details that all BEFORE
> > triggers on INSERT/UPDATE/DELETE statements are all executed before
Hi,
On 2022-08-03 16:33:46 -0400, Robert Haas wrote:
> On Wed, Aug 3, 2022 at 1:57 PM Andres Freund wrote:
> > The reason nothing might get logged in some cases is that
> > e.g. ResolveRecoveryConflictWithLock() tells
> > ResolveRecoveryConflictWithVirtualXIDs() to *not* report the waiting:
> >
Matthias van de Meent writes:
> I don't have a current version of the SQL spec, but one preliminary
> version of SQL:2012 I retrieved via the wiki details that all BEFORE
> triggers on INSERT/UPDATE/DELETE statements are all executed before
> _any_ of that statements' affected data is modified.
>
On Tue, 19 Apr 2022 at 14:00, Tomas Vondra
wrote:
>
> On 4/19/22 11:16, Etsuro Fujita wrote:
> > On Sun, Apr 17, 2022 at 6:20 PM Etsuro Fujita
> > wrote:
> >> Here
> >> is an example using HEAD:
> >>
> >> create extension postgres_fdw;
> >> create server loopback foreign data wrapper
Hi,
On 2022-08-03 17:21:58 -0400, Stephen Frost wrote:
> * Andres Freund (and...@anarazel.de) wrote:
> > On 2022-08-03 16:28:08 -0400, Stephen Frost wrote:
> > > Again, server-side only is not interesting and not a direction that
> > > makes sense to go in because it doesn't provide any way to
On Thu, Aug 4, 2022 at 9:28 AM Andrew Dunstan wrote:
> On 2022-08-01 Mo 16:06, Andrew Dunstan wrote:
> > I'll try it out on fairywren/drongo.
> They are happy with patches 2, 3, and 4.
Thanks for testing!
If there are no objections, I'll go ahead and commit these later today.
On 2022-08-01 Mo 16:06, Andrew Dunstan wrote:
> On 2022-08-01 Mo 01:09, Thomas Munro wrote:
>> On Thu, Jul 28, 2022 at 9:31 PM Thomas Munro wrote:
>>> There's one curious change in the draft patch attached: you can't
>>> unlink() a junction point, you have to rmdir() it. Previously, things
>>>
On Thu, Aug 4, 2022 at 3:30 AM Justin Pryzby wrote:
> On Thu, Dec 09, 2021 at 12:10:23PM +1300, Thomas Munro wrote:
> > This adds 2 whole minutes to the recovery check, when running with the
> > Windows serial-only scripts on Cirrus CI (using Andres's CI patches).
> > For Linux it adds ~20
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2022-08-03 16:28:08 -0400, Stephen Frost wrote:
> > Again, server-side only is not interesting and not a direction that
> > makes sense to go in because it doesn't provide any way to have
> > trust established in both directions, which
On Wed, Aug 3, 2022 at 1:47 PM Tom Lane wrote:
> Again, this seems to me to be breaking the test's real-world applicability
> for a (false?) sense of stability.
I agree.
A lot of the VACUUM test flappiness issues we've had to deal with in
the past now seem like problems with VACUUM itself, the
On Wed, 3 Aug 2022 at 20:04, Jacob Champion wrote:
>
> [was: CF app: add "Returned: Needs more interest"]
>
> On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud wrote:
> > I'm afraid that
> > patches will still be left alone to rot and there still be no clear rules on
> > what to do and when,
On 2022-08-03 16:46:57 -0400, Tom Lane wrote:
> Robert Haas writes:
> > Or we could disable autovacuum on the new cluster, which I think is a
> > better solution. I like it when things match exactly; it makes me feel
> > that the universe is well-ordered.
>
> Again, this seems to me to be
Hi,
On 2022-08-03 16:28:08 -0400, Stephen Frost wrote:
> Again, server-side only is not interesting and not a direction that
> makes sense to go in because it doesn't provide any way to have
> trust established in both directions, which is what all modern
> authentication methods do
Robert Haas writes:
> Or we could disable autovacuum on the new cluster, which I think is a
> better solution. I like it when things match exactly; it makes me feel
> that the universe is well-ordered.
Again, this seems to me to be breaking the test's real-world applicability
for a (false?)
On Wed, Aug 3, 2022 at 1:34 PM Tom Lane wrote:
> That doesn't seem like it'd be all that thorough: we expect VACUUM
> to skip pages whenever possible. I'm also a bit concerned about
> the expense, though admittedly this test is ridiculously expensive
> already.
I bet the SKIP_PAGES_THRESHOLD
On Wed, Aug 3, 2022 at 4:20 PM Andres Freund wrote:
> > I don't really like this approach. Imagine that the code got broken in
> > such a way that relfrozenxid and relminmxid were set to a value chosen
> > at random - say, the contents of 4 bytes of unallocated memory that
> > contained random
Peter Geoghegan writes:
> It couldn't hurt to do that as well, in passing (at the same time as
> testing that newrelfrozenxid >= oldrelfrozenxid directly). But
> deliberately running VACUUM afterwards seems like a good idea. We
> really ought to expect VACUUM to catch cases where
>
On Wed, Aug 3, 2022 at 1:57 PM Andres Freund wrote:
> The reason nothing might get logged in some cases is that
> e.g. ResolveRecoveryConflictWithLock() tells
> ResolveRecoveryConflictWithVirtualXIDs() to *not* report the waiting:
> /*
> * Prevent
On Wed, Aug 3, 2022 at 1:20 PM Andres Freund wrote:
> > I don't really like this approach. Imagine that the code got broken in
> > such a way that relfrozenxid and relminmxid were set to a value chosen
> > at random - say, the contents of 4 bytes of unallocated memory that
> > contained random
Greetings,
* samay sharma (smilingsa...@gmail.com) wrote:
> On Tue, Aug 2, 2022 at 2:48 PM Jacob Champion
> wrote:
> > [dev hat] That said, I plan to do some additional dev work on top of
> > this over the next couple of months. The ideal case would be to provide
> > a server-only extension that
On Wed, Aug 03, 2022 at 11:06:58AM -0700, Andres Freund wrote:
> On 2022-08-02 16:43:57 -0700, Nathan Bossart wrote:
>> >> +#ifdef USE_SSE2
>> >> +pg_attribute_no_sanitize_alignment()
>> >> +#endif
>> >
>> > What's the deal with this annotation? Needs a comment.
>>
>> Will do. c.h suggests that
Hi,
On 2022-08-03 09:59:40 -0400, Robert Haas wrote:
> On Tue, Aug 2, 2022 at 3:51 PM Tom Lane wrote:
> > > The test does look helpful and it would catch regressions. Loosely
> > > quoting Robert on a different point upthread, we don't want to turn off
> > > the alarm just because it's
Hi,
On 2022-08-03 15:36:40 -0400, Robert Haas wrote:
> On Wed, Aug 3, 2022 at 3:18 PM Andres Freund wrote:
> > In contrast to e.g. clog or multixact we don't need to access a lot of old
> > While we can't put a useful hard cap on the number of potential subtrans
> > entries (we can only throw
Andres Freund writes:
> I agree very much with that - just am doubtful that "lacks interest" is a good
> way of dealing with it, unless we just want to treat it as a nicer sounding
> "rejected".
I think there is a difference. "Lacks interest" suggests that there
is a path forward for the patch,
Hi,
On 2022-08-03 12:06:03 -0700, Jacob Champion wrote:
> On 8/3/22 11:41, Andres Freund wrote:
> > What patches are we concretely talking about?>
> > My impression is that a lot of the patches floating from CF to CF have
> > gotten
> > sceptical feedback and at best a minor amount of work to
On Wed, Aug 3, 2022 at 6:59 AM Robert Haas wrote:
> I don't really like this approach. Imagine that the code got broken in
> such a way that relfrozenxid and relminmxid were set to a value chosen
> at random - say, the contents of 4 bytes of unallocated memory that
> contained random garbage.
On Wed, Aug 3, 2022 at 3:18 PM Andres Freund wrote:
> In contrast to e.g. clog or multixact we don't need to access a lot of old
> While we can't put a useful hard cap on the number of potential subtrans
> entries (we can only throw subxid->parent mappings away once no existing
> snapshot might
Hi,
On 2022-08-01 17:42:49 +0100, Simon Riggs wrote:
> The reason for the slowdown is clear: when we overflow we check every
> xid against subtrans, producing a large stream of lookups. Some
> previous hackers have tried to speed up subtrans - this patch takes a
> different approach: remove as
On 8/3/22 11:41, Andres Freund wrote:
> What patches are we concretely talking about?>
> My impression is that a lot of the patches floating from CF to CF have gotten
> sceptical feedback and at best a minor amount of work to address that has been
> done.
-
Andres Freund writes:
> My impression is that a lot of the patches floating from CF to CF have gotten
> sceptical feedback and at best a minor amount of work to address that has been
> done.
That I think is a distinct issue: nobody wants to take on the
unpleasant job of saying "no, we don't want
On Tue, Aug 2, 2022 at 12:32 PM Tom Lane wrote:
> Hmmm ... now that you mention it, I see nothing in 002_pg_upgrade.pl
> that attempts to turn off autovacuum on either the source server or
> the destination. So one plausible theory is that autovac moved the
> numbers since we checked.
It's very
On Wed, Aug 03, 2022 at 11:26:43AM -0700, Andres Freund wrote:
> Hm. This looks more like an issue of DROP DATABASE not being interruptible. I
> suspect this isn't actually related to STRATEGY wal_log and could likely be
> reproduced in older versions too.
I couldn't reproduce it with file_copy,
Hi,
On 2022-08-03 10:52:36 -0700, Jacob Champion wrote:
> The situation I'm looking at, though, is where we have a dozen patches
> floating forward that multiple CFMs in a row feel should be returned,
> but they won't because claiming "they have feedback" is clearly unfair
> to the author. I
Hi,
On 2022-08-03 12:01:18 -0500, Justin Pryzby wrote:
> Now, I've reproduced the problem under valgrind, but it doesn't show anything
> useful
Yea, that looks like an issue on a different level.
>
> pryzbyj@pryzbyj:~$ while :; do psql -h /tmp template1 -c "DROP DATABASE a" -c
> "CREATE
Hi,
On 2022-08-02 16:43:57 -0700, Nathan Bossart wrote:
> >> +/*
> >> + * pg_linearsearch_uint32
> >> + *
> >> + * Returns the address of the first element in 'base' that equals 'key',
> >> or
> >> + * NULL if no match is found.
> >> + */
> >> +#ifdef USE_SSE2
> >>
[was: CF app: add "Returned: Needs more interest"]
On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud wrote:
> I'm afraid that
> patches will still be left alone to rot and there still be no clear rules on
> what to do and when, reminder for CFM and such, and that this new status would
> never be
On 2022-Aug-02, Amit Langote wrote:
> Regarding the patch, I agree that storing the recurse flag rather than
> overwriting subtype might be better.
>
> + boolexecTimeRecursion; /* set by ATPrepCmd if ATExecCmd must
> + * recurse to children */
>
>
Hi,
On 2022-07-26 13:03:54 -0700, Andres Freund wrote:
> On 2022-07-26 14:30:30 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2022-07-26 13:57:53 -0400, Tom Lane wrote:
> > >> So this is not a case of RecoveryConflictInterrupt doing the wrong thing:
> > >> the startup process hasn't
On Wed, Aug 3, 2022 at 10:09 AM Julien Rouhaud wrote:
> First of all, I didn't want to imply that rejecting a patch should be
> pleasant,
> sorry if that sounded that way.
No worries, I don't think it really sounded that way. :D
> It's not that I'm opposed to adding that status, I just don't
Here is a new patch set. 0001 is the currently-proposed patch from the
other thread [0] for determining SSE2 support. 0002 introduces the
optimized linear search function. And 0003 makes use of the new function
for the [sub]xip lookups in XidInMVCCSnapshot().
[0]
Hi,
On Wed, Aug 03, 2022 at 08:58:49AM -0700, Jacob Champion wrote:
> On Tue, Aug 2, 2022 at 8:00 PM Julien Rouhaud wrote:
> > I'm personally fine with the current statutes, as closing a patch with RwF
> > explaining that there was no interest is still a feedback,
>
> Making that explanation
On Wed, Aug 03, 2022 at 11:02:00AM -0500, Justin Pryzby wrote:
> But I reproduced the first problem with a handful of tries interrupting the
> while loop:
>
> 2022-08-03 10:39:50.129 CDT client backend[5530] [unknown] PANIC: could not
> open critical system index 2662
...
> So far, I haven't
On Wed, Aug 3, 2022 at 9:32 PM Justin Pryzby wrote:
>
> On Wed, Aug 03, 2022 at 04:45:23PM +0530, Dilip Kumar wrote:
> > Another version of the patch which closes the smgr at the end using
> > smgrcloserellocator() and I have also added a commit message.
>
> Thanks for providing a patch.
> This
On Wed, Aug 3, 2022 at 11:15 AM Junwang Zhao wrote:
>
> Attachment is a corrected version based on Tom's suggestion.
>
> Thanks.
>
> On Wed, Aug 3, 2022 at 9:56 PM Tom Lane wrote:
> >
> > Erikjan Rijkers writes:
> > > I don't think these "were"s are wrong but arguably changing them to
> > >
On Tue, Aug 2, 2022 at 4:32 AM Erik Rijkers wrote:
> > The part of the sentence inside parentheses is not clear to me, before
> > or after the patch:
> >
> > Dropping an extension causes its component objects, and other
> > explicitly
> > dependent routines (see ,
> > - the depends on
On Wed, Aug 03, 2022 at 12:00:39PM +0700, John Naylor wrote:
> Thanks for checking! Here's a concrete patch for testing.
LGTM
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com
On Wed, Aug 3, 2022 at 10:13 AM Tom Lane wrote:
> If you have a different solution that you can implement by, say,
> tomorrow, then go for it. But I want to see some fix in there
> within about 24 hours, because 15beta3 wraps on Monday and we
> will need at least a few days to see if the
On Wed, Aug 03, 2022 at 04:45:23PM +0530, Dilip Kumar wrote:
> Another version of the patch which closes the smgr at the end using
> smgrcloserellocator() and I have also added a commit message.
Thanks for providing a patch.
This seems to fix the second problem with accessing freed memory.
But I
On Tue, Aug 2, 2022 at 8:00 PM Julien Rouhaud wrote:
> I'm personally fine with the current statutes, as closing a patch with RwF
> explaining that there was no interest is still a feedback,
Hi Julien,
Making that explanation each time we intend to close a patch "needs
interest" takes a lot of
On Wed, 3 Aug 2022 at 9:22 PM, Robert Haas wrote:
> On Wed, Aug 3, 2022 at 7:15 AM Dilip Kumar wrote:
> > Another version of the patch which closes the smgr at the end using
> > smgrcloserellocator() and I have also added a commit message.
>
> Hmm, but didn't we decide against doing it that way
On Wed, Aug 3, 2022 at 7:15 AM Dilip Kumar wrote:
> Another version of the patch which closes the smgr at the end using
> smgrcloserellocator() and I have also added a commit message.
Hmm, but didn't we decide against doing it that way intentionally? The
comment you're deleting says "If we
On Thu, Dec 09, 2021 at 12:10:23PM +1300, Thomas Munro wrote:
> This adds 2 whole minutes to the recovery check, when running with the
> Windows serial-only scripts on Cirrus CI (using Andres's CI patches).
> For Linux it adds ~20 seconds to the total of -j8 check-world.
> Hopefully that's time
Attachment is a corrected version based on Tom's suggestion.
Thanks.
On Wed, Aug 3, 2022 at 9:56 PM Tom Lane wrote:
>
> Erikjan Rijkers writes:
> > I don't think these "were"s are wrong but arguably changing them to
> > "have" helps non-native speakers (like myself), as it doesn't change the
> On Aug 3, 2022, at 10:14 AM, Tom Lane wrote:
>
> Robert Haas writes:
>>> On Tue, Aug 2, 2022 at 3:51 PM Tom Lane wrote:
>>> I also think that ">=" is a sufficient requirement.
>
>> I don't really like this approach. Imagine that the code got broken in
>> such a way that relfrozenxid and
Robert Haas writes:
> On Tue, Aug 2, 2022 at 3:51 PM Tom Lane wrote:
>> I also think that ">=" is a sufficient requirement.
> I don't really like this approach. Imagine that the code got broken in
> such a way that relfrozenxid and relminmxid were set to a value chosen
> at random - say, the
On Tue, Aug 2, 2022 at 3:51 PM Tom Lane wrote:
> > The test does look helpful and it would catch regressions. Loosely
> > quoting Robert on a different point upthread, we don't want to turn off
> > the alarm just because it's spuriously going off.
> > I think the weakened check is OK (and
Erikjan Rijkers writes:
> I don't think these "were"s are wrong but arguably changing them to
> "have" helps non-native speakers (like myself), as it doesn't change the
> meaning significantly as far as I can see.
I think it does --- it changes the meaning from passive to active.
I don't
Amit Kapila writes:
> I have a question related to commit 964d01ae90. Today, after getting
> the latest code, when I compiled it on my windows machine, it lead to
> a compilation error because the outfuncs.funcs.c was not regenerated.
> I did the usual steps which I normally perform after getting
On Mon, Aug 1, 2022 at 6:46 PM Euler Taveira wrote:
>
> On Tue, Jul 5, 2022, at 9:29 AM, Amit Kapila wrote:
>
> I wonder why we don't apply the delay on commit/commit_prepared
> records only similar to physical replication. See recoveryApplyDelay.
> One more advantage would be then we don't need
HI All,
Following comment in RemoveNonParentXlogFiles() says that we are trying to
remove any WAL file whose segment number is >= the segment number of the
first WAL file on the new timeline. However, looking at the code, I can say
that we are trying to remove the WAL files from the previous
On Mon, Aug 1, 2022 at 10:13 PM Simon Riggs
wrote:
>
> "A mathematical catastrophe is a point in a model of an input-output
> system, where a vanishingly small change in the input can produce a
> large change in the output."
>
> We have just such a change in Postgres: when a snapshot overflows.
On Wed, Aug 3, 2022 at 1:41 PM Dilip Kumar wrote:
>
> On Wed, Aug 3, 2022 at 12:00 PM Dilip Kumar wrote:
> >
>
> > Okay, so AtEOXact_SMgr will only get rid of unowned smgr and ours are
> > owned by a fake relcache and whose lifetime is just portal memory
> > context which will go away at the
Thank you for your reply.
About 60,000 characters are registered in the IPAmj Mincho font designated by
the national specifications.
It should be able to handle all characters.
regards.
-Original Message-
From: Kyotaro Horiguchi
Sent: Wednesday, August 3, 2022 3:26 PM
To:
On 2022-Aug-01, Tom Lane wrote:
> One idea for avoiding confusion is to legislate that we won't
> use tabs at all in this file (which we could enforce via
> .gitattributes, I think).
+1.
> But that might just be making things equally inconvenient for
> everybody.
In this situation, the only
On 2022-Aug-03, Amit Kapila wrote:
> Thanks for the report and Thanks Michael for including me. I am just
> redirecting it to -hackers so that others involved in this feature
> also can share their views.
I'm sorry, but our policy is that crossposts are not allowed. I think
this policy is bad,
Thank you for the detailed explanation!
I doubt many people from -general would actually be able to provide such
info since the spirit of that list is to find work-arounds for problems and
questions at user level rather than dig into the details on how something
actually works.
It's worth adding
Hello,
> As discussed in [1], we're taking this opportunity to return some patchsets
> that don't appear to be getting enough reviewer interest.
Thank you for your helpful comments.
As you say, my patch doesn't seem to be of much interest to reviewers either.
I will discard the patch I proposed
1 - 100 of 117 matches
Mail list logo
