On Thu, Aug 27, 2020 at 03:27:58PM -0400, Daniel Jakots wrote: > Hi, > > I'm chasing a weird behavior with postgresql. Sometimes (it's very > infrequent) a sql request fails with "could not send data to client: > Permission denied". I reported the problem on pgsql-general@ [0] and if > I understood correctly, this happens when pgsql uses send(2) and gets > EACCES. > > According to send(2) this happens when "The connection was blocked by > pf(4)". I have a cron that modifies a table with > `pfctl -t TABLE_NAME -Tr -f TABLE_FILE_PATH` > > The file is large so it's not exactly immediate. Could pf temporarily > block new connections while it loads the file? Or am I looking at the > wrong thing? >
>From your pf rules, does the postgresql connection could be blocked if TABLE_NAME is empty/inconsistent ? Could you add (if you don't have already tested it), an explicit allow rule for postgresql to ensure the connection will success ? >From my reading, pfctl -Treplace is using DIOCRSETADDRS ioctl. On userland >side, it tries to do it in one step (see src/sbin/pfctl/pfctl_table.c line 228), but could iterate on pfr_set_addrs() (I am unsure if the change is atomic or if the iteration is to ensure the change will be atomic with large enough buffer for result). The DIOCRSETADDRS ioctl on kernel side is done under PF_LOCK(). But I didn't check if the match rule would be done under PF_LOCK() or not (I am not familiar enough with pf(4) code to find the code which do the check). Thanks. -- Sebastien Marie
