Re: Question about pg_upgrade from 9.2 to X.X
Moving to -general list (-hackers is for development topics like proposed patches and patch reviews and beta testing and crash reports). On Thu, Feb 28, 2019 at 10:13:58AM -0800, Perumal Raj wrote: > could not load library "$libdir/pg_reorg": > ERROR: could not access file "$libdir/pg_reorg": No such file or directory As Sergei said, you can run pg_dump -s and look for references to reorg, and drop them. Or, you could try this: CREATE EXTENSION pg_reorg FROM unpackaged; Or maybe this: CREATE EXTENSION pg_repack FROM unpackaged; If that works, you can DROP EXTENSION pg_repack; Otherwise, I think you can maybe do something like: DROP SCHEMA pg_repack CASCADE; -- or, DROP SCHEMA pg_reorg CASCADE; Please send output of: \dn
Re: Future Non-server Windows support???
On Sun, 03 Mar 2019 08:30:48 +0100, Laurenz Albe wrote: >Bill Haught wrote: >> My main concern is that Microsoft has Enterprise versions of Windows and >> versions for everything else which makes me wonder if at some point >> Windows versions for desktop use may not have features needed by some >> database applications or differences between the versions may be enough >> to necessitate slight tweaks to code and compiling additional versions. > >Speaking as a semi-ignorant, I had the impressions that all Windows versions >are pretty similar under the hood (with occasional annoying behavior changes), >and most of the differences are on the GUI level, while the C API is pretty >much the same. > >Yours, >Laurenz Albe Server versions are optimized for running background services rather than interactive programs. I don't know all the differences offhand, but I do know the servers use different algorithms (not just settings) for scheduling, memory management, and file caching. It isn't possible to tweak a Windows desktop into a server with just settings - the server actually is running (at least some) different code. George
FDW and remote cursor_tuple_fraction
Hi, One reason the remote plans via FDW are different than the plans of queries running directly on the remote server is that a cursor is used, which is optimized for low number of rows according to cursor_tuple_fraction. Is there any way to set parameters that affect the queries on the remote via FDW? If not, is there any plan to introduce such setting? -- Regards, Peter
Re: FDW and remote cursor_tuple_fraction
On Sun, Mar 3, 2019 at 12:38 PM auxsvr wrote: > Hi, > > One reason the remote plans via FDW are different than the plans of > queries running directly on the remote server is that a cursor is used, > which is optimized for low number of rows according to > cursor_tuple_fraction. Is there any way to set parameters that affect the > queries on the remote via FDW? If not, is there any plan to introduce such > setting? > It is a bit ugly, but there is this: alter server foo options (options '-c cursor_tuple_fraction=1.0'); Cheers, Jeff
Re: support for JSON Web Token
On Sat, Mar 2, 2019 at 4:09 PM Eugen Stan wrote: > Hi, > > I would like to advocate forJSON web token support in PostgreSQL. > > JWT tokens are used in a lot of web applications and I think there are > some very nice use cases for passing the token down to PostgreSQL. > pgjwt author here. While I do agree with you that a direct integration would simplify a few things, the idea doesn't really bring enough benefit to overcome some downsides. > Some of the first thing that comes to mind is pairing it with row level > security to implement authorization policies and data access directly in > DB. > It's possible to do this now, tools like PostgREST and Postgraphile use a pattern where they log in as an Anonymous user but when they get a valid JWT, they SET ROLE to the correct user. It's also possible to inspect jwt claims in RLS policy checks via variables that are set on each query. It's worth noting that neither of these projects use pgjwt but rather use the libraries that come with their runtimes. But more abstractly how would this integration work? Postgres does not speak HTTP, you'd have to extend the client protocol. That's gonna be a huge hurdle since its a large change to a lot of code outside of postgres itself. > I've did a bit of research and I found some prior work in [pgjwt] and > [postgres-jwt-prototype] . > > It seems to be pretty easy to support since most of the work is done: > PostgreSQL has crypto support via pgcrypto and has native JSON handling > functions. > pgcrypto only supports secret key signing with hmac, but it doesn't support public key signing. pgjwt was always just an expedient tool, for me at least, to use as an early adopter of PostgREST. It is nice to be able to generate valid jwts from the db with a secret. But for any more serious use it's going to need not only work to pgcrypto or a gratuitous self-plug for pgsodium (https://github.com/michelp/pgsodium) to support public key signing and it's going to need some eyeballs from real security people. I wrote them and I personally wouldn't use pgjwt (other than trival key generation) or pgsodium for production use without some more buy in from serious security people. That's huge hurdle #2. > JWT is a widely used technology, especially in web applications. > > This is why I think PostgreSQL should adopt a JWT extension in contrib. > > I believe PostgreSQL will benefit, especially in the web apps use. > > > What do you think? > > What would it take for a JWT extension to be added to postgresql contrib > or the official postgresql extensions ? > I like your enthusiasm for the idea, but it has some serious hurdles noted. In the mean time, if you're idea is to get working quickly with postgres and JWT, I would look at PostgREST and Postgraphile, and I hear Hasura is quite cool too although I don't have any firsthand experience with it. -Michel > > > Thanks, > > Eugen > > [pgjwt] https://github.com/michelp/pgjwt > > [postgres-jwt-prototype] https://github.com/larsar/postgres-jwt-prototype > > > >
Re: Future Non-server Windows support???
On Sun, Mar 03, 2019 at 08:30:48AM +0100, Laurenz Albe wrote: > Speaking as a semi-ignorant, I had the impressions that all Windows versions > are pretty similar under the hood (with occasional annoying behavior changes), > and most of the differences are on the GUI level, while the C API is pretty > much the same. There are multiple ways to build Postgres code on Windows: MSVC, Cygwin, MinGW. I cannot speak much for the MSI and packaging stuff delivered by companies which are active in the community and others, but for what it's worth the Windows port is still supported in the core code, and we have folks interested in it (just committed a patch to fix a rather old problem with MSVC port 30 minutes ago). -- Michael signature.asc Description: PGP signature
Re: Question about pg_upgrade from 9.2 to X.X
Thanks.Will decently try that option and keep you posted. Thanks again for redirecting to right group. Perumal Raju On Sun, Mar 3, 2019, 6:51 AM Justin Pryzby wrote: > Moving to -general list (-hackers is for development topics like proposed > patches and patch reviews and beta testing and crash reports). > > On Thu, Feb 28, 2019 at 10:13:58AM -0800, Perumal Raj wrote: > > could not load library "$libdir/pg_reorg": > > ERROR: could not access file "$libdir/pg_reorg": No such file or > directory > > As Sergei said, you can run pg_dump -s and look for references to reorg, > and > drop them. > > Or, you could try this: > CREATE EXTENSION pg_reorg FROM unpackaged; > > Or maybe this: > CREATE EXTENSION pg_repack FROM unpackaged; > > If that works, you can DROP EXTENSION pg_repack; > > Otherwise, I think you can maybe do something like: > DROP SCHEMA pg_repack CASCADE; -- or, > DROP SCHEMA pg_reorg CASCADE; > > Please send output of: \dn >
