On 2020-03-06 08:54, Kyotaro Horiguchi wrote:
The syntax seems getting confused. What happens if we typed in the
command "WAIT FOR TIMESTAMP '...' UNTIL TIMESTAMP '....'"? It seems
to me the options is useles. Couldn't the TIMEOUT option be a part of
event? I know gram.y doesn't accept that syntax but it is not
apparent from the description above.
I`ll fix the doc file.
Synopsis
==========
WAIT FOR [ANY | SOME | ALL] event [, event ...]
and event is:
LSN value [options]
TIMESTAMP value
and options is:
TIMEOUT delay
UNTIL TIMESTAMP timestamp
As I read through the previous thread, one of the reason for this
feature implemented as a syntax is it was inteded to be combined into
BEGIN statement. If there is not any use case for the feature midst
of a transaction, why don't you turn it into a part of BEGIN command?
It`s seem to have some limitations on hot standbys. I`ll take few days
to make a prototype.
Description
==========
WAIT FOR - make to wait statements (that are beneath) on sleep until
event happens (Don’t process new queries until an event happens).
...
Notice: WAIT FOR will release on PostmasterDeath or Interruption
events
if they come earlier then LSN or timeout.
I think interrupts ought to result in ERROR.
wait.c adds a fair amount of code and uses proc-array based
approach. But Thomas suggested queue-based approach and I also think
it is better. We already have a queue-based mechanism that behaves
almost the same with this feature in the comit code on master-side. It
avoids spurious backend wakeups. Couldn't we extend SyncRepWaitForLSN
or share a part of the code/infrastructures so that this feature can
share the code?
I`ll take a look on.
Thank you for your review.
Rebased patch is attached.
--
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
