Re: Making psql error out on output failures - Mailing list pgsql-hackers

From David Z
Subject Re: Making psql error out on output failures
Date
Msg-id 157896955591.709.8663084410799064450.pgcf@coridan.postgresql.org
Whole thread Raw
In response to Making psql error out on output failures  ("Daniel Verite" <daniel@manitou-mail.org>)
Responses Re: Making psql error out on output failures  ("Daniel Verite" <daniel@manitou-mail.org>)
List pgsql-hackers
Hi Daniel,
I agree with you if psql output doesn't indicate any error when the disk is full, then it is obviously not nice. In
somesituations, people may end up lost data permanently. 
 
However, after I quickly applied your idea/patch to "commit bf65f3c8871bcc95a3b4d5bcb5409d3df05c8273 (HEAD ->
REL_12_STABLE,origin/REL_12_STABLE)", and I found the behaviours/results are different.
 

Here is the steps and output, 
$ sudo mkdir -p /mnt/ramdisk
$ sudo mount -t tmpfs -o rw,size=1M tmpfs /mnt/ramdisk

Test-1: delete the "file", and run psql command from a terminal directly,
$ rm /mnt/ramdisk/file 
$ psql -d postgres  -At -c "select repeat('111', 1000000)" > /mnt/ramdisk/file
Error printing tuples
then dump the file,
$ rm /mnt/ramdisk/file 
$ hexdump -C /mnt/ramdisk/file 
00000000  31 31 31 31 31 31 31 31  31 31 31 31 31 31 31 31  |1111111111111111|
*
00100000

Test-2: delete the "file", run the command within psql console,
$ rm /mnt/ramdisk/file 
$ psql -d postgres
psql (12.1)
Type "help" for help.

postgres=# select repeat('111', 1000000) \g /mnt/ramdisk/file
Error printing tuples
postgres=# 
Then dump the file again,
$ hexdump -C /mnt/ramdisk/file 
00000000  20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20  |                |
*
00100000

As you can see the content are different after applied the patch. 

David

The new status of this patch is: Waiting on Author

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Unicode escapes with any backend encoding
Next
From: Alexander Korotkov
Date:
Subject: Re: Avoid full GIN index scan when possible