Tag: length

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?

Using slot and application to variable length vector

I have a list of 2D coordinates with a maximum length of 3, e.g.

peakdatAB {{1007.81, 8.64842}, {1008.38, 8.19264}}

I need to generate something like this

({PointSize[0.01], Blue, Point[#1], Red, Point[#2], Black, Point[#3]}) & @@ peakdatAB

but here the problem is the variable length of peakdatAB as when there is say no third point, it returns an error. How can I fix this?

Algorithm- Find the length of largest subarray having sum greater than k

I tried to solve this problem but could not do it better than O(n^2).

My Algorithm: 1.calculate prefixsum 2.for i 1...n   for j 1...i  if(presum[i]-presum[j-1]>k)   ans=max(ans,i-j);

However, this is inefficient for large values of n.Can someone help me with optimized algorithm along with code preferably in c++.