2022.03.03 12:13 AM
Hello everyone,
There is a RDB in our kxplatform(4.5) reported "splay" error when receiving data from TP (.u.upd is called) yestoday, the error message is like :
"error using update function" ### ("splay"; tableName; +`column1`column2....)
After i restarted the RDB, the error no longer exists.
The same error happened last week, one another RDB, and it was solved by restart.
If anyone have a clue about the reason please let me know, thank you all!
best,
leguan,
2022.03.03 01:24 AM
Hi leguan,
Below I have a q process that has loaded in a splayed table from disk, and when I attempt to upsert to it I receive the splay runtime error:
q) \ls
"sym"
"trades"
q) \l .
trades
sym time price
--------------------------------------------
hagl 2019.03.18D00:59:52.359311488 72.50709
cokn 2011.09.16D13:20:44.392412288 48.1804
ojeg 2001.06.09D22:38:22.583004264 93.51307
ohbo 2002.08.03D15:00:12.478929184 70.93398
caha 2012.02.12D05:29:19.432019136 94.52199
q) upsert[`trades;flip (5?`4;5?.z.P;5?100f)]
'2022.03.03T20:16:22.250 splay
[0] upsert[`trades;flip (10?`4;10?.z.P;10?100f)]
Compare this with a table defined in-memory (such as an RDB schema):
q)trades:([]sym:`$();time:`timestamp$();price:`float$())
q)trades
sym time price
--------------
q)upsert[`trades;flip (5?`4;5?.z.P;5?100f)]
`trades
q)trades
sym time price
-------------------------------------------
ncej 2010.12.07D17:24:19.578683840 39.27524
jogn 2012.10.28D18:28:23.546450688 51.70911
ciha 2001.11.10D07:36:32.747210000 51.59796
hkpb 2004.05.06D02:28:38.944876960 40.66642
aeaj 2008.04.29D20:37:48.030489920 17.80839
Has a process or a user loaded (or memory-mapped) the splayed table (or entire HDB) from disk into the RDB process?
Best regards,
David
2022.03.03 01:24 AM
Hi leguan,
Below I have a q process that has loaded in a splayed table from disk, and when I attempt to upsert to it I receive the splay runtime error:
q) \ls
"sym"
"trades"
q) \l .
trades
sym time price
--------------------------------------------
hagl 2019.03.18D00:59:52.359311488 72.50709
cokn 2011.09.16D13:20:44.392412288 48.1804
ojeg 2001.06.09D22:38:22.583004264 93.51307
ohbo 2002.08.03D15:00:12.478929184 70.93398
caha 2012.02.12D05:29:19.432019136 94.52199
q) upsert[`trades;flip (5?`4;5?.z.P;5?100f)]
'2022.03.03T20:16:22.250 splay
[0] upsert[`trades;flip (10?`4;10?.z.P;10?100f)]
Compare this with a table defined in-memory (such as an RDB schema):
q)trades:([]sym:`$();time:`timestamp$();price:`float$())
q)trades
sym time price
--------------
q)upsert[`trades;flip (5?`4;5?.z.P;5?100f)]
`trades
q)trades
sym time price
-------------------------------------------
ncej 2010.12.07D17:24:19.578683840 39.27524
jogn 2012.10.28D18:28:23.546450688 51.70911
ciha 2001.11.10D07:36:32.747210000 51.59796
hkpb 2004.05.06D02:28:38.944876960 40.66642
aeaj 2008.04.29D20:37:48.030489920 17.80839
Has a process or a user loaded (or memory-mapped) the splayed table (or entire HDB) from disk into the RDB process?
Best regards,
David
2022.03.07 01:27 AM
Hello David, thank you for your answer! There is no user or porcess loads hdb table to that RDB. Well the good news is the RDB has been working fine since last restart. Thanks agian and it is a great example!
2022.03.03 07:01 AM
The Reference lists for splay error: nyi op on splayed table. Does that help? Is there more to be said here?
2022.03.07 01:27 AM
Thank you SJT!
EMEA
Tel: +44 (0)28 3025 2242
AMERICAS
Tel: +1 (212) 447 6700
APAC
Tel: +61 (0)2 9236 5700
KX. All Rights Reserved.
KX and kdb+ are registered trademarks of KX Systems, Inc., a subsidiary of FD Technologies plc.