psql คำสั่งไม่ถูกต้อง \ N ขณะเรียกคืน sql


146

ฉันพยายามกู้คืนไฟล์ดัมพ์ แต่เกิดข้อผิดพลาด:

psql:psit.sql:27485: invalid command \N

มีวิธีแก้ไขไหม ฉันค้นหา แต่ไม่ได้รับคำตอบที่ชัดเจน

คำตอบ:


209

Postgres ใช้ "\ N" เป็นสัญลักษณ์แทนค่า NULL แต่คำสั่ง psql ทั้งหมดเริ่มต้นด้วยเครื่องหมายแบ็กสแลช "" คุณจะได้รับข้อความเหล่านี้เมื่อคำสั่งคัดลอกล้มเหลว แต่การโหลดดัมพ์ยังคงดำเนินต่อไป ข้อความนี้เป็นการเตือนที่ผิดพลาด คุณต้องค้นหาทุกบรรทัดก่อนเกิดข้อผิดพลาดนี้หากคุณต้องการดูสาเหตุที่แท้จริงว่าทำไมคำสั่ง COPY จึงล้มเหลว

เป็นไปได้ที่จะเปลี่ยน psql เป็นโหมด "stop on first error" และค้นหาข้อผิดพลาด:

psql -v ON_ERROR_STOP=1

7
ใช่ข้อผิดพลาดที่ง่ายมากที่จะทำเนื่องจากจำนวนข้อผิดพลาดของคำสั่งที่ไม่ถูกต้องเหล่านี้อาจมีขนาดใหญ่มากจนบดบังข้อผิดพลาดแรกที่เกิดขึ้นในช่วงต้น
crowmagnumb

6
มันค่อนข้างชั่วร้ายจาก PostgreSQL ที่ให้คำเตือนที่ทำให้เข้าใจผิดคำตอบของคุณช่วยฉันได้มาก!
Tregoreg

52
@Tregoreg - ใช่มันไม่เป็นมิตร - คุณสามารถเรียกใช้ psql ในโหมด "stop on first error" ทำให้การวินิจฉัยง่ายขึ้น "psql -v ON_ERROR_STOP = 1"
Pavel Stehule

2
สามารถเกิดขึ้นได้เมื่อเช่นcreate table...ล้มเหลวในการเริ่มต้น แต่การโหลดยังคงดำเนินต่อไป
JaakL

1
ฉันมาที่นี่เพราะข้อผิดพลาดเดียวกัน สิ่งที่คิดได้คือต้องทำ: (pg_restore ... | psql ...) 2>&1 | less
THK

36

ฉันได้รับข้อความแสดงข้อผิดพลาดเดียวกันเมื่อพยายามกู้คืนจาก pg_dump ไบนารี ฉันใช้pg_restoreเพื่อกู้คืนการถ่ายโอนข้อมูลของฉันและหลีกเลี่ยง\Nข้อผิดพลาดอย่างสมบูรณ์เช่น

pg_restore -c -F t -f your.backup.tar

คำอธิบายของสวิตช์:

-f, --file=FILENAME      output file name
-F, --format=c|d|t       backup file format (should be automatic)
-c, --clean              clean (drop) database objects before recreating

การใช้งาน cpu ที่ต่ำกว่ามากด้วยใช่หรือไม่?
catbadger

16

ฉันรู้ว่านี่เป็นโพสต์เก่า แต่ฉันเจอวิธีแก้ปัญหาอื่น: postgis ไม่ได้ติดตั้งในเวอร์ชันใหม่ของฉันซึ่งทำให้ฉันเกิดข้อผิดพลาดเดียวกันใน pg_dump


1
ช่างช่วยชีวิต!
matmat

8

ฉันเคยพบข้อผิดพลาดนี้ในอดีตเช่นกัน Pavel ถูกต้องโดยปกติจะเป็นสัญญาณว่ามีบางอย่างในสคริปต์ที่สร้างโดย pg_restore ล้มเหลว เนื่องจากข้อผิดพลาด "/ N" ทั้งหมดคุณจึงไม่เห็นปัญหาที่แท้จริงที่ด้านบนสุดของผลลัพธ์ ฉันแนะนำ:

  1. การแทรกตารางเล็ก ๆ ตัวเดียว (เช่นpg_restore --table=orders full_database.dump > orders.dump)
  2. หากคุณไม่มีบันทึกขนาดเล็กให้ลบระเบียนจำนวนมากออกจากสคริปต์การคืนค่า - ฉันเพิ่งตรวจสอบให้แน่ใจว่า. / เป็นแถวสุดท้ายที่จะโหลด (เช่นเปิดorders.dumpและลบระเบียนจำนวนมาก)
  3. ดูเอาต์พุตมาตรฐานและเมื่อคุณพบปัญหาคุณสามารถวางตารางและโหลดใหม่ได้ตลอดเวลา

ในกรณีของฉันฉันยังไม่ได้ติดตั้งส่วนขยาย "hstore" ดังนั้นสคริปต์จึงล้มเหลวที่ด้านบนสุด ฉันติดตั้ง hstore บนฐานข้อมูลปลายทางและฉันกลับมาทำธุรกิจ


"ฉันยังไม่ได้ติดตั้งส่วนขยาย" hstore "" TNX
iRhonin

7

คุณสามารถสร้างดัมพ์ของคุณโดยใช้คำสั่ง INSERTS โดยใช้พารามิเตอร์ --inserts


2
สิ่งนี้ใช้ได้กับฉัน! pg_dump - แทรก $ DATABASE> $ FILENAME
Abel


4

สิ่งเดียวกันเกิดขึ้นกับฉันในวันนี้ ฉันจัดการปัญหาโดยการถ่ายโอนข้อมูลด้วยคำสั่ง --inserts

สิ่งที่ฉันทำคือ:

1) pg_dump พร้อมเม็ดมีด:

pg_dump dbname --username=usernamehere --password --no-owner --no-privileges --data-only --inserts -t 'schema."Table"' > filename.sql

2) psql (กู้คืนไฟล์ที่ทิ้งของคุณ)

psql "dbname=dbnamehere options=--search_path=schemaname" --host hostnamehere --username=usernamehere -f filename.sql >& outputfile.txt

หมายเหตุ -1) ตรวจสอบให้แน่ใจว่าการเพิ่มไฟล์เอาต์พุตจะเพิ่มความเร็วในการนำเข้า

หมายเหตุ -2) อย่าลืมสร้างตารางที่มีชื่อและคอลัมน์เดียวกันก่อนนำเข้าด้วย psql


2

จากประสบการณ์ล่าสุดของฉันเป็นไปได้ที่จะได้รับข้อผิดพลาดนี้เมื่อปัญหาจริงไม่เกี่ยวข้องกับอักขระหลีกหรือขึ้นบรรทัดใหม่ ในกรณีของฉันฉันได้สร้างดัมพ์จากฐานข้อมูล A ด้วย
pg_dump -a -t table_name > dump.sql
และพยายามกู้คืนไปยังฐานข้อมูล B ด้วย
psql < dump.sql(หลังจากอัปเดต env vars ที่เหมาะสมแน่นอน)
สิ่งที่ฉันพบในที่สุดก็คือการถ่ายโอนข้อมูลแม้ว่าจะเป็นdata-only( -aตัวเลือก เพื่อไม่ให้โครงสร้างตารางเป็นส่วนหนึ่งของการถ่ายโอนข้อมูลอย่างชัดเจน) เป็นสคีมาโดยเฉพาะ นั่นหมายความว่าหากไม่มีการแก้ไขดัมพ์ด้วยตนเองฉันไม่สามารถใช้ดัมพ์ที่สร้างจากschema1.table_nameเพื่อเติมข้อมูลschema2.table_nameได้ การแก้ไขดัมพ์ด้วยตนเองทำได้ง่ายสคีมาถูกระบุไว้ใน 15 บรรทัดแรกหรือมากกว่านั้น



0

สำหรับฉันที่ใช้ postgreSQL 10 บน SUSE 12 ฉันแก้ไขinvalid command \Nข้อผิดพลาดโดยการเพิ่มเนื้อที่ดิสก์ การไม่มีพื้นที่ว่างบนดิสก์ทำให้เกิดข้อผิดพลาดสำหรับฉัน คุณสามารถบอกได้ว่าคุณใช้พื้นที่ดิสก์ไม่เพียงพอหรือไม่หากคุณดูที่ระบบไฟล์ข้อมูลของคุณจะอยู่ในdf -hเอาต์พุต หากใช้ระบบไฟล์ / เมาท์ 100% หลังจากทำสิ่งต่างๆเช่นpsql -f db.out postgres(ดูhttps://www.postgresql.org/docs/current/static/app-pg-dumpall.html ) คุณอาจต้องเพิ่มเนื้อที่ดิสก์ที่มี .


0

ฉันมีปัญหาเดียวกันฉันสร้างฐานข้อมูลใหม่และได้รับการinvalid command \Nกู้คืนด้วย psql ฉันแก้ไขโดยการตั้งค่าพื้นที่ตารางเดียวกันกับฐานข้อมูลเก่า

ตัวอย่างเช่นการสำรองฐานข้อมูลเก่ามีพื้นที่ตาราง "pg_default" ฉันกำหนดพื้นที่ตารางเดียวกันให้กับฐานข้อมูลใหม่และข้อผิดพลาดข้างต้นหายไปแล้ว!


0

ฉันทำตามตัวอย่างทั้งหมดนี้และทั้งหมดล้มเหลวด้วยข้อผิดพลาดที่เรากำลังพูดถึง:

คัดลอกตารางจากฐานข้อมูลหนึ่งไปยังอีกฐานข้อมูลใน Postgres

สิ่งที่ได้ผลคือไวยากรณ์กับ-Cดูที่นี่:

pg_dump -C -t tableName "postgres://$User:$Password@$Host:$Port/$DBName" | psql "postgres://$User:$Password@$Host:$Port/$DBName"

นอกจากนี้หากมี Schema ที่แตกต่างกันระหว่างทั้งสองฉันพบว่าการปรับเปลี่ยน schema ของ dB หนึ่งรายการให้ตรงกับที่อื่นเป็นสิ่งจำเป็นเพื่อให้สำเนา Table ทำงานได้เช่น:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;

0

ทางออกของฉันคือ:

psql -U your_user your_db < your.file.here.sql  2>&1|more

ด้วยวิธีนี้ฉันสามารถอ่านข้อความแสดงข้อผิดพลาด

ฉันหวังว่านี่จะช่วยทุกคน

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.