Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

kv rest api: counter operations shouldn't work on Entry values and vice versa #78

Closed
andybons opened this issue Sep 24, 2014 · 4 comments
Closed

kv rest api: counter operations shouldn't work on Entry values and vice versa #78

andybons opened this issue Sep 24, 2014 · 4 comments
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. help wanted Help is requested / needed by the one who filed the issue to fix it.

Comments

@andybons
Copy link
Contributor

No description provided.

@andybons andybons added C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. help wanted Help is requested / needed by the one who filed the issue to fix it. labels Sep 24, 2014
@spencerkimball
Copy link
Member

Support for this is now in the underlying system. proto.Value has a union between a byte string and an int64 integer value. You can Get and Scan rows which mix byte string values and integer values. You can also directly Put and integer value, as well as replace an integer value with a byte string and vice versa on Put. The one thing you can't do is Increment a non-integer value.

@tbg
Copy link
Member

tbg commented Dec 8, 2014

is this still open then?

@andybons
Copy link
Contributor Author

andybons commented Dec 8, 2014

We just need to make sure we enforce "The one thing you can't do is Increment a non-integer value"

@tbg tbg mentioned this issue Dec 8, 2014
Closed
spencerkimball pushed a commit that referenced this issue Dec 10, 2014
Add test to verify non-integer values cannot be incremented via REST
2e948dd 
Fixes issue #78
@spencerkimball spencerkimball mentioned this issue Dec 10, 2014
Merged
@tbg
Copy link
Member

tbg commented Dec 10, 2014

@spencerkimball, want to close this or is something missing?

tbg referenced this issue in tbg/cockroach Aug 31, 2016
@tbg
storage: instrument eager ReplicaGC
f6ec548 
We have been seeing long startup times which disappear spontaneously. During a
restart of the beta cluster, the following goroutine was observed, which suggests
that we were spending a lot of time GCing replicas on startup.

    engine              ??:0                     _Cfunc_DBIterNext(cockroachdb#324, cockroachdb#323, 0, 0, 0, 0, 0, 0, 0)
    engine              rocksdb.go:1135          (*rocksDBIterator).Next(cockroachdb#235)
    storage             replica_data_iter.go:104 (*ReplicaDataIterator).Next(cockroachdb#316)
    storage             store.go:1748            (*Store).destroyReplicaData(#109, cockroachdb#317, 0, 0)
    storage             store.go:841             (*Store).Start.func2(0x101b, cockroachdb#300, 0x36, 0x40, cockroachdb#301, 0x36, 0x40, cockroachdb#315, 0x3, 0x4, ...)
    storage             store.go:734             IterateRangeDescriptors.func1(cockroachdb#306, 0x40, 0x41, cockroachdb#307, 0x92, 0x92, cockroachdb#341, 0, 0x186c, 0x4000, ...)
    engine              mvcc.go:1593             MVCCIterate(cockroachdb#329, #68, #47, #81, cockroachdb#232, 0x9, 0x10, cockroachdb#233, 0xb, 0x10, ...)
    storage             store.go:738             IterateRangeDescriptors(cockroachdb#330, cockroachdb#196, #47, #81, cockroachdb#195, #179, #110)
    storage             store.go:867             (*Store).Start(#109, cockroachdb#330, cockroachdb#196, #179, cockroachdb#185, 0x1)
    server              node.go:405              (*Node).initStores(#78, cockroachdb#330, cockroachdb#196, #98, 0x1, 0x1, #179, 0, #55)
    server              node.go:330              (*Node).start(#78, cockroachdb#330, cockroachdb#196, #42, #129, #98, 0x1, 0x1, 0, 0, ...)
    server              server.go:431            (*Server).Start(#5, cockroachdb#330, cockroachdb#196, #95, 0x1)
    cli                 start.go:368             runStart(#34, #178, 0, 0x9, 0, 0)
    cobra               command.go:599           (*Command).execute(#34, #177, 0x9, 0x9, #34, #177)
    cobra               command.go:689           (*Command).ExecuteC(#33, #70, cockroachdb#343, #72)
    cobra               command.go:648           (*Command).Execute(#33, #71, cockroachdb#343)
    cli                 cli.go:96                Run(#64, 0xa, 0xa, 0, 0)
    main                main.go:37               main()
tbg referenced this issue in tbg/cockroach Aug 31, 2016
@tbg
storage: instrument eager ReplicaGC
c51054f 
We have been seeing long startup times which disappear spontaneously. During a
restart of the beta cluster, the following goroutine was observed, which suggests
that we were spending a lot of time GCing replicas on startup.

    engine              ??:0                     _Cfunc_DBIterNext(cockroachdb#324, cockroachdb#323, 0, 0, 0, 0, 0, 0, 0)
    engine              rocksdb.go:1135          (*rocksDBIterator).Next(cockroachdb#235)
    storage             replica_data_iter.go:104 (*ReplicaDataIterator).Next(cockroachdb#316)
    storage             store.go:1748            (*Store).destroyReplicaData(#109, cockroachdb#317, 0, 0)
    storage             store.go:841             (*Store).Start.func2(0x101b, cockroachdb#300, 0x36, 0x40, cockroachdb#301, 0x36, 0x40, cockroachdb#315, 0x3, 0x4, ...)
    storage             store.go:734             IterateRangeDescriptors.func1(cockroachdb#306, 0x40, 0x41, cockroachdb#307, 0x92, 0x92, cockroachdb#341, 0, 0x186c, 0x4000, ...)
    engine              mvcc.go:1593             MVCCIterate(cockroachdb#329, #68, #47, #81, cockroachdb#232, 0x9, 0x10, cockroachdb#233, 0xb, 0x10, ...)
    storage             store.go:738             IterateRangeDescriptors(cockroachdb#330, cockroachdb#196, #47, #81, cockroachdb#195, #179, #110)
    storage             store.go:867             (*Store).Start(#109, cockroachdb#330, cockroachdb#196, #179, cockroachdb#185, 0x1)
    server              node.go:405              (*Node).initStores(#78, cockroachdb#330, cockroachdb#196, #98, 0x1, 0x1, #179, 0, #55)
    server              node.go:330              (*Node).start(#78, cockroachdb#330, cockroachdb#196, #42, #129, #98, 0x1, 0x1, 0, 0, ...)
    server              server.go:431            (*Server).Start(#5, cockroachdb#330, cockroachdb#196, #95, 0x1)
    cli                 start.go:368             runStart(#34, #178, 0, 0x9, 0, 0)
    cobra               command.go:599           (*Command).execute(#34, #177, 0x9, 0x9, #34, #177)
    cobra               command.go:689           (*Command).ExecuteC(#33, #70, cockroachdb#343, #72)
    cobra               command.go:648           (*Command).Execute(#33, #71, cockroachdb#343)
    cli                 cli.go:96                Run(#64, 0xa, 0xa, 0, 0)
    main                main.go:37               main()
soniabhishek pushed a commit to soniabhishek/cockroach that referenced this issue Feb 15, 2017
@himanshu144141
Merge pull request cockroachdb#78 from crowdflux/bugfix/algo-timing
2e2faa4 
bug fix also wait timing
@cucaroach cucaroach mentioned this issue Nov 4, 2021
Closed
pav-kv pushed a commit to pav-kv/cockroach that referenced this issue Mar 5, 2024
@ahrtr
Merge pull request cockroachdb#78 from erikgrinaker/forget-leader
a10cd45 
add `ForgetLeader`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Code not up to spec/doc, specs & docs deemed correct. Solution expected to change code/behavior. help wanted Help is requested / needed by the one who filed the issue to fix it.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@andybons @tbg @spencerkimball