Pour les colonnes de type texte, Il suffit d'avoir le COLLATE basé une locale qui s'appelle pareil mais qui ne trie pas pareil entre le primaire et le secondaire. C'est pourquoi le primaire et le secondaire devraient avoir exactement le même OS dans la même version.

Sur linux il y a une MAJ majeure récente de la libc qui a accru le risque ces derniers temps, cf https://blog-postgresql.verite.pro/2018 … grade.html
quand on ne réindexe pas suite à un upgrade, ou quand le couple (primaire,secondaire) a des versions décalées de la libc.

Il faudrait reposter l'URL car ça ne doit pas être la même, c'est  versionné.

Hmm. Le tri par le tableau n'est pas fait pour trier mais pour générer un nouveau rang (dense_rank()) dès que la valeur change dans la même partition. On ne peut pas changer ce tri sans que ça invalide complètement l'idée qui fonde cette requête.

Mais on doit pouvoir influer dans le sens voulu en triant par date la sous-requête "liste", autrement dit:

select liste.*, dense_rank() over (partition by numero order by tableau)
from (select numero,date, array_agg( array[debut,fin] order by debut) as tableau
          from NomDeTable group by numero,date ORDER BY date) AS liste
order by numero, date;

Donc le triplet c'est 3 lignes, et ça c'est compliqué du point de vue relationnel, qui ne gère pas de relations inter-lignes en-dehors des contraintes d'unicité.
Pour pouvoir dire qu'un groupe de 3 lignes est égal ou pas à une autre groupe de 3 lignes, et ça sur toute la longueur de la table, typiquement il faudrait les aggréger pour qu'un triplet devienne une seule ligne.

Le s donne un nom à la sous-requête; effectivement c'est obligatoire syntaxiquement.
On peut aussi ajouter le mot clef AS pour que ce soit plus lisible, du style:

select .. from ( ...sous-requête...)  AS nom1, (... autre sous-requête...) AS nom2

Rassembler se fait généralement avec GROUP BY. En numérotant les lignes dans un certain ordre on peut grouper sur ce numéro.

Voici un exemple très schématique pour être concret:

1. soit jeu de test avec un timestamp et une valeur

CREATE TEMP TABLE test AS
select
(now()+n*'1 second'::interval)::timestamp(0) as t,
random()*1000 as v
from generate_series(1,10) as n;

select * from test;

          t          |        v         
---------------------+------------------
2020-05-06 13:51:59 | 82.4452051892877
2020-05-06 13:52:00 | 339.041672646999
2020-05-06 13:52:01 | 824.749575462192
2020-05-06 13:52:02 | 717.561565339565
2020-05-06 13:52:03 | 764.736431185156
2020-05-06 13:52:04 | 604.845985304564
2020-05-06 13:52:05 | 82.1709437295794
2020-05-06 13:52:06 | 402.444486506283
2020-05-06 13:52:07 | 747.045868076384
2020-05-06 13:52:08 | 624.612233601511

2. numérote les lignes en partant de 0 dans l'ordre des timestamps. C'est la partie fenêtrage:

select row_number() over(order by t)-1 as rn, t, v from test;

rn |          t          |        v         
----+---------------------+------------------
  0 | 2020-05-06 13:51:59 | 82.4452051892877
  1 | 2020-05-06 13:52:00 | 339.041672646999
  2 | 2020-05-06 13:52:01 | 824.749575462192
  3 | 2020-05-06 13:52:02 | 717.561565339565
  4 | 2020-05-06 13:52:03 | 764.736431185156
  5 | 2020-05-06 13:52:04 | 604.845985304564
  6 | 2020-05-06 13:52:05 | 82.1709437295794
  7 | 2020-05-06 13:52:06 | 402.444486506283
  8 | 2020-05-06 13:52:07 | 747.045868076384
  9 | 2020-05-06 13:52:08 | 624.612233601511

3. regroupe par bloc de 3 lignes consécutives avec la moyenne des valeurs. C'est la partie group by par-dessus le fenêtrage:

select rn/3 as bloc ,avg(v) from (
select row_number() over(order by t)-1 as rn, t, v from test
) s group by rn/3 order by rn/3;

bloc |       avg       
------+------------------
    0 | 415.412151099493
    1 | 695.714660609762
    2 | 410.553766104082
    3 | 624.612233601511

Si  lsof -i TCP:5432 ne renvoie rien alors que que le port est en écoute, c'est peut-être un problème de droits.
Je n'ai pas de mac sous la main pour tester, mais sous linux c'est le cas.
Exécuter la commande avec sudo donnerait peut-être un résultat plus fiable.

D'après le résultat de ps il y a bien un postgres qui tourne et vous pouvez vraisemblablement vous connecter avec l'exécutable /Library/PostgreSQL/12/bin/psql

Le résultat voulu est un idlocal dans la colonne de gauche, sans répétition d'une ligne à l'autre, et sur chaque ligne  à droite de idlocal 6 colonnes avec les propriétaires correspondants.
Pour ça il faut grouper uniquement par idlocal et utiliser une fonction d'aggrégat pour générer les résultats des 6 colonnes.

C'est ça qui n'est pas intuitivement évident dans les requêtes qui font des tableaux croisés. Bien que logiquement il y ait un seul "ddenom" possible pour un couple (idlocal, ntile) donné, le moteur SQL n'en sait rien. La solution est d'utiliser un aggrégat comme MAX(ddenom). Le max d'une liste d'une seule valeur étant cette valeur, ça convient très bien.

Dans l'idée ce modèle de requête doit marcher (voir la version éditée avec FILTER)

SELECT
  idlocal,
  max(ddenom) FILTER (where ntile = 1) "Nom proprietaire 1",
  max(ddenom) FILTER (where ntile = 2) "Nom proprietaire 2",
... etc pour les autres valeurs...
FROM analyse_complete_test
GROUP BY idlocal;

Il y a 5 colonnes dans cette requête. Autant il est facile d'avoir 0 pour un count(*) quand il n'y a pas de ligne qui correspond (en fait c'est même le comportement de base), autant dans les 4 autres colonnes quelles seraient les valeurs attendues?

N'oubliez pas qu'une vue ou une requête donnée a une seule structure et généralement répond à une seule question.

Comme la doc le dit ici:

https://docs.postgresql.fr/12/datatype. … ype-serial

SERIAL n'est pas un vrai type de données, le type correspondant  est integer (ou int4 ou int c'est pareil).

Ce qui est important à conserver c'est la clause DEFAULT. C'est elle qui fait le lien avec la séquence créée automatiquement quand on utilise SERIAL.

Au passage psql n'affiche pas serial mais int comme type de colonne:

test=> create table public.test(id serial);
CREATE TABLE
test=> \d public.test
                               Table « public.test »
 Colonne |  Type   | Collationnement | NULL-able |            Par défaut            
---------+---------+-----------------+-----------+----------------------------------
 id      | integer |                 | not null  | nextval('test_id_seq'::regclass)

L'outil que vous utilisez affiche SERIAL probablement en comparant le nom de la séquence avec le nom de la colonne, c'est pourquoi en changeant le nom de la colonne sans changer le nom de la séquence il arrête d'afficher SERIAL.

Avec cette erreur il y a normalement un contexte qui donne le numéro de ligne. Il faudrait regarder la ligne en question.
La raison la plus probable est qu'il y a une occurence du séparateur a l'intérieur d'un champ, que ce champ n'est pas encadré entre guillemets , et que du coup il est compté pour deux champs.
Idéalement il faut produire du vrai CSV, car cette situation n'est pas possible dans un CSV valide quand les règles d'encadrement par guillemets sont respectées, comme décrit dans https://tools.ietf.org/html/rfc4180

Ce que je voulais dire par un changement c'est plutôt de savoir si pendant que cet UPDATE met à jour is_dequeued il peut y avoir une autre transaction qui chercher à changer le id_queue de la même ligne.

Mais si l'exécuteur utilise l'index unique sur id pour faire l'update et que cet index est corrompu ça pourrait expliquer pourquoi il peut trouver plusieurs lignes correspondant à un même id, c'est pourquoi je pense qu'il faudrait vérifier ça.