On Wed, Nov 20, 2024 at 7:57 PM Tom Lane wrote:
> but I wonder if you could be failing to close out the SELECT statement before
> issuing ALTER.
Thanks! This led me to check some debug details, and in fact we don't
close the portal, only the statement. (Besides a bug in the debug
log...)
Now I
Hi,
I'm developing the Dart client for Postgresql, which is using the
extended query protocol by default. I have received a report which
shows a difference in locking behavior inside a transaction, depending
which protocol we are using.
My main question: is this something that is implemented in a
On Sun, Sep 8, 2024 at 3:41 PM Laurenz Albe wrote:
> You must be doing something wrong then, because it works:
And you are right, I was doing something wrong:
The combination of the change and the library internals triggered a
SET statement_timeout TO 3000; before the ROLLBACK was sent, and the
On Sun, Sep 8, 2024 at 1:19 PM Laurenz Albe wrote:
> ROLLBACK and COMMIT are working: they end the transaction.
I have this reproduction test, and ROLLBACK does fail:
https://github.com/isoos/postgresql-dart/pull/363/files#diff-4547e49b04ec8280fb8f4f1ebf695b77f9a2d9a4ac9bcfd685bcd570a46baa80R122
I'm one of the developers of the Dart-language Postgresql client
package. I am working on adding a feature that may set the
statement_timeout value before a session or a query as the client
requests it, however, I'm stuck with the following error:
setup:
CREATE TABLE t (id INT PRIMARY KEY);
INSERT
I have a database with about 1 TB of data, mostly inserts, little
updates and deletes, and I want to setup 2 logical replication for it.
What should be my expectation with the replication?
1. What is the time-window that either of the nodes can be offline?
- Will it survive if the node doing the p
