psql, sql'yi geri yüklerken \ N geçersiz komutu


137

Döküm dosyamı geri yüklemeye çalışıyorum ama bir hataya neden oldu:

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

Bir çözüm var mı? Aradım ama net bir cevap alamadım.

Yanıtlar:


198

Postgres, NULL değeri yerine "\ N" kullanır. Ancak tüm psql komutları ters eğik çizgi "\" simgesiyle başlar. Böylece, muhtemelen copy deyimi başarısız olduğunda, ancak bir döküm yükleme devam ettiğinde bu mesajları alabilirsiniz. Bu mesaj yalnızca yanlış alarmdır. COPY deyiminin başarısız olmasının nedeni için önce bir satır aramanız gerekir.

Psql'yi "ilk hatada dur" moduna geçirmek ve hatayı bulmak mümkündür:

psql -v ON_ERROR_STOP=1

7
Evet, bu geçersiz komut hatalarının sayısı son derece büyük olduğundan, ilk hatanın erken isabetini tamamen gizleyebildiğinden, yapılması çok, çok kolay bir hata.
crowmagnumb

5
PostgreSQL'den bu kadar yanıltıcı bir uyarı vermek oldukça kötü, cevabınız bana çok zaman kazandırdı!
Tregoreg

50
@Tregoreg - evet, kolay değil - psql'yi "ilk hatada dur" modunda çalıştırabilirsiniz. Teşhisi basitleştirir "psql -v ON_ERROR_STOP = 1"
Pavel Stehule

2
Örneğin create table...başlangıçta başarısız olduğunda , ancak yükleme devam ettiğinde olabilir .
JaakL

1
Buraya aynı hatadan dolayı geldim. Anladığım şey şuydu: (pg_restore ... | psql ...) 2>&1 | less
THK

33

İkili bir dökümden geri yüklemeye çalışırken aynı hata mesajını alıyorum. Eskiden pg_restoredökümümü geri yüklerdim ve \Nhatalardan tamamen kaçınırdım, örn.

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

Anahtarların açıklaması:

-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


ayrıca çok daha düşük cpu kullanımı, değil mi?
catbadger

15

Bunun eski bir gönderi olduğunu biliyorum ama başka bir çözümle karşılaştım: postgis yeni sürümüme yüklenmedi, bu da pg_dump'ta aynı hataya neden oldu


1
Ne cankurtaran!
matmat

8

Bu hatayla geçmişte de karşılaştım. Pavel haklı, bu genellikle pg_restore tarafından oluşturulan komut dosyasındaki bir şeyin başarısız olduğunun bir işaretidir. Tüm "/ N" hatalarından dolayı, çıktının en üstünde gerçek sorunu görmüyorsunuz. Öneririm:

  1. tek, küçük bir tablo eklemek (ör. pg_restore --table=orders full_database.dump > orders.dump)
  2. küçük bir tane yoksa, geri yükleme betiğinden bir grup kaydı silin - sadece yüklenecek son satırın ./ olduğundan emin oldum (ör. orders.dump bir grup kaydı ve silin)
  3. standart çıktıyı izleyin ve sorunu bulduğunuzda, her zaman tabloyu bırakıp yeniden yükleyebilirsiniz.

Benim durumumda, "hstore" eklentisini henüz kurmadım, bu yüzden komut dosyası en üstte başarısız oluyordu. Hedef veritabanına hstore'u kurdum ve işime geri döndüm.


"Henüz" hstore "uzantısını yüklemedim", TNX.
Arash Fatahzade

7

Dökümünüzü --inserts parametresiyle INSERTS deyimlerini kullanarak oluşturabilirsiniz.


2
Bu benim için çalışıyor! pg_dump - $ DATABASE> $ FILENAME ekler
Abel

4

Postgresql- (sürümünüz) -postgis-betikleri yükleyin


4

Aynı şey bugün bana da oldu. Sorunu --inserts komutu ile damping yaparak hallettim.

Yaptığım şey:

1) eklerle pg_dump:

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

2) psql (dökülmüş dosyanızı geri yükleyin)

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

Not-1) Çıkış dosyası eklemenin içe aktarma hızını artıracağından emin olun.

Not-2) psql ile içe aktarmadan önce aynı isim ve sütunlarla tablo oluşturmayı unutmayınız.


2

Son deneyimime göre, gerçek sorunun kaçış karakterleri veya yeni satırlarla ilgisi olmadığında bu hatayı almak mümkündür. Benim durumumda, A veri tabanından bir döküm oluşturmuştum
pg_dump -a -t table_name > dump.sql
ve onu B veri tabanına geri yüklemeye çalışıyordum
psql < dump.sql(tabii ki uygun ortam değişkenlerini güncelledikten sonra)
Sonunda anladığım şey, dökümün olmasına rağmen data-only( -aseçenek , böylece tablo yapısı açıkça dökümün bir parçası değildir), şemaya özgüdür. Bu, dökümü manuel olarak değiştirmeden schema1.table_namedoldurmak için içinden oluşturulan bir dökümü kullanamayacağım anlamına geliyordu schema2.table_name. Dökümün manuel olarak değiştirilmesi kolaydı, şema ilk 15 satırda belirtildi.


1

Çoğu zaman çözüm postgres-contribpaketi kurmaktır.


0

Aynı sorunu yaşadım, yeni bir veritabanı oluşturdum ve invalid command \N psql ile geri yüklemeye . Eski veritabanı ile aynı tablo alanını ayarlayarak çözdüm.

Örneğin, eski veritabanı yedeklemesinin tablo alanı "pg_default" vardı, aynı tablo alanını yeni veritabanına tanımladım ve yukarıdaki hata gitti!


0

Tüm bu örnekleri takip ettim ve hepsi bahsettiğimiz hatayla başarısız oldu:

Postgres'te bir veritabanından diğerine tablo kopyalama

İşe yarayan şey -C ile sözdizimiydi , buraya bakın:

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

Ayrıca ikisi arasında farklı Şemalar varsa, Tablo kopyalarının çalışması için bir dB'nin şemasını diğerleriyle eşleşecek şekilde değiştirmenin gerekli olduğunu buluyorum, örneğin:

DROP SCHEMA public;
ALTER SCHEMA originalDBSchema RENAME TO public;

-1

SUSE 12'de postgreSQL 10 kullanıyorum, invalid command \Ndisk alanını artırarak hatayı çözdüm . Yetersiz disk alanı benim için hataya neden oluyordu. Verilerinizin df -hçıktıda gideceği dosya sistemine bakarsanız, disk alanınızın bitip bitmediğini anlayabilirsiniz . Dosya sistemi / bağlama% 100 kullanılıyorsa, aşağıdaki gibi bir şey yaptıktan sonra psql -f db.out postgres(bkz. Https://www.postgresql.org/docs/current/static/app-pg-dumpall.html ) mevcut disk alanını artırmanız gerekebilir. .

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.