And while some of the fixes seem to extend the time between occurrences (particularly increasing shared buffer memory), none have proven a permanent fix.
PSEQUEL M1 FULL
pg_restore appears to have flagged this issue where pg_dump didn't, writing a clean DB sans the faulty index.Ĭontinued to experience this issue after attempting several workarounds, including a full pg_dump and restore of the affected database. As such, my final suggestion on this issue is to perform pg_dump, then use pg_restore, not pg_dump to restore the database. My hunch is that corruption or another issue with this index was causing the Bad Address errors. Here's the interesting bit: pg_restore failed to restore one of the indexes in the database, and noted it during the restore process (which otherwise completed). Ended up reinstalling a fresh Apple Silicon version of Postgres using Homebrew then doing a pg_dump of my existing database (experiencing the errors) and restoring it to the new installation/cluster. adjustments extended the time between errors, but didn't eliminate it completely.
PSEQUEL M1 PRO
Thanks!ĮDIT: I was able to reproduce the same issue on an older MacBook Pro (also running Big Sur), so it seems unrelated to M1 but potentially related to Big Sur. Has anyone else experienced this? Any solution ideas would be much appreciated. Pg_restore: from TOC entry 277 1259 16955 TABLE u1oi0d2o8cha8f Pg_restore: error: could not execute query: ERROR: table "" does not existĬommand was: DROP TABLE "public"."" I believe it's at the root of the issue, but I'm not sure what the solution would be: pg_restore: dropping TABLE
PSEQUEL M1 DOWNLOAD
When I run development restore production, I get hundreds of lines in my terminal that look like the output below (this is immediately after the download completes but before it goes on to create defaults, process data, sequence sets, etc.).
I'm using thoughtbot parity to sync up my dev environment database with what's currently in production. (I've also run the Disk Utility FirstAid check multiple times it says everything's healthy, but I have no idea how reliable that is.) I've encountered a couple other people on random message boards who are experiencing the same issue (also on new Macs) and not having any luck, which is why I'm reluctant to believe that it's a drive corruption issue. I'm aware of all the configuration challenges related to ARM-based M1 Macs, which is why I've uninstalled and reinstalled everything from Homebrew to Postgres multiple times in numerous ways (with Rosetta, without Rosetta, using arch -x86_64 brew commands, using the Postgres app instead of the Homebrew install). The strange thing is that I can often refresh the browser repeatedly in order to get things to work (until they inevitably don't again). Whether I use a Rails server or Foreman, I receive errors in both my browser and terminal like PG::InternalError: ERROR: could not read block 15 in file "base/147456/148555": Bad address or PG::Error (invalid encoding name: unicode) or Error during failsafe response: PG::UnableToSend: no connection to the server.
Ever since I got a new ARM-based M1 MacBook Pro, I've been experiencing severe and consistent PostgreSQL issues (psql 13.1).
0 kommentar(er)
