On Sun, Jun 16, 2019 at 01:52:03PM -0400, Tom Lane wrote:
Fabien COELHO writes:
This theory is insufficient to explain why Coelho's animals failed,
though. Maybe it would, if you also posit a ccache screwup? But it's
not obvious from their configurations that they're using ccache at all.
I
Fabien COELHO writes:
>> This theory is insufficient to explain why Coelho's animals failed,
>> though. Maybe it would, if you also posit a ccache screwup? But it's
>> not obvious from their configurations that they're using ccache at all.
> Indeed, no ccache. The compilers change often (well,
Hello Tom,
I see that Coelho's two bleeding-edge-clang animals are reporting that
failure too. Normally I'd just ignore those two;
And you'd be right.
they break pretty regularly. Maybe you're using an
almost-bleeding-edge clang?
Oh --- I managed to reproduce that failure locally on RH
I wrote:
> Tomas Vondra writes:
>> OK, it seems the buildfarm is getting green again. I'm not sure why I'm
>> seeing the failure in 011_crash_recovery.pl, while the buildfarm does
>> not. Perhaps my environment is borked in some way? Not sure.
> I see that Coelho's two bleeding-edge-clang animals
Tomas Vondra writes:
> OK, it seems the buildfarm is getting green again. I'm not sure why I'm
> seeing the failure in 011_crash_recovery.pl, while the buildfarm does
> not. Perhaps my environment is borked in some way? Not sure.
I see that Coelho's two bleeding-edge-clang animals are reporting t
Tomas Vondra writes:
> Anyway, I'm wondering if we need the REVOKE/GRANT on pg_statistic_ext at
> all, and if we do if we should just remove the list of columns, and
> grant SELECT on all. All the sensitive columns were moved to another
> catalog, after all.
+1. Per-column permissions checks see
On Sun, Jun 16, 2019 at 12:03:28PM +0200, Tomas Vondra wrote:
On Sun, Jun 16, 2019 at 10:56:51AM +0200, Tomas Vondra wrote:
On Sun, Jun 16, 2019 at 07:18:58AM +0100, Dean Rasheed wrote:
On Sun, 16 Jun 2019, 03:05 Tom Lane, wrote:
I wrote:
Tomas Vondra writes:
Rework the pg_statistic_ext c
On Sun, Jun 16, 2019 at 10:56:51AM +0200, Tomas Vondra wrote:
On Sun, Jun 16, 2019 at 07:18:58AM +0100, Dean Rasheed wrote:
On Sun, 16 Jun 2019, 03:05 Tom Lane, wrote:
I wrote:
Tomas Vondra writes:
Rework the pg_statistic_ext catalog
So ... not one of the buildfarm members that are runn
On Sun, Jun 16, 2019 at 07:18:58AM +0100, Dean Rasheed wrote:
On Sun, 16 Jun 2019, 03:05 Tom Lane, wrote:
I wrote:
> Tomas Vondra writes:
>> Rework the pg_statistic_ext catalog
> So ... not one of the buildfarm members that are running TAP tests
> likes this. ...
> I think probably what's ha
On Sun, 16 Jun 2019, 03:05 Tom Lane, wrote:
> I wrote:
> > Tomas Vondra writes:
> >> Rework the pg_statistic_ext catalog
>
> > So ... not one of the buildfarm members that are running TAP tests
> > likes this. ...
> > I think probably what's happening is that pg_dump is still trying to dump
> >
I wrote:
> Tomas Vondra writes:
>> Rework the pg_statistic_ext catalog
> So ... not one of the buildfarm members that are running TAP tests
> likes this. ...
> I think probably what's happening is that pg_dump is still trying to dump
> directly from the catalog, when what it needs to do now is du
Tomas Vondra writes:
> Rework the pg_statistic_ext catalog
So ... not one of the buildfarm members that are running TAP tests
likes this. The failures look like
# Running: pg_dump --no-sync
--file=/Users/tgl/pgsql/src/bin/pg_dump/tmp_check/tmp_test_cSh8/role.sql
--role=regress_dump_test_role
12 matches
Mail list logo
