> >> b...@yugabyte.com wrote:
> >>
> >> I’ve no idea how I might have found this without human help.
> >
> > x...@thebuild.com wrote:
> >
> > That sounds like an excellent documentation patch!
>
> Well, it’s already documented clearly enough. The question is how to find
> it—especially if you
>> b...@yugabyte.com wrote:
>>
>> I’ve no idea how I might have found this without human help.
>
> x...@thebuild.com wrote:
>
> That sounds like an excellent documentation patch!
Well, it’s already documented clearly enough. The question is how to find
it—especially if you don’t know that the
> On Feb 20, 2023, at 17:54, Bryn Llewellyn wrote:
>
>
> I’ve no idea how I might have found this without human help.
That sounds like an excellent documentation patch!
>> b...@yugabyte.com wrote:
>>
>> It seems a bit odd that psql has no syntax to ask for this in its
>> interactive mode.
>
> dan...@manitou-mail.org wrote:
>
> Backslash-semicolon is the syntax.
Thanks, Daniel. Yes, that works. And the server’s SQL statement log confirms
this.
I’ve no idea
Bryn Llewellyn wrote:
> 2023-02-20 12:42:44.993 PST [2540504] d0$u0@d0 LOG: 0: statement:
> insert into s.t(v) values(17); insert into s.t(v) values(42);
> 2023-02-20 12:42:44.993 PST [2540504] d0$u0@d0 LOCATION: exec_simple_query,
> postgres.c:971
>
> It seems a bit odd that psql h
> x...@thebuild.com wrote:
>
>> b...@yugabyte.com wrote:
>>
>> 2. If I send over "begin" and then "insert into s.t(v) values(42)", then (so
>> far) a second session will not see the effect of my SQL's. It sees this only
>> when I send over "commit". (If I send over "rollback" instead of "commit
On Mon, Feb 20, 2023 at 12:57 PM Bryn Llewellyn wrote:
> 3. Chapter 55 also has a section "Multiple Statements In A Simple Query".
> But this feature seems to do no more semantically beyond implicitly
> achieving what I could do by surrounding several statements explicitly with
> "begin; ... comm
> On Feb 20, 2023, at 11:57, Bryn Llewellyn wrote:
> 2. If I send over "begin" and then "insert into s.t(v) values(42)", then (so
> far) a second session will not see the effect of my SQL's. It sees this only
> when I send over "commit". (If I send over "rollback" instead of "commit",
> then
> b...@yugabyte.com wrote:
>
> ...it's not clear who actually implements the opening "start transaction"
> and the closing "commit" around every submitted SQL statement when
> autocommit is "on". Is this done in client-side code (maybe implying
> three round trips per in
> On Feb 18, 2023, at 18:52, Ian Lawrence Barwick wrote:
>
> Historical trivia: PostgreSQL had a (backend) "autocommit" GUC in 7.3
> only, which remained as
> a dummy GUC until 9.5 (see: https://pgpedia.info/a/autocommit.html ).
Well, that was a pretty whacky idea. :-)
2023年2月19日(日) 9:51 Christophe Pettus :
>
>
>
> > On Feb 18, 2023, at 15:49, Bryn Llewellyn wrote:
> >
> > I’ve searched in vain for an account of how "autocommit" mode actually
> > works.
>
> I realize now I may have misinterpreted your question... apologies if so! If
> you mean the BEGIN and C
On Sat, Feb 18, 2023 at 4:49 PM Bryn Llewellyn wrote:
>
> And that the mode is a property of the current session.
>
To rephrase the other responses, the client-defined setting has no inherent
relationship to the concept of a PostgreSQL session. How the client uses
that setting is internal to th
> On Feb 18, 2023, at 15:49, Bryn Llewellyn wrote:
>
> I’ve searched in vain for an account of how "autocommit" mode actually works.
I realize now I may have misinterpreted your question... apologies if so! If
you mean the BEGIN and COMMIT statement that some client libraries insert into
t
> On Feb 18, 2023, at 15:49, Bryn Llewellyn wrote:
>
> Or is it done server-side?
It's done server-side. Note that what really happens is that, when a statement
begins execution and there is no open transaction, a snapshot is taken and then
released when the statement finishes (just as hap
Hi,
On Sat, Feb 18, 2023 at 03:49:26PM -0800, Bryn Llewellyn wrote:
>
> But it's not clear who actually implements the opening "start transaction"
> and the closing "commit" around every submitted SQL statement when autocommit
> is "on".
>
> Is this done in client-side code (maybe implying three r
I’ve searched in vain for an account of how "autocommit" mode actually works.
(I tried the built-in search feature within the PG docs. And I tried Google.)
It seems clear enough that turning "autocommit" mode "on" or "off" is done by
using a client-env-specific command like "\set" is psql, or "S
16 matches
Mail list logo
