Re: Idea: PostgreSQL equivalent to Oracle's KEEP clause

Thanks David. Similar to your "TOP() and BOTTOM() aggregate" idea, you might find Erwin Brandstetter's solution using the LAST() aggregate function interesting: ( https://dba.stackexchange.com/a/324646/100880) If the FIRST_LAST_AGG extension is installed, then we can do something like this:

Re: Uppercase version of ß desired

"Peter J. Holzer" writes: > On 2023-03-13 17:38:51 -0400, Celia McInnis wrote: >> I would be really happy if postgresql had an upper case version of the ß >> german character. > But the 'ß' is a bit special as it is usually uppercased to 'SS' > (although 'ẞ' is now officially allowed, too). >

Re: Uppercase version of ß desired

On 2023-03-13 17:38:51 -0400, Celia McInnis wrote: > I would be really happy if postgresql  had an upper case version of the ß > german character. The wiki page > https://en.wikipedia.org/wiki/%C3%9F > > indicates that the capital (U+1E9E ẞ LATIN CAPITAL LETTER SHARP S) was encoded > by ISO 10646

Using GSSAPI/Kerbros/Active Directory: want the database user name to be the full name including the realm name without specifying the user

Good afternoon, We can successfully connect via GSSAPI/Kerberos using our Active Directory credentials when we map the domain user to a database user that matches the name when the domain information is removed. When we have a user called mich C:\Users\mich2581>"c:\Program

Uppercase version of ß desired

HI: I would be really happy if postgresql had an upper case version of the ß german character. The wiki page https://en.wikipedia.org/wiki/%C3%9F indicates that the capital (U+1E9E ẞ LATIN CAPITAL LETTER SHARP S) was encoded by ISO 10646

Re: Properly handle OOM death?

> On Mar 13, 2023, at 12:25 PM, Joe Conway wrote: > > On 3/13/23 16:18, Israel Brewster wrote: >>> Did you try setting "vm.overcommit_memory=2"? > >> root@novarupta:~# sysctl -w vm.overcommit_memory=2 >> sysctl: setting key "vm.overcommit_memory", ignoring: Read-only file system > >> I’m

Re: Properly handle OOM death?

> On Mar 13, 2023, at 12:16 PM, Peter J. Holzer wrote: > > On 2023-03-13 09:55:50 -0800, Israel Brewster wrote: >> On Mar 13, 2023, at 9:43 AM, Peter J. Holzer wrote: > The syslog should contain a list of all tasks prior to the kill. For > example, I just provoked an OOM kill on my laptop and

Re: Properly handle OOM death?

On 3/13/23 16:18, Israel Brewster wrote: On Mar 13, 2023, at 11:42 AM, Joe Conway wrote: I am not entirely sure, but without actually testing it I suspect that since memory.max = high (that is, the limit is whatever the host has available) the OOM kill is technically a cgroup OOM kill even

Re: Properly handle OOM death?

> On Mar 13, 2023, at 11:42 AM, Joe Conway wrote: > > On 3/13/23 15:18, Israel Brewster wrote: >> The syslog specifically says "Memory cgroup out of memory”, if that means >> something (this is my first exposure to cgroups, if you couldn’t >> tell). > > I am not entirely sure, but without

Re: Properly handle OOM death?

On 2023-03-13 09:55:50 -0800, Israel Brewster wrote: > On Mar 13, 2023, at 9:43 AM, Peter J. Holzer wrote: > > On 2023-03-13 09:21:18 -0800, Israel Brewster wrote: > >> I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit > >> more > >> memory constrained than I would like,

Re: Properly handle OOM death?

On 3/13/23 15:18, Israel Brewster wrote: root@novarupta:~# cat /sys/fs/cgroup/system.slice/system-postgresql.slice/postgresql@13-main.service/memory.max max root@novarupta:~# cat /sys/fs/cgroup/system.slice/system-postgresql.slice/postgresql@13-main.service/memory.high max root@novarupta:~#

Re: Properly handle OOM death?

On Mon, Mar 13, 2023 at 1:21 PM Israel Brewster wrote: > > I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit more > memory constrained than I would like, such that every week or so the various > processes running on the machine will align badly and the OOM killer will >

Re: Properly handle OOM death?

On Mar 13, 2023, at 11:10 AM, Joe Conway wrote: > > On 3/13/23 14:50, Israel Brewster wrote: >> Looks like V2: >> root@novarupta:~# stat -fc %T /sys/fs/cgroup/ >> cgroup2fs > > Interesting -- it does indeed look like you are using cgroup v2 > > So the file you want to look at in that case is:

Re: Binary large object processing problems

Ok, I will do that. ANd it works now in both way Regards Raivo On Mon, Mar 13, 2023 at 6:18 PM Tom Lane wrote: > Raivo Rebane writes: > > Thank for answer, but I was also readed this manual and found there : > > 35.3.2. Importing a Large Object > > You need to read the start of that section,

Re: Properly handle OOM death?

On 3/13/23 14:50, Israel Brewster wrote: Looks like V2: root@novarupta:~# stat -fc %T /sys/fs/cgroup/ cgroup2fs Interesting -- it does indeed look like you are using cgroup v2 So the file you want to look at in that case is: 8<--- cat

Re: Properly handle OOM death?

> On Mar 13, 2023, at 10:37 AM, Joe Conway wrote: > > On 3/13/23 13:55, Israel Brewster wrote: >> 1) They reference a “Memory cgroup out of memory”, which refers back >> to the opening comment on Joe Conway’s message - this would imply to >> me that I *AM* running with a cgroup memory.limit set.

Re: Properly handle OOM death?

On 3/13/23 13:55, Israel Brewster wrote: 1) They reference a “Memory cgroup out of memory”, which refers back to the opening comment on Joe Conway’s message - this would imply to me that I *AM* running with a cgroup memory.limit set. Not sure how that changes things? cgroup memory limit is

Re: Properly handle OOM death?

> On Mar 13, 2023, at 9:43 AM, Peter J. Holzer wrote: > > On 2023-03-13 09:21:18 -0800, Israel Brewster wrote: >> I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit more >> memory constrained than I would like, such that every week or so the various >> processes running on

Re: Properly handle OOM death?

On 2023-03-13 09:21:18 -0800, Israel Brewster wrote: > I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit more > memory constrained than I would like, such that every week or so the various > processes running on the machine will align badly and the OOM killer will kick > in,

Re: Properly handle OOM death?

> On Mar 13, 2023, at 9:36 AM, Joe Conway wrote: > > On 3/13/23 13:21, Israel Brewster wrote: >> I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit >> more memory constrained than I would like, such that every week or so the >> various processes running on the machine

Re: Properly handle OOM death?

> On Mar 13, 2023, at 9:28 AM, Adrian Klaver wrote: > > On 3/13/23 10:21 AM, Israel Brewster wrote: >> I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit >> more memory constrained than I would like, such that every week or so the >> various processes running on the

Re: Properly handle OOM death?

On 3/13/23 13:21, Israel Brewster wrote: I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit more memory constrained than I would like, such that every week or so the various processes running on the machine will align badly and the OOM killer will kick in, killing off

Re: Properly handle OOM death?

On 3/13/23 10:21 AM, Israel Brewster wrote: I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit more memory constrained than I would like, such that every week or so the various processes running on the machine will align badly and the OOM killer will kick in, killing off

Properly handle OOM death?

I’m running a postgresql 13 database on an Ubuntu 20.04 VM that is a bit more memory constrained than I would like, such that every week or so the various processes running on the machine will align badly and the OOM killer will kick in, killing off postgresql, as per the following journalctl

Re: Binary large object processing problems

Raivo Rebane writes: > Thank for answer, but I was also readed this manual and found there : > 35.3.2. Importing a Large Object You need to read the start of that section, which says All large object manipulation using these functions must take place within an SQL transaction block, As

Re: Binary large object processing problems

Thank for answer, but I was also readed this manual and found there : 35.3.2. Importing a Large Object To import an operating system file as a large object, call Oid lo_import(PGconn *conn, const char *filename); *filename* specifies the operating system name of the file to be imported as a

Re: Binary large object processing problems

## Raivo Rebane (raivor...@gmail.com): > Can anybody help me find where is my mistake an what is working solution ? The documentation clearly states "All large object manipulation using these functions must take place within an SQL transaction block"

Binary large object processing problems

Hi I am novice in pogres C API user and I want to store Binary Large Object into database from C language program. I am using following source : Oid nloid = lo_import(conn, FileFUllName.c_str()); if (nloid == 0) { std::cerr << "Error importing large object: " << PQerrorMessage(conn) <<

Re: Seq Scan because of stats or because of cast?

Dominique Devienne writes: > I figured that query would use the "pg_auth_members_role_member_index" > index, > but instead it's using a sequential scan. > And I'm wondering is this is because the cardinality of that catalog is > small (172), > which is just an artifact of my dev-testing, or

Seq Scan because of stats or because of cast?

I'm interested in the members of specific roles, providing the roles of interest to the query via an array of integers (binary bind in code, not textual array literal like I had to use to have the EXPLAIN work, see below). I figured that query would use the "pg_auth_members_role_member_index"