Re: Proposed Chinese Translation of Community Code of Conduct

Hello, The Chinese translation looks good. regards, Bo Peng On Fri, 21 May 2021 09:58:12 -0700 Stacey Haysler wrote: > The PostgreSQL Community Code of Conduct Committee has received a draft of > the Chinese translation of the Code of Conduct Policy updated August 18, 2020 > for review. > Th

Re: The contents of the pg_timezone_names view bring some surprises

Tom, David, Adrian, and Peter—thank you all very much for taking an interest in my questions. Your responses have, collectively, been an enormous help. I deleted the text of the exchanges in this particular branch of the overall discussion because it's become rather difficult to work out who sai

Re: Postgres prepare statement caching issue in postgres command line

On 5/22/21 1:25 PM, Soumya Prasad Ukil wrote: I have been using postgres prepare statement feature through JDBC. I could see the same prepare statement multiple times, parsing is not happening in postgres backend, which is expected. However I do the same in psql command line, that does not happ

Re: Postgres prepare statement caching issue in postgres command line

On 5/22/21 4:11 PM, Tom Lane wrote: Soumya Prasad Ukil writes: I have been using postgres prepare statement feature through JDBC. I could see the same prepare statement multiple times, parsing is not happening in postgres backend, which is expected. However I do the same in psql command line,

Re: Framework for 0 downtime deploys

On Sat, May 22, 2021 at 11:11:46AM +, Zahir Lalani wrote: > > Confidential > > > Hello All > > > > I wonder if I could garner some of the wealth of experience on this group: > > > > Our current application deployments

Re: Postgres prepare statement caching issue in postgres command line

Soumya Prasad Ukil writes: > I have been using postgres prepare statement feature through JDBC. I could > see the same prepare statement multiple times, parsing is not happening in > postgres backend, which is expected. However I do the same in psql command > line, that does not happen. It goes

Re: Fwd: Proposed Chinese Translation of Community Code of Conduct

On Sat, May 22, 2021 at 12:18 PM Peter J. Holzer wrote: > > On 2021-05-21 12:35:49 -0500, Ron wrote: > > I see the attachments in your first email. > > Fascinating. I don't in the normal view but do see them in the MIME > structure: > > I 1 [multipa/alternativ, 7bit, 180K]

Postgres prepare statement caching issue in postgres command line

I have been using postgres prepare statement feature through JDBC. I could see the same prepare statement multiple times, parsing is not happening in postgres backend, which is expected. However I do the same in psql command line, that does not happen. It goes to parsing every time I execute Usi

Re: The contents of the pg_timezone_names view bring some surprises

On 5/22/21 10:55 AM, Peter J. Holzer wrote: On 2021-05-22 08:26:27 -0700, Adrian Klaver wrote: On 5/22/21 3:09 AM, Peter J. Holzer wrote: On 2021-05-19 06:57:13 -0700, Adrian Klaver wrote: On 5/18/21 11:31 PM, Bryn Llewellyn wrote: This claims (as I read it) that a time zone abbreviation uniq

Re: The contents of the pg_timezone_names view bring some surprises

On 2021-05-22 08:26:27 -0700, Adrian Klaver wrote: > On 5/22/21 3:09 AM, Peter J. Holzer wrote: > > On 2021-05-19 06:57:13 -0700, Adrian Klaver wrote: > > > On 5/18/21 11:31 PM, Bryn Llewellyn wrote: > > > > This claims (as I read it) that a time zone abbreviation uniquely > > > > determines an off

Re: The contents of the pg_timezone_names view bring some surprises

On 5/22/21 3:09 AM, Peter J. Holzer wrote: On 2021-05-19 06:57:13 -0700, Adrian Klaver wrote: On 5/18/21 11:31 PM, Bryn Llewellyn wrote: This seems to be at odds with what section “8.5.3. Time Zones” at https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES

Re: PG 14 - can't upgrade from a database using an aggregate with anyelement and anyarray

Tom Lane schrieb am 22.05.2021 um 15:25:>> this aggregate can be created without problems on PG 13 and before: CREATE AGGREGATE array_accum(anyelement) ( SFUNC = array_append, STYPE = anyarray, INITCOND = '{}' ); However, that fails with PG 14beta1 because ar

Re: pgbackrest - hiding the encryption password

On 5/22/21 5:52 AM, Peter J. Holzer wrote: On 2021-05-19 12:49:42 -0500, Ron wrote: Currently on our RHEL 7.8 system, /etc/pgbackrest.conf is root:root and 633 perms. Did you mean 644? 633 would be very strange permissions (write and execute but not read for group and others). Yes, I noticed

Re: Fwd: Proposed Chinese Translation of Community Code of Conduct

On 5/22/21 5:18 AM, Peter J. Holzer wrote: On 2021-05-21 12:35:49 -0500, Ron wrote: I see the attachments in your first email. Fascinating. I don't in the normal view but do see them in the MIME structure: I 1 [multipa/alternativ, 7bit, 180K] I 2 ├─>

Re: PG 14 - can't upgrade from a database using an aggregate with anyelement and anyarray

Thomas Kellerer writes: > this aggregate can be created without problems on PG 13 and before: >CREATE AGGREGATE array_accum(anyelement) ( >SFUNC = array_append, >STYPE = anyarray, >INITCOND = '{}' >); > However, that fails with PG 14beta1 because array_append's pa

PG 14 - can't upgrade from a database using an aggregate with anyelement and anyarray

Hello, this aggregate can be created without problems on PG 13 and before: CREATE AGGREGATE array_accum(anyelement) ( SFUNC = array_append, STYPE = anyarray, INITCOND = '{}' ); However, that fails with PG 14beta1 because array_append's parameter are now (anycompatiblearra

Re: Framework for 0 downtime deploys

No silver bullets exist (yet). A couple of things I can recommend: 1. GitLab's experience of changing schema without downtime and maintaining backward compatibility – they have open documentation and a lot of things solved and documented - start here: https://docs.gitlab.com/ee/development/mig

Framework for 0 downtime deploys

Confidential Hello All I wonder if I could garner some of the wealth of experience on this group: Our current application deployments (every 3 weeks) require about 30min downtime. We are now tasked of making this 0 downtime. >From all the reading I have done, we have solutions for the infrastru

Re: pgbackrest - hiding the encryption password

On 2021-05-19 12:49:42 -0500, Ron wrote: > Currently on our RHEL 7.8 system, /etc/pgbackrest.conf is root:root and 633 > perms. Did you mean 644? 633 would be very strange permissions (write and execute but not read for group and others). hp -- _ | Peter J. Holzer| Story must ma

Re: The contents of the pg_timezone_names view bring some surprises

On 2021-05-22 12:09:23 +0200, Peter J. Holzer wrote: > On 2021-05-19 06:57:13 -0700, Adrian Klaver wrote: > > On 5/18/21 11:31 PM, Bryn Llewellyn wrote: > > > This seems to be at odds with what section “8.5.3. Time Zones” at > > > > > > https://www.postgresql.org/docs/current/datatype-datetime.htm

Re: Fwd: Proposed Chinese Translation of Community Code of Conduct

On 2021-05-21 12:35:49 -0500, Ron wrote: > I see the attachments in your first email. Fascinating. I don't in the normal view but do see them in the MIME structure: I 1 [multipa/alternativ, 7bit, 180K] I 2 ├─> [text/plain, quoted, utf-8, 0.8K] I 3

Re: The contents of the pg_timezone_names view bring some surprises

On 2021-05-19 06:57:13 -0700, Adrian Klaver wrote: > On 5/18/21 11:31 PM, Bryn Llewellyn wrote: > > This seems to be at odds with what section “8.5.3. Time Zones” at > > > > https://www.postgresql.org/docs/current/datatype-datetime.html#DATATYPE-TIMEZONES > > > >

Re: The contents of the pg_timezone_names view bring some surprises

On 2021-05-18 23:31:57 -0700, Bryn Llewellyn wrote: > Africa/Algiers | CET| 01:00:00 | f > Africa/Cairo | EET| 02:00:00 | f > Africa/Tripoli | EET| 02:00:00 | f > Africa/Tunis | CET| 01:00:00 | f > CET| CEST | 02:00:00 | t > EET