Tag Info

New answers tagged

0

If no delete or update happened, autovacuum shouldn't process the table, per autovacuum_analyze_threshold. See Automatic Vacuuming for the relevant configuration parameters. You may set log_autovacuum_min_duration to zero to help figure out what's being autovacuumed. In any case, it is possible to completely disable autovacuum for a particular table, with: ...


0

If You use Linux you should list processes with ps aux and find Autovacuum process. Then just kill it(autovacuum should be working as another process if it's turned on).


0

repmgr is a nice place to go indeed. If you use pacemaker/corosync you shoud check this as well, its a Resource Agent handling repmgr : https://github.com/xmm/repmgr. Pelase note you might need to either patch the provided Resource Agent or patch repmgr.


0

The answer is: "Yes, sure you can." But I doubt you wanted to ask that. Obviously, you need to make sure you only kill processes that need killing. If possible, it's best done with the same role as the targeted processes to avoid collateral damage - only superusers can terminate processes of other roles. Related: How do I detach all other users from a ...


2

pg_settings is a view, not a table. And every session has its own version of it. Per documentation: The change only affects the value used by the current session. The attempt to access it from a different connection (session) is futile.


0

It may be that i was doing something wrong here since I am very new to postgres. But this only solved the first part of the problem for me - setting the privileges on all existing tables. In order for permissions to be correctly set for my user on new tables that are created i has to set default permissions for the user: ALTER DEFAULT PRIVILEGES IN SCHEMA ...


2

The issue is covered in this detailed blog. In short, the master and the standby servers must all have archive_mode = on and an archive_command, until 9.3 which removes this requirement.


2

Also addressing the question in the comments. Role public Per documentation: The key word PUBLIC indicates that the privileges are to be granted to all roles, including those that might be created later. PUBLIC can be thought of as an implicitly defined group that always includes all roles. Bold emphasis mine. Membership in public cannot be ...


1

To address the question of why test can SELECT from tables without a GRANT, it is because you have not explicitly run REVOKE for the ability to connect to your database(s) from PUBLIC, and then explicitly run GRANT for your test user: REVOKE connect ON DATABASE testdb FROM PUBLIC; GRANT connect ON DATABASE testdb TO test; Once that is done, you would ...



Top 50 recent answers are included