Tag: length

Oracle 19 ORA-01450: maximum key length (6398) exceeded

I am using Oracle 19 and recently changed the collation to XGERMAN_AI. This required to change the MAX_STRING_SIZE to be EXTENDED as in the following link https://docs.oracle.com/database/121/REFRN/GUID-D424D23B-0933-425F-BC69-9C0E6724693C.htm#REFRN10321

Now, trying to create tables with unique constraints on varchar2 columns produce the error

ORA-01450: maximum key length (6398) exceeded.

Here is my table

CREATE TABLE MY_TABLE (     ID NUMBER(38, 0) DEFAULT PKS_MY_TABLE_SEQ.nextval NOT NULL,      VERSION NUMBER(38, 0) DEFAULT 0 NOT NULL,      CREATED_BY VARCHAR2(50 CHAR) NOT NULL,      CREATED_AT TIMESTAMP NOT NULL,      MODIFIED_BY VARCHAR2(50 CHAR) NOT NULL,      MODIFIED_AT TIMESTAMP NOT NULL,      ID_OLD NUMBER(38, 0),      RISK_LEVEL VARCHAR2(255 CHAR) NOT NULL,      REMARKS VARCHAR2(255 CHAR),      IS_DEACTIVATED NUMBER(1) DEFAULT 0 NOT NULL,      COLOR VARCHAR2(255 CHAR) NOT NULL,      CONSTRAINT MY_TABLE_PK PRIMARY KEY (ID),      UNIQUE (RISK_LEVEL) )

I googled this error, and all results say that it is becase the index size is bigger than the block size which is 8k. But in my case the column RISK_LEVEL is only 255 char long! (255*4 bytes = 1020 bytes), which is much less than 8k and also 6398

Any idea how to fix this?

Can a bolt-action hunting rifle (long arm), be fired when target is at arm’s length? [closed]

Yesterday, I was running my homebrew system (D100), with a friend and one of my nephews over Discord. It was a zombie apocalypse theme. The situation occurred, when my friend (carrying a bolt-action hunting rifle), was rushed by an ‘infected’, and it did a ‘claw strike’, and missed. It was my friend’s turn next. He wanted to do a scoped shot with the bolt-action hunting rifle, but I informed him that the infected was at arms length (too close).

He said he still wanted to fire his rifle (which I considered a long arm), but I said the target was too close. I gave him the option of using the rifle stock to make a melee attack, but he still wanted to fire the rifle. The ‘discussion’ went on for some time, with me trying to explain to the 2 of them (a third one soon joined in), all saying that he could fire the rifle, even if the target was at arm’s length (1 to 1.5ft away?) Hunting rifle stats: Most full-size, bolt-action hunting rifles weigh more or less eight pounds, are around 41 to 42 inches long and have 22- to 24-inch barrels. This means that with scope, sling and everything hunt-ready, the typical rifle rig weighs-in at around nine pounds. So from above, the rifle needs 3.5 feet ‘clearance’ to fire.

I was telling my friend that because the target was so close, and the rifle was a ‘long arm’, he didn’t have enough ‘space’ to bring it to bare, and point the barrel end at the target (it was in his face’, almost).

Any advice would be most appreciated concerning this above situation.

Does the optimized column order for a PostgreSQL table always have variable length types at the end?

There’s a popular and seemingly authoritative blog post called On Rocks and Sand on how to optimize PostgreSQL tables for size to eliminate internal padding by re-ordering their column length. They explain how variable-length types incur some extra padding if they’re not at the end of the table:

This means we can chain variable length columns all day long without introducing padding except at the right boundary. Consequently, we can deduce that variable length columns introduce no bloat so long as they’re at the end of a column listing.

And at the end of the post, to summarize:

Sort the columns by their type length as defined in pg_type.

There’s a library that integrates with Ruby’s ActiveRecord to automatically re-order columns to reduce padding called pg_column_byte_packer. You can see the README in that repo cites the above blog post and in general does the same thing that the blog post describes.

However, the pg_column_byte_packer does not return results consistent with the blog post it cites. The blog post pulls from from PostgreSQL’s internal pg_type.typelen which puts variable-length columns always at the end via an alignment of -1. pg_column_byte_packer gives them an alignment of 3.

pg_column_byte_packer has an explanatory comment:

    # These types generally have an alignment of 4 (as designated by pg_type     # having a typalign value of 'i', but they're special in that small values     # have an optimized storage layout. Beyond the optimized storage layout, though,     # these small values also are not required to respect the alignment the type     # would otherwise have. Specifically, values with a size of at most 127 bytes     # aren't aligned. That 127 byte cap, however, includes an overhead byte to store     # the length, and so in reality the max is 126 bytes. Interestingly TOASTable     # values are also treated that way, but we don't have a good way of knowing which     # values those will be.     #     # See: `fill_val()` in src/backend/access/common/heaptuple.c (in the conditional     # `else if (att->attlen == -1)` branch.     #     # When no limit modifier has been applied we don't have a good heuristic for     # determining which columns are likely to be long or short, so we currently     # just slot them all after the columns we believe will always be long.

The comment appears to be not wrong as text columns do have a pg_type.typalign of 4 but they’ve also got a pg_type.typlen of -1 which the blog post argues gets the most optimal packing when at the end of the table.

So in the case of a table that has a four byte alignment column, a text column, and a two byte alignment column, pg_column_byte_packer will put the text columns right in between the two. They’ve even got a unit test to assert that this always happens.

My question here is: what order of columns actually packs for minimal space? The comment from pg_column_byte_packer appears to be not wrong as text columns do have a pg_type.typalign of 4, but they’ve also got a pg_type.typlen of -1.

Which is the correct length for a sailing ship, 100 ft. or 80 ft.?

Ghosts of Saltmarsh provides both stat blocks and deck plans for the several kinds of ships listed in the Dungeon Master’s Guide. The stat blocks include, among other things, ship sizes expressed as "X ft. by Y ft." Deck plans, meanwhile, are presented as maps on a standard grid of 5-foot squares.

However, the deck plans don’t all match up with the ship sizes stated in the stat blocks. The sailing ship, in particular, is listed in its stat block as having a size of "100 ft. by 20 ft." But its deck plan clearly shows only 16 squares, or 80 ft., from bow to stern.

It is tempting to try to resolve this discrepancy by supposing that a ship, like a creature, might control a space larger than its actual physical size. (See PHB p. 191.) The typical medium humanoid, after all, isn’t 5 ft. wide; it’s smaller than the space it controls. However, that supposition is undermined by the galley, which is listed as "130 ft. by 20 ft." and yet measures 27 squares, or 135 ft., from bow to stern. It is difficult to imagine how a ship could be larger than the space it controls — and so the whole notion that ship size is about controlled space rather than actual size appears to break down.

What, then, is the actual length of a sailing ship? Is it 100 ft. as its stat block states, or 80 ft. as shown in its deck plan, or something else?

Where do I find the length of the seasons in Rokugan?

Rokugan has a rather large canon lore, and I am a little dumbstruck when trying to sift through all of them for the information I seek about the climate of Rokugan.

In particular, I try to find out when the seasons are changing, and if Rokugan does feature a "rainy season" like Japan, which is kind of an addition to in between Spring and Summer there. For example, the year 2019/20 has the following dates for its seasons in Kyoto Area:

enter image description here

Why limit password length?

This question is inspired by Is there any security risk in not setting a maximum password length?.

Specifically the accepted answer https://security.stackexchange.com/a/238033/9640 says limits are recommended to avoid exhausting the server.

Also it seems to me that if the server is hashing your password to a n digit hash, there is no security advantage to having a password that is longer than n digits. An entity that could reasonable brute force the n digit space, would not have to brute force the (n+1) digit space to brute force your (n+1) digit password. In practical terms, a 1000 digit password is not really more secure than a 500 digit password.

However, what about double hashing the password.

  1. The user enters a password of arbitrary length.
  2. The client hashes the password to a fixed length.
  3. The server can reject the client’s hash if it is not the fixed length (protecting the server from resource exhaustion).
  4. The server otherwise treats the client’s hash as the password and proceeds in the usual manner (it re-hashes it).

In this way, if you want a 10,000 character long password go for it. Your browser will invisibly to you, transform your 10,000 character long password to a 128 character long password (still very secure) and the only change in the server is that now the server knows that all passwords must be exactly 128 characters long so it can reject some logins more easily.

The primary benefit of this scheme is that no user will ever be told "your password is too long". I personally find this message to be disheartening. But I concede that this benefit is not monumental. So if there are any security holes that I am not seeing, this scheme is probably not worth it.

Is there any security risk in not setting a maximum password length?

I’m a listener of the podcast "Security Now" where Steve Gibson, a security expert, often claims that there are no reasons to limit the number of characters a user can use in their passwords when they create an account on a website. I have never understood how it is even technically possible to allow an unlimited number of characters and how it could not be exploited to create a sort of buffer overflow.

I found a related question here, but mine is slightly different. The author of the other question explicitly mentions in their description that they understand why setting a maximum length of 100000000 characters would be a problem. I actually want to know why it would be a problem, is it like I have just said because of buffer overflows? But to be vulnerable to a buffer overflow, shouldn’t you have a sort of boundary which you can’t exceed in the first place, and thus if you didn’t limit the number of characters, would you even have this risk? And if you are thinking about starving a computer’s RAM or resources, could even a very large password be a problem?

So, I guess it is possible not to limit the number of characters in a password: all you’d have to do would be to not use the maxlength attribute or not have a password validation function on the server side. Would that be the secure way to do it? And if it is, is there any danger in allowing an unlimited number of characters for your passwords? On the other hand, NIST recommends developers to limit passwords to 256 characters. If they take the time to recommend a limitation, does it mean there has to be one?