On 4/18/21 5:58 PM, Mark Dilger wrote:
>
>> On Apr 18, 2021, at 6:19 AM, Andrew Dunstan wrote:
>>
>> how about specifying pg_catalog as the schema instead of public?
> Done.
>
Pushed with slight changes.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Greetings,
* Mark Dilger (mark.dil...@enterprisedb.com) wrote:
> > On Apr 20, 2021, at 3:19 PM, Tom Lane wrote:
> > The rest of your analysis seems a bit off-point to me, which is what
> > makes me think that one of us is confused. If Alice is storing her
> > data in a Postgres database, she
> On Apr 20, 2021, at 3:19 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote:
>>> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
>>> wrote:
I think you are conflating the concept of an operating system adminstrator
with the concept of
Mark Dilger writes:
>> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote:
>> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
>> wrote:
>>> I think you are conflating the concept of an operating system adminstrator
>>> with the concept of the database superuser/owner.
>> You should conflate those
> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote:
>
> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
> wrote:
>> I think you are conflating the concept of an operating system adminstrator
>> with the concept of the database superuser/owner.
>
> You should conflate those things, because
On Tue, Apr 20, 2021 at 12:05 PM Tom Lane wrote:
> > I think the distinction I would draw is between things we would expect
> > to be present in every Postgres installation (e.g. pg_stat_statements,
> > auto_explain, postgres_fdw, hstore) and things we don't for one reason
> > or another (e.g.
Andrew Dunstan writes:
> On 4/20/21 11:09 AM, Tom Lane wrote:
>> Indeed. But I'm down on this idea of inventing src/extensions,
>> because then there will constantly be questions about whether FOO
>> belongs in contrib/ or src/extensions/.
> I think the distinction I would draw is between
On 4/20/21 11:09 AM, Tom Lane wrote:
> Alvaro Herrera writes:
>> Actually I think the best balance would be to leave things where they
>> are, and move amcheck to src/extensions/ once the next devel cycle
>> opens. That way, we avoid the (pretty much pointless) laborious task of
>> moving
> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote:
>
> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
> wrote:
>> I think you are conflating the concept of an operating system adminstrator
>> with the concept of the database superuser/owner.
>
> You should conflate those things, because
Alvaro Herrera writes:
> Actually I think the best balance would be to leave things where they
> are, and move amcheck to src/extensions/ once the next devel cycle
> opens. That way, we avoid the (pretty much pointless) laborious task of
> moving pg_amcheck to contrib only to move it back on the
On 4/20/21 8:47 AM, Robert Haas wrote:
> On Mon, Apr 19, 2021 at 2:55 PM Andrew Dunstan wrote:
>> There are at least two other client side programs in contrib. So this
>> argument doesn't quite hold water from a consistency POV.
> I thought that at first, too. But then I realized that those
On 2021-Apr-20, Michael Paquier wrote:
> Agreed. Something like src/extensions/ would be a tempting option,
> but I don't think that it is a good idea to introduce a new piece of
> infrastructure at this stage, so moving both to contrib/ would be the
> best balance with the current pieces at
On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
wrote:
> I think you are conflating the concept of an operating system adminstrator
> with the concept of the database superuser/owner.
You should conflate those things, because there's no meaningful
privilege boundary between them:
On Tue, Apr 20, 2021 at 2:47 PM Robert Haas wrote:
>
> On Mon, Apr 19, 2021 at 2:55 PM Andrew Dunstan wrote:
> > There are at least two other client side programs in contrib. So this
> > argument doesn't quite hold water from a consistency POV.
>
> I thought that at first, too. But then I
On Mon, Apr 19, 2021 at 2:55 PM Andrew Dunstan wrote:
> There are at least two other client side programs in contrib. So this
> argument doesn't quite hold water from a consistency POV.
I thought that at first, too. But then I realized that those programs
are oid2name and vacuumlo. And oid2name,
On Mon, Apr 19, 2021 at 10:31:18PM -0700, Mark Dilger wrote:
> I think you are conflating the concept of an operating system
> adminstrator with the concept of the database superuser/owner. If
> the operating system user that postgres is running as cannot execute
> any binaries, then "copy from
> On Apr 19, 2021, at 9:22 PM, Michael Paquier wrote:
>
> On Mon, Apr 19, 2021 at 08:39:06PM -0700, Mark Dilger wrote:
>> This is a classic privilege escalation attack. Bob has one
>> privilege, and uses it to get another.
>
> Bob is a superuser, so it has all the privileges of the world
On Mon, Apr 19, 2021 at 08:39:06PM -0700, Mark Dilger wrote:
> This is a classic privilege escalation attack. Bob has one
> privilege, and uses it to get another.
Bob is a superuser, so it has all the privileges of the world for this
instance. In what is that different from BASE_BACKUP or just
> On Apr 19, 2021, at 8:06 PM, Michael Paquier wrote:
>
> On Mon, Apr 19, 2021 at 07:15:23PM -0700, Mark Dilger wrote:
>> There is another issue to consider. Installing pg_amcheck in no way
>> opens up an avenue of attack that I can see. It is just a client
>> application with no special
On Mon, Apr 19, 2021 at 07:15:23PM -0700, Mark Dilger wrote:
> There is another issue to consider. Installing pg_amcheck in no way
> opens up an avenue of attack that I can see. It is just a client
> application with no special privileges. But installing amcheck
> arguably opens a line of
> On Apr 19, 2021, at 6:41 PM, Michael Paquier wrote:
>
> On Mon, Apr 19, 2021 at 12:53:29PM -0400, Tom Lane wrote:
>> FWIW, I think that putting them both in contrib makes the most
>> sense from a structural standpoint.
>>
>> Either way, though, you'll still need the proposed option to
>>
On Mon, Apr 19, 2021 at 12:53:29PM -0400, Tom Lane wrote:
> FWIW, I think that putting them both in contrib makes the most
> sense from a structural standpoint.
>
> Either way, though, you'll still need the proposed option to
> let the executable issue a CREATE EXTENSION to get the shlib
>
On 4/19/21 1:25 PM, Mark Dilger wrote:
>
>> On Apr 19, 2021, at 9:53 AM, Tom Lane wrote:
>>
>> Andrew Dunstan writes:
>>> OK, so let's fix it. If amcheck is going to stay in contrib then ISTM
>>> pg_amcheck should move there. I can organize that if there's agreement.
>>> Or else let's move
> On Apr 19, 2021, at 9:53 AM, Tom Lane wrote:
>
> Andrew Dunstan writes:
>> OK, so let's fix it. If amcheck is going to stay in contrib then ISTM
>> pg_amcheck should move there. I can organize that if there's agreement.
>> Or else let's move amcheck as Alvaro suggests.
>
> FWIW, I think
Andrew Dunstan writes:
> OK, so let's fix it. If amcheck is going to stay in contrib then ISTM
> pg_amcheck should move there. I can organize that if there's agreement.
> Or else let's move amcheck as Alvaro suggests.
FWIW, I think that putting them both in contrib makes the most
sense from a
On Mon, Apr 19, 2021 at 12:37 PM Mark Dilger
wrote:
> > OK, so let's fix it. If amcheck is going to stay in contrib then ISTM
> > pg_amcheck should move there. I can organize that if there's agreement.
> > Or else let's move amcheck as Alvaro suggests.
>
> Ah, no. I wrote pg_amcheck in contrib
> On Apr 19, 2021, at 9:32 AM, Andrew Dunstan wrote:
>
>
> On 4/18/21 7:32 PM, Alvaro Herrera wrote:
>> On 2021-Apr-18, Andrew Dunstan wrote:
>>
>>> On 4/17/21 3:43 PM, Mark Dilger wrote:
I'd also like your impressions on whether we're likely to move
contrib/amcheck into core
On 4/18/21 7:32 PM, Alvaro Herrera wrote:
> On 2021-Apr-18, Andrew Dunstan wrote:
>
>> On 4/17/21 3:43 PM, Mark Dilger wrote:
>>> I'd also like your impressions on whether we're likely to move
>>> contrib/amcheck into core anytime soon. If so, is it worth adding
>>> an option that we'll soon
On 2021-Apr-18, Andrew Dunstan wrote:
> On 4/17/21 3:43 PM, Mark Dilger wrote:
> > I'd also like your impressions on whether we're likely to move
> > contrib/amcheck into core anytime soon. If so, is it worth adding
> > an option that we'll soon need to deprecate?
>
> I think if it stays as an
> On Apr 18, 2021, at 6:19 AM, Andrew Dunstan wrote:
>
> how about specifying pg_catalog as the schema instead of public?
Done.
v2-0001-Adding-install-missing-option-to-pg_amcheck.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
On 4/17/21 3:43 PM, Mark Dilger wrote:
>
>> On Apr 16, 2021, at 11:06 AM, Andrew Dunstan wrote:
>>
>>
>> Hi,
>>
>> Peter Geoghegan suggested that I have the cross version upgrade checker
>> run pg_amcheck on the upgraded module. This seemed to me like a good
>> idea, so I tried it, only to find
> On Apr 16, 2021, at 11:06 AM, Andrew Dunstan wrote:
>
>
> Hi,
>
> Peter Geoghegan suggested that I have the cross version upgrade checker
> run pg_amcheck on the upgraded module. This seemed to me like a good
> idea, so I tried it, only to find that it refuses to run unless the
> amcheck
Hi,
Peter Geoghegan suggested that I have the cross version upgrade checker
run pg_amcheck on the upgraded module. This seemed to me like a good
idea, so I tried it, only to find that it refuses to run unless the
amcheck extension is installed. That's fair enough, but it also seems to
me like
33 matches
Mail list logo
