pull down to refresh

It's not a bug, it always worked like that.
The ids are sequential, and you can always still pay for an item.
Once an id was assigned, it's gone.
120 sats \ 1 reply \ @grayruby 8h
I still think it should be fixed. Haha
reply
20 sats \ 0 replies \ @ek 8h
I respect that opinion haha
reply
60 sats \ 6 replies \ @k00b 8h
It's more complicated than just unpaid items or deletions. Rollbacks after inserts also leave "holes" in sequences.
Because smallserial, serial and bigserial are implemented using sequences, there may be "holes" or gaps in the sequence of values which appears in the column, even if no rows are ever deleted. A value allocated from the sequence is still "used up" even if a row containing that value is never successfully inserted into the table column. This may happen, for example, if the inserting transaction rolls back.
Afaik the best we can say about sequences is that they're monotonically increasing (if NO CYCLE is used (which is the default)).
The id is not the item count. It's a rough overestimate of the item count.
reply
You could just make a temporary buffer (new table) until the item paid.
reply
40 sats \ 4 replies \ @k00b 6h
100% not worth it.
reply
I bet that's a pain in the ass. Any way to know the real number of paid items right now?
reply
30 sats \ 2 replies \ @k00b 6h
SQL's count.
reply
No doubt you can do it. I was just asking the pleb stacker!
What about a sudden spike in total daily items? Is SN going parabolic all of a sudden?
reply
THE RETAIL IS COMING!
lol, cope
reply
If you give a look at recent/all, there's certainly a new wave of stackers who are creating items. And the old ones have also been more activated. Certainly it looks like the rough patch has been mended all of a sudden.
reply
Copium and hopium
reply