Re: Upgrade mode will prevent the installer .... (pgAgent)
Boylan, Ross wrote: I can't interpret this message, or figure out whether I should select the option or not. My main problem is that my intuition is that checking "upgrade mode" will perform an upgrade, but the text of the message seems to say that checking upgrade mode will NOT perform an upgrade. Since I don't know if images are OK, I'll try to transcribe the message: "Upgrade mode will prevent the installer from modifying the database cluster by loading pgAgent SQL scripts in preparation for upgrading from earlier releases of PostgreSQL using the pg_upgrade tool." It's a fine example of twisty English that's been compacted down for length instead of clarity; it took me a couple of passes to decide this is probably what it means: If you check the box, the installation process of pgAgent will not load certain (any?) pgAgent scripts. These scripts are for pgAgent's own internal use, when you upgrade Postgres itself using pg_upgrade. Context: Running the Windows Installer for v12 with v11 still installed on the machine. After the main install I selected several packages, including pgagent, which I also selected for v11. I have a mild preference for treating 12 as a clean install without migrating anything from 11, since it was just a test database. It sounds like you probably want to leave this unchecked, based on "I have a mild preference for treating 12 as a clean install without migrating anything from 11". -kgd
Re: Tablespace setup issue
Sébastien Bihorel wrote: Hi, I am new to this list and reaching out because I am having troubles setting up a local PostgreSQL database on my laptop. Maybe, as a preamble, I should say that I am pretty much a novice trying to teach myself and get practical experience about database and SQL queries (I have some general idea about relational DB structure and operation but no actual experience creating a DB or writing SQL queries). Some background about my setup: - OS: my laptop runs Linux Mint 19.1 (a flavor of ubuntu 18.04); psql 12.1 was installed along with pgadmin 4. There is a single user (ie, sebastien) on this machine and the group postgres exists. I have also successfully created a database (sebastien) for the new superuser sebastien, and a schema (test) within this database. Now, I would like to assign a particular disk location for the tablespace used by this database but I am getting all kinds of errors apparently linked to folder permissions. The location is /home/sebastien/data/pgdata96_sebastien This is probably not what going to do what you want. At best it will be a spaghetti pile of mixed up permissions, working against several sets of common practice and security restrictions, to get it to work. I wouldn't be surprised if you ran into SELinux or AppArmor restrictions too (or another similar system, I think there are a couple more). has the following properties: /home/sebastien/data $ ls -l drwxr-xr-x 2 sebastien postgres 4096 Nov 19 09:14 pgdata96_sebastien The manual states "The location must be an existing, empty directory that is owned by the PostgreSQL operating system user." So, I am not sure what I am doing wrong. Web searches ran on these error messages did not enlighten me more... The files and directories that the Postgres server manages MUST be owned by the OS user "postgres". This directory is still owned by your OS user sebastien. You will probably also have to play games with the permissions on /home/sebastien and /home/sebastien/data to get this to work at all. Your OS user will not be able to usefully read any files that Postgres creates directly, so there's not much value in putting them outside of the default directory tree under /var/lib/postgres. Postgres is pretty good about managing its own data files; unless you need to quickly glue on more storage without disturbing an active production server, or need to put a particular table or database on expensive-but-faster (or possibly slower-but-much-larger-and-cheaper) storage, you probably don't need to use tablespaces. For experimenting with them it would be a lot simpler to create a directory (or two, or three) under /var/lib/postgres for them, owned by the postgres OS user. -kgd
Re: Mail list manager request
Rich Shepard wrote: Looking at the postgresql.org web site I could not find the mail list manager for direct contact so I apologize for writing here. I use procmail to sort incoming messages to the proper file. Messages from the mail list come with varying information at the bottom of the headers; it could be From:, Cc:, cc:, or in two cases List-ID:. Because of the inconsistency I cannot get a recipe that consistently puts the mail list messages in the proper file so they end up in my alpine INBOX where I need to manually redirect them; Please modify the MLM software to use the List-Id: on all messages that way my procmail recipe: :0: * ^List-Id:.* database will put incoming threads and messages where they belong. At a not-entirely-wild guess, based on replies to your recent couple of posts, the messages that went astray were the direct mail copies that never passed through the list in the first place. I use an almost identical recipe myself (and a matching one for psql-admin) and I don't recall seeing stray mail since the list platform migration. I catch most of those direct-mail copies with this addition: :0 * ^TO_pgsql-.*@(lists.)?postgresql.org $DEFAULT/.postgres/ Personally, I try to keep mail to any of the lists I read purely on-list unless a personal CC has been explicitly asked for. -kgd
