Sophie

Sophie

distrib > Mageia > 6 > x86_64 > media > core-updates > by-pkgid > 78943537a03eb3bb165d73ab4fd2d713 > files > 900

postgresql9.4-docs-9.4.24-1.mga6.noarch.rpm

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>test_shm_mq</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 9.4.24 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="Additional Supplied Modules"
HREF="contrib.html"><LINK
REL="PREVIOUS"
TITLE="test_parser"
HREF="test-parser.html"><LINK
REL="NEXT"
TITLE="tsearch2"
HREF="tsearch2.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2019-08-11T16:12:25"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="4"
ALIGN="center"
VALIGN="bottom"
><A
HREF="index.html"
>PostgreSQL 9.4.24 Documentation</A
></TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
TITLE="test_parser"
HREF="test-parser.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="contrib.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Appendix F. Additional Supplied Modules</TD
><TD
WIDTH="20%"
ALIGN="right"
VALIGN="top"
><A
TITLE="tsearch2"
HREF="tsearch2.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="TEST-SHM-MQ"
>F.41. test_shm_mq</A
></H1
><P
>  <TT
CLASS="FILENAME"
>test_shm_mq</TT
> is an example of how to use dynamic shared memory
  and the shared memory message queue facilities to coordinate a user backend
  with the efforts of one or more background workers.  It is not intended to
  do anything useful on its own; rather, it is a demonstration of how these
  facilities can be used, and a unit test of those facilities.
 </P
><P
>  The function is this extension send the same message repeatedly through
  a loop of processes.  The message payload, the size of the message queue
  through which it is sent, and the number of processes in the loop are
  configurable.  At the end, the message may be verified to ensure that it
  has not been corrupted in transmission.
 </P
><DIV
CLASS="SECT2"
><H2
CLASS="SECT2"
><A
NAME="AEN131580"
>F.41.1. Functions</A
></H2
><PRE
CLASS="SYNOPSIS"
>test_shm_mq(queue_size int8, message text,
            repeat_count int4 default 1, num_workers int4 default 1)
    RETURNS void</PRE
><P
>   This function sends and receives messages synchronously.  The user
   backend sends the provided message to the first background worker using
   a message queue of the given size.  The first background worker sends
   the message to the second background worker, if the number of workers
   is greater than one, and so forth.  Eventually, the last background
   worker sends the message back to the user backend.  If the repeat count
   is greater than one, the user backend then sends the message back to
   the first worker.  Once the message has been sent and received by all
   the coordinating processes a number of times equal to the repeat count,
   the user backend verifies that the message finally received matches the
   one originally sent and throws an error if not.
  </P
><PRE
CLASS="SYNOPSIS"
>test_shm_mq_pipelined(queue_size int8, message text,
                      repeat_count int4 default 1, num_workers int4 default 1,
                      verify bool default true)
    RETURNS void</PRE
><P
>   This function sends the same message multiple times, as specified by the
   repeat count, to the first background worker using a queue of the given
   size.  These messages are then forwarded to each background worker in
   turn, in each case using a queue of the given size.  Finally, the last
   background worker sends the messages back to the user backend.  The user
   backend uses non-blocking sends and receives, so that it may begin receiving
   copies of the message before it has finished sending all copies of the
   message.  The <TT
CLASS="LITERAL"
>verify</TT
> argument controls whether or not the
   received copies are checked against the message that was sent.  (This
   takes nontrivial time so it may be useful to disable it for benchmarking
   purposes.)
  </P
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="test-parser.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="tsearch2.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>test_parser</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="contrib.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>tsearch2</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>