On 2023-11-27 03:08, Alexander Korotkov wrote:
I've retried my case with v6 and it doesn't fail anymore. But I
wonder how safe it is to reset xmin within the user-visible function?
We have no guarantee that the function is not called inside the
complex query. Then how will the rest of the query
On Mon, Nov 20, 2023 at 1:10 PM Картышов Иван
wrote:
> Alexander, thank you for your review and pointing this issues. According to
> them I made some fixes and rebase all patch.
>
> But I can`t repeat your ERROR. Not with hot_standby_feedback = on nor
> hot_standby_feedback = off.
>
> master: crea
On Thu, Nov 23, 2023 at 5:52 AM Bowen Shi wrote:
> I used the latest code and found some conflicts while applying. Which PG
> version did you rebase?
I've successfully applied the patch on bc3c8db8ae. But I've used
"patch -p1 < wait_proc_v6.patch", git am doesn't work.
--
Regards,
Alexande
Hi,
I used the latest code and found some conflicts while applying. Which PG
version did you rebase?
Regards
Bowen Shi
Alexander, thank you for your review and pointing this issues. According to
them I made some fixes and rebase all patch.
But I can`t repeat your ERROR. Not with hot_standby_feedback = on nor
hot_standby_feedback = off.master: create table test as (select i from
generate_series(1,1) i);
slav
Hi!
On Wed, Oct 4, 2023 at 1:22 PM Alexander Korotkov wrote:
> I see you're concentrating on the procedural version of this feature. But
> when you're calling a procedure within a normal SQL statement, the executor
> gets a snapshot and holds it until the procedure finishes. In the case the
>
Hi, Ivan!
On Fri, Jun 30, 2023 at 11:32 AM Картышов Иван
wrote:
> All rebased and tested
>
Thank you for continuing to work on this patch.
I see you're concentrating on the procedural version of this feature. But
when you're calling a procedure within a normal SQL statement, the executor
gets
All rebased and tested
--
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres comp...@postgrespro.ru>
diff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index becc2bda62..c7460bd9b8 100644
--- a/src/backend/access/
Fix build.meson troubles
--
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index dbe9394762..422bb1ed82 100644
--- a/src/backend/access/transam/xlogreco
Update patch to fix conflict with master
--
Ivan Kartyshov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Companydiff --git a/src/backend/access/transam/xlogrecovery.c b/src/backend/access/transam/xlogrecovery.c
index dbe9394762..422bb1ed82 100644
--- a/src/backend/access/t
Here I made new patch of feature, discussed above.
WAIT FOR procedure - waits for certain lsn on pause
==
Synopsis
==
SELECT pg_wait_lsn(‘LSN’, timeout) returns boolean
Where timeout = 0, will wait infinite without timeout
And if timeout = 1, then just check if lsn wa
On 28.02.23 11:10, Kartyshov Ivan wrote:
3) Procedure style: Tom Lane and Kyotaro (wait_proc_v1.patch)
https://www.postgresql.org/message-id/27171.1586439221%40sss.pgh.pa.us
https://www.postgresql.org/message-id/20210121.173009.235021120161403875.horikyota.ntt%40gmail.com
==
advantages: n
On Wed, Mar 01, 2023 at 03:31:06PM -0500, Greg Stark wrote:
> Fwiw I prefer the functions approach. I do like me some nice syntax
> but I don't see any particular advantage of the special syntax in this
> case. They don't seem to provide any additional expressiveness.
So do I, eventhough I saw a p
On Tue, 28 Feb 2023 at 05:13, Kartyshov Ivan wrote:
>
> Below I provide the implementation of patches for the first three types.
> I propose to discuss this feature again/
Oof, that doesn't really work with the cfbot. It tries to apply all
three patches and of course the second and third fail to
Intro==
The main purpose of the feature is to achieve
read-your-writes-consistency, while using async replica for reads and
primary for writes. In that case lsn of last modification is stored
inside
application. We cannot store this lsn inside database, since reads are
distributed across
At Thu, 18 Mar 2021 18:57:15 +0500, Ibrar Ahmed wrote
in
> On Thu, Jan 21, 2021 at 1:30 PM Kyotaro Horiguchi
> wrote:
>
> > Hello.
> >
> > At Wed, 18 Nov 2020 15:05:00 +0300, a.pervush...@postgrespro.ru wrote in
> > > I've changed the BEGIN WAIT FOR LSN statement to core functions
> > > pg_wai
On Thu, Jan 21, 2021 at 1:30 PM Kyotaro Horiguchi
wrote:
> Hello.
>
> At Wed, 18 Nov 2020 15:05:00 +0300, a.pervush...@postgrespro.ru wrote in
> > I've changed the BEGIN WAIT FOR LSN statement to core functions
> > pg_waitlsn, pg_waitlsn_infinite and pg_waitlsn_no_wait.
> > Currently the function
Hello.
At Wed, 18 Nov 2020 15:05:00 +0300, a.pervush...@postgrespro.ru wrote in
> I've changed the BEGIN WAIT FOR LSN statement to core functions
> pg_waitlsn, pg_waitlsn_infinite and pg_waitlsn_no_wait.
> Currently the functions work inside repeatable read transactions, but
> waitlsn creates a s
Hello,
I've changed the BEGIN WAIT FOR LSN statement to core functions
pg_waitlsn, pg_waitlsn_infinite and pg_waitlsn_no_wait.
Currently the functions work inside repeatable read transactions, but
waitlsn creates a snapshot if called first in a transaction block, which
can possibly lead the tr
Hi!
On Mon, Nov 16, 2020 at 1:09 PM wrote:
> I've changed the BEGIN WAIT FOR LSN statement to core functions
> pg_waitlsn, pg_waitlsn_infinite and pg_waitlsn_no_wait.
> Currently the functions work inside repeatable read transactions, but
> waitlsn creates a snapshot if called first in a transact
Hello,
I've changed the BEGIN WAIT FOR LSN statement to core functions
pg_waitlsn, pg_waitlsn_infinite and pg_waitlsn_no_wait.
Currently the functions work inside repeatable read transactions, but
waitlsn creates a snapshot if called first in a transaction block, which
can possibly lead the tr
Anna Akenteva писал 2020-04-08 22:36:
On 2020-04-08 04:09, Kyotaro Horiguchi wrote:
I like your suggested keywords! I think that "AFTER" + "WITHIN" sound
the most natural. We could completely give up the LSN keyword for now.
The final command could look something like:
BEGIN AFTER ‘0/303EC60’ W
On Tue, Aug 18, 2020 at 01:12:51PM +0300, Anna Akenteva wrote:
> I updated the most recent patch and removed the use of "master" from it,
> replacing it with "primary".
This is failing to apply lately, causing the CF bot to complain:
http://cfbot.cputube.org/patch_29_772.log
--
Michael
signature
On 2020-07-13 14:21, Daniel Gustafsson wrote:
This patch require some rewording of documentation/comments and
variable names
after the language change introduced by 229f8c219f8f..a9a4a7ad565b, the
thread
below can be used as reference for how to change:
https://www.postgresql.org/message-id/fl
This patch require some rewording of documentation/comments and variable names
after the language change introduced by 229f8c219f8f..a9a4a7ad565b, the thread
below can be used as reference for how to change:
https://www.postgresql.org/message-id/flat/20200615182235.x7lch5n6kcjq4aue%40alap3.anaraze
On 2020-04-11 00:44, Andres Freund wrote:
I think there's also some advantages of having it in a single statement
for poolers. If a pooler analyzes BEGIN AFTER 'xx/xx' it could
e.g. redirect the transaction to a node that's caught up far enough,
instead of blocking. But that can't work even close
Hi,
On 2020-04-10 17:17:10 -0400, Tom Lane wrote:
> > ISTM that we can make it BEGIN AFTER 'xx/xx' or such, which'd not
> > require any keywords, it'd be easier to use than a procedure.
>
> I still don't see a good argument for tying this to BEGIN. If it
> has to be a statement, why not a standa
Andres Freund writes:
> On 2020-04-10 16:29:39 -0400, Tom Lane wrote:
>> Good point, but we could address that by making it a procedure no?
> Probably. Don't think we have great infrastructure for builtin
> procedures yet though? We'd presumably not want to use plpgsql.
Don't think anyone's trie
Hi,
On 2020-04-10 16:29:39 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I don't think a function is a good idea - it'll cause a snapshot to be
> > held while waiting. Which in turn will cause hot_standby_feedback to not
> > be able to report an increased xmin up. And it will possibly hit
>
Andres Freund writes:
> I don't think a function is a good idea - it'll cause a snapshot to be
> held while waiting. Which in turn will cause hot_standby_feedback to not
> be able to report an increased xmin up. And it will possibly hit
> snapshot recovery conflicts.
Good point, but we could addr
Hi,
On 2020-04-10 11:25:02 +0900, Fujii Masao wrote:
> > BEGIN
> > WAIT (LSN '16/B374D848', WHATEVER_OPTION_YOU_WANT);
> > ...
> > COMMIT;
> >
> > It requires only one reserved keyword 'WAIT'. The advantage of this
> > approach is that it can be extended to support xid, timestamp, csn or
> > an
On 2020-04-10 05:25, Fujii Masao wrote:
On 2020/04/10 3:16, Alexey Kondratov wrote:
Just another idea in case if one will still decide to go with a
separate statement + BEGIN integration instead of a function. We could
use parenthesized options list here. This is already implemented for
VACUUM
On 2020/04/10 3:16, Alexey Kondratov wrote:
On 2020-04-09 16:33, Tom Lane wrote:
Fujii Masao writes:
On 2020/04/09 16:11, Kyotaro Horiguchi wrote:
At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in
Why is this getting grafted onto BEGIN/START TRANSACTION in the
first place?
The rat
On 2020-04-09 16:33, Tom Lane wrote:
Fujii Masao writes:
On 2020/04/09 16:11, Kyotaro Horiguchi wrote:
At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane
wrote in
Why is this getting grafted onto BEGIN/START TRANSACTION in the
first place?
The rationale for not being a fmgr function is stated in
Fujii Masao writes:
> On 2020/04/09 16:11, Kyotaro Horiguchi wrote:
>> At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in
>>> Why is this getting grafted onto BEGIN/START TRANSACTION in the
>>> first place?
>> The rationale for not being a fmgr function is stated in the following
>> comments.
On 2020/04/09 16:11, Kyotaro Horiguchi wrote:
At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in
Anna Akenteva writes:
I'd like to hear others' opinions on the syntax as well.
Pardon me for coming very late to the party, but it seems like there are
other questions that ought to be ans
At Wed, 08 Apr 2020 16:35:46 -0400, Tom Lane wrote in
> Anna Akenteva writes:
> > I'd like to hear others' opinions on the syntax as well.
>
> Pardon me for coming very late to the party, but it seems like there are
> other questions that ought to be answered before we worry about any of
> this
Anna Akenteva writes:
> I'd like to hear others' opinions on the syntax as well.
Pardon me for coming very late to the party, but it seems like there are
other questions that ought to be answered before we worry about any of
this. Why is this getting grafted onto BEGIN/START TRANSACTION in the
f
On 2020-04-08 04:09, Kyotaro Horiguchi wrote:
How about something like the follows.
BEGIN AFTER ColId Sconst
BEGIN FOLOWING ColId Sconst
UNTIL ;
LIMIT BY ;
WITHIN Iconst;
regards.
I like your suggested keywords! I think that "AFTER" + "WITHIN" sound
the most natural. We could completely giv
At Wed, 8 Apr 2020 02:52:55 +0300, Alexander Korotkov
wrote in
> On Wed, Apr 8, 2020 at 2:14 AM Kartyshov Ivan
> wrote:
> > On 2020-04-08 00:27, Tom Lane wrote:
> > > Alexander Korotkov writes:
> > » WAIT FOR LSN lsn [ TIMEOUT timeout ]
> > >
> > > This seems like a really carelessly chosen
On Wed, Apr 8, 2020 at 2:14 AM Kartyshov Ivan
wrote:
> On 2020-04-08 00:27, Tom Lane wrote:
> > Alexander Korotkov writes:
> » WAIT FOR LSN lsn [ TIMEOUT timeout ]
> >
> > This seems like a really carelessly chosen syntax —- *three* new
> > keywords, when you probably didn't need any. Are you
On 2020-04-08 00:27, Tom Lane wrote:
Alexander Korotkov writes:
» WAIT FOR LSN lsn [ TIMEOUT timeout ]
This seems like a really carelessly chosen syntax —- *three* new
keywords, when you probably didn't need any. Are you not aware that
there is distributed overhead in the grammar for every
On Tue, Apr 7, 2020 at 10:58 PM Anna Akenteva wrote:
> Thank you for your review!
> Ivan and I have worked on the patch and tried to address your comments:
I've pushed this. I promise to do careful post-commit review and
resolve any issues arising.
--
Alexander Korotkov
Postgres Professiona
On 2020-04-07 12:58, Amit Kapila wrote:
Review comments:
1.
+static void
+DeleteEvent(void)
I don't see how this is implemented or called to handle any errors.
2.
+ if (InterruptPending)
+ {
+ DeleteEvent();
+ ProcessInterrupts();
+ }
We generally do this type of handling via CHECK_FOR_INTERRUP
On Tue, Apr 7, 2020 at 5:37 PM Anna Akenteva wrote:
>
> On 2020-04-07 13:32, Amit Kapila wrote:
> > First, I don't
> > think we have a consensus on the syntax being used in the patch
> > (various people didn't agree to LSN specific syntax). They wanted a
> > more generic syntax and I see that we
On Tue, Apr 7, 2020 at 3:07 PM Anna Akenteva wrote:
> On 2017-10-31 12:42:56, Ants Aasma wrote:
> > For lack of a better proposal I would like something along the lines
> > of:
> > WAIT FOR state_id[, state_id] [ OPTIONS (..)]
>
> As for giving up waiting for multiple events: we can only wait for
On 2020-04-07 13:32, Amit Kapila wrote:
First, I don't
think we have a consensus on the syntax being used in the patch
(various people didn't agree to LSN specific syntax). They wanted a
more generic syntax and I see that we tried to implement it and it
turns out to be a bit complex but that doe
On Tue, Apr 7, 2020 at 5:56 AM Alexander Korotkov
wrote:
>
> On Tue, Apr 7, 2020 at 12:58 AM Kartyshov Ivan
> wrote:
> > On 2020-04-04 03:14, Alexander Korotkov wrote:
> > > I think that now we would be fine with single LSN and single TIMEOUT.
> > > In future we may add multiple LSNs/TIMEOUTs or/
On Tue, Apr 7, 2020 at 7:56 AM Anna Akenteva wrote:
>
> On 2020-04-07 00:58, Kartyshov Ivan wrote:
> > Ok, here is a new version of patch with single LSN and TIMEOUT.
>
> I had a look at the code and did some more code cleanup, with Ivan's
> permission.
> This is what I did:
> - Removed "WAIT FOR"
On 2020-04-07 00:58, Kartyshov Ivan wrote:
Ok, here is a new version of patch with single LSN and TIMEOUT.
I had a look at the code and did some more code cleanup, with Ivan's
permission.
This is what I did:
- Removed "WAIT FOR" command tag from cmdtaglist.h and renamed WaitStmt
to WaitClaus
On Tue, Apr 7, 2020 at 12:58 AM Kartyshov Ivan
wrote:
> On 2020-04-04 03:14, Alexander Korotkov wrote:
> > I think that now we would be fine with single LSN and single TIMEOUT.
> > In future we may add multiple LSNs/TIMEOUTs or/and support for
> > expressions as LSNs/TIMEOUTs if we figure out it's
On 2020-04-04 03:14, Alexander Korotkov wrote:
I think that now we would be fine with single LSN and single TIMEOUT.
In future we may add multiple LSNs/TIMEOUTs or/and support for
expressions as LSNs/TIMEOUTs if we figure out it's necessary.
I also think it's good to couple waiting for lsn with
On 2020-04-03 21:51, Anna Akenteva wrote:
I did some code cleanup and added tests - both for the standalone WAIT
FOR statement and for WAIT FOR as a part of BEGIN. The new patch is
attached.
I did more cleanup and code optimization on waiting events on latch.
And rebase patch.
--
Ivan Kartysho
Hi!
On Fri, Apr 3, 2020 at 9:51 PM Anna Akenteva wrote:
> In the patch that I reviewed, you could do things like:
> WAIT FOR
> LSN lsn0,
> LSN lsn1 TIMEOUT time1,
> LSN lsn2 TIMEOUT time2;
> and such a statement was in practice equivalent to
> WAIT FOR LSN(max
I did some code cleanup and added tests - both for the standalone WAIT
FOR statement and for WAIT FOR as a part of BEGIN. The new patch is
attached.
On 2020-04-03 17:29, Alexey Kondratov wrote:
On 2020-04-01 02:26, Anna Akenteva wrote:
- WAIT FOR [ANY | ALL] event [, ...]
- BEGIN [ WORK | TR
On 2020-04-01 02:26, Anna Akenteva wrote:
On 2020-03-27 04:15, Kartyshov Ivan wrote:
Anna, feel free to work on this patch.
Ivan and I worked on this patch a bit more. We fixed the bugs that we
could find and cleaned up the code. For now, we've kept both options:
WAIT as a standalone statement
On 2020-03-27 04:15, Kartyshov Ivan wrote:
Anna, feel free to work on this patch.
Ivan and I worked on this patch a bit more. We fixed the bugs that we
could find and cleaned up the code. For now, we've kept both options:
WAIT as a standalone statement and WAIT as a part of BEGIN. The new
pa
Anna, thank you for your review.
On 2020-03-25 21:10, Anna Akenteva wrote:
On 2020-03-21 14:16, Kartyshov Ivan wrote:
and event is:
LSN value [options]
TIMESTAMP value
I would maybe remove WAIT FOR TIMESTAMP. As Robert Haas has pointed
out, it seems a lot like pg_slee
On 2020-03-21 14:16, Kartyshov Ivan wrote:
As it was discussed earlier, I added wait for statement into
begin/start statement.
Thanks! To address the discussion: I like the idea of having WAIT as a
part of BEGIN statement rather than a separate command, as Thomas Munro
suggested. That way, the
As it was discussed earlier, I added wait for statement into begin/start
statement.
Synopsis
==
BEGIN [ WORK | TRANSACTION ] [ transaction_mode[, ...] ] wait_for_event
where transaction_mode is one of:
ISOLATION LEVEL { SERIALIZABLE | REPEATABLE READ | READ
COMMITTED |
On 2020-03-17 15:47, Kartyshov Ivan wrote:
Synopsis
==
WAIT FOR [ANY | SOME | ALL] event [, event ...]
I'm confused as to what SOME would mean in this
command's syntax, but I can see you removed it
from gram.y since the last patch. Did you
decide to not implement it after all?
Also,
I made some improvements over old implementation WAIT FOR.
Synopsis
==
WAIT FOR [ANY | SOME | ALL] event [, event ...]
and event is:
LSN value options
TIMESTAMP value
and options is:
TIMEOUT delay
UNTIL TIMESTAMP timestamp
ALL - option used by
Sorry, I have some troubles on email sending.
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 o
I just wanted to express my excitement that this is being picked up again.
I was very much looking forward to this years ago, and the use case for me
is still there, so I am excited to see this moving again.
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 sy
Hello.
I looked this briefly but not tested.
At Fri, 06 Mar 2020 00:24:01 +0300, Kartyshov Ivan
wrote in
> On 2018-03-06 14:50, Simon Riggs wrote:
> > On 6 March 2018 at 11:24, Dmitry Ivanov
> > wrote:
> >>> In PG11, I propose the following command, sticking mostly to Ants'
> >>> syntax, and
On 2018-03-06 14:50, Simon Riggs wrote:
On 6 March 2018 at 11:24, Dmitry Ivanov
wrote:
In PG11, I propose the following command, sticking mostly to Ants'
syntax, and allowing to wait for multiple events before it returns.
It
doesn't hold snapshot and will not get cancelled by Hot Standby.
WA
On Wed, Mar 04, 2020 at 07:17:31AM -0500, David Steele wrote:
> On 3/4/20 5:36 AM, Fujii Masao wrote:
>> There are no updates from about two years before, but this patch
>> has been registered in CF 2020-03. Not sure why. It should be marked
>> as Returned with Feedback again?
>
> Worse, it was ma
On 3/4/20 5:36 AM, Fujii Masao wrote:
On Tue, Mar 13, 2018 at 10:06 PM David Steele wrote:
On 3/6/18 9:25 PM, Michael Paquier wrote:
On Tue, Mar 06, 2018 at 02:24:24PM +0300, Ivan Kartyshov wrote:
Hello, I now is preparing the patch over syntax that Simon offered. And in
few day I will update
On Tue, Mar 13, 2018 at 10:06 PM David Steele wrote:
>
> Hi Ivan,
>
> On 3/6/18 9:25 PM, Michael Paquier wrote:
> > On Tue, Mar 06, 2018 at 02:24:24PM +0300, Ivan Kartyshov wrote:
> >> Hello, I now is preparing the patch over syntax that Simon offered. And in
> >> few day I will update the patch.
Hi Ivan,
On 3/6/18 9:25 PM, Michael Paquier wrote:
> On Tue, Mar 06, 2018 at 02:24:24PM +0300, Ivan Kartyshov wrote:
>> Hello, I now is preparing the patch over syntax that Simon offered. And in
>> few day I will update the patch.
>> Thank you for your interest in thread.
>
> It has been more tha
On Tue, Mar 06, 2018 at 02:24:24PM +0300, Ivan Kartyshov wrote:
> Hello, I now is preparing the patch over syntax that Simon offered. And in
> few day I will update the patch.
> Thank you for your interest in thread.
It has been more than one month since a patch update has been requested,
and time
On 6 March 2018 at 11:24, Dmitry Ivanov wrote:
>> In PG11, I propose the following command, sticking mostly to Ants'
>> syntax, and allowing to wait for multiple events before it returns. It
>> doesn't hold snapshot and will not get cancelled by Hot Standby.
>>
>> WAIT FOR event [, event ...] opti
In PG11, I propose the following command, sticking mostly to Ants'
syntax, and allowing to wait for multiple events before it returns. It
doesn't hold snapshot and will not get cancelled by Hot Standby.
WAIT FOR event [, event ...] options
event is
LSN value
TIMESTAMP value
options
TIMEOUT dela
Andres Freund писал 2018-03-02 03:47:
On 2018-02-02 19:41:37 +, Simon Riggs wrote:
On 2 February 2018 at 18:46, Robert Haas
wrote:
> On Fri, Feb 2, 2018 at 3:46 AM, Simon Riggs wrote:
>> In PG11, I propose the following command, sticking mostly to Ants'
>> syntax, and allowing to wait for
On 2018-02-02 19:41:37 +, Simon Riggs wrote:
> On 2 February 2018 at 18:46, Robert Haas wrote:
> > On Fri, Feb 2, 2018 at 3:46 AM, Simon Riggs wrote:
> >> In PG11, I propose the following command, sticking mostly to Ants'
> >> syntax, and allowing to wait for multiple events before it returns
On 2 February 2018 at 18:46, Robert Haas wrote:
> On Fri, Feb 2, 2018 at 3:46 AM, Simon Riggs wrote:
>> In PG11, I propose the following command, sticking mostly to Ants'
>> syntax, and allowing to wait for multiple events before it returns. It
>> doesn't hold snapshot and will not get cancelled
On Fri, Feb 2, 2018 at 3:46 AM, Simon Riggs wrote:
> In PG11, I propose the following command, sticking mostly to Ants'
> syntax, and allowing to wait for multiple events before it returns. It
> doesn't hold snapshot and will not get cancelled by Hot Standby.
>
> WAIT FOR event [, event ...] optio
Greetings,
* Simon Riggs (si...@2ndquadrant.com) wrote:
> On 22 January 2018 at 23:21, Stephen Frost wrote:
>
> >> It sounds reasonable. I can offer the following version.
> >>
> >> WAIT LSN lsn_number;
> >> WAIT LSN lsn_number TIMEOUT delay;
> >> WAIT LSN lsn_number INFINITE;
> >> WAIT
On 30 October 2017 at 17:25, Ivan Kartyshov wrote:
> It sounds reasonable. I can offer the following version.
>
> WAIT LSN lsn_number;
> WAIT LSN lsn_number TIMEOUT delay;
> WAIT LSN lsn_number INFINITE;
> WAIT LSN lsn_number NOWAIT;
>
>
> WAIT [token] wait_value [option];
>
> token
On 22 January 2018 at 23:21, Stephen Frost wrote:
>> It sounds reasonable. I can offer the following version.
>>
>> WAIT LSN lsn_number;
>> WAIT LSN lsn_number TIMEOUT delay;
>> WAIT LSN lsn_number INFINITE;
>> WAIT LSN lsn_number NOWAIT;
>>
>>
>> WAIT [token] wait_value [option];
>>
Greetings Ivan,
* Ivan Kartyshov (i.kartys...@postgrespro.ru) wrote:
> Ants Aasma писал 2017-10-26 17:29:
> >On Mon, Oct 23, 2017 at 12:29 PM, Ivan Kartyshov
> > wrote:
> >>Ants Aasma писал 2017-09-26 13:00:
> >>>
> >>>Exposing this interface as WAITLSN will encode that visibility order
> >>>match
On Tue, Oct 31, 2017 at 9:42 PM, Ants Aasma wrote:
> Robert made a good point that people will still rely on the token
> being an LSN, but perhaps they will be slightly less angry when we
> explicitly tell them that this might change in the future.
This thread has stalled, I am marking the patch
101 - 183 of 183 matches
Mail list logo
