SPI_execute
SPI_execute — выполнить команду
Синтаксис
int SPI_execute(const char *command
, boolread_only
, longcount
)
Описание
SPI_execute
выполняет заданную команду SQL для получения строк в количестве, ограниченном count
. С параметром read_only
, равным true
, команда должна только читать данные; это несколько сокращает издержки на её выполнение.
Эту функцию можно вызывать только из подключённой функции на C.
Если count
равен 0, команда выполняется для всех строк, к которым она применима. Если count
больше нуля, будет получено не более чем count
строк; выполнение команды остановится при достижении этого предела, практически так же, как и с предложением LIMIT
в запросе. Например, команда:
SPI_execute("SELECT * FROM foo", true, 5);
получит из таблицы не более 5 строк. Заметьте, что это ограничение действует, только когда команда действительно возвращает строки. Например, эта команда:
SPI_execute("INSERT INTO foo SELECT * FROM bar", false, 5);
вставляет все строки из bar
, игнорируя параметр count
. Однако команда
SPI_execute("INSERT INTO foo SELECT * FROM bar RETURNING *", false, 5);
вставит не более 5 строк, так как её выполнение будет остановлено после получения пятой строки, выданной предложением RETURNING
.
В одной строке можно передать несколько команд; SPI_execute
возвращает результат команды, выполненной последней. Параметр count
при этом будет применяться к каждой команде по отдельности (несмотря даже на то, что возвращён будет только последний результат). Это ограничение не будет распространяться на скрытые команды, генерируемые правилами.
Когда параметр read_only
равен false
, SPI_execute
увеличивает счётчик команд и получает новый снимок перед выполнением каждой очередной команды в строке. Этот снимок фактически не меняется при текущем уровне изоляции транзакций SERIALIZABLE
или REPEATABLE READ
, но в режиме READ COMMITTED
после обновления снимка очередная команда может видеть результаты только что зафиксированных транзакций из других сеансов. Это важно для согласованного поведения, когда команды модифицируют базу данных.
Когда параметр read_only
равен true
, SPI_execute
не обновляет снимок и не увеличивает счётчик команд, и допускает в строке команд только SELECT
. Заданные команды выполняются со снимком, ранее полученным для окружающего запроса. Этот режим выполнения несколько быстрее режима чтения/записи вследствие исключения издержек, связанных с отдельными командами. Он также позволяет создавать подлинно стабильные функции: так как последующие вызовы в транзакции будут использовать один снимок, результаты команд не изменятся.
Смешивать команды, только читающие, с командами, читающими и пишущими, в одной процедуре, использующей SPI, обычно неразумно; запросы только на чтение не увидят результатов изменений в базе данных, произведённых пишущими запросами.
Число строк, которые были фактически обработаны (последней) командой, возвращается в глобальной переменной SPI_processed
. Если эта функция возвращает значение SPI_OK_SELECT
, SPI_OK_INSERT_RETURNING
, SPI_OK_DELETE_RETURNING
или SPI_OK_UPDATE_RETURNING
, вы можете обратиться по глобальному указателю SPITupleTable *SPI_tuptable
и прочитать строки результата. Некоторые служебные команды (например, EXPLAIN
) также возвращают наборы строк, и SPI_tuptable
будет содержать их результаты и в этих случаях. Другие вспомогательные команды (COPY
, CREATE TABLE AS
) не возвращают набор строк, так что указатель SPI_tuptable
равен NULL, но они так же возвращают число обработанных строк в SPI_processed
.
Структура SPITupleTable
определена так:
typedef struct SPITupleTable { /* Открытые члены */ TupleDesc tupdesc; /* дескриптор кортежа */ HeapTuple *vals; /* массив кортежей */ uint64 numvals; /* число фактически представленных кортежей */ /* Закрытые члены, не предназначенные для внешнего использования */ uint64 alloced; /* зарезервированное в памяти число элементов vals */ MemoryContext tuptabcxt; /* контекст таблицы результатов в памяти */ slist_node next; /* ссылка для внутреннего обслуживания */ SubTransactionId subid; /* подтранзакция, создавшая структуру tuptable */ } SPITupleTable;
Поля tupdesc
, vals
и numvals
могут использоваться кодом, вызывающим SPI, остальные поля являются внутренними. vals
представляет собой массив указателей на кортежи. Число записей в нём указывается в numvals
(по некоторым историческим причинам это число также возвращается в SPI_processed
). Поле tupdesc
содержит дескриптор кортежа, который вы сможете передать функциям SPI, работающими с кортежами.
SPI_finish
освобождает все структуры SPITupleTable
, размещённые в памяти для текущей функции на C. Вы можете освободить структуру конкретной результирующей таблицы, если она вам не нужна, вызвав SPI_freetuptable
.
Аргументы
const char *
command
строка с командой, которая должна быть выполнена
bool
read_only
true
для режима выполнения «только чтение»long
count
максимальное число строк, которое должно быть возвращено; с
0
ограничения нет
Возвращаемое значение
Если команда была выполнена успешно, возвращается одно из следующих (неотрицательных) значений:
SPI_OK_SELECT
если выполнялась команда
SELECT
(но неSELECT INTO
)SPI_OK_SELINTO
если выполнялась команда
SELECT INTO
SPI_OK_INSERT
если выполнялась команда
INSERT
SPI_OK_DELETE
если выполнялась команда
DELETE
SPI_OK_UPDATE
если выполнялась команда
UPDATE
SPI_OK_MERGE
если выполнялась команда
MERGE
SPI_OK_INSERT_RETURNING
если выполнялась команда
INSERT RETURNING
SPI_OK_DELETE_RETURNING
если выполнялась команда
DELETE RETURNING
SPI_OK_UPDATE_RETURNING
если выполнялась команда
UPDATE RETURNING
SPI_OK_UTILITY
если выполнялась служебная команда (например,
CREATE TABLE
)SPI_OK_REWRITTEN
если команда была преобразована правилом в команду другого вида (например,
UPDATE
стал командойINSERT
).
В случае ошибки возвращается одно из следующих отрицательных значений:
SPI_ERROR_ARGUMENT
если в качестве
command
переданNULL
илиcount
меньше 0SPI_ERROR_COPY
при попытке выполнить
COPY TO stdout
илиCOPY FROM stdin
SPI_ERROR_TRANSACTION
при попытке выполнить команду управления транзакциями (
BEGIN
,COMMIT
,ROLLBACK
,SAVEPOINT
,PREPARE TRANSACTION
,COMMIT PREPARED
,ROLLBACK PREPARED
или любую их вариацию)SPI_ERROR_OPUNKNOWN
если тип команды неизвестен (такого быть не должно)
SPI_ERROR_UNCONNECTED
если вызывается из неподключённой функции на C
Примечания
Все функции SPI, выполняющие запросы, заполняют и SPI_processed
, и SPI_tuptable
(только указатель, но не содержимое структуры). Сохраните эти две глобальные переменные в локальных переменных функции на C, если хотите обращаться к таблице результата SPI_execute
или другой функции, выполняющей запрос, в нескольких вызовах процедуры.
pg_standby
pg_standby — supports the creation of a PostgreSQL warm standby server
Synopsis
pg_standby
[option
...] archivelocation
nextwalfile
walfilepath
[restartwalfile
]
Description
pg_standby supports creation of a “warm standby” database server. It is designed to be a production-ready program, as well as a customizable template should you require specific modifications.
pg_standby is designed to be a waiting restore_command
, which is needed to turn a standard archive recovery into a warm standby operation. Other configuration is required as well, all of which is described in the main server manual (see Section 26.2).
To configure a standby server to use pg_standby, put this into its postgresql.conf
configuration file:
restore_command = 'pg_standby archiveDir
%f %p %r'
where archiveDir
is the directory from which WAL segment files should be restored.
If restartwalfile
is specified, normally by using the %r
macro, then all WAL files logically preceding this file will be removed from archivelocation
. This minimizes the number of files that need to be retained, while preserving crash-restart capability. Use of this parameter is appropriate if the archivelocation
is a transient staging area for this particular standby server, but not when the archivelocation
is intended as a long-term WAL archive area.
pg_standby assumes that archivelocation
is a directory readable by the server-owning user. If restartwalfile
(or -k
) is specified, the archivelocation
directory must be writable too.
There are two ways to fail over to a “warm standby” database server when the master server fails:
- Smart Failover
In smart failover, the server is brought up after applying all WAL files available in the archive. This results in zero data loss, even if the standby server has fallen behind, but if there is a lot of unapplied WAL it can be a long time before the standby server becomes ready. To trigger a smart failover, create a trigger file containing the word
smart
, or just create it and leave it empty.- Fast Failover
In fast failover, the server is brought up immediately. Any WAL files in the archive that have not yet been applied will be ignored, and all transactions in those files are lost. To trigger a fast failover, create a trigger file and write the word
fast
into it. pg_standby can also be configured to execute a fast failover automatically if no new WAL file appears within a defined interval.
Options
pg_standby accepts the following command-line arguments:
-c
Use
cp
orcopy
command to restore WAL files from archive. This is the only supported behavior so this option is useless.-d
Print lots of debug logging output on
stderr
.-k
Remove files from
archivelocation
so that no more than this many WAL files before the current one are kept in the archive. Zero (the default) means not to remove any files fromarchivelocation
. This parameter will be silently ignored ifrestartwalfile
is specified, since that specification method is more accurate in determining the correct archive cut-off point. Use of this parameter is deprecated as of PostgreSQL 8.3; it is safer and more efficient to specify arestartwalfile
parameter. A too small setting could result in removal of files that are still needed for a restart of the standby server, while a too large setting wastes archive space.-r
maxretries
Set the maximum number of times to retry the copy command if it fails (default 3). After each failure, we wait for
sleeptime
*num_retries
so that the wait time increases progressively. So by default, we will wait 5 secs, 10 secs, then 15 secs before reporting the failure back to the standby server. This will be interpreted as end of recovery and the standby will come up fully as a result.-s
sleeptime
Set the number of seconds (up to 60, default 5) to sleep between tests to see if the WAL file to be restored is available in the archive yet. The default setting is not necessarily recommended; consult Section 26.2 for discussion.
-t
triggerfile
Specify a trigger file whose presence should cause failover. It is recommended that you use a structured file name to avoid confusion as to which server is being triggered when multiple servers exist on the same system; for example
/tmp/pgsql.trigger.5432
.-V
--version
Print the pg_standby version and exit.
-w
maxwaittime
Set the maximum number of seconds to wait for the next WAL file, after which a fast failover will be performed. A setting of zero (the default) means wait forever. The default setting is not necessarily recommended; consult Section 26.2 for discussion.
-?
--help
Show help about pg_standby command line arguments, and exit.
Notes
pg_standby is designed to work with PostgreSQL 8.2 and later.
PostgreSQL 8.3 provides the %r
macro, which is designed to let pg_standby know the last file it needs to keep. With PostgreSQL 8.2, the -k
option must be used if archive cleanup is required. This option remains available in 8.3, but its use is deprecated.
PostgreSQL 8.4 provides the recovery_end_command
option. Without this option a leftover trigger file can be hazardous.
pg_standby is written in C and has an easy-to-modify source code, with specifically designated sections to modify for your own needs
Examples
On Linux or Unix systems, you might use:
archive_command = 'cp %p .../archive/%f' restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log' recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
where the archive directory is physically located on the standby server, so that the archive_command
is accessing it across NFS, but the files are local to the standby (enabling use of ln
). This will:
produce debugging output in
standby.log
sleep for 2 seconds between checks for next WAL file availability
stop waiting only when a trigger file called
/tmp/pgsql.trigger.5442
appears, and perform failover according to its contentremove the trigger file when recovery ends
remove no-longer-needed files from the archive directory
On Windows, you might use:
archive_command = 'copy %p ...\\archive\\%f' restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p %r 2>>standby.log' recovery_end_command = 'del C:\pgsql.trigger.5442'
Note that backslashes need to be doubled in the archive_command
, but not in the restore_command
or recovery_end_command
. This will:
use the
copy
command to restore WAL files from archiveproduce debugging output in
standby.log
sleep for 5 seconds between checks for next WAL file availability
stop waiting only when a trigger file called
C:\pgsql.trigger.5442
appears, and perform failover according to its contentremove the trigger file when recovery ends
remove no-longer-needed files from the archive directory
The copy
command on Windows sets the final file size before the file is completely copied, which would ordinarily confuse pg_standby. Therefore pg_standby waits sleeptime
seconds once it sees the proper file size. GNUWin32's cp
sets the file size only after the file copy is complete.
Since the Windows example uses copy
at both ends, either or both servers might be accessing the archive directory across the network.
Author
Simon Riggs <simon@2ndquadrant.com>