Re: Simplify ACL handling for large objects and removal of superuser() checks

From: Vaishnavi Prabakaran <vaishnaviprabakaran(at)gmail(dot)com>
To: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Simplify ACL handling for large objects and removal of superuser() checks
Date: 2017-09-26 00:04:36
Message-ID: CAOoUkxRXiupOkyVZ1jzCAt0sh3O_md51wO-BrXo0-kMy7m47=Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Sep 19, 2017 at 5:12 PM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
wrote:

>
> >>@@ -163,22 +150,16 @@ lo_read(int fd, char *buf, int len)
> >> ....
> >> + if ((lobj->flags & IFS_RDLOCK) == 0)
> >>+ ereport(ERROR,
> >>+ (errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE),
> >>+ errmsg("large object descriptor %d was not opened for reading",
> >>+ fd)));
> >
> > Do we ever reach this error? Because per my understanding
>
> This error can be reached, and it is part of the regression tests. One
> query which passed previously is now failing:
> +SELECT loread(lo_open(1001, x'20000'::int), 32); -- fail, wrong mode
> +ERROR: large object descriptor 0 was not opened for reading

Yes, I did realize on further reading the patch and what led to the
confusion is that in the 3rd patch , updated documentation(copied below)
still says that reading from a descriptor opened with INV_WRITE is
possible. I think we need some correction here to reflect the modified code
behavior.

+ or other transactions. Reading from a descriptor opened with
+ <symbol>INV_WRITE</symbol> or <symbol>INV_READ</> <literal>|</>
+ <symbol>INV_WRITE</symbol> returns data that reflects all writes of
+ other committed transactions as well as writes of the current
+ transaction.

Thanks & Regards,
Vaishnavi,
Fujitsu Australia.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2017-09-26 00:04:38 Re: Shaky coding for vacuuming partitioned relations
Previous Message Michael Paquier 2017-09-25 23:50:59 Re: Shaky coding for vacuuming partitioned relations