Make new SSL TAP test for channel_binding more robust
The test would fail in an environment including a certificate file in
~/.postgresql/. bdd6e9b fixed a similar failure, and d6e612f introduced
the same problem again with a new test.
Author: Kyotaro Horiguchi
Discussion:
https://postgr.es/m/2
Make new SSL TAP test for channel_binding more robust
The test would fail in an environment including a certificate file in
~/.postgresql/. bdd6e9b fixed a similar failure, and d6e612f introduced
the same problem again with a new test.
Author: Kyotaro Horiguchi
Discussion:
https://postgr.es/m/2
Fix replica backward scan race condition.
It was possible for the logic used by backward scans (which must reason
about concurrent page splits/deletions in its own peculiar way) to
become confused when running on a replica. Concurrent replay of a WAL
record that describes the second phase of page
doc: PG 13 relnotes: hash_mem_multiplier can restore old behav.
Document that hash_mem_multiplier can get query behavior closer to the
pre-PG 13 behavior of allowing hashing to use more memory.
Reported-by: Peter Geoghegan
Discussion:
https://postgr.es/m/CAH2-Wzn3kwQm_pe6g2=ki+p7+zrqh5gvfgn6sw
Add nbtree page deletion assertion.
Add a documenting assertion that's similar to the nearby assertion added
by commit cd8c73a3. This conveys that the entire call to _bt_pagedel()
does no work if it isn't possible to get a descent stack for the initial
scanblkno page.
Branch
--
master
Detai
Remove unnecessary "DISTINCT" in psql's queries for \dAc and \dAf.
A moment's examination of these queries is sufficient to see that
they do not produce duplicate rows, unless perhaps there's
catalog corruption. Using DISTINCT anyway is inefficient and
confusing; moreover it sets a poor example f
Remove unnecessary "DISTINCT" in psql's queries for \dAc and \dAf.
A moment's examination of these queries is sufficient to see that
they do not produce duplicate rows, unless perhaps there's
catalog corruption. Using DISTINCT anyway is inefficient and
confusing; moreover it sets a poor example f
Doc: fix obsolete info about allowed range of TZ offsets in timetz.
We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but
that commit forgot to fix the documentation about timetz.
Per bug #16571 from osdba.
Discussion: https://postgr.es/m/[email protected]
Br
Doc: fix obsolete info about allowed range of TZ offsets in timetz.
We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but
that commit forgot to fix the documentation about timetz.
Per bug #16571 from osdba.
Discussion: https://postgr.es/m/[email protected]
Br
Doc: fix obsolete info about allowed range of TZ offsets in timetz.
We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but
that commit forgot to fix the documentation about timetz.
Per bug #16571 from osdba.
Discussion: https://postgr.es/m/[email protected]
Br
Doc: fix obsolete info about allowed range of TZ offsets in timetz.
We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but
that commit forgot to fix the documentation about timetz.
Per bug #16571 from osdba.
Discussion: https://postgr.es/m/[email protected]
Br
Doc: fix obsolete info about allowed range of TZ offsets in timetz.
We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but
that commit forgot to fix the documentation about timetz.
Per bug #16571 from osdba.
Discussion: https://postgr.es/m/[email protected]
Br
Doc: fix obsolete info about allowed range of TZ offsets in timetz.
We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but
that commit forgot to fix the documentation about timetz.
Per bug #16571 from osdba.
Discussion: https://postgr.es/m/[email protected]
Br
Doc: fix obsolete info about allowed range of TZ offsets in timetz.
We've allowed UTC offsets up to +/- 15:59 since commit cd0ff9c0f, but
that commit forgot to fix the documentation about timetz.
Per bug #16571 from osdba.
Discussion: https://postgr.es/m/[email protected]
Br
Robert Haas writes:
> While I like having HP-UX buildfarm coverage, the status page says
> that gaur is running 10.20, which according to noted reliable source
> Wikipedia, was released in 1996 and went out of support in 2003. So I
> wonder whether testing that version is really a sensible thing t
On Sat, Aug 1, 2020 at 2:16 PM Tom Lane wrote:
> There wasn't any amazingly good reason to be using -O1 for gaur,
> so I've switched the animal to use -O2. I expect it'll go back
> to green in a few hours.
While I like having HP-UX buildfarm coverage, the status page says
that gaur is running 10
Fix behavior of ecpg's "EXEC SQL elif name".
This ought to work much like C's "#elif defined(name)"; but the code
implemented it in a way equivalent to endif followed by ifdef, so that
it didn't matter whether any previous branch of the IF construct had
succeeded. Fix that; add some test cases co
Fix behavior of ecpg's "EXEC SQL elif name".
This ought to work much like C's "#elif defined(name)"; but the code
implemented it in a way equivalent to endif followed by ifdef, so that
it didn't matter whether any previous branch of the IF construct had
succeeded. Fix that; add some test cases co
Michael Paquier writes:
> Oops. Thanks, Tom. I did not notice the failure. pademelon does not
> run automatically, explaining why there is a hole of two weeks in the
> report, right?
Yeah, I just boot it up every week or two ... machine is too noisy to keep
running all the time.
19 matches
Mail list logo
