I cannot at the moment but from my explanation do you have any idea of what might be happening?

Downgraded to 28.3 and still the same

The problem is in the export I think

Because the file is smaller than the data in the db

I have attached on a thread below a relevant portion of the log of the postgres instance when the import fails

But what you explain is to a generic postgres instance, or are you actually referring to prisma?

Are you running prisma from the cloud in isolation, only attached to the postgres? Or does it have a phpadmin interface? The prisma one is pretty nice, but not without flaw. But it's somewhere in the command chain thats causing the error to get stacked, either it's due to a wierd one off, that's causing alphabetical dump and import, or its something in the command that's not leveraging the native dump commands effectively for postgres. Unless you have shard failure, or something extreme impacting your assembly, like all out replication failure

but since your getting some dump, I would assume it's either some constraint thats hanging at your key error because its hitting that fairly early on in the dump, or its another process taking over the PGDUMP and injecting sql dump binary into the process, causing the key error.

those were most commonly what I saw in working with postgres anyways.

but if you isolate one from the other, it's easier to generate a work around. If it's the two schema indexs being exported on top of each other, you know its a naming issue and you need to get a template that can dictate the export order. If it's the SQL code injection, you need to more than likely, dump the DB directly, with the Postgres CLI or track down the sequencing used for the index dump from the command and ensure no SQL commands are leaking in. That last one can be a bit harder, since they are related, I always ended up dumping by hand so to speak, because API's are mostly homegrown and it can be hard to disentangle what's causing the mixin and why it's not agreeing with your index/schema

I'm sorry if that's not terribly helpful. I had hoped you had graphql as a "front end" on it, and we could just get a json dump from it, from the client, or use the prisma cli on the ql, to dump to console

For now I've found that the server mentions a JDBCDriver exception "Cannot connect to postgres"

But it's wierd because the server is actually returning data properly via graphql queries

WARNING: IOException occurred while connecting to postgres:5432 java.net.UnknownHostException: postgres

version: '3' services: prisma: image: prismagraphql/prisma:1.29 restart: always ports: - "4466:4466" environment: PRISMA_CONFIG: | port: 4466 databases: default: connector: postgres host: postgres port: 5432 user: prisma password: prisma migrations: true postgres: image: postgres:10.5 restart: always environment: POSTGRES_USER: prisma POSTGRES_PASSWORD: prisma volumes: - postgres:/var/lib/postgresql/data-old volumes: postgres:

I think I found something

postgres_1 | 2019-03-01 151228.639 UTC [30] LOG: could not write temporary statistics file "pg_stat_tmp/db_16384.tmp": No space left on device postgres_1 | 2019-03-01 151228.639 UTC [30] LOG: could not close temporary statistics file "pg_stat_tmp/db_0.tmp": No space left on device postgres_1 | 2019-03-01 151228.639 UTC [30] LOG: could not close temporary statistics file "pg_stat_tmp/global.tmp": No space left on device postgres_1 | 2019-03-01 151239.656 UTC [1612] LOG: using stale statistics instead of current ones because stats collector is not responding

No space left on device -> What?

There is clearly space

docker@default:~$ sudo df -h Filesystem Size Used Available Use% Mounted on tmpfs 7.0G 224.0M 6.8G 3% / tmpfs 3.9G 0 3.9G 0% /dev/shm /dev/sda1 17.8G 7.1G 9.8G 42% /mnt/sda1 cgroup 3.9G 0 3.9G 0% /sys/fs/cgroup /c/Users 938.7G 165.5G 773.2G 18% /c/Users /dev/sda1 17.8G 7.1G 9.8G 42% /mnt/sda1/var/lib/docker overlay 17.8G 7.1G 9.8G 42% /mnt/sda1/var/lib/docker/overlay2/e8c242359164bafbe466edba069136dcc6228d4e832c13b334906b3caca9299c/merged overlay 17.8G 7.1G 9.8G 42% /mnt/sda1/var/lib/docker/overlay2/5497fa0a864220dfa828c3c841049e479e28cd5cc2a7471330e68978efab1e41/merged shm 64.0M 0 64.0M 0% /mnt/sda1/var/lib/docker/containers/04e1f6f5351d9b355b46734149895604b0ba27d0d59cf38be7d87988c1bad601/mounts/shm shm 64.0M 8.0K 64.0M 0% /mnt/sda1/var/lib/docker/containers/075634145ea95ceebff73e5c5ae2668aeef8b5eed30848fb4a88eaafa9c886d2/mounts/shm overlay 17.8G 7.1G 9.8G 42% /mnt/sda1/var/lib/docker/overlay2/779830ffd755e55b7856683518b9137cadc6a5037716753dc13592bf9a5eaeee/merged shm 64.0M 0 64.0M 0% /mnt/sda1/var/lib/docker/containers/b7241a3805a94bf122fd5fd99b2a57a8a81884e5d70fd8689d4118c6b82dc4bc/mounts/shm overlay 17.8G 7.1G 9.8G 42% /mnt/sda1/var/lib/docker/overlay2/5bf63d42ae7033b5be6b1d9e18b855fa26eb9e26417d05faa0b042f72110668b/merged shm 64.0M 0 64.0M 0% /mnt/sda1/var/lib/docker/containers/e65e856d4a2e463ab4119821d5793e8eed7da63ca221b246b3e850b9e0da8fc5/mounts/shm overlay 17.8G 7.1G 9.8G 42% /mnt/sda1/var/lib/docker/overlay2/179e307dff4b0aa990d0e6d3d062171e662ce0f63458d20d7a8be62c75bbf022/merged overlay 17.8G 7.1G 9.8G 42% /mnt/sda1/var/lib/docker/overlay2/55a1feee761f69059f122b5569ec518ffdb7dcbfa25ac6d3416994494619e7c9/merged shm 64.0M 0 64.0M 0% /mnt/sda1/var/lib/docker/containers/e50f6433c2ffc4a13fc7e64191dc115be74c1c55f526e3417ff3c58930f5bf13/mounts/shm shm 64.0M 0 64.0M 0% /mnt/sda1/var/lib/docker/containers/42ccc2eed036e538f4495683892a6a083df6a22ba1d78e27fe701ea10c3af36b/mounts/shm

Yes the problem was "space related"

How could I increase this limit on the server?

I have a lot more space available

I think we found some potentially recurring issue that could go into the FAQ/Docs here

I was using the same exact prisma instance that operated on the same postgres instance. The apparent reason it was not working is because the docker volume that contained the postgres data was full / not allowed to grow by docker. I fixed it by cleaning unused images and volumes. Maybe a guide on how to configure the docker volume appropriately to store arbitrary amounts of data would be helpful.

If you need more info I am happy to provide it 🙂

Heads up!! I may have found a key insight into this. The space being full probably didn't help but it probably wasn't the cause

I think prisma takes IDs as being unique within the entire instance

So Iwas trying to import the same dataset to the same intance in multiple namespaces at the same time

I'll make more tests and confirm that

Okay that was not the case

But what does the state.json file mean? I've discovered I can import an uncompressed folder and found that this file gets edited by the prisma import command

Which is very counterintuitive since the same data may be reused so why edit anything inside it? If it's some state realted to the import process... then no wonder why it doesn't work the next time you try to import

If I manually put those values at 0 it works once and imports correctly the data. But it still outputs a bunch of already exists errors (probably harmless because if it's already there that means at least the data got inserted)

I know software is hard, don't take it badly 🙂

It's to provide the information to catch and fix those bugs

I'm on 1.29, I don't know if you have maybe addressed it on 1.31-alpha

Maybe the client forgets to remove the .import after importing a zip?