Peter Eisentraut wrote:
> > If there's no more review to do, would you consider moving it to
> > Ready for Committer?
>
> committed
Thanks!
Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite
On 2020-03-06 10:36, Daniel Verite wrote:
David Zhang wrote:
Thanks for your review, now the new patch with the error message in PG
style is attached.
The current status of the patch is "Needs review" at
https://commitfest.postgresql.org/27/2400/
If there's no more review to do, woul
David Zhang wrote:
> Thanks for your review, now the new patch with the error message in PG
> style is attached.
The current status of the patch is "Needs review" at
https://commitfest.postgresql.org/27/2400/
If there's no more review to do, would you consider moving it to
Ready for Co
Hi Alvaro,
Thanks for your review, now the new patch with the error message in PG
style is attached.
On 2020-02-28 8:03 a.m., Alvaro Herrera wrote:
On 2020-Feb-18, David Zhang wrote:
3. I think a better way to resolve this issue will still be the solution
with an extra %m, which can make th
On 2020-Feb-18, David Zhang wrote:
> 3. I think a better way to resolve this issue will still be the solution
> with an extra %m, which can make the error message much more informative to
> the end users.
Yes, agreed. However, we use a style like this:
pg_log_error("could not pr
hi,
I did some further research on this bug. Here is the summary:
1. Tried to wrap "fputs" similar to "fprintf" redefined by "pg_fprintf",
but it ended up with too much error due to "fputs" is called everywhere
in "print_unaligned_text". If add an extra static variable to track the
output sta
David Zhang wrote:
> > Are you sure? I don't find that redefinition. Besides
> > print_aligned_text() also calls putc and puts.
> Yes, below is the gdb debug message when psql first time detects the
> error "No space left on device". Test case, "postgres=# select
> repeat('111', 100)
On 2020-01-28 4:14 a.m., Daniel Verite wrote:
David Zhang wrote:
The error "No space left on device" can be logged by fprintf() which is
redefined as pg_fprintf() when print_aligned_text() is called
Are you sure? I don't find that redefinition. Besides
print_aligned_text() also calls
David Zhang wrote:
> The error "No space left on device" can be logged by fprintf() which is
> redefined as pg_fprintf() when print_aligned_text() is called
Are you sure? I don't find that redefinition. Besides
print_aligned_text() also calls putc and puts.
> Will that be a better solut
On 2020-01-20 2:42 a.m., Daniel Verite wrote:
David Zhang wrote:
Yes, I agree with you. For case 2 "select repeat('111', 100) \g
/mnt/ramdisk/file", it can be easily fixed with more accurate error
message similar to pg_dump, one example could be something like below.
But for case
David Zhang wrote:
> Yes, I agree with you. For case 2 "select repeat('111', 100) \g
> /mnt/ramdisk/file", it can be easily fixed with more accurate error
> message similar to pg_dump, one example could be something like below.
> But for case 1 "psql -d postgres -At -c "select repe
On 2020-01-16 5:20 a.m., Daniel Verite wrote:
David Zhang wrote:
If I change the error log message like below, where "%m" is used to pass the
value of strerror(errno), "could not write to output file:" is copied from
function "WRITE_ERROR_EXIT".
- pg_log_error("Err
David Zhang wrote:
> If I change the error log message like below, where "%m" is used to pass the
> value of strerror(errno), "could not write to output file:" is copied from
> function "WRITE_ERROR_EXIT".
> - pg_log_error("Error printing tuples");
> +
Right, the file difference is caused by "-At".
On the other side, in order to keep the output message more consistent with
other tools, I did a litter bit more investigation on pg_dump to see how it
handles this situation. Here is my findings.
pg_dump using WRITE_ERROR_EXIT to throw the error m
David Z wrote:
> $ psql -d postgres -At -c "select repeat('111', 100)" >
> /mnt/ramdisk/file
The -A option selects the unaligned output format and -t
switches to the "tuples only" mode (no header, no footer).
> Test-2: delete the "file", run the command within psql console,
> $ rm /
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 some situations, people may end up lost
data permanently.
However, after I quickly applied your idea/patch to "commit
bf65f3c8871bcc95a3b4d5bcb5409d3df05c8273 (HEAD ->
Hi,
When exporting data with psql -c "..." >file or select ... \g file inside
psql,
post-creation output errors are silently ignored.
The problem can be seen easily by creating a small ramdisk and
filling it over capacity:
$ sudo mount -t tmpfs -o rw,size =1M tmpfs /mnt/ramdisk
$ psql -d postg
17 matches
Mail list logo
