Re: Snapshot synchronization, again...
| От | Alvaro Herrera |
|---|---|
| Тема | Re: Snapshot synchronization, again... |
| Дата | |
| Msg-id | 1298333744-sup-4262@alvh.no-ip.org обсуждение исходный текст |
| Ответ на | Re: Snapshot synchronization, again... (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Snapshot synchronization, again...
|
| Список | pgsql-hackers |
Excerpts from Tom Lane's message of lun feb 21 21:00:19 -0300 2011: > Alvaro Herrera <alvherre@commandprompt.com> writes: > > Actually this seems rather difficult to do, because in order to invoke > > the function that imports the snapshot, you have to call SELECT, which > > acquires a snapshot beforehand. So when we actually import the > > passed-in snapshot, there's already a snapshot set. This is odious but > > I don't see a way around that -- other than adding special grammar > > support which seems overkill. > > No, I don't think it is. The alternative is semantics that are > at least exceedingly ugly, and very possibly flat-out broken. > To take just one point, you have no way at all of preventing the > transaction from having done something else using its original > snapshot. That's true too. So let's discuss the syntax. MaybeSTART TRANSACTION SNAPSHOT '\xdeadbeef'; This kind of extension seems ugly though; maybe we should considerSTART TRANSACTION (snapshot='\xdeadbeef'); (like VACUUM, EXPLAIN and COPY) or some such? I don't think we need another "top-level" command for this. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
В списке pgsql-hackers по дате отправления: