From: | David Zhang <david(dot)zhang(at)highgo(dot)ca> |
---|---|
To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Making psql error out on output failures |
Date: | 2020-01-28 20:59:30 |
Message-ID: | 13ed77bb-82f1-f025-f8c9-206b0f77141a@highgo.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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 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', 1000000) \g /mnt/ramdisk/file"
bt
#0 flushbuffer (target=0x7ffd6a709ad0) at snprintf.c:313
#1 0x000055ba90b88b6c in dopr_outchmulti (c=32, slen=447325,
target=0x7ffd6a709ad0) at snprintf.c:1435
#2 0x000055ba90b88d5e in trailing_pad (padlen=-1499997,
target=0x7ffd6a709ad0) at snprintf.c:1514
#3 0x000055ba90b87f36 in fmtstr (value=0x55ba90bb4f9a "", leftjust=1,
minlen=1499997, maxwidth=0, pointflag=0, target=0x7ffd6a709ad0) at
snprintf.c:994
#4 0x000055ba90b873c6 in dopr (target=0x7ffd6a709ad0,
format=0x55ba90bb5083 "%s%-*s", args=0x7ffd6a709f40) at snprintf.c:675
#5 0x000055ba90b865b5 in pg_vfprintf (stream=0x55ba910cf240,
fmt=0x55ba90bb507f "%-*s%s%-*s", args=0x7ffd6a709f40) at snprintf.c:257
#6 0x000055ba90b866aa in pg_fprintf (stream=0x55ba910cf240,
fmt=0x55ba90bb507f "%-*s%s%-*s") at snprintf.c:270
#7 0x000055ba90b75d22 in print_aligned_text (cont=0x7ffd6a70a210,
fout=0x55ba910cf240, is_pager=false) at print.c:937
#8 0x000055ba90b7ba19 in printTable (cont=0x7ffd6a70a210,
fout=0x55ba910cf240, is_pager=false, flog=0x0) at print.c:3378
#9 0x000055ba90b7bedc in printQuery (result=0x55ba910f9860,
opt=0x7ffd6a70a2c0, fout=0x55ba910cf240, is_pager=false, flog=0x0) at
print.c:3496
#10 0x000055ba90b39560 in PrintQueryTuples (results=0x55ba910f9860) at
common.c:874
#11 0x000055ba90b39d55 in PrintQueryResults (results=0x55ba910f9860) at
common.c:1262
#12 0x000055ba90b3a343 in SendQuery (query=0x55ba910f2590 "select
repeat('111', 1000000) ") at common.c:1446
#13 0x000055ba90b51f36 in MainLoop (source=0x7f1623a9ea00
<_IO_2_1_stdin_>) at mainloop.c:505
#14 0x000055ba90b5c4da in main (argc=3, argv=0x7ffd6a70a738) at
startup.c:445
(gdb) l
308 size_t written;
309
310 written = fwrite(target->bufstart, 1, nc,
target->stream);
311 target->nchars += written;
312 if (written != nc)
313 target->failed = true;
314 }
315 target->bufptr = target->bufstart;
316 }
317
(gdb) p written
$2 = 1023
(gdb) p nc
$3 = 1024
(gdb) p strerror(errno)
$4 = 0x7f16238672c9 "No space left on device"
(gdb)
>
>> Will that be a better solution if redefine fputs similar to fprintf and
>> log the exact error when first time discovered?
> I think we can assume it's not acceptable to have pg_fprintf()
> to print anything to stderr, or to set a flag through a global
> variable. So even if using pg_fprintf() for all the printing, no matter
> how (through #defines or otherwise), there's still the problem that the
> error needs to be propagated up the call chain to be processed by psql.
>
>> The concern is that if we can't provide a more accurate
>> information to the end user when error happens, sometimes the
>> end user might got even confused.
> It's better to have a more informative message, but I'm for
> not having the best be the enemy of the good.
> The first concern is that at the moment, we have no error
> report at all in the case when the output can be opened
> but the error happens later along the writes.
>
>
> Best regards,
--
David
Software Engineer
Highgo Software Inc. (Canada)
www.highgo.ca
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2020-01-28 20:59:53 | Re: [PoC] Non-volatile WAL buffer |
Previous Message | Robert Haas | 2020-01-28 20:58:28 | Re: Removing pg_pltemplate and creating "trustable" extensions |