On Mon, Aug 01, 2022 at 10:02:19PM -0700, Nathan Bossart wrote:
> On Sat, Jul 30, 2022 at 11:51:56PM -0700, Noah Misch wrote:
> > Inviting the administrator to resolve things is more dangerous than just
> > returning true. I recommend making this text more opinionated and simpler:
> > libraries mu
Hello,
Following the bug report at [1], I sent the attached patch to pgsql-bugs
mailing list. I'm starting a thread here to add it to the next commitfest.
The problem I'm trying to solve is that, contrary to btree, gist and sp-gist
indexes, gin indexes do not charge any cpu-cost for descending
On Wed, Aug 03, 2022 at 11:24:17AM +0900, Kyotaro Horiguchi wrote:
> At Tue, 2 Aug 2022 16:03:42 -0500, Don Seiler wrote in
> > could not link file “pg_wal/xlogtemp.18799" to
> > > “pg_wal/0001D4530010”: File exists
> Hmm. It seems like a race condition betwen StartupXLOG() and
> Re
I'm not sure this fits -hackers..
At Tue, 2 Aug 2022 18:57:41 -0700, Dmitry Koterov
wrote in
> Hi.
>
> Suppose on master, I run a *multi-query* using PQexec and save the value
> returned by pg_current_wal_insert_lsn:
>
> master_lsn = query(master, "INSERT INTO some VALUES (...); SELECT
> pg_c
I think in the following sentence, were should be replaced with have,
what do you think?
```
/*
-* We were just issued a SAVEPOINT inside a
transaction block.
+* We have just issued a SAVEPOINT inside a
transaction block.
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 transaction end. So as Andres
> suggested options could be that a)
At Wed, 3 Aug 2022 00:28:47 -0700, Noah Misch wrote in
> On Wed, Aug 03, 2022 at 11:24:17AM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 2 Aug 2022 16:03:42 -0500, Don Seiler wrote in
> > > could not link file “pg_wal/xlogtemp.18799" to
> > > > “pg_wal/0001D4530010”: File exists
>
>
> On 3 Aug 2022, at 10:10, Junwang Zhao wrote:
>
> I think in the following sentence, were should be replaced with have,
> what do you think?
>
> ```
>/*
> -* We were just issued a SAVEPOINT inside a
> transaction block.
> +
Op 03-08-2022 om 10:10 schreef Junwang Zhao:
I think in the following sentence, were should be replaced with have,
what do you think?
```
/*
-* We were just issued a SAVEPOINT inside a
transaction block.
+* We have just iss
On Wed, Aug 3, 2022 at 4:23 PM Daniel Gustafsson wrote:
>
> > On 3 Aug 2022, at 10:10, Junwang Zhao wrote:
> >
> > I think in the following sentence, were should be replaced with have,
> > what do you think?
> >
> > ```
> >/*
> > -* We were just iss
yeah, not a grammar mistake at all, "were" should be used here, thanks
for pointing that out ;)
On Wed, Aug 3, 2022 at 4:27 PM Erikjan Rijkers wrote:
>
> Op 03-08-2022 om 10:10 schreef Junwang Zhao:
> > I think in the following sentence, were should be replaced with have,
> > what do you think?
>
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 t
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
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, p
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 dis
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: thomas.mu.
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 tran
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. In
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 timel
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 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
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 nece
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 possibly
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 con
> 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 r
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 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 wel
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 didn't
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 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 t
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 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 buildfar
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 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 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
> > > "h
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 se
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 suc
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 each
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]
https://postgr.es/m/CAFBsxsGkt
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 se
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 d
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 */
>
> Migh
[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 use
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
> >> +pg_attribute_no_sanitize_align
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 DATABA
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 think
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, b
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
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 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.
- https://commitfest.postgresql.org/38/248
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 man
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 ne
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. Well
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 add
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 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 sub
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 spuriously
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
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 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 gar
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 ResolveRecoveryCo
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
> relfrozenxid/re
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 gar
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 stu
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?) sense
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 (certificates,
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 breakin
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, reminde
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 t
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 is
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 seconds
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 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.
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 hav
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 postgres_fd
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.
>
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:
> >
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
>
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 d
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 se
"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 en
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
> > +
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 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 Ci
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 __strt
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 to
Andres Freund writes:
> Another potential cleanup is the fallback for strtoll/strtoull.
+1, I suspect the alternate spellings are dead.
regards, tom lane
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] | ^
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
> >
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 intr
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
> >> .gita
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 spinnin
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 polic
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.*'
> >
> > Does
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, Thom
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 commen
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 op
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
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 i
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
> > reprodu
1 - 100 of 120 matches
Mail list logo
