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?