On 2024-02-12 Mo 11:44, Dave Cramer wrote:

Dave Cramer
www.postgres.rocks


On Mon, 12 Feb 2024 at 09:19, Andrew Dunstan <and...@dunslane.net> wrote:


    On 2024-02-12 Mo 08:51, Dave Cramer wrote:


    On Sat, 10 Feb 2024 at 13:28, Andrew Dunstan
    <and...@dunslane.net> wrote:


        On 2024-02-10 Sa 12:20, Dave Cramer wrote:


        On Sat, 10 Feb 2024 at 11:19, Andrew Dunstan
        <and...@dunslane.net> wrote:


            On 2024-02-09 Fr 14:23, Dave Cramer wrote:

            Dave Cramer
            www.postgres.rocks <http://www.postgres.rocks>


            On Fri, 9 Feb 2024 at 07:18, Dave Cramer
            <davecramer@postgres.rocks>
            <mailto:davecramer@postgres.rocks> wrote:





                On Fri, 9 Feb 2024 at 00:26, Michael Paquier
                <mich...@paquier.xyz> wrote:

                    On Tue, Feb 06, 2024 at 07:01:49AM -0500, Dave
                    Cramer wrote:
                    > Thanks, this patch works and
                    > testing with meson passes.

                    Only with the version posted at [1]? 
                    Interesting, that's the same
                    contents as v8 posted upthread, minus
                    src/tools/ because we don't need
                    to care about them anymore.

                    Andrew, what's happening on the test side?  It
                    does not seem you've
                    mentioned any details about what is going
                    wrong, or I have just missed
                    them.

                    > I'll try the buildfarm next.

                    [1]:
                    
https://www.postgresql.org/message-id/ea42654a-3dc4-98b0-335b-56b7ec5e5...@dunslane.net


                interestingly meson test does not produce any error
                The buildfarm produces the following error for me:

                -SELECT relname, attname, coltypes,
                get_columns_length(coltypes)
                - FROM check_columns
                - WHERE get_columns_length(coltypes) % 8 != 0 OR
                -  'name'::regtype::oid = ANY(coltypes);
                - relname | attname | coltypes | get_columns_length
                ----------+---------+----------+--------------------
                -(0 rows)
                -
                +server closed the connection unexpectedly
                +This probably means the server terminated abnormally
                +before or while processing the request.
                +connection to server was lost


            Actually digging some more, here is the actual error

            2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:
             server process (PID 11204) was terminated by exception
            0xC0000005
            2024-02-09 13:31:11.008 -05 postmaster[10672] DETAIL:
             Failed process was running: VACUUM;
            2024-02-09 13:31:11.008 -05 postmaster[10672] HINT:
             See C include file "ntstatus.h" for a description of
            the hexadecimal value.
            2024-02-09 13:31:11.008 -05 postmaster[10672] LOG:
             terminating any other active server processes
            2024-02-09 13:31:11.013 -05 postmaster[10672] LOG:  all
            server processes terminated; reinitializing
            2024-02-09 13:31:11.034 -05 startup[6152] LOG:
             database system was interrupted; last known up at
            2024-02-09 13:31:01 -05





        So how does one debug this ?

        Also if I `run meson test` I don't see this error. What does
        the buildfarm do differently?


        First it does this:


            meson test -C $pgsql --no-rebuild --suite setup


        Then it does this (jflag is for the number of jobs):


            meson test -t $meson_test_timeout $jflag -C $pgsql
            --logbase checklog --print-errorlogs --no-rebuild --suite
            regress --test-args=--no-locale



    running the above manually produces no errors ??



    Not for me. I get the error I previously reported, It's an access
    violation error.




OK, so I have managed to get a debugger attached to postgres.exe when it faults and the fault occurs at
https://github.com/postgres/postgres/blob/09eb633e1baa3b7cd7929f3cc77f9c46f63c20b1/src/backend/utils/mmgr/dsa.c#L869
span is pointing to 0x0



Further data point. If I select a build type of 'debug' instead of 'debugoptimized' the error disappears.


cheers


andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

Reply via email to