From: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp> |
---|---|
To: | coelho(at)cri(dot)ensmp(dot)fr |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Using COPY FREEZE in pgbench |
Date: | 2021-03-14 12:14:49 |
Message-ID: | 20210314.211449.2134573009361549472.t-ishii@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Ok. ISTM that the option should be triggered as soon as it is
> available, but you do as you wish.
Can you elaborate why you think that using COPY FREEZE before 14 is
beneficial? Or do you want to standardize to use COPY FREEZE?
> I'm unsure how this could happen ever. The benefit of not caring is
> less lines of codes in pgbench and a later call will catch the issue
> anyway, if libpq is corrupted.
I have looked in the code of PQprotocolVersion. The only case in which
it returns 0 is there's no connection. Yes, you are right. Once the
connection has been successfuly established, there's no chance it
fails. So I agree with you.
>>> Question: should there be a word about copy using the freeze option?
>>> I'd say yes, in the section describing "g".
>>
>> Can you elaborate about "section describing "g"? I am not sure what
>> you mean.
>
> The "g" item in the section describing initialization steps
> (i.e. option -I). I'd suggest just to replace "COPY" with "COPY
> FREEZE" in the sentence.
Ok. The section is needed to be modified.
Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Dolgov | 2021-03-14 14:48:33 | Re: Index Skip Scan (new UniqueKeys) |
Previous Message | Michael Paquier | 2021-03-14 11:59:08 | Re: Fallback table AM for relkinds without storage |