Clean up management of IP addresses in our SSL tests.
Instead of hard-wiring the netmask as /32, allow it to be specified
where we specify the server address. This will ease changing the
test to use IPv6, when/if somebody wants to do that.
Also remove the hard-wired pg_hba.conf entries for IPv6
Michael Paquier writes:
> On Mon, Jan 06, 2020 at 07:14:49PM -0500, Tom Lane wrote:
>> I propose the attached, which removes the unnecessary entries
>> and puts full control of the IPv4/IPv6 decision in one place
>> (well, two places). The test will still always connect over IPv4,
>> but at least
On Mon, Jan 06, 2020 at 07:14:49PM -0500, Tom Lane wrote:
> I propose the attached, which removes the unnecessary entries
> and puts full control of the IPv4/IPv6 decision in one place
> (well, two places). The test will still always connect over IPv4,
> but at least there's now a clear route to c
On Mon, Jan 06, 2020 at 03:08:25PM -0500, Tom Lane wrote:
> I updated prairiedog and gaur to use OpenSSL 1.0.1e, but we are
> not out of the woods there:
>
> * prairiedog required 6:46 to run the ssl test [1], compared to 3:24
> in its last run with 0.9.8x. Why so much slower?
I have seen the te
I wrote:
> * gaur fell over in the ssl test [2]. I had not asked it to run that
> test before, so this may well be a pre-existing issue not something
> new with the version change. It looks like something in that test
> is assuming that we have IPv6 support, which maybe it shouldn't be,
> even in
On 2020-Jan-07, Thomas Munro wrote:
> On Fri, Jan 3, 2020 at 7:41 AM Alvaro Herrera
> wrote:
> > On 2020-Jan-01, Bruce Momjian wrote:
> > > Update copyrights for 2020
> > > src/test/ssl/ssl/client-der.key | Bin 1191 -> 1192
> > > bytes
> > > src/test/ssl/ssl/client-encrypt
On Fri, Jan 3, 2020 at 7:41 AM Alvaro Herrera wrote:
> On 2020-Jan-01, Bruce Momjian wrote:
> > Update copyrights for 2020
> > src/test/ssl/ssl/client-der.key | Bin 1191 -> 1192
> > bytes
> > src/test/ssl/ssl/client-encrypted-der.key | Bin 1191 -> 1192
> > bytes
Reduce the number of GetFlushRecPtr() calls done by walsenders.
Since the WAL flush position only moves forward, it's safe to cache
its previous value within each walsender process, and update from
shared memory only once we've caught up to the previously-seen value.
When there are many active wal
Reduce the number of GetFlushRecPtr() calls done by walsenders.
Since the WAL flush position only moves forward, it's safe to cache
its previous value within each walsender process, and update from
shared memory only once we've caught up to the previously-seen value.
When there are many active wal
I wrote:
> You'll probably see failures from some of my dinosaurs too.
> I've not yet switched them over to using newer OpenSSL,
> but will do so tomorrow or so.
I updated prairiedog and gaur to use OpenSSL 1.0.1e, but we are
not out of the woods there:
* prairiedog required 6:46 to run the ssl t
Add functions min_scale(numeric) and trim_scale(numeric).
These allow better control of trailing zeroes in numeric values.
Pavel Stehule, based on an old proposal of Marko Tiikkaja's;
review by Karl Pinc
Discussion:
https://postgr.es/m/[email protected]
Have logical replication subscriber fire column triggers
The logical replication apply worker did not fire per-column update
triggers because the updatedCols bitmap in the RTE was not populated.
This fixes that.
Reviewed-by: Euler Taveira
Discussion:
https://www.postgresql.org/message-id/flat/2
Have logical replication subscriber fire column triggers
The logical replication apply worker did not fire per-column update
triggers because the updatedCols bitmap in the RTE was not populated.
This fixes that.
Reviewed-by: Euler Taveira
Discussion:
https://www.postgresql.org/message-id/flat/2
Have logical replication subscriber fire column triggers
The logical replication apply worker did not fire per-column update
triggers because the updatedCols bitmap in the RTE was not populated.
This fixes that.
Reviewed-by: Euler Taveira
Discussion:
https://www.postgresql.org/message-id/flat/2
14 matches
Mail list logo
