Horton

Re: New Object Access Type hooks

Mark Dilger <mark.dilger@enterprisedb.com>

View thread View on postgr.es
From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, Joshua Brindle <joshua.brindle@crunchydata.com>, Robert Haas <robertmhaas@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Jeff Davis <pgsql@j-davis.com>, Joe Conway <joe@crunchydata.com>
Date: 2022-04-04T20:50:40Z
Lists: pgsql-hackers 

> On Apr 4, 2022, at 1:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 
> Yeah, it's plausible to get a failure on either the write or read side
> depending on timing.
> 
> Perhaps libpq should be trying harder to make those cases look alike, but
> this test is about server behavior not libpq behavior, so I'm inclined
> to just make it lax.

+1.

I've gotten this test failure only a few times in perhaps the last six months, so if we narrow the opportunity for test failure without closing it entirely, we're just making the test failures that much harder to diagnose.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Update some tests in 013_crash_restart.pl.

  2. Avoid freeing objects during json aggregate finalization

  3. SQL/JSON constructors

  4. Force NO_LOCALE / UTF8 for test_oat_hooks tests

  5. Temporarily disable installcheck for test_oat_hooks module

  6. Fix new Object Access hooks test

  7. Add String object access hooks

  8. Add a test module for Object Access hooks