On 5/15/19 5:29 PM, Julie Nishimura wrote:
Guys, thank you everybody who tried to solve this mystery! It is solved
now. I went through the logs and found those "alter database" commands,
based on host and time, I've just found shell script which was executing
from crontab and setting all databa
Guys, thank you everybody who tried to solve this mystery! It is solved now. I
went through the logs and found those "alter database" commands, based on host
and time, I've just found shell script which was executing from crontab and
setting all databases (except system ones and control) default
On 5/15/19 3:28 PM, Julie Nishimura wrote:
Nope, I did not...
pg_roles only shows "rolconfig" as {default_transaction_read_only=true}
for some users...
The only other commands I ran between creation of tablespace and alter
dbs are:
grant all on tablespace vol4 to public;
grant create on ta
Nope, I did not...
pg_roles only shows "rolconfig" as {default_transaction_read_only=true} for
some users...
The only other commands I ran between creation of tablespace and alter dbs are:
grant all on tablespace vol4 to public;
grant create on tablespace vol4 to public;
__
No, Rob, old existing tables are still on other volumes (the are almost 20 tb),
only new tables are now created on new volume
From: Rob Sargent
Sent: Wednesday, May 15, 2019 2:02 PM
To: pgsql-general@lists.postgresql.org
Subject: Re: default_tablespace in 8.3 pos
On 5/15/19 3:01 PM, Julie Nishimura wrote:
No, I did not have them at all in my script. I did not touch neither
these three dbs, nor like some others that I did not intend to alter,
but they are altered regardless. Or unless this is what pg_database
reports back to me... What is even more inter
that makes sense, thanks!
From: Adrian Klaver
Sent: Wednesday, May 15, 2019 3:15 PM
To: Julie Nishimura; David G. Johnston
Cc: pgsql-general@lists.postgresql.org
Subject: Re: default_tablespace in 8.3 postgresql
On 5/15/19 3:01 PM, Julie Nishimura wrote:
> No, I
On 5/15/19 3:01 PM, Julie Nishimura wrote:
No, I did not have them at all in my script. I did not touch neither
these three dbs, nor like some others that I did not intend to alter,
but they are altered regardless. Or unless this is what pg_database
reports back to me... What is even more inter
No, I did not have them at all in my script. I did not touch neither these
three dbs, nor like some others that I did not intend to alter, but they are
altered regardless. Or unless this is what pg_database reports back to me...
What is even more interesting, if I use PGAdmin for one of the dbs
On 5/15/19 2:45 PM, Julie Nishimura wrote:
Adrian, only first 3 (which are template0, postgres, control). Rest of
them are set to vol4.
Do the script(s) reflect this?
In other words did you have a script for each and every database and was
the default_tablespace set different in some of them?
Adrian, only first 3 (which are template0, postgres, control). Rest of them are
set to vol4.
The only explanation I would have that all of those databases which have
tablespace vol4 as default were copied from template1 without explicitly
specified tablespace name, and "control" was created wit
On 5/15/19 2:15 PM, Julie Nishimura wrote:
Sure, thank you guys!
CREATE TABLESPACE vol4
OWNER postgres
LOCATION '/data/vol4';
ALTER DATABASE tables_ericb
SET default_tablespace = 'vol4';
ALTER DATABASE conversion_feasibility_too
SET default_tablespace = 'vol4';
... and so on for 60 dbs
Sure, thank you guys!
CREATE TABLESPACE vol4
OWNER postgres
LOCATION '/data/vol4';
ALTER DATABASE tables_ericb
SET default_tablespace = 'vol4';
ALTER DATABASE conversion_feasibility_too
SET default_tablespace = 'vol4';
... and so on for 60 dbs...
but not for all 70+
___
On 5/15/19 1:57 PM, Julie Nishimura wrote:
This puzzles me too! I found that bizarre myself. What is even more
interesting, we have about 80 databases, and all of them now have
default_tablespace=vol4, except only one - "control" database. The only
explanation I would have that all of those dat
On 5/15/19 2:57 PM, Julie Nishimura wrote:
This puzzles me too! I found that bizarre myself. What is even more
interesting, we have about 80 databases, and all of them now have
default_tablespace=vol4, except only one - "control" database. The
only explanation I would have that all of those da
This puzzles me too! I found that bizarre myself. What is even more
interesting, we have about 80 databases, and all of them now have
default_tablespace=vol4, except only one - "control" database. The only
explanation I would have that all of those databases which have tablespace vol4
as defaul
On 5/15/19 1:01 PM, Julie Nishimura wrote:
Adrian, thanks for your reply.
This is very interesting behavior...
Those databases have been created long time ago, only some tables in
them were created today.
So, make it more clear: lets say we have 5 user databases, 5 tables in
each db, + template
On Wed, May 15, 2019 at 1:01 PM Julie Nishimura
wrote:
> However, since I have modified template1 (and most likely, those databases
> were copied from it in the past), it changed default_parameter for them as
> well.
>
This seems unlikely to be the case - changing template1 should not be
affecti
Adrian, thanks for your reply.
This is very interesting behavior...
Those databases have been created long time ago, only some tables in them were
created today.
So, make it more clear: lets say we have 5 user databases, 5 tables in each db,
+ template0, template1, . I have modified 3 user databa
On 5/15/19 12:39 PM, Julie Nishimura wrote:
Hello, I have created new tablespace on a new drive yesterday and
modified some of existing databases to use this tablespace as default,
like this:
ALTER DATABASE xxx
SET default_tablespace = 'vol4';
So, this command did not physically move any exist
Hello, I have created new tablespace on a new drive yesterday and modified some
of existing databases to use this tablespace as default, like this:
ALTER DATABASE xxx
SET default_tablespace = 'vol4';
So, this command did not physically move any existing tables/indices on the
database xxx, but al
On 5/15/19 2:37 AM, Prakash Ramakrishnan wrote:
Hi Adrian,
I don't much about pgbackrest i think it will take backup from archives
Now only one the issue means perl cant load.
I don't use pgBackRest so I am speculating now, but I believe your issue
is due to mixing local and remote operation
Hi Adrian,
I don't much about pgbackrest i think it will take backup from archives Now
only one the issue means perl cant load.
Regards,
Prakash.R
On Tue, May 14, 2019 at 8:15 PM Adrian Klaver
wrote:
> On 5/14/19 7:40 AM, Prakash Ramakrishnan wrote:
> > Hi Adrian,
> >
> > Prod server retention
Hello,
Thank You for the response.
Yes that's possible to monitor replication delay. But my questions were
not about monitoring network issues.
I use exactly wal_sender_timeout=1s because it allows to detect
replication problems quickly.
So, I need clarification to the following questions:
Is
24 matches
Mail list logo
