RE: libpq debug log

Hi Iwata-san I reviewed v10-0001-libpq-trace.patch. (But I don't check recent discussion...) I found some bugs. I'm suggesting some refactoring. @@ -6809,7 +6809,17 @@ PQtrace(PGconn *conn, FILE *debug_port) + if (pqTraceInit(conn)) + { + conn->Pfdebug = debug_port;

RE: [bugfix]"make installcheck" could not work in PGXS

Hello, On Fri, Aug 5, 2020 at 10:57:56 +, Michael Paquier wrote: > Yeah, that's a known problem. One way to counter that is for example > to grab the path of pg_regress from pg_config --libdir and set > $ENV{PG_REGRESS} to it, but that's hacky. So I agree that it would be > good to do som

[bugfix]"make installcheck" could not work in PGXS

Hello, I found that "make installcheck" could not work in PGXS. --[/src/foo_project/Makefile]-- SUBDIRS = foo TAP_TESTS = 1 PG_CONFIG = pg_config PGXS := $(shell $(PG_CONFIG) --pgxs) include $(PGXS) $(recurse) $(recurse_always) --[/src/foo_project/t/001_foo_test.pl] use strict; use warnings;

RE: archive status ".ready" files may be created too early

Hello, > At Mon, 13 Jul 2020 01:57:36 +, "Kyotaro Horiguchi > " wrote in > Am I missing something here? I write more detail(*). Record-A and Record-B are cross segment-border records. Record-A spans segment X and X+1. Record-B spans segment X+2 and X+3. If both records have been ins

RE: archive status ".ready" files may be created too early

Hello, Horiguchi-san At Monday, July 6, 2020 05:13:40 +, "Kyotaro Horiguchi " wrote in > > > after WAL buffer is filled up to the requested position. So when it > > > crosses segment boundary we know the all past corss segment-boundary > > > records are stable. That means all we need to reme

RE: archive status ".ready" files may be created too early

Hello, Horiguchi-san Thank you for your comment and patch. At Thursday, June 25, 2020 3:36 PM(JST), "Kyotaro Horiguchi " wrote in > I think we don't need most of that shmem stuff. XLogWrite is called I wanted no more shmem stuff too, but other ideas need more lock that excludes inserter and w

RE: archive status ".ready" files may be created too early

> On 5/28/20, 11:42 PM, "matsumura@fujitsu.com" > wrote: > > I'm preparing a patch that backend inserting segment-crossboundary > > WAL record leaves its EndRecPtr and someone flushing it checks > > the EndRecPtr and notifies.. I'm sorry for my s

RE: archive status ".ready" files may be created too early

2020-03-26 18:50:24 Bossart, Nathan wrote: > The v3 patch is a proof-of-concept patch that moves the ready-for- > archive logic to the WAL writer process. We mark files as ready-for- > archive when the WAL flush pointer has advanced beyond a known WAL > record boundary. I like such a simple re

RE: WAL archive is lost

Tomas-san and Jeff-san I'm very sorry for my slow response. Tomas-san wrote: > That does indeed seem like a bug. We should certainly archive all WAL > segments, irrespectedly of primary shutdowns/restarts/whatever. I think so, too. Tomas-san wrote: > I guess we should make sure the archiver is

WAL archive is lost

Hi all I find a situation that WAL archive file is lost but any WAL segment file is not lost. It causes for archive recovery to fail. Is this behavior a bug? example: WAL segment files 00010001 00010002 00010003 Archive files 0001

libpq calls blocking recv when it could not send data enough.

Hi all Libpq may be blocked by recv without checking data arrival when libpq could not send data enough. I think it should check by pqReadReady() for avoiding blocking. Note: I didn't encounter any issue that the pqReadData is blocked. [src/interfaces/libpq/fe-misc.c] pqSendSome(PGconn *conn