Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-31662

plugin ha_connect, file_type=DBF DELETE fails

Details

    Description

      @@version: 11.0.2-MariaDB

      like MDEV-31625 but different:

      There's a problem still in the deletes aren't affecting the file format correctly (though SQL seems to cope).

      MariaDB [test]>  insert into t1 values (4),(3),(2),(1);
       
      $ od --endian=big -x /tmp/build-mariadb-server-10.4-datadir/test/t1.dbf 
      0000000 037b 070b 0400 0000 4200 0c00 0000 0000
      0000020 0000 0000 0000 0000 0000 0000 0000 0000
      0000040 6100 0000 0000 0000 0000 004e 0000 0000
      0000060 0b00 0000 0000 0000 0000 0000 0000 0000
      0000100 0d00 2020 2020 2020 2020 2020 2034 2020
      0000120 2020 2020 2020 2020 2033 2020 2020 2020
      0000140 2020 2020 2032 2020 2020 2020 2020 2020
      0000160 2031 1a00
      0000163
      

      MariaDB [test]> delete from t1 where a=1;
       
      $ od --endian=big -x /tmp/build-mariadb-server-10.4-datadir/test/t1.dbf 
      0000000 037b 070b 0400 0000 4200 0c00 0000 0000
      0000020 0000 0000 0000 0000 0000 0000 0000 0000
      0000040 6100 0000 0000 0000 0000 004e 0000 0000
      0000060 0b00 0000 0000 0000 0000 0000 0000 0000
      0000100 0d00 2020 2020 2020 2020 2020 2034 2020
      0000120 2020 2020 2020 2020 2033 2020 2020 2020
      0000140 2020 2020 2032 2a20 2020 2020 2020 2020
      0000160 2031 1a00
      0000163
      

      offset 0146 is different.

      The record isn't deleted, its still there. The Number of records in the header isn't updated.

      libreoffice thinks the file is now corrupted (though does a decent recovery job).

      Attachments

        Issue Links

          Activity

            danblack Daniel Black added a comment -

            DUNAZOLTAN, how important is the DELETE use case to you? Just wondering how to prioritise it.

            danblack Daniel Black added a comment - DUNAZOLTAN , how important is the DELETE use case to you? Just wondering how to prioritise it.

            DELETE use case is not important to me. I mainly use SELECT and INSERT statements.
            But, what about the UPDATE use case? Can I use it safely?

            DUNAZOLTAN Mr. Zoltan Duna added a comment - DELETE use case is not important to me. I mainly use SELECT and INSERT statements. But, what about the UPDATE use case? Can I use it safely?
            danblack Daniel Black added a comment -

            As far as I can see UPDATES behave correctly. They overwrite the fields of the table and it doesn't need to be shrunk or the table header updated with a change in rows. Table fields are also of a fixed size.

            So DELETEs will be fixed eventually. If anyone is currently affected by the poor dbf format implementation of a DELETE please comment and watch this issue and we'll prioritize it more.

            danblack Daniel Black added a comment - As far as I can see UPDATES behave correctly. They overwrite the fields of the table and it doesn't need to be shrunk or the table header updated with a change in rows. Table fields are also of a fixed size. So DELETEs will be fixed eventually. If anyone is currently affected by the poor dbf format implementation of a DELETE please comment and watch this issue and we'll prioritize it more.
            danblack Daniel Black added a comment -

            notably but not critical is that UPDATE writes to file, two rows instead of 1, its just the second is same as it was.

            MariaDB [test]>  insert into t1 values (4),(3),(2),(1);
            Query OK, 4 rows affected (0.001 sec)
            Records: 4  Duplicates: 0  Warnings: 0
            MariaDB [test]> update t1 set a=5 where a=4;
            Query OK, 1 row affected (0.002 sec)
            Rows matched: 1  Changed: 1  Warnings: 0
            

            trace extract of UPDATE query only

            [pid 203959] openat(AT_FDCWD, "/tmp/build-mariadb-server-10.4-datadir/./test/t1.dbf", O_RDWR) = 45
            [pid 203959] newfstatat(45, "", {st_mode=S_IFREG|0660, st_size=115, ...}, AT_EMPTY_PATH) = 0
            [pid 203959] lseek(45, 0, SEEK_SET)     = 0
            [pid 203959] read(45, "\3{\7\16\4\0\0\0B\0\f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 66) = 66
            [pid 203959] read(45, "           4           3        "..., 4096) = 49
            [pid 203959] read(45, "", 4096)         = 0
            [pid 203959] lseek(45, 0, SEEK_SET)     = 0
            [pid 203959] read(45, "\3{\7\16\4\0\0\0B\0\f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 66) = 66
            [pid 203959] write(45, "           5           3        "..., 48) = 48
            [pid 203959] close(45)                  = 0
            

            danblack Daniel Black added a comment - notably but not critical is that UPDATE writes to file, two rows instead of 1, its just the second is same as it was. MariaDB [test]> insert into t1 values (4),(3),(2),(1); Query OK, 4 rows affected (0.001 sec) Records: 4 Duplicates: 0 Warnings: 0 MariaDB [test]> update t1 set a=5 where a=4; Query OK, 1 row affected (0.002 sec) Rows matched: 1 Changed: 1 Warnings: 0 trace extract of UPDATE query only [pid 203959] openat(AT_FDCWD, "/tmp/build-mariadb-server-10.4-datadir/./test/t1.dbf", O_RDWR) = 45 [pid 203959] newfstatat(45, "", {st_mode=S_IFREG|0660, st_size=115, ...}, AT_EMPTY_PATH) = 0 [pid 203959] lseek(45, 0, SEEK_SET) = 0 [pid 203959] read(45, "\3{\7\16\4\0\0\0B\0\f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 66) = 66 [pid 203959] read(45, " 4 3 "..., 4096) = 49 [pid 203959] read(45, "", 4096) = 0 [pid 203959] lseek(45, 0, SEEK_SET) = 0 [pid 203959] read(45, "\3{\7\16\4\0\0\0B\0\f\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 66) = 66 [pid 203959] write(45, " 5 3 "..., 48) = 48 [pid 203959] close(45) = 0

            People

              anel Anel Husakovic
              danblack Daniel Black
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.