>
> If you look at the code of worker_spi.c closely the answer shows up by
> itself:
>
> appendStringInfo(&buf,
> "CREATE SCHEMA \"%s\" "
> "CREATE TABLE \"%s\" ("
> " type text CHECK (type IN ('total',
> 'delta')), "
> " value integer)"
> "CREATE UNIQUE INDEX \"%s_unique_total\" ON \"%s\" (type)
> "
> "WHERE type = 'total'",
>
> In this case "total" is not a type, it is one of the authorized value in
> the value. So just insert an initial tuple like that:
> INSERT INTO schema1.counted VALUES ('total', 1);
> And then insert periodically for example the following:
> INSERT INTO schema1.counted VALUES ('delta', 3);
> And then the background worker will sum up the values inserted in
> "delta" tuples to the actual "total".
>
>
I could not find the table schema1.counted. What confused me is that I
ran SELECT worker_spi_launch(1); but it created the schema in the database
postgres instead of the current database I am in! Doesn't that seem a bit
counter-intuitive? Anyway, I found it now, so I am good to go! Thank you!
> > I am trying to use this extension as a pattern for my own background
> > worker, but just trying to understand it.
>
> You are right to do so, this is a good learning step.
> --
> Michael
>
Since you mention, can anyone elaborate further on the memory leak danger
here?
Line 193 in src/test/modules/worker_spi/worker_spi.c read:
# Note some memory might be leaked here.
Is this any reason *not *to use this pattern in production?
Thanks,
Jeremy
