> 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
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
> 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
> 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
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
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
> On Sat, Feb 18, 2023 at 7:47 AM Siddharth Jain wrote:
>
>> I think the answer is no but wanted to confirm here. this is what my best
>> friend told me.
>>
>> [image: image.png]
>>
>
> I find the last paragraph suspect. The rest is basically correct.
Yeah. Pgpool-II has query cache but
>
> >> Even still,
> >> the information about buffers that you've shown does indeed appear to
> >> be total nonsense (while everything else we can see looks plausible).
Actually not only buffers. The elapsed time also looks strange. And this is
the first reason why I paid attention to this
Adrian,
thanks for pointing out the fix. We are just about to update to 11.18 next
month.
Mikhael
On Thu, 16 Feb 2023 at 23:44, Adrian Klaver
wrote:
> On 2/15/23 22:57, Mikhail Balayan wrote:
> > Hello,
> >
> > I have a big table in the actively working system, in which nothing is
> > written
Thanks all for the replies. Just wanted to confirm.
On Sat, Feb 18, 2023 at 10:45 AM Steven Lembark wrote:
> On Sat, 18 Feb 2023 12:43:42 -0600
> Ron wrote:
>
> > > I think the answer is no but wanted to confirm here. this is what
> > > my best friend told me.
>
> There are caches for prepared
On Sat, 18 Feb 2023 12:43:42 -0600
Ron wrote:
> > I think the answer is no but wanted to confirm here. this is what
> > my best friend told me.
There are caches for prepared statements, table rows, indexes.
What about the caches are you interested in?
--
Steven Lembark
Workhorse Computing
On 18.02.23 17:16, Erik Wienhold wrote:
On 18/02/2023 15:02 CET Tomas Pospisek wrote:
so I'm trying to authenticate psql (on Windows) -> postgres (on Linux)
via Active Directory.
psql (Linux) -> postgres (Linux) with authentication against Active
Directory does work.
However the same with
> On 18/02/2023 15:02 CET Tomas Pospisek wrote:
>
> so I'm trying to authenticate psql (on Windows) -> postgres (on Linux)
> via Active Directory.
>
> psql (Linux) -> postgres (Linux) with authentication against Active
> Directory does work.
>
> However the same with psql.exe on Windows does not.
> On Feb 18, 2023, at 06:59, Peter J. Holzer wrote:
> I think the reason
> is that the use case (the exact same query is submitted repeatedly) is
> sufficiently rare that it isn't all that effective in practice.
And, in this use case, a prepared statement is in effect a cache of the parsing
On 2023-02-18 06:46:59 -0800, Siddharth Jain wrote:
> I think the answer is no but wanted to confirm here. this is what my best
> friend told me.
>
> image.png
ChatGPT is your best friend?
It is correct. PostgreSQL doesn't have a query cache. I think the reason
is that the use case (the exact
Hello all,
so I'm trying to authenticate psql (on Windows) -> postgres (on Linux)
via Active Directory.
psql (Linux) -> postgres (Linux) with authentication against Active
Directory does work.
However the same with psql.exe on Windows does not. I get:
D:\>C:\OSGeo4W\bin\psql.exe
17 matches
Mail list logo
