Re: postgresql-10.3 on unbuntu-17.10 - how??
Re: Adrian Klaver 2018-03-20 <4c40e7c5-efa7-00d7-b891-acc9c1ec7...@aklaver.com> > > However I need to upgrade to 10.3 and the normal "apt update; > > apt upgrade" does not offer 10.3. Also, doing a fresh install > > still installs 10.1. > > https://wiki.postgresql.org/wiki/Apt > "2018-01-17: Ubuntu zesty (17.04) is unsupported now, Ubuntu removed it from > their mirrors " > > > > > Is Pgdg 10.3 even available for ubuntu 17.10? How the heck does > > one upgrade to it? > > 18.04 LTS (Bionic Beaver)?: > > http://apt.postgresql.org/pub/repos/apt/dists/bionic-pgdg/ Ack. We skipped 17.10 and went straight to supporting the upcoming 18.04 (you can already install it). Sorry, there's only 24h a day :( Christoph
Re: postgresql-10.3 on unbuntu-17.10 - how??
Re: Stuart McGraw 2018-03-23 > So what I was thinking of was rebuilding the Pgdg Ubuntu source > package (I'm assuming one is available somewhere). I have had > good results on Fedora backporting current versions of Postgresql > from later fedora's to my invariably outdated version of Fedora > by rebuilding the later version's Fedora postgresql source rpm. > This produces an installable binary package that will satisfy > the dependencies of all those other programs eliminating the > need to rebuild them. I was guessing I could do something > similar in the Ubuntu world. But, moot now fortunately :-) Fwiw, all the packages on apt.postgresql.org are built from the same source package for all distributions (with only the version number changed to reflect the build target), so simply rebuilding the source package for your OS would definitely work. "apt-get source postgresql-10" will download it. (Fine print: there's a few tweaks [1] applied to cater for older distributions that lack newer features, e.g. the postgresql-10 (source) package in Debian wheezy and Ubuntu trusty disables the systemd support, but that's rare exceptions, and really only applies to the "old" distributions still supported.) Re the original "where is artful" question, we try to support the non-LTS releases, but it didn't work out this time. We'll add 18.10 if it becomes clear that the 18.04 LTS packages are incompatible with it. Christoph [1] https://git.postgresql.org/gitweb/?p=pgapt.git;a=blob;f=jenkins/generate-pgdg-source;hb=HEAD#l181
Re: Unknown database folders in base directory
Re: Adarsh Sharma 2018-06-07 > *drwx-- 2 postgres postgres 163840 Mar 19 18:18 2567078690* > *drwx-- 2 postgres postgres 237568 Mar 19 19:10 2567168798* > *drwx-- 2 postgres postgres 151552 Mar 19 19:19 2567176994* > *drwx-- 2 postgres postgres 172032 Mar 19 19:34 2567193375* These have all similar timestamps. Were you repeatedly trying to create new databases at that time, but ran out of disk space and PostgreSQL was panicing? That would explain the issue. You can safely remove old database directories that are not referenced in pg_database - you don't even need to shut down first, as PostgreSQL doesn't know about the files anymore. Christoph
Re: Who and How is responsible for released installations packages and 3rd party packs? (e.g. on https://yum.postgresql.org/9.6/redhat/rhel-7.3-x86_64/)
Re: Devrim Gündüz 2018-08-03 <1cdedaf455c4f326f31b103ab805d48da9914cb7.ca...@gunduz.org> > > What about 3rd party libraries like plv8 - Who and How (based on which > > criteria, which versions) build RPM and upload them there? > > Latest versions of PL/v8 does not build on RHEL/Fedora anymore, at least from > the package build point of view. RPMs are not supposed to download extra > dependencies from elsewhere. Fwiw, I stopped maintaining plv8 in Debian for that reason. The build process is roughly equivalent to downloading all of chromium's dependencies, and build v8 from that. v8 is no longer a shared library, unfortunately. Christoph signature.asc Description: PGP signature
Re: Who and How is responsible for released installations packages and 3rd party packs? (e.g. on https://yum.postgresql.org/9.6/redhat/rhel-7.3-x86_64/)
Re: Bruce Momjian 2018-08-10 <20180810192205.gc7...@momjian.us> > Uh, who is building PL/v8 currently, and for what operating systems? No one? No one is likely correct. Christoph
Re: Who and How is responsible for released installations packages and 3rd party packs? (e.g. on https://yum.postgresql.org/9.6/redhat/rhel-7.3-x86_64/)
Re: Bruce Momjian 2018-08-10 <20180810194407.ge7...@momjian.us> > Wow, OK. That's bad news. So PL/v8 is no longer a viable stored > procedure language? It is bad news, the plv8 upstream is very pleasant to work with. But now building plv8 means building v8 first, which means something like downloading and building the whole chrome toolchain. That's 30 GB of stuff, including binary blobs from the internet. plv8 will work for anyone willing to go through that. It's just not feasible to support it from a packager perspective. Christoph
Re: Upgrading old server
Re: Ekaterina Amez 2019-09-25 <8818b028-bd2d-412e-d4e3-e29c49ffe...@zunibal.com> > We've decided to upgrade our PostgreSQL production servers. First task is > remove an old v7.14 version. It was supposed to be upgraded to a v8.4 > server. The server was installed, several databases where released here but > v7.4 was never migrated. The plan is pg_dump this database and psql it to > existing 8.4 server. After this, we'll pg_upgrade. If you doing dump-restore anyway, why not restore into v11 rightaway? Christoph
Re: pg12 rc1 on CentOS8 depend python2
Re: Tom Lane 2019-09-27 <19495.1569591...@sss.pgh.pa.us> > Another idea might be to bundle them into the plpython package > instead of contrib (and similarly for the plperl transforms). Fwiw, the Debian packages do that. Christoph
Re: pg12 rc1 on CentOS8 depend python2
Re: Devrim Gündüz 2019-09-30 <21705bb57210f01b559ec2f5de8550df586324e2.ca...@gunduz.org> > I think postgresql-contrib-py3 is really the best idea at this point, > otherwise > I cannot see a clean way to make this without breaking existing installations. Users of these (now contrib) modules need to have postgresql12-plpython3 installed anyway, so it's unlikely you'd be breaking anyone's installation. > I cannot move those contrib modules under plpython* subpackage -- I mean, I > *can, but then the installations will break in next upgrade. OTOH, I can add > Requires: -contrb for plpython package, then it will be the same problem. There must be a way to move a file from one package to another? (In .deb, this requires Replaces: sourcedeb (<< newversion) Conflits: sourcedeb (<< newversion) in the target package.) Christoph
Re: Inherited an 18TB DB & need to backup
Re: Rory Campbell-Lange > On 15/05/20, Suhail Bamzena (suhailsa...@gmail.com) wrote: > > Hello All, > > I have very recently inherited an 18 TB DB that is running version 9.2. Push hard to get that upgraded to a supported version. Christoph
PostgreSQL on focal and llvm version
Re: hubert depesz lubaczewski
> Soo... plot thickens.
>
> Looks that pg 12 supplied by pgdg required libllvm9:
>
> =$ apt-cache show postgresql-12 | grep -E '^(Package|Version|Depends):'
> Package: postgresql-12
> Version: 12.9-2.pgdg20.04+1
> Depends: ..., libllvm9 (>= 1:9~svn298832-1~), ...
>
> Package: postgresql-12
> Version: 12.9-0ubuntu0.20.04.1
> Depends: ..., libllvm10 (>= 1:9~svn298832-1~), ...
>
> Package: postgresql-12
> Version: 12.2-4
> Depends: ..., libllvm10 (>= 1:9~svn298832-1~), ...
>
>
> Newer pg12 (12.10) from pgdg also depends on llvm9. Perhaps changing the deb
> to
> use/depend-on llvm10 would solve the problem, for now I'm not sure how to do
> it. Reached to Christoph about it.
Thanks for spotting that. The problem turned out me being not smart
enough to determine the newest llvm version installed; the
not-quite-correct Makefile code failed on "9" < "10".
I have now fixed that problem. Updated postgresql-{11,12,13,14}
packages using libllvm10 instead of libllvm9 are available in
focal-pgdg-testing.
Since this is potentially a breaking change, I'll not push these live
immediately but will give people a chance to test these until next
week.
Christoph
AIX and EAGAIN on open()
Hello, a customer running PG on AIX [1] is occasionally seeing "Resource temporarily unavailable" (EAGAIN) returned by open() calls: [1] We have PostgreSQL 11.13 on powerpc-ibm-aix7.2.5.0, compiled by /opt/IBM/xlc/13.1.0/bin/xlc, 64-bit 2022-05-19 03:28:13 CEST:127.0.0.1(63265):x@x:[64029168]: ERROR: could not open file "base/16401/935915821_fsm": Resource temporarily unavailable 2022-05-19 03:28:13 CEST:127.0.0.1(63265):x@x:[64029168]: CONTEXT: SQL statement "INSERT INTO s[...]" PL/pgSQL function s...() line 12 at SQL statement 2022-05-19 03:28:13 CEST:127.0.0.1(63265):x@x:[64029168]: STATEMENT: PREPARE ... AS insert into ... 2022-04-16 01:45:31 CEST:127.0.0.1(58946):x@x:[20906970]: ERROR: could not access status of transaction 0 2022-04-16 01:45:31 CEST:127.0.0.1(58946):x@x:[20906970]: DETAIL: Could not open file "pg_subtrans/6158": Resource temporarily unavailable. 2022-04-16 01:45:31 CEST:127.0.0.1(58946):x@x:[20906970]: STATEMENT: PREPARE ... AS update ... 2020-12-01 09:24:30 CET:127.0.0.1(59898):x@x:[6227520]: ERROR: could not access status of transaction 0 2020-12-01 09:24:30 CET:127.0.0.1(59898):x@x:[6227520]: DETAIL: Could not open file "pg_subtrans/AC9E": Resource temporarily unavailable. 2020-12-01 09:24:30 CET:127.0.0.1(59898):x@x:[6227520]: STATEMENT: PREPARE ... AS DELETE FROM open() should not return EAGAIN as per POSIX [2], [2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html#tag_16_357_05 and the AIX documentation says it would only return EAGAIN if O_TRUNC is used [3], but as far as I can tell, PG does not use that flag. [3] https://www.ibm.com/docs/en/aix/7.2?topic=o-open-openat-openx-openxat-open64-open64at-open64x-open64xat-creat-creat64-subroutine IBM's reply to the issue back in December 2020 was this: The man page / infocenter document is not intended as an exhaustive list of all possible error codes returned and their circumstances. "Resource temporarily unavailable" may also be returned for O_NSHARE, O_RSHARE with O_NONBLOCK. Afaict, PG does not use these flags either. We also ruled out that the system is using any anti-virus or similar tooling that would intercept IO traffic. Does anything of that ring a bell for someone? Is that an AIX bug, a PG bug, or something else? Christoph -- Senior Consultant, Tel.: +49 2166 9901 187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Geoff Richardson, Peter Lilley Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Re: AIX and EAGAIN on open()
Re: Thomas Munro > > Does anything of that ring a bell for someone? Is that an AIX bug, a > > PG bug, or something else? > > No clue here. Anything unusual about the file system (NFS etc)? Can > you truss/strace the system calls, to sanity check the flags arriving > into open(), and see if there's any unexpected other activity around > open() calls that might be coming from something you're linked > against? Hi, it's local storage, 16Gb SAN, Unity 500 storage, all data is on SSD disks, and file system is JFS2 (mount options are rw,log=INLINE). Good point about the flags, but we don't have access to the servers, so not sure if it will be possible to retrieve strace information. I'll try asking. Thanks, Christoph -- Senior Consultant, Tel.: +49 2166 9901 187 credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Geoff Richardson, Peter Lilley Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Re: Forks of pgadmin3?
Re: Jeff Janes 2019-03-23 > On Fri, Mar 22, 2019 at 8:04 AM Steve Atkins wrote: > > > On Mar 22, 2019, at 10:56 AM, Christian Henz > > There's the BigSQL fork, which had at least some minimal support > > for 10. I've no idea whether it's had / needs anything for 11 > > I just installed BigSQL's v11 of the database to get the pgAdmin3 that > comes with it (I couldn't get the Windows installer to install just > pgAdmin, I had to take the entire server installation along with it) . > Even though it comes with v11, when you start it says it only supports up > to v10, and then gives a series of warnings about catalogs and system admin > functions not being as expected. Once you are past the warnings, it does > work at least on the surface, but I have to think some features aren't > going to work. The BigSQL pgadmin3 "LTS" thing is a giant marketing hoax. Their patch consists of 90% replacing the original logo with their own version. The rest is mostly more re-branding, and then a tiny fraction of the patch establishes compatibility with PostgreSQL 10.0. They fumbled the version check, so it will complain about incompatibilities if you run it against 10.1 or any later version. The Debian pgadmin3 package has patches that actually work, also available on apt.postgresql.org. I don't claim that it is "supporting" PG10/11 in the sense that it knows about all features, but all the warnings on startup are properly avoided. Some day, I should build RedHat/Windows packages from that and put them somewhere... https://salsa.debian.org/postgresql/pgadmin3/tree/master/debian/patches Christoph
Re: Obsolete Linux downloads (Debian) instructions
Re: Daniel Gustafsson > > On 12 Apr 2024, at 12:43, Laura Smith > > wrote: > > > Who do I have to badger to get the obsolete and frankly dangerous Debian > > repo instructions fixed @ https://www.postgresql.org/download/linux/debian/ > > ? I still think that "frankly dangerous" is a gross exaggeration, but the long-due update of the Debian and Ubuntu download pages has now happened. Christoph
Re: Fwd: Regarding tables detach concurrently with run_maintenance_proc()
Re: Durgamahesh Manne > with pg_partman By default proc() does not detach tables concurrently. How > do we implement tables detach concurrently without blocking other sessions > Here queries not using date column to detach tables with > run_maintenance_proc() which is not using concurrently based on the > retention policy which leads to scan all available child tables hence need > to trigger this proc with concurrently option to avoid blocking other child > tables beyond rentention policy while running statements on them You might have more success by filing pg_partman issues at https://github.com/pgpartman/pg_partman/issues > Do we have any other alternative rather than using pg_partman()? Well you can just run the same commands manually that pg_partman would run. Christoph
Re: What generates pg_config.h?
Re: Adrian Klaver 2018-01-06 <67591f85-a910-2e0b-1fdd-9c774eacd...@aklaver.com> > The problem you are running into is that the build process is using both the > older(9.6.5) and newer(10.0) pg_config.h at the same time. Fwiw, all issues I've seen so far of that kind could be resolved by putting -I$(pg_config --includedir-server) before -I$(pg_config --includedir) in the Makefile. I don't know of any PG extension existing in the wild that does not work with having both /usr/include/postgresql/$version/server/pg_config.h and /usr/include/postgresql/pg_config.h installed - and we are packaging a lot of extensions for apt.postgresql.org for non-latest majors. Christoph
Re: Building PostgreSQL old version from source to test vulnerability CVE-2017-7546
Re: Julián Jiménez González 2018-02-21 > I need and would greatly appreciate any help tracking this problem down. I'd try setting gdb breakpoints on the relevant code lines/functions. If it helps, old Ubuntu packages are available there: http://atalia.postgresql.org/morgue/ https://wiki.postgresql.org/wiki/Apt/FAQ#Where_are_older_versions_of_the_packages.3F Christoph
Re: How to pass a list of locations (longitude, latitude) to a PostgreSQL/PostGIS stored function?
Re: Tom Lane > You might be best advised to create a composite > type like "location (long bigint, lat bigint)" and use an array of > that. Or use the geometry types from PostGIS, since you are probably going to do geo lookups on these points anyway. Christoph
Re: password rules
Re: raphi > Sorry for this rather long (first) email on this list but I feel like I had > to explain our usecase and why LDAP is not always as simple as adding a line > to hba.conf. Did you give the "pam" method a try? There are PAM modules for all sorts of password checks. Christoph
