> On Jul 19, 2020, at 22:13, Thorsten Schöning wrote:
> Does Postgres support that in an easy way, without the need to reverse
> engineer an otherwise unknown the schema?
It is straight-forward enough to determine the user-created objects in the
schema, and then alter their ownership. For ne
Guten Tag Christophe Pettus,
am Sonntag, 19. Juli 2020 um 23:38 schrieben Sie:
> In this case, you may need to change the ownership of the various
> objects directly in the database, rather than using dump/restore as
> a way of changing ownership all at once.
Does Postgres support that in an easy
On Sun, Jul 19, 2020 at 11:01 PM Abraham, Danny wrote:
> Segmentation fault in _alloc_initial_pthread at 0x9521474
> 0x9521474 (_alloc_initial_pthread+0x1d4) e803 ld
> r0,0x0(r3)
> (dbx) where
> _alloc_initial_pthread(??) at 0x9521474
> __pth_init(??) at
> On Jul 19, 2020, at 14:25, Thorsten Schöning wrote:
> Would I need to restore the whole dump as super user? But how do I own
> all those restored contents to some other database user afterwards?
In this case, you may need to change the ownership of the various objects
directly in the databa
Guten Tag Tom Lane,
am Sonntag, 19. Juli 2020 um 22:37 schrieben Sie:
> In this case, you have to restore the cast as superuser, because nobody
> else is going to be treated as owning these built-in types.
How do I do that when I have large dumps with lots of those CASTs and
in worst case don't e
Guten Tag Thorsten Schöning,
am Sonntag, 19. Juli 2020 um 21:51 schrieben Sie:
> If they are not only created by superusers, how can I restore CASTs to
> a database owned by some other user? There are no other users than
> the one owning the database in my case.
I've retried things and must have
=?windows-1250?Q?Thorsten_Sch=F6ning?= writes:
> Guten Tag Tom Lane,
> am Sonntag, 19. Juli 2020 um 20:37 schrieben Sie:
>> It's a security thing. A user who can create such a cast can thereby
>> change the behavior of other people's queries.
> I'm not sure what your are telling me: Can CASTs on
Guten Tag Tom Lane,
am Sonntag, 19. Juli 2020 um 20:37 schrieben Sie:
> It's a security thing. A user who can create such a cast can thereby
> change the behavior of other people's queries.
I'm not sure what your are telling me: Can CASTs only be created by
superusers? I didn't read that in the
On Sun, Jul 19, 2020 at 11:04 AM Abraham, Danny
wrote:
>
> Customer is using 10.4 , not 9.5.5.
>
> Does the same argument apply for upgrading to 10.12 ?
>
Running the current minor release of PostgreSQL is a pre-req when reporting
problems; moreso when it's largely impractical for someone else t
=?utf-8?Q?Thorsten_Sch=C3=B6ning?= writes:
> Expectation was that whatever gets created in that DB is owned by the
> new user. But I'm running into the following error:
>> pg_restore: [archiver (db)] could not execute query: ERROR: must be owner
>> of type character varying or type inet
The er
Hi all,
one of my apps and databases uses custom CASTs and is used with the
user "postgres" for historical reasons. I would like to change that to
use a non-superuser for that app+database only. So I dumped the DB
using the C-format and tried to restore into a newly creeated DB:
> createuser --en
Customer is using 10.4 , not 9.5.5.
Does the same argument apply for upgrading to 10.12 ?
Thanks
Danny
-Original Message-
From: Tom Lane
Sent: Sunday, July 19, 2020 6:04 PM
To: Abraham, Danny
Cc: pgsql-gene...@postgresql.org
Subject: [EXTERNAL] Re: PG 9.5.5 cores on AIX 7.1
"Abraha
"Abraham, Danny" writes:
> Slow machine, high stress.
> I think/hope that PG is the victim of an overstressed machine.
> Has anyone faced this issue in the past?
Not to point out the obvious, but you're evidently using parallel
queries, which was a brand new thing in 9.5; and it had its share
of
Slow machine, high stress.
I think/hope that PG is the victim of an overstressed machine.
Has anyone faced this issue in the past?
Thanks
Danny
Segmentation fault in _alloc_initial_pthread at 0x9521474
0x9521474 (_alloc_initial_pthread+0x1d4) e803 ld
r0,0x0(r3)
14 matches
Mail list logo
