On Thu, 5 Jun 2025 at 12:49, Peter Eisentraut wrote:
> I propose to address this by not allowing the use of user-defined
> functions in generation expressions for now. The attached patch
> implements this. This assumes that all built-in functions are
> trustworthy, for this purpose, which seems
On Thu, 29 May 2025 at 15:43, Robert Haas wrote:
> that would also imply,
> for example, that there's no way to run a pg_dump without letting any
> user on the system obtain superuser privileges.
I checked, pg_dump seems safe, it doesn't extract the values, even when
using --column-inserts.
pg_r
On Mon, 26 May 2025 at 16:17, jian he wrote:
> calling exploit_generated.exploit by normal user or superuser the
> effects are different,
> that by definition is not IMMUTABLE.
Yeah, i know this is *wrong* usage of IMMUTABLE, the point is that a rogue
regular user *can* use this pattern to become
On Sat, 24 May 2025 at 15:43, jian he wrote:
> sorry, I am not fully sure what this means. a minimum sql reproducer
would be
> great.
The initial email contains a fully self-contained example of a regular user
becoming a superuser. The only thing the superuser had to do was
SELECT * FROM unt
On Fri, 23 May 2025 at 14:48, jian he wrote:
> when you mark it as IMMUTABLE, postgres think it's IMMUTABLE, but in this
case
> exploit_generated.exploit(i int) clearly is not an IMMUTABLE function.
>
> Only IMMUTABLE functions are allowed in generated expressions,
> but you can still misuse it by
discussion from secur...@postgresql.org:
On Fri, 16 May 2025 at 23:12, Noah Misch wrote:
>
> On Fri, May 16, 2025 at 07:16:13PM +0200, Feike Steenbergen wrote:
> > On Fri, 16 May 2025 at 19:00, Noah Misch wrote:
> > > Thanks for the report. Does this attack work if the rea
before
starting postgres/initdb or the like
install -o postgres -g postgres -d -m 0700 "${PGDATA}"
> The world has changed! And the old standards don't work...
There's enough people running Postgres in Docker containers in production
for almost a decade.
It does work!
Kind regards,
Feike Steenbergen
Hi all,
I'd like to get some feedback on whether or not implementing a DNS SRV feature
for connecting to PostgreSQL would be desirable/useful.
The main use case is to have a DNS SRV record that lists all the possible
primaries of a given replicated PostgreSQL cluster. With auto failover
solutions
On 5 January 2018 at 15:19, Simon Riggs wrote:
> Yup, I got this.
I saw the commit in the master branch but not in the REL_10_STABLE branch,
I'm totally not up-to-date with the backpatching process, but I was wondering
if it still needs to be added to REL_10_STABLE
regards,
Feike
On 23 December 2017 at 11:58, Michael Paquier wrote:
> On Fri, Dec 22, 2017 at 07:55:19AM +0100, Feike Steenbergen wrote:
>> On 21 December 2017 at 05:32, Michael Paquier
>> wrote:
>>
>> > Don't you want to put that in its own block? That's rather
>&
On 21 December 2017 at 05:32, Michael Paquier wrote:
> Don't you want to put that in its own block? That's rather
> important not to miss for administrators.
I didn't want to add yet another block on that documentation page,
as it already has 2, however it may be good to upgrade the
note to a c
On 21 December 2017 at 14:11, Michael Paquier wrote:
> You mean a WAL receiver here, not a WAL sender.
Fixed, thanks
0002-Fix-permissions-check-on-pg_stat_get_wal_senders.patch
Description: Binary data
that, however
pg_stat_get_wal_senders was somehow not part of that commit, that
seems an oversight.
1:
https://www.postgresql.org/message-id/CA%2BOCxoyYxO%2BJmzv2Micj4uAaQdAi6nq0w25BPQgLLxsrvTmREw%40mail.gmail.com\
regards,
Feike Steenbergen
0001-Fix-permissions-check-on
On 20 December 2017 at 06:22, Michael Paquier
wrote:
> prepare_transaction.sgml has a "Caution" block mentioning that it is
> unwise to keep 2PC transactions unfinished for a too-long time as it
> interferes with VACUUM. In doc/src/sgml/logicaldecoding.sgml, it would
> be nice to add the a similar
Hi,
While doing some wraparound debugging, I saw the hint regarding upcoming
wraparound did not include the problem of having a stale replication
slot (which I'm actually using to force wraparound issues).
I remember a few discussions where a stale replication slot was actually
the culprit in the
On 28 November 2017 at 23:17, Peter Geoghegan wrote:
> BTW, a good short term solution for you might be to change the vacuum
> cost delay settings. They're pretty conservative by default.
>
> There is a good chance that your indexes are mostly in memory even on
> large tables, and B-Tree indexes a
On 28 November 2017 at 22:48, Peter Geoghegan wrote:
> There is a patch in the ongoing CF to do this:
Ah, thanks, I'll probably review that one then
> It's a lot harder to do this correctly than it first appears.
I already thought my naive approach would not suffice
Sorry, I didn't attach a good patch, this one should be better
0002-skip_cleanup_for_stale_relation.patch
Description: Binary data
On a server with a very frequent xid wraparound I can see that the
anti-wraparound vacuum is finished very quickly with the heap, yet it still
scans all the indexes, which causes it to still have to read a lot of data,
which takes a considerable amount of time.
I dove into the code a bit and as fa
19 matches
Mail list logo
