Status: Works for me

PostgreSQL is indeed case-insensitive by default.

Are you using a custom UserProvider of sorts? Because there is no UserProviderInterface for PDO/PostgreSQL provided by default. If so, you need to update your query, if you are using Doctrine ORM make sure to use `lastUsed` in name option of the column, so Doctrine quotes it using the correct platform.

I tried to use custom user provider, but using in-memory at the moment. And indeed reverted that line back and it still works properly. Maybe something was wrong in custom user provider. I'll give it another try with custom user provider soon.
Thanks

Aaaand gotcha!
It works fine in prod environment, but just now I tried to access my dev environment with rememberme cookie and it fails now. Opening another tab with the same cookie, but accessing prod environment goes just fine! Trying dev environment again - it fails.
The error is

 Notice: Undefined index: lastUsed
 500 Internal Server Error - ContextErrorException 

in vendor/symfony/symfony/src/Symfony/Bridge/Doctrine/Security/RememberMe/DoctrineTokenProvider.php at line 71  -
at DoctrineTokenProvider ->loadTokenBySeries ('***')
in vendor/symfony/symfony/src/Symfony/Component/Security/Http/RememberMe/PersistentTokenBasedRememberMeServices.php at line 71  +
at PersistentTokenBasedRememberMeServices ->processAutoLoginCookie (array('***', '***'), object(Request))
in vendor/symfony/symfony/src/Symfony/Component/Security/Http/RememberMe/AbstractRememberMeServices.php at line 119  +
at AbstractRememberMeServices ->autoLogin (object(Request))
in vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/RememberMeListener.php at line 75  +
at RememberMeListener ->handle (object(GetResponseEvent))
in var/cache/dev/classes.php at line 5211  +

As I've mentioned earlier I'm still using in-memory provider.
Clearing symfony cache didn't help.

That happens with the column in question being all-lower-case.

Should it be modified to be exactly "lastUsed" in the database, another error shows up:

An exception occurred while executing 'SELECT class, username, value, lastUsed FROM rememberme_token WHERE series=?' with params ["***"]:

SQLSTATE[42703]: Undefined column: 7 ERROR: column "lastused" does not exist
LINE 1: SELECT class, username, value, lastUsed FROM rememberme_toke...
^
500 Internal Server Error - InvalidFieldNameException
2 linked Exceptions:

    PDOException » PDOException » 

Also, now that the column is exactly "lastUsed" it is now broken for prod environment as well.

Reverting the column in the database back to all-lower-case fixes it for prod environment, but not for the dev environment, which is still broken with aforementioned "Notice: Undefined index: lastUsed" message.

Now another experiment.
Clear cookies and login via dev environment - all is fine. Until I open prod environment with the same cookies. After that accessing dev environment fails with "Notice: Undefined index: lastUsed" message.

What is wrong here?

Looks like
$sql = 'SELECT class, username, value, lastUsed'
is inconsistent with
return new PersistentToken($row['class'], $row['username'], $series, $row['value'], new \DateTime($row['lastUsed']));

@PF4Public could you please fork the standard edition and reproduce this issue on a new branch with a minimum amount of code? I'd be happy to look into this, but first need a reproducible scenario.

@jakzal Please inspect my fork here: https://github.com/PF4Public/symfony-standard
You can see my minimal project there. I didn't commit "vendors" tree as well as I didn't bother to remove unused "use" statements. There you can find sql file for postgres database table. Note that the field in question created as "lastUsed".
After navigating to / location it properly redirects to /login location. Which presents login page. However entering proper credentials (according to security.yml) fails with

InvalidFieldNameException: An exception occurred while executing 'INSERT INTO rememberme_token (class, username, series, value, lastUsed) VALUES (?, ?, ?, ?, ?)' with params ["Symfony\Component\Security\Core\User\User", "test", ....

SQLSTATE[42703]: Undefined column: 7 ERROR: column "lastused" of relation "rememberme_token" does not exist
LINE 1: ...rememberme_token (class, username, series, value, lastUsed) ...

So I still suppose that all sql statements do not adequately quote the "lastUsed" field. Which is partially solved if replacing lastUsed with lastused in table, but still stumbles on $row['lastUsed'] which expects it to be camel-cased.

This looks really weird (as you can see in the exception message the statement does not use lastusedbut indeedlastUsed`).

It does not look weird to me.
Postgresql will interpret the line INSERT INTO rememberme_token (class, username, series, value, lastUsed) as INSERT INTO rememberme_token (class, username, series, value, lastused) unless some further function call arranges quotes for lastUsed, but this never happened, thus the exception.

@PF4Public Would you be interested in working on a patch for this issue?

As I've already mentioned, replacing 'lastUsed' with 'lastused' with all-lowercase fields in database makes it work for me.

It looks like the key issue here is the difference between how MySQL and PostgreSQL treat unquoted strings in field names in SQL queries. Therefore statements from doctrine-bridge / Security / RememberMe / DoctrineTokenProvider.php work differently for different databases.
So to fix this there are two approaches IMHO:

1. rewrite DoctrineTokenProvider.php to use lowercase field names only
2. ensure proper quoting on a higher level in database abstraction

As for the 1 point - it is relatively easily done, and I believe will not interfere with any other Symfony code.
Point 2 however is the proper way of fixing this IMHO, but it requires a better knowledge of Symfony code and I'm afraid I cannot help with it for I'm not familiar enough with Symfony internals.

It looks like the key issue here is the difference between how MySQL and PostgreSQL treat unquoted strings in field names in SQL queries.

Like I said "PostgreSQL is indeed case-insensitive by default.", when you quote the field/table name it's used as intended (the casing is preserved) otherwise it's lowercase. This is conform the SQL99 standard btw 👍

The SQL:2008 and SQL-99 standards define databases to be case insensitive for identifiers unless they are quoted. Lower case characters may be used in identifiers and keywords, but are considered to be their upper case counterparts.

MySQL can actually work bit a funky here when your on a Case sensitive filesystem and using MyISAM, because the table structure is stored in a single file which equals the table name. So the table does exist despite the casing difference 😅

I think we can safely change lastUsed to lowercase, or otherwise use something like isset($row['lastUsed']) ? $row['lastUsed'] : $row['lastused']?