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 had
> 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 the
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 thin
> 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 there's
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. pgc
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 things
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 pg_am
> 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 there's
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 prog
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 hand
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:
http://rhaas.blogs
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 realize
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 pr
> 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 for
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 C
> 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 pri
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 attack
> 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
>> le
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
> loaded.
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 amch
> 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 th
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 str
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 or
> 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 anyti
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 nee
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 PostgreS
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 ex
32 matches
Mail list logo
