Skip to content

first ILP write to previously dropped table goes AWOL #5803

@nwoolmer

Description

@nwoolmer

To reproduce

The following test case fails because the first write after the drop and recreate goes missing.

If you catch the CairoException from the assert txn=1 check, and then try again, it will successfully send the data. But only new data, not the original, lost row.

Remaking the sender also resolves it.

Add to LineHttpSenderTest:

 @Test
    public void testCanSendRowAfterDropAndRecreate() throws Exception {
        TestUtils.assertMemoryLeak(() -> {
            try (final TestServerMain serverMain = startWithEnvVariables(
                    PropertyKey.HTTP_RECEIVE_BUFFER_SIZE.getEnvVarName(), "2048"
            )) {
                serverMain.start();
                serverMain.ddl("CREATE TABLE test123 (Time TIMESTAMP, Value DOUBLE) timestamp(Time) PARTITION BY year WAL;");

                long time1 = 1_000_000;
                long time2 = time1 * 2;

                int port = serverMain.getHttpServerPort();
                try (Sender sender = Sender.builder(Sender.Transport.HTTP)
                        .address("localhost:" + port)
                        .build()
                ) {
                    sender.table("test123")
                            .doubleColumn("Value", 1.0)
                            .at(time1, ChronoUnit.MICROS);
                    sender.flush();

                    serverMain.awaitTxn("test123", 1);
                    serverMain.assertSql("test123;",
                            "Time\tValue\n" +
                                    "1970-01-01T00:00:01.000000Z\t1.0\n");

                    serverMain.ddl("DROP TABLE test123;");

                    serverMain.ddl("CREATE TABLE test123 (Time TIMESTAMP, Value DOUBLE) timestamp(Time) PARTITION BY year WAL;");
                    serverMain.awaitTxn("test123", 0);
                    serverMain.assertSql("test123;",
                            "Time\tValue\n");

                    sender.table("test123")
                            .doubleColumn("value", 1.0)
                            .at(time1, ChronoUnit.MICROS);
                    sender.flush();

                    serverMain.awaitTxn("test123", 1);

                    serverMain.assertSql("test123;",
                            "Time\tValue\n" +
                                    "1970-01-01T00:00:01.000000Z\t1.0\n");

                    sender.table("test123")
                            .doubleColumn("value", 2.0)
                            .at(time2, ChronoUnit.MICROS);
                    sender.flush();

                    serverMain.awaitTxn("test123", 2);

                    serverMain.assertSql("test123;",
                            "Time\tValue\n" +
                                    "1970-01-01T00:00:01.000000Z\t1.0\n" +
                                    "1970-01-01T00:00:02.000000Z\t2.0\n");
                }
            }
        });
    }

QuestDB version:

Pre-9.0.0 master

OS, in case of Docker specify Docker and the Host OS:

Windows and MacOS

File System, in case of Docker specify Host File System:

N/A

Full Name:

Nick Woolmer

Affiliation:

QuestDB

Have you followed Linux, MacOs kernel configuration steps to increase Maximum open files and Maximum virtual memory areas limit?

  • Yes, I have

Additional context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    BugIncorrect or unexpected behaviorILPIssues or changes relating to Influx Line Protocolexternal

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions