Re: Limiting memory allocation

memory allocated by each backend. This could be advantageous for giving per-backend memory usage to the user, as well as for enforcing a limit on the total amount of memory allocated by the backends. — Oleksii Kliukin

Issues with building cpp extensions on PostgreSQL 10+

Hello, I’ve recently tried to build an extension that employs C++ files and also passes them to a linker to make a shared library. I’ve discovered a few issues with them: - in v10 CFLAGS_SL is not appended to the CXXFLAGS in Makefile.shlib, resulting in cpp files compiled without -fPIC, leading

pg_upgrade and subscriptions

Hello, I came across a surprising behavior when upgrading our PostgreSQL 10 DBs that also serve as a destination for the logical replication of some reference tables. pg_upgrade turns off all subscriptions on the cluster and doesn't turn them on. Specifically, it creates them with connect =

Re: [HACKERS] Help required to debug pg_repack breaking logical replication

Hello, Petr Jelinek wrote: > On 08/10/17 15:21, Craig Ringer wrote: >> On 8 October 2017 at 02:37, Daniele Varrazzo >> wrote: >>> Hello, >>> >>> we have been reported, and I have experienced a couple of times, >>> pg_repack breaking logical replication. >>> >>> -

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

Alvaro Herrera wrote: > On 2019-Jun-18, Oleksii Kliukin wrote: > >> Sorry, I was confused, as I was looking only at >> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=de87a084c0a5ac927017cd0834b33a932651cfc9 >> >> without taking your subsequent

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

Alvaro Herrera wrote: > On 2019-Jun-16, Oleksii Kliukin wrote: > >> Alvaro Herrera wrote: >> >>> On 2019-Jun-14, Alvaro Herrera wrote: >>> >>>> I think there are worse problems here. I tried the attached isolation >>>> spec. Note

Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

Alvaro Herrera wrote: > On 2019-Jun-14, Alvaro Herrera wrote: > >> I think there are worse problems here. I tried the attached isolation >> spec. Note that the only difference in the two permutations is that s0 >> finishes earlier in one than the other; yet the first one works fine and >> the

Re: upgrades in row-level locks can deadlock

Alvaro Herrera wrote: > On 2019-Jun-13, Alvaro Herrera wrote: > >> On 2019-Jun-13, Oleksii Kliukin wrote: >> >>> Makes sense. For the symmetry I have included those that perform lock >>> upgrades in one session and those that doesn’t, while the other se

Re: upgrades in row-level locks can deadlock

Hello, Alvaro Herrera wrote: > On 2019-Jun-12, Oleksii Kliukin wrote: > >> Thank you! I can make it even simpler; s1 just acquires for share lock, s3 >> gets for update one and s2 takes for share lock first, and then tries to >> acquire for update one; once s

Re: upgrades in row-level locks can deadlock

Oleksii Kliukin wrote: > Hi, > > Alvaro Herrera wrote: > >> On 2019-May-22, Oleksii Kliukin wrote: >> >>> X1: select id from job where name = 'a' for key share; >>> Y: select id from job where name = 'a' for update; -- starts waiting for X1 >>&

upgrades in row-level locks can deadlock

Hello, I have recently observed a deadlock on one of our production servers related to locking only a single row in a job table. There were two functions involved in the deadlock, the first one acquires a “for key share” lock on the row that represents the job it works on and subsequently

Re: Per-tablespace autovacuum settings

Robert Haas wrote: > On Thu, Apr 25, 2019 at 12:36 PM Oleksii Kliukin wrote: >> - Fallbacks to autovacuum parameters in another scope. Right now in the >> absence of the per-table and per-tablespace autovacuum parameters the code >> uses the ones from the global scope.

Re: Per-tablespace autovacuum settings

Hello, Oleksii Kliukin wrote: > Tom Lane wrote: > > >> I don't know how to make this better, but I wish we'd take a step >> back and think about it rather than just accreting more and more >> complexity. > > I am willing to do the refactoring whe

Re: Prepared transaction releasing locks before deregistering its GID

Hi, Michael Paquier wrote: > On Wed, Feb 20, 2019 at 11:50:42AM +0100, Oleksii Kliukin wrote: >> RecoverPreparedTransactions calls ProcessRecords with >> twophase_recover_callbacks right after releasing the TwoPhaseStateLock, so I >> think lock_held should be false here

Re: Prepared transaction releasing locks before deregistering its GID

n extra routine, which means more conflicts to handle > when back-patching 2PC stuff), and the time it took to find the issue > are pointing out that we should patch only HEAD. Sounds reasonable. Regards, Oleksii Kliukin

Re: Prepared transaction releasing locks before deregistering its GID

Hi, Oleksii Kliukin wrote: > > The approach looks good to me. Surprisingly, I saw no stalled backends > because of the double acquisition of lock at TwoPhaseGetGXact once I put a > simple TwoPhaseStateLock right before the "gxact->valid = false” line; I > will t

Prepared transaction releasing locks before deregistering its GID

e description of commit prepared, or is there any interest in changing the behavior to avoid such conflicts altogether (perhaps by holding the lock throughout the cleanup phase)? Regards, Oleksii Kliukin

Re: Per-tablespace autovacuum settings

Tom Lane wrote: > Oleksii Kliukin writes: >> Is there any interest in making autovacuum parameters available on a >> tablespace level in order to apply those to all vacuumable objects in the >> tablespace? > > I understand what you want to accomplish, and it doesn't

Re: Per-tablespace autovacuum settings

Andres Freund wrote: > Hi, > > On 2019-02-14 17:56:17 +0100, Oleksii Kliukin wrote: >> Is there any interest in making autovacuum parameters available on a >> tablespace level in order to apply those to all vacuumable objects in the >> tablespace? >> >>

Per-tablespace autovacuum settings

(in case of a conflict, relation options should always take priority). Regards, Oleksii Kliukin

Re: Connection slots reserved for replication

> On 12. Feb 2019, at 05:12, Michael Paquier wrote: > > On Mon, Feb 11, 2019 at 08:57:41PM -0700, Kevin Hale Boyes wrote: >> I think there's a small problem with the commit. >> The position of xlrec.max_wal_senders (line 117) should be below >> max_worker_processes. > > Fixed, thanks!

Re: Connection slots reserved for replication

> On 7. Feb 2019, at 07:51, Michael Paquier wrote: > > On Sat, Feb 02, 2019 at 10:35:20AM +0900, Michael Paquier wrote: >> Oh, I have just noticed this patch when doing my vacuum homework. I >> have just added my name as committer, just wait a bit until the CF is >> closed before I begin

Re: Connection slots reserved for replication

> On 31. Jan 2019, at 11:50, Petr Jelinek wrote: > > On 31/01/2019 11:25, Oleksii Kliukin wrote: >> >> >>> On 25. Jan 2019, at 18:37, Oleksii Kliukin >> <mailto:al...@hintbits.com>> wrote: >>> >>> Hello, >>> >>&

Re: Connection slots reserved for replication

> On 25. Jan 2019, at 18:37, Oleksii Kliukin wrote: > > Hello, > >> On 24. Jan 2019, at 13:47, Kyotaro HORIGUCHI >> mailto:horiguchi.kyot...@lab.ntt.co.jp>> >> wrote: > > Thank you for the review.I took a liberty to address it with v9.

Re: pg_basebackup, walreceiver and wal_sender_timeout

> On 29. Jan 2019, at 10:45, Magnus Hagander wrote: > > On Tue, Jan 29, 2019 at 6:19 AM Michael Paquier > wrote: > On Mon, Jan 28, 2019 at 02:00:59PM +0100, Alex Kliukin wrote: > > While reading the doc page for the pg_basebackup, I've been confused > > by the fact

Re: Connection slots reserved for replication

Hello, > On 24. Jan 2019, at 13:47, Kyotaro HORIGUCHI > wrote: Thank you for the review.I took a liberty to address it with v9. > > Documentation looks fine for me. By the way, a comment for the > caller-site of CheckRequreParameterValues() in xlog.c looks > somewhat stale. > >> /* Check to

Re: Connection slots reserved for replication

On Wed, Jan 2, 2019, at 12:36, Alexander Kukushkin wrote: > Hi, > > On Wed, 2 Jan 2019 at 12:17, Oleksii Kliukin wrote: > > > Thank you. Attached the new version(called it v8) with the following > > changes to the documentation: > > Thank you for jumping on it

Re: Connection slots reserved for replication

On Wed, Jan 2, 2019, at 11:02, Petr Jelinek wrote: > The patch generally looks good, but the documentation of max_wal_senders > needs updating. In config.sgml we say: > > > WAL sender processes count towards the total number > > of connections, so this parameter's value must be less than > >

Re: Connection slots reserved for replication

On Mon, Dec 17, 2018, at 14:10, Alexander Kukushkin wrote: > Hi, > > On Thu, 6 Dec 2018 at 00:55, Petr Jelinek > wrote: > > > Does excluding WAL senders from the max_connections limit and including > > > max_wal_senders in MaxBackends also imply that we need to add > > > max_wal_senders to

Re: \gexec \watch

Hi Álvaro, > On 6. Dec 2018, at 13:56, Alvaro Herrera wrote: > > To Oleksii's question, I think if you want to repeat the first query > over and over, you'd use something like this: > > select format('select now() as execution_time, %L as generation_time', now()) > as query \gset > :query

Re: \gexec \watch

> On 6. Dec 2018, at 09:01, Alvaro Herrera wrote: > > On 2018-Dec-06, David Fetter wrote: > >> There's a bit of a philosophical issue here, or a mathematical one, >> whichever way you want to put it. Does it actually make sense to have >> the behavior of one "semicolon" spill onto another?

Re: Connection slots reserved for replication

> On 30. Nov 2018, at 13:58, Alexander Kukushkin wrote: > > attaching the new version of the patch. > Now it simply reserves max_wal_senders slots in the ProcGlobal, what > guarantees that only walsender process could use them. With this patch It looks like InitProcess will trigger the

Re: [PATCH] Fix for infinite signal loop in parallel scan

> On 18. Sep 2018, at 03:18, Thomas Munro wrote: > > On Tue, Sep 18, 2018 at 1:15 AM Chris Travers > wrote: >> On Mon, Sep 17, 2018 at 2:59 PM Oleksii Kliukin wrote: >>> With the patch applied, the posix_fallocate loop terminated right away >>> (becaus

Re: [PATCH] Fix for infinite signal loop in parallel scan

by just blocking SIGUSR1 for the duration of posix_fallocate? Cheers, Oleksii Kliukin