From: Kyotaro Horiguchi
> > if (PQstatus(entry->conn) != CONNECTION_OK ||
> > PQtransactionStatus(entry->conn) != PQTRANS_IDLE ||
> > entry->changing_xact_state)
> > {
> > elog(DEBUG3, "discarding connection %p", entry->conn);
> > dis
From: Masahiko Sawada
> So what's your opinion?
My opinion is simple and has not changed. Let's clarify and refine the design
first in the following areas (others may have pointed out something else too,
but I don't remember), before going deeper into the code review.
* FDW interface
New func
From: Jamison, Kirk/ジャミソン カーク
> I have confirmed that the above comment (commenting out the lines in
> RelationTruncate) solves the issue for non-recovery case.
> The attached 0004 patch is just for non-recovery testing and is not included
> in
> the final set of patches to be committed for vacuu
> As for 0004:
> When testing TRUNCATE, remove the change to storage.c because it was
> intended to troubleshoot the VACUUM test.
I meant vacuum.c. Sorry.
Regards
Takayuki Tsunakawa
The patch looks good except for the minor one:
(1)
+* as the total nblocks for a given fork. The cached value returned by
nblocks -> blocks
Regards
Takayuki Tsunakawa
From: Thomas Munro
> On Thu, Oct 22, 2020 at 7:33 PM Kyotaro Horiguchi
> wrote:
> > Mmm. Not exact. The requirement here is that we must be certain that
> > the we don't have a buffuer for blocks after the file size known to
> > the process. While recoverying, If the first lseek() returned small
From: Thomas Munro
> > I'm probably being silly, but can't we avoid the problem by using fstat()
> instead of lseek(SEEK_END)? Would they return the same value from the
> i-node?
>
> Amazingly, st_size can disagree with SEEK_END when using the Linux NFS
> client, but its behaviour is worse. Her
401 - 407 of 407 matches
Mail list logo
