Hi,
On October 2, 2021 1:18:38 PM PDT, Daniel Gustafsson wrote:
>> On 2 Oct 2021, at 22:01, Andres Freund wrote:
>> On 2021-10-02 20:42:00 +0200, Daniel Gustafsson wrote:
>>> Same, and for my case I run several CI jobs to compile/test against
>>> different
>>> OpenSSL versions etc.
>>
>> On t
Andrew Dunstan writes:
> On 10/2/21 5:03 PM, Tom Lane wrote:
>> IIUC, the only problem for a non-updated animal would be that it'd
>> run the test twice? Or would it actually fail? If the latter,
>> we'd need to sit on the patch rather longer.
> The patch removes test.sh, so yes it would break.
On 10/2/21 5:03 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I haven't looked at the patch closely yet, but from a buildfarm POV I
>> think the only thing that needs to be done is to inhibit the buildfarm
>> client module if the TAP tests are present. The buildfarm code that runs
>> TAP tests
On Fri, Oct 1, 2021 at 2:35 PM Bossart, Nathan wrote:
> On 9/30/21, 3:44 PM, "Peter Geoghegan" wrote:
> > I will commit this patch in a few days, barring objections.
>
> +1
Okay, pushed.
Thanks
--
Peter Geoghegan
Thomas Munro writes:
> On Sun, Oct 3, 2021 at 11:26 AM Tom Lane wrote:
>> I'd still defend our exception for Central America: CLDR maps that
>> to Guatemala which seems pretty random, even if they haven't observed
>> DST there for a few years. For the rest of it, though, "we follow CLDR"
>> has
Andres Freund writes:
> On October 2, 2021 3:26:35 PM PDT, Tom Lane wrote:
>> However, the example
>> we started the thread with is that Andres thought "Greenwich Standard
>> Time" would get him UTC, or at least something a lot less oddball than
>> what he got.
> FWIW, that was just the default
Chapman Flack writes:
> I'm having difficulty coming up with a query that actually doesn't
> run the SRF to completion.
>From memory, nodeFunctionscan always populates the tuplestore immediately.
I've looked into changing that but not got it done.
If you write the function in the targetlist, ie
Hi,
I am trying to improve (i.e. have any at all) test coverage of the
ExprContextCallback for a ValuePerCall SRF function handler.
I'm having difficulty coming up with a query that actually doesn't
run the SRF to completion.
The form I've been trying looks like
SELECT *
FROM
executeSelectToRe
> On 3 Oct 2021, at 00:39, Kevin Burke wrote:
> Updated patch that removes the "Maybe"
Thanks, I’ll take care of this tomorrow along with Rachels patch.
./daniel
On Sun, Oct 3, 2021 at 11:26 AM Tom Lane wrote:
> > Eyeballing these, three look strange to me in a list of otherwise
> > city-based names: Pacific/Guam (instead of Port Moresby, capital of
> > PNG which apparently shares zone rules with the territory of Guam) and
> > Pacific/Samoa (country name i
Hi,
On October 2, 2021 3:26:35 PM PDT, Tom Lane wrote:
>However, the example
>we started the thread with is that Andres thought "Greenwich Standard
>Time" would get him UTC, or at least something a lot less oddball than
>what he got.
FWIW, that was just the default on those machines (which in t
Thomas Munro writes:
> On Sun, Oct 3, 2021 at 9:42 AM Tom Lane wrote:
>> * Now-documented decision to map "Greenwich Standard Time"
>> to Europe/London, not Atlantic/Reykjavik as they have it.
> Hmm. It's hard to pick a default from that set of merged zones, but
> the funny thing about this cho
> When I click the mail archive link
> (https://www.postgresql.org/message-id/flat/72a0d590d6ba06f242d75c2e64182...@postgrespro.ru)
> in CF app web page of this entry:
> https://commitfest.postgresql.org/34/3194/
>
> I got:
>
> Error 503 Backend fetch failed
>
> Backend fetch failed
> Guru Medit
On 2021-Sep-27, Michael Paquier wrote:
> I got again a failure today, so I have used this occasion to check that
> when the checkpoint gets stuck the WAL sender process getting SIGCONT
> is still around, waiting for a write to happen:
> * thread #1, queue = 'com.apple.main-thread', stop reason = s
Andres Freund writes:
> On 2021-10-02 16:44:44 -0400, Tom Lane wrote:
>> If you'd like that, there would need to be some (ahem) documentation
>> of how to use it.
> Yea, definitely necessary. Where would we want it to be? ci/README.md? That'd
> be viewable on the various git hosting platforms. I
On Sat, Oct 2, 2021 at 1:55 AM Tom Lane wrote:
> BTW, I find those "territory" annotations in the CLDR data to be
> fascinating. If that corresponds to something that we could retrieve
> at runtime, it'd allow far better mapping of Windows zones than we
> are doing now. I have no interest in wor
On Sun, Oct 3, 2021 at 9:42 AM Tom Lane wrote:
> * Now-documented decision to map "Greenwich Standard Time"
> to Europe/London, not Atlantic/Reykjavik as they have it.
Hmm. It's hard to pick a default from that set of merged zones, but
the funny thing about this choice is that Europe/London is t
Hi,
On 2021-10-02 16:44:44 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > I hope it will also encourage people to test more widely, given how easy
> > it will make it.
>
> If you'd like that, there would need to be some (ahem) documentation
> of how to use it.
Yea, definitely necessary. Whe
Andrew Dunstan writes:
> I haven't looked at the patch closely yet, but from a buildfarm POV I
> think the only thing that needs to be done is to inhibit the buildfarm
> client module if the TAP tests are present. The buildfarm code that runs
> TAP tests should automatically detect and run the new
On 10/1/21 2:19 AM, Michael Paquier wrote:
> On Thu, May 20, 2021 at 03:07:56PM +0900, Michael Paquier wrote:
>> This stuff still needs to be expanded depending on how PostgresNode is
>> made backward-compatible, but I'll wait for that to happen before
>> going further down here. I have also spe
Andrew Dunstan writes:
> I hope it will also encourage people to test more widely, given how easy
> it will make it.
If you'd like that, there would need to be some (ahem) documentation
of how to use it.
regards, tom lane
I wrote:
> Oh, thanks for the pointer to CLDR! I tried re-generating our data
> based on theirs, and ended up with the attached draft patch.
Hearing no objections, pushed after another round of review
and a couple more fixes.
For the archives' sake, here are the remaining discrepancies
between o
On 10/2/21 11:05 AM, Tom Lane wrote:
> Andres Freund writes:
>> It's not like this forces you to use cirrus or anything. For people that
>> don't
>> want to use CI, It'll make cfbot a bit more effective (because people can
>> adjust what it tests as appropriate for $patch), but that's it.
> Yea
> On 2 Oct 2021, at 22:01, Andres Freund wrote:
> On 2021-10-02 20:42:00 +0200, Daniel Gustafsson wrote:
>> Same, and for my case I run several CI jobs to compile/test against different
>> OpenSSL versions etc.
>
> On that note: Did you do this for windows? If so, I'd rather not figure that
> out
Hi,
On 2021-10-02 20:42:00 +0200, Daniel Gustafsson wrote:
> Same, and for my case I run several CI jobs to compile/test against different
> OpenSSL versions etc.
On that note: Did you do this for windows? If so, I'd rather not figure that
out myself...
Greetings,
Andres Freund
Hi,
On 2021-10-02 11:05:20 -0400, Tom Lane wrote:
> Yeah. I cannot see any reason to object to Andres' 0002 patch: you can
> just ignore those files if you don't want to use cirrus. It does set a
> precedent that we'd also accept infrastructure for other CI systems,
> but as long as they're simi
> On 2 Oct 2021, at 21:41, Andres Freund wrote:
>> One thing to note for Cirrus on macOS (I've never seen it anywhere else) is
>> that it intermittently will fail on a too long socketpath:
>
> I've seen it somewhere else before. It wasn't even intermittent - it always
> failed. I worked around t
> On 2 Oct 2021, at 21:45, Andres Freund wrote:
> I wonder if we shouldn't stop skipping the ssl / kerberos / ldap (and perhaps
> others) tests in the makefile, and instead do so in the tap tests
> themselves. Then one can see them included as the skipped in the tap result
> output, which seems l
Hi,
On 2021-10-02 12:41:07 -0700, Andres Freund wrote:
> On 2021-10-02 20:42:00 +0200, Daniel Gustafsson wrote:
> > + tests_script:
> > +- su postgres -c 'ulimit -c unlimited ; ${TIMEOUT_CMD} make -s
> > ${CHECK} ${CHECKFLAGS} -j8'
> > Don't you need PG_TEST_EXTRA=ssl here to ensure the src/
Hi,
On 2021-10-02 20:42:00 +0200, Daniel Gustafsson wrote:
> > On 2 Oct 2021, at 00:27, Andres Freund wrote:
> > Right now the patch attached
> > - runs check-world on FreeBSD, Linux, macOS - all using gcc
> > - freebsd, linux use a custom generated image
> > - macOS installs missing dependenci
> On 2 Oct 2021, at 00:27, Andres Freund wrote:
> For several development efforts I found it to be incredibly valuable to push
> changes to a personal repository and see a while later whether tests succeed
> on a number of different platforms. This is especially useful for platforms
> that are q
> On 2 Oct 2021, at 17:24, Tom Lane wrote:
>
> Alvaro Herrera writes:
>> I think if we all agree that this is a desired workflow, then we should
>> update the app to allow WoA patches to be moved to next CF.
>
> I'm fairly astonished that anyone would have thought that that
> *wasn't* an expect
Daniel Gustafsson writes:
>> On 2 Oct 2021, at 02:09, Kevin Burke wrote:
>> This patch amends the error message to give help to the user.
> I think this makes sense,
+1. I'd take out the "Maybe"; the diagnosis seems pretty certain.
regards, tom lane
> On 2 Oct 2021, at 02:09, Kevin Burke wrote:
> This patch amends the error message to give help to the user.
I think this makes sense, and is in line with Rachels patch [0] a few days ago
that I plan on pushing; small error hints which wont get in the way of
established developers, but which ca
On Fri, Oct 01, 2021 at 06:33:01PM -0300, Alvaro Herrera wrote:
> On 2021-Aug-13, David Christensen wrote:
>
> > Both bugs #16676[1] and #17141[2] illustrate that the combination of
> > SKIP LOCKED and FETCH FIRST WITH TIES break expectations when it comes
> > to rows returned to other sessions ac
I got the error message in the subject and was unsure how to continue; I
didn't see any hits for the error message on the mailing list, and it was
hard to determine from the context around the error in the
Makefile.global.in about the best way to solve the problem.
This patch amends the error mess
On Thu, Sep 30, 2021 at 05:08:24PM +1300, Thomas Munro wrote:
> On Thu, Sep 30, 2021 at 4:49 PM Michael Paquier wrote:
> > fsync_pgdata() is going to manipulate many inodes anyway, because
> > that's a code path designed to do so. If we know that syncfs() is
> > just going to be better, I'd rathe
Alvaro Herrera writes:
> On 2021-Oct-02, Tom Lane wrote:
>> Yeah. I have been thinking of looking through the oldest CF entries
>> and proposing that we just reject any that look permanently stalled.
> I was just going to say the same thing yesterday, and reference [1]
> when I did it once in 20
Alvaro Herrera writes:
> I think if we all agree that this is a desired workflow, then we should
> update the app to allow WoA patches to be moved to next CF.
I'm fairly astonished that anyone would have thought that that
*wasn't* an expected case. For example, if someone reviews a
patch and set
On 2021-Oct-02, Tom Lane wrote:
> Yeah. I have been thinking of looking through the oldest CF entries
> and proposing that we just reject any that look permanently stalled.
> It doesn't do much good to leave things in the list when there's
> no apparent interest in pushing them to conclusion. Bu
On 2021-Oct-01, Daniel Gustafsson wrote:
> > On 1 Oct 2021, at 19:49, Jaime Casanova
> > wrote:
> > I will do that but we should improve that process.
>
> Correct again.
I think if we all agree that this is a desired workflow, then we should
update the app to allow WoA patches to be moved to
Andres Freund writes:
> It's not like this forces you to use cirrus or anything. For people that don't
> want to use CI, It'll make cfbot a bit more effective (because people can
> adjust what it tests as appropriate for $patch), but that's it.
Yeah. I cannot see any reason to object to Andres'
Michael Paquier writes:
> That's the tricky part. It does not really make sense either to keep
> moving patches that are waiting on author for months. The scan of the
> CF app I have done was about those idle patches waiting on author for
> months. It takes time as authors and/or reviewers tend
On 2021-Oct-02, Dilip Kumar wrote:
> I have written two patches, Approach1 is as you described using a
> static boolean and Approach2 as a local variable to XLogAssembleRecord
> as described by Amit, attached both of them for your reference.
> IMHO, either of these approaches looks cleaner.
Thank
Hello Peter,
Attached v9 integrates your tests and makes them work.
Attached v11 is a rebase.
--
Fabien.diff --git a/contrib/pg_stat_statements/expected/pg_stat_statements.out b/contrib/pg_stat_statements/expected/pg_stat_statements.out
index b52d187722..0cf4a37a5f 100644
--- a/contrib/pg_st
Hello, Andres.
Could you please clarify how to better deal with the situation?
According to your previous letter, I think there was some
misunderstanding regarding the latest patch version (but I am not
sure). Because as far as understand provided optimization (lazily
calculated optional offset t
On Sat, 2 Oct 2021 at 23:22, Andreas Karlsson wrote:
> Please add your patch to the current open commitfest.
>
Done. https://commitfest.postgresql.org/35/3338/
Thanks for the guidance.
Daniel
On Fri, Oct 1, 2021 at 6:24 PM Alvaro Herrera wrote:
>
> On 2021-Oct-01, Amit Kapila wrote:
> I think a straight standalone variable (probably a static boolean in
> xloginsert.c) might be less confusing.
I have written two patches, Approach1 is as you described using a
static boolean and Approac
On 10/2/21 5:48 AM, Daniel Fone wrote:
I don’t get these compiler warnings and I can’t find any settings to use that
might generate them. I’m compiling on macOS 11.6 configured with
`--enable-cassert --enable-depend --enable-debug CFLAGS=-O0`
I’ve optimistically updated the patch to hopefully
On Thu, Sep 30, 2021 at 3:39 PM vignesh C wrote:
>
> The suggested change works, I have modified it in the attached patch.
>
I have reviewed the latest version and made a number of changes to the
0001 patch. The changes are in v1-0001-Changes-by-Amit. It includes
(a) Changed preprocess_pubobj_lis
50 matches
Mail list logo
