On Wed, 2021-10-20 at 23:29 +0300, Radoslav Nedyalkov wrote:
> We have a busy database that has oid increasing with 50-100M per month.
> There is no oid type across user attributes anywhere nor user tables with
> oids;
> Not sure where this generation comes from. If you can hint me, it would be
I wrote:
> Anyway, it doesn't look like there's much hope of improving this
> aspect without a significant rewrite.
Just to close out this thread: I've now posted such a rewrite at
https://www.postgresql.org/message-id/2273648.1634764485%40sss.pgh.pa.us
regards, tom lane
Radoslav Nedyalkov writes:
> We have a busy database that has oid increasing with 50-100M per month.
> There is no oid type across user attributes anywhere nor user tables with
> oids;
> Not sure where this generation comes from. If you can hint me, it would be
> great.
Lots of short-lived
On Wednesday, October 20, 2021, Radoslav Nedyalkov
wrote:
> Hello all,
> We have a busy database that has oid increasing with 50-100M per month.
> There is no oid type across user attributes anywhere nor user tables with
> oids;
> Not sure where this generation comes from. If you can hint me,
Hello all,
We have a busy database that has oid increasing with 50-100M per month.
There is no oid type across user attributes anywhere nor user tables with
oids;
Not sure where this generation comes from. If you can hint me, it would be
great.
Also what happens when pg_class.oid reaches 4B.
After some further investigation I think I might have actually got this the
wrong way round. I now strongly suspect that what I am seeing is related to
the presence of histogram_bounds for Table A (possibly a bug? or me being
silly).
Looking into the code (
On Wed, 20 Oct 2021 at 20:52, Adrian Klaver
wrote:
> On 10/20/21 08:07, Toomas wrote:
> > Hi Adrian,
> >
> > Thank you for your help. The issue was that when user logged into
> database his session_user user was set as owner of database automatically.
> User had success to change password when
On 10/20/21 08:07, Toomas wrote:
Hi Adrian,
Thank you for your help. The issue was that when user logged into database his
session_user user was set as owner of database automatically. User had success
to change password when session_user = current_user was set before.
I'm not
Hi Adrian,
Thank you for your help. The issue was that when user logged into database his
session_user user was set as owner of database automatically. User had success
to change password when session_user = current_user was set before.
BR,
Toomas
> On 20. Oct 2021, at 17:45, Adrian Klaver
Hi all
I have a Postgres/PostGIS database with two separate database tables each
of which has the following column structure:
- identifier (text)
- geometry (geometryz,27700)
- properties (jsonb)
I have created a GIN index (jsonb_path_ops) over the properties column on
both tables.
As I
On 10/20/21 07:38, Toomas wrote:
Hi,
Is there any possibilities that db user can change own password?
There is no difference does the user uses ALTER command or \password
meta-command, result is the same - response is “permission denied”.
dbname=> \password
Enter new password:
Enter it
Hi,
Is there any possibilities that db user can change own password?
There is no difference does the user uses ALTER command or \password
meta-command, result is the same - response is “permission denied”.
dbname=> \password
Enter new password:
Enter it again:
ERROR: permission denied
BR,
On Tue, Oct 19, 2021 at 10:31 PM Kristjan Mustkivi
wrote:
> Postgres v11.12. Getting "ERROR: publication "new_rep_pub" does not
> exist" after renaming an existing publication. And the only way to get
> it working seems to start from scratch. What am I missing?
Ok, the recipe works perfectly in
13 matches
Mail list logo
