| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru> |
| Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, a(dot)korotkov(at)postgrespro(dot)ru, i(dot)kartyshov(at)postgrespro(dot)ru, amit(dot)kapila16(at)gmail(dot)com, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: [HACKERS] make async slave to wait for lsn to be replayed |
| Date: | 2020-04-08 20:35:46 |
| Message-ID: | 13716.1586378146@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru> 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
first place? It seems like it would be just as useful as a separate
command, if not more so. You could always start a transaction just
after waiting. Conversely, there might be reasons to want to wait
within an already-started transaction.
If it could survive as a separate command, then I'd humbly suggest
that it requires no grammar work at all. You could just invent one
or more functions that take suitable parameters.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Justin Pryzby | 2020-04-08 21:00:53 | Re: explain HashAggregate to report bucket and memory stats |
| Previous Message | Tom Lane | 2020-04-08 20:30:22 | Re: backup manifests and contemporaneous buildfarm failures |