On 8/28/23 18:35, Jerry Sievers wrote:
> Adrian Klaver writes:
>
>> On 8/28/23 13:06, Alan Stange wrote:
>>
>>> All,
>>> We recently changed the name of the superuser role in our database,
> My take on this, is that the *postmaster* user is perhaps the o
On 8/28/23 16:11, Adrian Klaver wrote:
> On 8/28/23 13:06, Alan Stange wrote:
>> All,
>>
>> We recently changed the name of the superuser role in our database, and
>> then noticed some issues with the autovacuum processes. We are running
>> 15.3, and had a logi
All,
We recently changed the name of the superuser role in our database, and
then noticed some issues with the autovacuum processes. We are running
15.3, and had a login role, lets call it 'red', which had the superuser
attribute assigned to it. This was the original owner/creator of all
the da
Of course that would be in the manual ;-) Thank you for pointing this
out. We've been doing upgrades the reliable old school way for so long
that I wasn't aware that something better was already well documented.
Thank you,
Alan
On 12/2/21 11:10, Adrian Klaver wrote:
> On 12/2/2
Hello all,
We're running a 13.x installation and looking to upgrade to 14.1. This
is all on Linux servers. We have a main instance running with a number
of hot standby replicas configured. In the past, we have done a
dump/restore on a slow evening and then rsynced all the bits around so
that
On 8/6/21 3:14 PM, Tom Lane wrote:
> Alan Stange writes:
>> In order to track down some bugs, we thought it would be useful to
>> append some comments to the sql being sent to postgresql like this:
>> select foo from bar -- a comment with some metadata
>> however
Hello all,
In order to track down some bugs, we thought it would be useful to
append some comments to the sql being sent to postgresql like this:
select foo from bar -- a comment with some metadata
however, the postgresql server was not including the appended comment in
the log file.
If we
