public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 1/1] resownerbench
5+ messages / 3 participants
[nested] [flat]
* [PATCH 1/1] resownerbench
@ 2020-11-11 22:40 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Heikki Linnakangas @ 2020-11-11 22:40 UTC (permalink / raw)
---
contrib/resownerbench/Makefile | 17 ++
contrib/resownerbench/resownerbench--1.0.sql | 14 ++
contrib/resownerbench/resownerbench.c | 154 +++++++++++++++++++
contrib/resownerbench/resownerbench.control | 6 +
contrib/resownerbench/snaptest.sql | 37 +++++
5 files changed, 228 insertions(+)
create mode 100644 contrib/resownerbench/Makefile
create mode 100644 contrib/resownerbench/resownerbench--1.0.sql
create mode 100644 contrib/resownerbench/resownerbench.c
create mode 100644 contrib/resownerbench/resownerbench.control
create mode 100644 contrib/resownerbench/snaptest.sql
diff --git a/contrib/resownerbench/Makefile b/contrib/resownerbench/Makefile
new file mode 100644
index 00000000000..9b0e1cfee1a
--- /dev/null
+++ b/contrib/resownerbench/Makefile
@@ -0,0 +1,17 @@
+MODULE_big = resownerbench
+OBJS = resownerbench.o
+
+EXTENSION = resownerbench
+DATA = resownerbench--1.0.sql
+PGFILEDESC = "resownerbench - benchmark for ResourceOwners"
+
+ifdef USE_PGXS
+PG_CONFIG = pg_config
+PGXS := $(shell $(PG_CONFIG) --pgxs)
+include $(PGXS)
+else
+subdir = contrib/resownerbench
+top_builddir = ../..
+include $(top_builddir)/src/Makefile.global
+include $(top_srcdir)/contrib/contrib-global.mk
+endif
diff --git a/contrib/resownerbench/resownerbench--1.0.sql b/contrib/resownerbench/resownerbench--1.0.sql
new file mode 100644
index 00000000000..d29182f5982
--- /dev/null
+++ b/contrib/resownerbench/resownerbench--1.0.sql
@@ -0,0 +1,14 @@
+/* contrib/resownerbench/resownerbench--1.0.sql */
+
+-- complain if script is sourced in psql, rather than via CREATE EXTENSION
+\echo Use "CREATE EXTENSION resownerbench" to load this file. \quit
+
+CREATE FUNCTION snapshotbench_lifo(numkeep int, numsnaps int, numiters int)
+RETURNS double precision
+AS 'MODULE_PATHNAME', 'snapshotbench_lifo'
+LANGUAGE C STRICT VOLATILE;
+
+CREATE FUNCTION snapshotbench_fifo(numkeep int, numsnaps int, numiters int)
+RETURNS double precision
+AS 'MODULE_PATHNAME', 'snapshotbench_fifo'
+LANGUAGE C STRICT VOLATILE;
diff --git a/contrib/resownerbench/resownerbench.c b/contrib/resownerbench/resownerbench.c
new file mode 100644
index 00000000000..acfb6c39199
--- /dev/null
+++ b/contrib/resownerbench/resownerbench.c
@@ -0,0 +1,154 @@
+#include "postgres.h"
+
+#include "catalog/pg_type.h"
+#include "catalog/pg_statistic.h"
+#include "executor/spi.h"
+#include "funcapi.h"
+#include "libpq/pqsignal.h"
+#include "utils/catcache.h"
+#include "utils/syscache.h"
+#include "utils/timestamp.h"
+#include "utils/snapmgr.h"
+
+PG_MODULE_MAGIC;
+
+PG_FUNCTION_INFO_V1(snapshotbench_lifo);
+PG_FUNCTION_INFO_V1(snapshotbench_fifo);
+
+/*
+ * ResourceOwner Performance test, using RegisterSnapshot().
+ *
+ * This takes three parameters: numkeep, numsnaps, numiters.
+ *
+ * First, we register 'numkeep' snapshots. They are kept registed
+ * until the end of the test. Then, we repeatedly register and
+ * unregister 'numsnaps - numkeep' additional snapshots, repeating
+ * 'numiters' times. All the register/unregister calls are made in
+ * LIFO order.
+ *
+ * Returns the time spent, in milliseconds.
+ *
+ * The idea is to test the performance of ResourceOwnerRemember()
+ * and ReourceOwnerForget() operations, under different regimes.
+ *
+ * In the old implementation, if 'numsnaps' is small enough, all
+ * the entries fit in the resource owner's small array (it can
+ * hold 64 entries).
+ *
+ * In the new implementation, the array is much smaller, only 8
+ * entries, but it's used together with the hash table so that
+ * we stay in the "array regime" as long as 'numsnaps - numkeep'
+ * is smaller than 8 entries.
+ *
+ * 'numiters' can be adjusted to adjust the overall runtime to be
+ * suitable long.
+ */
+Datum
+snapshotbench_lifo(PG_FUNCTION_ARGS)
+{
+ int numkeep = PG_GETARG_INT32(0);
+ int numsnaps = PG_GETARG_INT32(1);
+ int numiters = PG_GETARG_INT32(2);
+ int i;
+ instr_time start,
+ duration;
+ Snapshot lsnap;
+ Snapshot *rs;
+ int numregistered = 0;
+
+ rs = palloc(Max(numsnaps, numkeep) * sizeof(Snapshot));
+
+ lsnap = GetLatestSnapshot();
+
+ PG_SETMASK(&BlockSig);
+ INSTR_TIME_SET_CURRENT(start);
+
+ while (numregistered < numkeep)
+ {
+ rs[numregistered] = RegisterSnapshot(lsnap);
+ numregistered++;
+ }
+
+ for (i = 0 ; i < numiters; i++)
+ {
+ while (numregistered < numsnaps)
+ {
+ rs[numregistered] = RegisterSnapshot(lsnap);
+ numregistered++;
+ }
+
+ while (numregistered > numkeep)
+ {
+ numregistered--;
+ UnregisterSnapshot(rs[numregistered]);
+ }
+ }
+
+ while (numregistered > 0)
+ {
+ numregistered--;
+ UnregisterSnapshot(rs[numregistered]);
+ }
+
+ INSTR_TIME_SET_CURRENT(duration);
+ INSTR_TIME_SUBTRACT(duration, start);
+ PG_SETMASK(&UnBlockSig);
+
+ PG_RETURN_FLOAT8(INSTR_TIME_GET_MILLISEC(duration));
+};
+
+
+/*
+ * Same, but do the register/unregister operations in
+ * FIFO order.
+ */
+Datum
+snapshotbench_fifo(PG_FUNCTION_ARGS)
+{
+ int numkeep = PG_GETARG_INT32(0);
+ int numsnaps = PG_GETARG_INT32(1);
+ int numiters = PG_GETARG_INT32(2);
+ int i,
+ j;
+ instr_time start,
+ duration;
+ Snapshot lsnap;
+ Snapshot *rs;
+ int numregistered = 0;
+
+ rs = palloc(Max(numsnaps, numkeep) * sizeof(Snapshot));
+
+ lsnap = GetLatestSnapshot();
+
+ PG_SETMASK(&BlockSig);
+ INSTR_TIME_SET_CURRENT(start);
+
+ while (numregistered < numkeep)
+ {
+ rs[numregistered] = RegisterSnapshot(lsnap);
+ numregistered++;
+ }
+
+ for (i = 0 ; i < numiters; i++)
+ {
+ while (numregistered < numsnaps)
+ {
+ rs[numregistered] = RegisterSnapshot(lsnap);
+ numregistered++;
+ }
+
+ for (j = numkeep; j < numregistered; j++)
+ UnregisterSnapshot(rs[j]);
+ numregistered = numkeep;
+ }
+
+ for (j = 0; j < numregistered; j++)
+ UnregisterSnapshot(rs[j]);
+ numregistered = numkeep;
+
+ INSTR_TIME_SET_CURRENT(duration);
+ INSTR_TIME_SUBTRACT(duration, start);
+ PG_SETMASK(&UnBlockSig);
+
+ PG_RETURN_FLOAT8(INSTR_TIME_GET_MILLISEC(duration));
+};
diff --git a/contrib/resownerbench/resownerbench.control b/contrib/resownerbench/resownerbench.control
new file mode 100644
index 00000000000..ada88b8eed8
--- /dev/null
+++ b/contrib/resownerbench/resownerbench.control
@@ -0,0 +1,6 @@
+# resownerbench
+
+comment = 'benchmark for ResourceOwners'
+default_version = '1.0'
+module_pathname = '$libdir/resownerbench'
+relocatable = true
diff --git a/contrib/resownerbench/snaptest.sql b/contrib/resownerbench/snaptest.sql
new file mode 100644
index 00000000000..18c54e13fc9
--- /dev/null
+++ b/contrib/resownerbench/snaptest.sql
@@ -0,0 +1,37 @@
+--
+-- Performance test RegisterSnapshot/UnregisterSnapshot.
+--
+select numkeep, numsnaps,
+ -- numiters,
+ -- round(lifo_time_ms) as lifo_total_time_ms,
+ -- round(fifo_time_ms) as fifo_total_time_ms,
+ round((lifo_time_ms::numeric / (numkeep + (numsnaps - numkeep) * numiters)) * 1000000, 1) as lifo_time_ns,
+ round((fifo_time_ms::numeric / (numkeep + (numsnaps - numkeep) * numiters)) * 1000000, 1) as fifo_time_ns
+from
+(values (0, 1, 10000000),
+ (0, 5, 2000000),
+ (0, 10, 1000000),
+ (0, 60, 100000),
+ (0, 70, 100000),
+ (0, 100, 100000),
+ (0, 1000, 10000),
+ (0, 10000, 1000),
+
+-- These tests keep 9 snapshots registered across the iterations. That
+-- exceeds the size of the little array in the patch, so this exercises
+-- the hash lookups. Without the patch, these still fit in the array
+-- (it's 64 entries without the patch)
+ (9, 10, 10000000),
+ (9, 100, 100000),
+ (9, 1000, 10000),
+ (9, 10000, 1000),
+
+-- These exceed the 64 entry array even without the patch, so these fall
+-- in the hash table regime with and without the patch.
+ (65, 70, 1000000),
+ (65, 100, 100000),
+ (65, 1000, 10000),
+ (65, 10000, 1000)
+) AS params (numkeep, numsnaps, numiters),
+lateral snapshotbench_lifo(numkeep, numsnaps, numiters) as lifo_time_ms,
+lateral snapshotbench_fifo(numkeep, numsnaps, numiters) as fifo_time_ms;
--
2.29.2
--------------1104342304EC6341F5D7C60C--
^ permalink raw reply [nested|flat] 5+ messages in thread
* Segmentation fault on FreeBSD with GSSAPI authentication
@ 2024-01-27 12:45 Michał Kłeczek <[email protected]>
2024-01-27 14:43 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Tom Lane <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Michał Kłeczek @ 2024-01-27 12:45 UTC (permalink / raw)
To: PostgreSQL Hackers <[email protected]>
Hi All,
I am trying to use GSSAPI (Kerberos auth) on FreeBSD.
After several attempts I was able to build PostgreSQL 16 from FreeBSD ports with GSSAPI support. The steps were:
1. Uninstall Heimdal
2. Install krb5 (MIT Kerberos)
3. Build Pg with GSSAPI support
I configured pg_hba.conf to require GSSAPI authentication for one of the users.
When trying to connect using “psql -h postgres” (postgres is the name of the host) I get:
psql: error: connection to server at “postgres.[domainname]” ([ipaddress]), port 5432 failed: connection to server at “postgres.[domainname]” ([ipaddress]), port 5432 failed: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Configured Pg to debug log and here are the relevant syslog entries:
an 27 13:33:45 postgres postgres[61605]: [36-1] 2024-01-27 13:33:45.779 CET [61605] DEBUG: forked new backend, pid=61626 socket=10
Jan 27 13:33:45 postgres postgres[61605]: [37-1] 2024-01-27 13:33:45.786 CET [61605] DEBUG: forked new backend, pid=61627 socket=10
Jan 27 13:33:45 postgres postgres[61605]: [38-1] 2024-01-27 13:33:45.786 CET [61605] DEBUG: reaping dead processes
Jan 27 13:33:45 postgres postgres[61605]: [39-1] 2024-01-27 13:33:45.787 CET [61605] DEBUG: server process (PID 61626) was terminated by signal 11: Segmentation fault
Jan 27 13:33:45 postgres postgres[61605]: [40-1] 2024-01-27 13:33:45.787 CET [61605] LOG: server process (PID 61626) was terminated by signal 11: Segmentation fault
Jan 27 13:33:45 postgres postgres[61605]: [41-1] 2024-01-27 13:33:45.787 CET [61605] LOG: terminating any other active server processes
Jan 27 13:33:45 postgres postgres[61605]: [42-1] 2024-01-27 13:33:45.787 CET [61605] DEBUG: sending SIGQUIT to process 61611
Jan 27 13:33:45 postgres postgres[61605]: [43-1] 2024-01-27 13:33:45.787 CET [61605] DEBUG: sending SIGQUIT to process 61627
Jan 27 13:33:45 postgres postgres[61605]: [44-1] 2024-01-27 13:33:45.787 CET [61605] DEBUG: sending SIGQUIT to process 61607
Jan 27 13:33:45 postgres postgres[61605]: [45-1] 2024-01-27 13:33:45.787 CET [61605] DEBUG: sending SIGQUIT to process 61606
Jan 27 13:33:45 postgres postgres[61605]: [46-1] 2024-01-27 13:33:45.787 CET [61605] DEBUG: sending SIGQUIT to process 61609
Jan 27 13:33:45 postgres postgres[61605]: [47-1] 2024-01-27 13:33:45.787 CET [61605] DEBUG: sending SIGQUIT to process 61610
Jan 27 13:33:45 postgres postgres[61605]: [48-1] 2024-01-27 13:33:45.789 CET [61605] DEBUG: reaping dead processes
Jan 27 13:33:45 postgres postgres[61605]: [49-1] 2024-01-27 13:33:45.789 CET [61605] DEBUG: server process (PID 61627) exited with exit code 2
I am not familiar enough with FreeBSD to be able to gather any crash dumps or backtraces, I am afraid.
--
Michal
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Segmentation fault on FreeBSD with GSSAPI authentication
2024-01-27 12:45 Segmentation fault on FreeBSD with GSSAPI authentication Michał Kłeczek <[email protected]>
@ 2024-01-27 14:43 ` Tom Lane <[email protected]>
2024-01-27 15:20 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Michał Kłeczek <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Tom Lane @ 2024-01-27 14:43 UTC (permalink / raw)
To: Michał Kłeczek <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <[email protected]> writes:
> I am trying to use GSSAPI (Kerberos auth) on FreeBSD.
> After several attempts I was able to build PostgreSQL 16 from FreeBSD ports with GSSAPI support. The steps were:
> 1. Uninstall Heimdal
> 2. Install krb5 (MIT Kerberos)
> 3. Build Pg with GSSAPI support
Which FreeBSD version? Which krb5 package version?
Is this x86_64, or something else?
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Segmentation fault on FreeBSD with GSSAPI authentication
2024-01-27 12:45 Segmentation fault on FreeBSD with GSSAPI authentication Michał Kłeczek <[email protected]>
2024-01-27 14:43 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Tom Lane <[email protected]>
@ 2024-01-27 15:20 ` Michał Kłeczek <[email protected]>
2024-01-27 18:29 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Tom Lane <[email protected]>
0 siblings, 1 reply; 5+ messages in thread
From: Michał Kłeczek @ 2024-01-27 15:20 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
> On 27 Jan 2024, at 15:43, Tom Lane <[email protected]> wrote:
>
> =?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <[email protected]> writes:
>> I am trying to use GSSAPI (Kerberos auth) on FreeBSD.
>
>> After several attempts I was able to build PostgreSQL 16 from FreeBSD ports with GSSAPI support. The steps were:
>> 1. Uninstall Heimdal
>> 2. Install krb5 (MIT Kerberos)
>> 3. Build Pg with GSSAPI support
>
> Which FreeBSD version? Which krb5 package version?
> Is this x86_64, or something else?
Right, sorry:
1. X86_64
2. FreeBSD 13.2 (It is in a TrueNAS Jail if it makes any difference)
3. krb5-1.21.2
—
Michal
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Segmentation fault on FreeBSD with GSSAPI authentication
2024-01-27 12:45 Segmentation fault on FreeBSD with GSSAPI authentication Michał Kłeczek <[email protected]>
2024-01-27 14:43 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Tom Lane <[email protected]>
2024-01-27 15:20 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Michał Kłeczek <[email protected]>
@ 2024-01-27 18:29 ` Tom Lane <[email protected]>
0 siblings, 0 replies; 5+ messages in thread
From: Tom Lane @ 2024-01-27 18:29 UTC (permalink / raw)
To: Michał Kłeczek <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>
=?utf-8?Q?Micha=C5=82_K=C5=82eczek?= <[email protected]> writes:
> On 27 Jan 2024, at 15:43, Tom Lane <[email protected]> wrote:
>> Which FreeBSD version? Which krb5 package version?
>> Is this x86_64, or something else?
> Right, sorry:
> 1. X86_64
> 2. FreeBSD 13.2 (It is in a TrueNAS Jail if it makes any difference)
> 3. krb5-1.21.2
Hmm. I made a desultory attempt at replicating this, using
a fully-updated FreeBSD 13.2 image. I can't find anything wrong,
but it's not clear to me that I duplicated your configuration.
To make sure we're on the same page: do the tests in src/test/kerberos
in our source tree pass on your system? Read the README there for
caveats, then do
make check PG_TEST_EXTRA=kerberos
regards, tom lane
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2024-01-27 18:29 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-11-11 22:40 [PATCH 1/1] resownerbench Heikki Linnakangas <[email protected]>
2024-01-27 12:45 Segmentation fault on FreeBSD with GSSAPI authentication Michał Kłeczek <[email protected]>
2024-01-27 14:43 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Tom Lane <[email protected]>
2024-01-27 15:20 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Michał Kłeczek <[email protected]>
2024-01-27 18:29 ` Re: Segmentation fault on FreeBSD with GSSAPI authentication Tom Lane <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox