Horton

Thread

Commits

  1. postgres_fdw, dblink: Validate use_scram_passthrough values

  1. ci: Skip minfree file in the cores_backtrace.sh

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2025-10-17T08:26:04Z

    Hi,

Melanie mentioned on the Postgres Discord channel that the OpenBSD CI
task’s 'Run cores' script fails [1] because it tries to process a file
named minfree, which is not a valid core file.

This patch updates the cores_backtrace.sh script to skip the minfree
file across all CI operating systems, since it is not expected to be a
valid core file on any of them.

The fix was proposed by Christoph Berg, I created the patch and
verified that it works.

[1] https://cirrus-ci.com/task/6309105838587904

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

  2. Re: ci: Skip minfree file in the cores_backtrace.sh

    Daniel Gustafsson <daniel@yesql.se> — 2025-10-17T09:15:39Z

    > On 17 Oct 2025, at 10:26, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:

> This patch updates the cores_backtrace.sh script to skip the minfree
> file across all CI operating systems, since it is not expected to be a
> valid core file on any of them.

+1, seems correct from a read through.

--
Daniel Gustafsson

  3. Re: ci: Skip minfree file in the cores_backtrace.sh

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2025-10-17T10:28:57Z

    Hi,

On Fri, 17 Oct 2025 at 12:15, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 17 Oct 2025, at 10:26, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote:
>
> > This patch updates the cores_backtrace.sh script to skip the minfree
> > file across all CI operating systems, since it is not expected to be a
> > valid core file on any of them.
>
> +1, seems correct from a read through.

Thanks for looking into it!

Here is an example CI run [1]. I broke the CI on purpose, so you can
see that the 'Run cores' script finished successfully in all CI
operating systems that run cores_backtrace.sh.

[1] https://cirrus-ci.com/build/4950636673892352

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

  4. Re: ci: Skip minfree file in the cores_backtrace.sh

    Álvaro Herrera <alvherre@kurilemu.de> — 2025-10-17T12:25:19Z

    On 2025-Oct-17, Nazir Bilal Yavuz wrote:

>  first=1
> -for corefile in $(find "$directory" -type f) ; do
> +# minfree is not a core file but may exists in the crash directory, skip it
> +for corefile in $(find "$directory" -type f -not -name "minfree") ; do
>      if [ "$first" -eq 1 ]; then
>          first=0
>      else

This looks quite random.  Why not do "find ... -name '*core*'" instead?
I mean, if we have minfree there today, we could have maxbusy tomorrow
or whatever.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"We’ve narrowed the problem down to the customer’s pants being in a situation
 of vigorous combustion" (Robert Haas, Postgres expert extraordinaire)

  5. Re: ci: Skip minfree file in the cores_backtrace.sh

    Daniel Gustafsson <daniel@yesql.se> — 2025-10-17T12:31:40Z

    > On 17 Oct 2025, at 14:25, Álvaro Herrera <alvherre@kurilemu.de> wrote:
> 
> On 2025-Oct-17, Nazir Bilal Yavuz wrote:
> 
>> first=1
>> -for corefile in $(find "$directory" -type f) ; do
>> +# minfree is not a core file but may exists in the crash directory, skip it
>> +for corefile in $(find "$directory" -type f -not -name "minfree") ; do
>>     if [ "$first" -eq 1 ]; then
>>         first=0
>>     else
> 
> This looks quite random.  Why not do "find ... -name '*core*'" instead?
> I mean, if we have minfree there today, we could have maxbusy tomorrow
> or whatever.

I think we should be able to count of the core directory on controlled CI
instances not being cluttered with random files - if it is we probably want a
test failure logged so we can look at it - but minfree is a special file for
core dump handling on some platforms so skipping that make sense I think.

--
Daniel Gustafsson

  6. Re: ci: Skip minfree file in the cores_backtrace.sh

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2025-10-17T12:38:03Z

    On Fri, 17 Oct 2025 at 15:31, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 17 Oct 2025, at 14:25, Álvaro Herrera <alvherre@kurilemu.de> wrote:
> >
> > On 2025-Oct-17, Nazir Bilal Yavuz wrote:
> >
> >> first=1
> >> -for corefile in $(find "$directory" -type f) ; do
> >> +# minfree is not a core file but may exists in the crash directory, skip it
> >> +for corefile in $(find "$directory" -type f -not -name "minfree") ; do
> >>     if [ "$first" -eq 1 ]; then
> >>         first=0
> >>     else
> >
> > This looks quite random.  Why not do "find ... -name '*core*'" instead?
> > I mean, if we have minfree there today, we could have maxbusy tomorrow
> > or whatever.
>
> I think we should be able to count of the core directory on controlled CI
> instances not being cluttered with random files - if it is we probably want a
> test failure logged so we can look at it - but minfree is a special file for
> core dump handling on some platforms so skipping that make sense I think.

I agree with both. How about moving "minfree" to a variable
(presumably an array); instead of having a hard coded string? So that
we can exclude all files in this variable.

-- 
Regards,
Nazir Bilal Yavuz
Microsoft

  7. Re: ci: Skip minfree file in the cores_backtrace.sh

    Álvaro Herrera <alvherre@kurilemu.de> — 2025-10-17T13:46:47Z

    On 2025-Oct-17, Daniel Gustafsson wrote:

> I think we should be able to count of the core directory on controlled CI
> instances not being cluttered with random files - if it is we probably want a
> test failure logged so we can look at it - but minfree is a special file for
> core dump handling on some platforms so skipping that make sense I think.

Well, did you look at the rest of the CI file?  It has to copy files
from here and there into the common directory.  Within each system the
directory it uses is always the same, sure, but otherwise the whole
thing is pretty haphazard.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Entristecido, Wutra                     (canción de Las Barreras)
echa a Freyr a rodar
y a nosotros al mar"

  8. Re: ci: Skip minfree file in the cores_backtrace.sh

    Nazir Bilal Yavuz <byavuz81@gmail.com> — 2026-04-07T11:05:23Z

    Hi,

This problem is still happening.

On Fri, 17 Oct 2025 at 15:31, Daniel Gustafsson <daniel@yesql.se> wrote:
>
> > On 17 Oct 2025, at 14:25, Álvaro Herrera <alvherre@kurilemu.de> wrote:
> >
> > On 2025-Oct-17, Nazir Bilal Yavuz wrote:
> >
> >> first=1
> >> -for corefile in $(find "$directory" -type f) ; do
> >> +# minfree is not a core file but may exists in the crash directory, skip it
> >> +for corefile in $(find "$directory" -type f -not -name "minfree") ; do
> >>     if [ "$first" -eq 1 ]; then
> >>         first=0
> >>     else
> >
> > This looks quite random.  Why not do "find ... -name '*core*'" instead?
> > I mean, if we have minfree there today, we could have maxbusy tomorrow
> > or whatever.
>
> I think we should be able to count of the core directory on controlled CI
> instances not being cluttered with random files - if it is we probably want a
> test failure logged so we can look at it - but minfree is a special file for
> core dump handling on some platforms so skipping that make sense I think.

I see that we already search for *core* string in the
cores_backtrace.sh script (we do it only for OpenBSD but I think it
doesn't matter):

```
base=$(echo "$filename" | sed 's/\.core.*$//')
```

So, I wanted to continue with Álvaro's suggestion. v2 is attached.

Example CI run: https://cirrus-ci.com/build/6447813132812288


--
Regards,
Nazir Bilal Yavuz
Microsoft

  9. Re: ci: Skip minfree file in the cores_backtrace.sh

    Ilmar Y <tanswis42@gmail.com> — 2026-05-28T12:44:32Z

    I looked at v2, focused on the cores_backtrace.sh file selection.

The patch applies cleanly on current master at
8a86aa313a714adc56c74e4b08793e4e6102b5ca.

git diff --check reports no issues, and:

sh -n src/tools/ci/cores_backtrace.sh

reports no syntax issues.

I checked the current Cirrus core-file naming and did not find a configured
name that this pattern would miss. Linux uses /tmp/cores/%e-%s-%p.core,
FreeBSD uses /tmp/cores/%N.%P.core, NetBSD/OpenBSD move *.core files into
the common directory, and macOS uses ${HOME}/cores/core.%P.

I also checked the OpenBSD cores step in the linked Cirrus run:
https://cirrus-ci.com/build/6447813132812288

It ran cores_backtrace.sh, lldb loaded /var/crash/initdb.core, and
thread backtrace all produced a backtrace.

I have not reproduced the original failure locally or run Cirrus CI myself.

Regards,
Ilmar