Re: locks within select

On Monday, December 13, 2021, Marc Millas wrote: > > I was wondering if for example, within a join, some kind of lock may be > acquired so that the dataset concerned is not changed during execution ? > (for example a delete then autovacuum ??) > Read this primer on MVCC from the docs: https://ww

Re: log shipping with pg_receivewal

On Tue, Dec 14, 2021 at 9:55 AM Marc Millas wrote: > > Hi, > postgres 13 question, > > if I setup pg_receivewal from a primary instance to a given directory, and > then setup a standby with a restore_command pointing to that directory,, the > changes on the primary are applied on the standby at

Re: log shipping with pg_receivewal

On Tue, Dec 14, 2021 at 05:25:04AM +0100, Marc Millas wrote: > My question: as the synchronous option is supposed to make pg_receivewal > write transaction immediately in the wal files, is there a way to ask the > standby to apply them on the fly ie. without waiting a wal file change ? Nope, there

log shipping with pg_receivewal

Hi, postgres 13 question, if I setup pg_receivewal from a primary instance to a given directory, and then setup a standby with a restore_command pointing to that directory,, the changes on the primary are applied on the standby at each wal change. And this, even if I run pg_receivewal with the --s

locks within select

Hi, To my understanding, a select on a table does acquire an access share lock on that table. my question is: is there any other kind of lock that a select may acquire ? obviously, all explicit locking schemes like select for update, etc... is out of this question scope. I was wondering if for ex

Re: Why can't I have a "language sql" anonymous block?

On 12/13/21 13:15, Bryn Llewellyn wrote: Well… that’s the answer: “nobody thought it’d be useful”. Thanks, Tom. The difference between using a “language sql” anonymous block and just executing the contained SQL statements? is partly a clear declaration of the intent of your code and a guarante

Re: When Update balloons memory

Klaudie Willis writes: > So, it seems like the index is central cog here: >> create index ind1 on alpha ((deltatime::date)); > where "alpha" is a partition tableset partitioned by (deltatime::date) > The general and simple updates like: >> update alphatable set gamma=gamma || "#postfix#" > makes t

Re: When Update balloons memory

Thanks for the insight! I have recreated the problem on a different machine and installation where I was more free to experiment to isolate what causes this. So, it seems like the index is central cog here: > create index ind1 on alpha ((deltatime::date)); where "alpha" is a partition tableset pa

Re: Why can't I have a "language sql" anonymous block?

Well… that’s the answer: “nobody thought it’d be useful”. Thanks, Tom. The difference between using a “language sql” anonymous block and just executing the contained SQL statements? is partly a clear declaration of the intent of your code and a guarantee that all the statements are sent from cl

Properly handling aggregate in nested function call

I am working on a C aggregate function that returns a numeric[] result. If I execute the aggregate and return the results directly in my SQL, I get the expected results. For example: SELECT vec_agg_mean(nums) FROM measurements; NOTICE: avg 0 = 1.2300 NOTICE: avg 1 = 1.97000

Re: Why can't I have a "language sql" anonymous block?

Bryn Llewellyn writes: > Was there a deliberate decision not to allow a “language sql” anonymous > block? Or is it just that nobody thought that it would be useful? I think nobody thought it'd be useful. What's the difference from just executing the contained SQL statements? (If DO blocks had

Why can't I have a "language sql" anonymous block?

My question is this: Was there a deliberate decision not to allow a “language sql” anonymous block? Or is it just that nobody thought that it would be useful? Here’s what I mean. First, something that works (using PG Version 14.1): create procedure p_plpgsql() security definer language plpg

Re: Where can I follow the progress of "Pluggable Storage" development?

Thank you, I will check it out. Em seg., 13 de dez. de 2021 16:19, Fabrízio de Royes Mello < fabri...@timbira.com.br> escreveu: > > Em seg., 13 de dez. de 2021 às 11:35, Jean Baro > escreveu: > > > > Hello there. > > > > I am just an enthusiast of PostgreSQL and would like to get more > informat

Re: Where can I follow the progress of "Pluggable Storage" development?

Em seg., 13 de dez. de 2021 às 11:35, Jean Baro escreveu: > > Hello there. > > I am just an enthusiast of PostgreSQL and would like to get more information about Pluggable Storage's progress (or not). Please. > We already support it since version 12 released in 2019 but we named it as "Table Acce

Re: Error : /usr/local/share/lua/5.1/pgmoon/init.lua:211: don’t know how to auth: 10

Kaushal Shriyan writes: >> Error: >> /usr/local/share/lua/5.1/pgmoon/init.lua:211: don't know how to auth: 10 I believe this is failing on a SCRAM password challenge. You need to update the client-side code to a version that knows about SCRAM, or else change your password to be MD5-hashed instea

Error : /usr/local/share/lua/5.1/pgmoon/init.lua:211: don’t know how to auth: 10

Hi, I am running CentOS Stream release 8 with kong-2.6.0-1.x86_64 with the below PostgreSQL database versions. postgresql14-libs-14.1-1PGDG.rhel8.x86_64 postgresql14-14.1-1PGDG.rhel8.x86_64 postgresql14-server-14.1-1PGDG.rhel8.x86_64. #kong migrations bootstrap -c /etc/kong/kong.conf --vv > 202

RE: [EXTERNAL] Re: performance expectations for table(s) with 2B recs

> > >From: Peter J. Holzer hjp-pg...@hjp.at >Sent: Friday, December 10, 2021 3:43 PM >To: >pgsql-general@lists.postgresql.org >Subject: Re: [EXTERNAL] Re: performance expectations for table(s) with 2B recs > >On 2021-12-10 18:04:0

Re: Postgresql + containerization possible use case

Thank you Rainer, I'll have to play a little bit myself, and read some serious docs about it, in order to fully comprehend your thoughts. I'll revisit your positions I hope. On 13/12/21 5:11 μ.μ., Rainer Duffner wrote: Am 13.12.2021 um 12:41 schrieb Achilleas Mantzios mailto:ach...@matrix.ga

Re: Postgresql + containerization possible use case

On 13/12/21 5:55 μ.μ., Adrian Klaver wrote: On 12/13/21 03:41, Achilleas Mantzios wrote: Hi Rainer, On 13/12/21 11:50 π.μ., Rainer Duffner wrote: So Docker is NOT free? Please share your thoughts? I am a complete noob. Take a look here: https://www.docker.com/pricing Thank you Adrian!

Re: Postgresql + containerization possible use case

Hi On 13/12/21 6:11 μ.μ., Benedict Holland wrote: Check out rolling updates with kubernetis and yes, a containerized postgresql environment is likely the best option. The really nice bit about containers is that you don't actually care about underlying hardware. You need a docker daemon. K8 manag

Re: Postgresql + containerization possible use case

Check out rolling updates with kubernetis and yes, a containerized postgresql environment is likely the best option. The really nice bit about containers is that you don't actually care about underlying hardware. You need a docker daemon. K8 manages clusters and it sounds like your use case would b

Re: Postgresql + containerization possible use case

Hi Berto, On 13/12/21 3:03 μ.μ., Bèrto ëd Sèra wrote: On Mon, 13 Dec 2021 at 12:41, Achilleas Mantzios mailto:ach...@matrix.gatewaynet.com>> wrote: Hmm, I don't know about that. The hardware is given (existing) and limited. You are like the 2nd person who warned about comms as being an

Re: Postgresql + containerization possible use case

On 12/13/21 03:41, Achilleas Mantzios wrote: Hi Rainer, On 13/12/21 11:50 π.μ., Rainer Duffner wrote: So Docker is NOT free? Please share your thoughts? I am a complete noob. Take a look here: https://www.docker.com/pricing Achilleas Mantzios DBA, Analyst, IT Lead IT DEPT Dynacom Tanker

Re: Postgresql + containerization possible use case

> Am 13.12.2021 um 12:41 schrieb Achilleas Mantzios > : > > Our setup has been open source since forever. So licenses for something that > used to be free for ages would be hard to introduce. That ist totally understandable. 140x800 for the RHEL license alone is over 100k/year. Though you mi

Where can I follow the progress of "Pluggable Storage" development?

Hello there. I am just an enthusiast of PostgreSQL and would like to get more information about Pluggable Storage's progress (or not). Please. Thanks

Re: Postgresql + containerization possible use case

Hi Rainer, On 13/12/21 11:50 π.μ., Rainer Duffner wrote: Am 10.12.2021 um 13:01 schrieb Achilleas Mantzios mailto:ach...@matrix.gatewaynet.com>>: On 10/12/21 1:24 μ.μ., o1bigtenor wrote: On Fri, Dec 10, 2021 at 3:24 AM Achilleas Mantzios mailto:ach...@matrix.gatewaynet.com>> wrote: H

Re: Postgresql + containerization possible use case

> Am 10.12.2021 um 13:01 schrieb Achilleas Mantzios > : > > On 10/12/21 1:24 μ.μ., o1bigtenor wrote: >> >> >> On Fri, Dec 10, 2021 at 3:24 AM Achilleas Mantzios >> mailto:ach...@matrix.gatewaynet.com>> wrote: >> Hi >> we are running some 140 remote servers (in the 7 seas via satellite >> co

LibPQ: Lifetime of PGresult passed in to PQnoticeReceiver callback

Hi, The doc at https://www.postgresql.org/docs/current/libpq-notice-processing.html is not clear to me on whether it should be PQclear'd or not. Who manages the lifetime of that PGresult? Also, the "could be called as long as either the PGconn or PGresult exist" mention, implies we do not need to

Re: Postgresql + containerization possible use case

On 11/12/21 6:31 μ.μ., Michael Lewis wrote: Interesting. I'm not sure that moving an image for a VM with Postgres is compatible with the goal of minimizing time/data but if upgrades are yearly or something, perhaps that is reasonable. It has been 9+ years since that post as well. But the full dat

Re: Postgresql + containerization possible use case

Hi Michael, Adrian On 10/12/21 11:28 μ.μ., Adrian Klaver wrote: On 12/10/21 12:06, Michael Lewis wrote: On Fri, Dec 10, 2021, 2:24 AM Achilleas Mantzios mailto:ach...@matrix.gatewaynet.com>> wrote:     Hi     we are running some 140 remote servers (in the 7 seas via satellite     connections)

Re: Postgresql + containerization possible use case

Hi Adrian On 10/12/21 6:01 μ.μ., Adrian Klaver wrote: On 12/10/21 01:24, Achilleas Mantzios wrote: Hi The idea for future upgrades is to containerize certain aspects of the software. The questions are (I am not skilled in docker, only minimal contact with lxd) : - is this a valid use case

Re: Postgresql + containerization possible use case

On 10/12/21 4:02 μ.μ., o1bigtenor wrote: The 'book' says everything is wonderful - - - - if it were me - - - no guarantees until 'I' am sure. If they want it - - - - and want you to guarantee it - - - - I wouldn't touch it myself!! (That's my opinion and worth all of what you paid for it. I ha