Alexander Lakhin writes:
> I've reproduced this behavior with two reduced sqls.
> prepared_xacts.sql:
> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
> CREATE TABLE pxtest4 (a int);
> PREPARE TRANSACTION 'regress_sub2';
> \c -
> COMMIT PREPARED 'regress_sub2';
> -- the script ends prematurely
Hello Tom,
16.12.2024 07:23, Tom Lane wrote:
Alexander Lakhin writes:
...
So GetSafeSnapshot() waits indefinitely for possibleUnsafeConflicts to
become empty (for other backend to remove itself from the list of possible
conflicts
inside ReleasePredicateLocks()), but it doesn't happen.
This s
BTW, I did a little bit of performance testing using current OpenBSD
(7.6), and it looks like they partially fixed the performance issues
I saw with their named POSIX semaphores back in 2021. "pgbench -S"
seems to show TPS rates right about on par with a SysV-sema build.
There is still a measurabl
Andres Freund writes:
> On 2024-12-18 12:00:48 -0500, Tom Lane wrote:
>> NetBSD does, but they consume an FD per sema, which is actually worse
>> because the default max-open-files-per-process is none too large either.
> Doesn't seem that bad on netbsd 10. Via Bilal's netbsd CI patch, I get:
> #
Hi,
On 2024-12-18 12:00:48 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Maybe we should consider switching those platforms to unnamed posix
> > semaphores?
>
> I already looked into that. OpenBSD still doesn't have cross-process
> posix semaphores, at least according to its man page.
Ugh
Andres Freund writes:
> Maybe we should consider switching those platforms to unnamed posix
> semaphores?
I already looked into that. OpenBSD still doesn't have cross-process
posix semaphores, at least according to its man page. NetBSD does,
but they consume an FD per sema, which is actually wo
Hi,
On 2024-12-18 11:23:23 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> >> After some testing and searching for documentation, it seems that at
> >> least the BSD platforms have a very low default semmns setting
> >> (apparently 60, which leads to max_connections=30).
>
> > The low semaph
Peter Eisentraut writes:
>>> * Why in the world is the default value of max_wal_senders 10?
> Here is where this change was originally discussed:
> https://www.postgresql.org/message-id/flat/CABUevEy4PR_EAvZEzsbF5s%2BV0eEvw7shJ2t-AUwbHOjT%2ByRb3A%40mail.gmail.com
Hmm. There was not a lot in th
On 16.12.24 19:19, Andres Freund wrote:
* Why in the world is the default value of max_wal_senders 10?
I find it hard to believe that there are installations using
more than about 3, and even there you can bet they are changing
a lot of other parameters.
I don't think it's that rare as logical
Thomas Munro writes:
> Whenever I run into this, or my Mac requires manual ipcrm to clean up
> leaked SysV kernel junk, I rebase my patch for sema_kind = 'futex'.
> Here it goes. It could be updated to support NetBSD I believe, but I
> didn't try as its futex stuff came out later.
FWIW, I looked
On Mon, Dec 16, 2024 at 6:00 PM Alexander Lakhin wrote:
> It turned out that OpenBSD has semmns as low as 60 (see [4])
Whenever I run into this, or my Mac requires manual ipcrm to clean up
leaked SysV kernel junk, I rebase my patch for sema_kind = 'futex'.
Here it goes. It could be updated to su
Andres Freund writes:
> On 2024-12-16 12:52:46 -0500, Tom Lane wrote:
>> * Why in the world is the default value of max_wal_senders 10?
>> I find it hard to believe that there are installations using
>> more than about 3, and even there you can bet they are changing
>> a lot of other parameters.
Hi,
On 2024-12-16 12:52:46 -0500, Tom Lane wrote:
> or 20 + 3 + 1 + 8 + 10 + 6 = 48. We allocate semaphores in groups
> of SEMAS_PER_SET (16), plus one for identification purposes,
> so with this many semaphores needed we create 3 sets of 17 semaphores
> = 51 semaphores. One more requested semap
Andrew Dunstan writes:
> On 2024-12-16 Mo 12:23 AM, Tom Lane wrote:
>> Yeah. That was more-or-less okay before we invented parallel query,
>> but now there needs to be some headroom. I've thought about adjusting
>> initdb to not allow max_connections less than 25 (can't remember if
>> I actually
On 2024-12-16 Mo 12:23 AM, Tom Lane wrote:
Alexander Lakhin writes:
I deployed OpenBSD 7.4 locally and reproduced "too many clients" and that
hang as well. It turned out that OpenBSD has semmns as low as 60 (see [4])
and as a consequence, initdb sets max_connections = 20 for the regression
tes
Alexander Lakhin writes:
> I deployed OpenBSD 7.4 locally and reproduced "too many clients" and that
> hang as well. It turned out that OpenBSD has semmns as low as 60 (see [4])
> and as a consequence, initdb sets max_connections = 20 for the regression
> test database. (This can be helpful someti
16 matches
Mail list logo
