On 18 November 2015 at 18:18, Konstantin Knizhnik <k.knizh...@postgrespro.ru > wrote:
> But now SPI is used not only inside UDFs. It is also used in background > workers. For example in receiver_raw, written by Michael Paquier (I lot of > thanks Michael, understand logical replication without them will be much > more difficult). > Right now transactions have to be started by background worker using > StartTransactionCommand(). > So receiver_raw is not able to preserve master's transaction semantic > (certainly it can be implemented). I doubt the raw receiver approach can ever really lead to a complete replication solution, so I'm not completely convinced this is a problem worth solving. That tool is a great demo and learning utility, but that's very much what I see it as. (Then again, I would say that, wouldn't I? I have my own work in the running in the same space. Make of that what you will.) I suspect you'd need a way to invoke an incomplete SQL parser that can parse the SQL well enough to give you a TransactionStmt or tell you "I dunno what it it, but it doesn't look like a TransactionStmt". -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services On 18 November 2015 at 18:18, Konstantin Knizhnik <k.knizh...@postgrespro.ru > wrote: > Hello, > > SPI was originally developed for execution SQL statements from C user > defined functions in context of existed transaction. > This is why it is not possible to execute any transaction manipulation > statement (BEGIN, COMMIT, PREPARE,...) using > SPI_execute:SPI_ERROR_TRANSACTION is returned. > > But now SPI is used not only inside UDFs. It is also used in background > workers. For example in receiver_raw, written by Michael Paquier (I lot of > thanks Michael, understand logical replication without them will be much > more difficult). > Right now transactions have to be started by background worker using > StartTransactionCommand(). > So receiver_raw is not able to preserve master's transaction semantic > (certainly it can be implemented). > > I wonder whether SPI can be extended now to support transaction > manipulation functions when been called outside transaction context? Or > there are some principle problem with it? > > Thanks in advance, > Konstantin > > > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
