On Tue, Jan 5, 2021 at 3:40 PM Tom Lane wrote:
>
> easter...@verfriemelt.org writes:
> > i found, that the behaviour of variable assignment in combination with
> > union is not working anymore:
> > DO $$
> > DECLARE t bool;
> > begin
> > t := a FROM ( SELECT true WHERE false ) t(a) UN
On Wed, Jan 6, 2021 at 9:39 PM Tom Lane wrote:
>
> Merlin Moncure writes:
> > On Tue, Jan 5, 2021 at 3:40 PM Tom Lane wrote:
> >> easter...@verfriemelt.org writes:
> >>> i found, that the behaviour of variable assignment in combination with
> >&g
On Wed, Jan 6, 2021 at 11:07 PM Pavel Stehule wrote:
> čt 7. 1. 2021 v 4:20 odesílatel Merlin Moncure napsal:
>>
>> On Tue, Jan 5, 2021 at 3:40 PM Tom Lane wrote:
>> >
>> > easter...@verfriemelt.org writes:
>> > > i found, that the behavio
On Thu, Jan 7, 2021 at 10:55 AM Pavel Stehule wrote:
>> Again, if this is narrowly confined to assignment into set query
>> operations, maybe this is not so bad. But is it?
>
> PLpgSQL_Expr: opt_target_list
> <--><--><-->from_clause where_clause
> <--><--><-->group_clause having_clause window_cla
On Thu, Nov 12, 2020 at 4:40 PM Tomas Vondra
wrote:
>masterzedstore/pglzzedstore/lz4
> -
>copy 1855680922131
>dump 751 905 811
>
> And the size of the lineitem
On Mon, Nov 16, 2020 at 10:07 AM Tomas Vondra
wrote:
>
>
> On 11/16/20 1:59 PM, Merlin Moncure wrote:
> > On Thu, Nov 12, 2020 at 4:40 PM Tomas Vondra
> > wrote:
> >>masterzedstore/pglzzedstore/lz4
> >> ---
Hello all,
We just upgraded from postgres 11 to 12.6 and our server is running
out of memory and rebooting about 1-2 times a day.Application
architecture is a single threaded stored procedure, executed with CALL
that loops and never terminates. With postgres 11 we had no memory
issues. Ultima
On Tue, Mar 30, 2021 at 7:14 PM Tom Lane wrote:
>
> Justin Pryzby writes:
> > On Tue, Mar 30, 2021 at 04:17:03PM -0500, Merlin Moncure wrote:
> >> We just upgraded from postgres 11 to 12.6 and our server is running
> >> out of memory and rebooting about 1-2 time
Consider the following snippet
create table data as select generate_series(1,100) s;
do $d$
begin
PERFORM * FROM dblink_connect('test','');
PERFORM * from dblink_send_query('test', 'SELECT * FROM data');
LOOP
if dblink_is_busy('test') = 0
THEN
PERFORM * FROM dblink_get_r
On Thu, Apr 8, 2021 at 1:05 PM Merlin Moncure wrote:
> This effect is only noticeable when the remote query is returning
> volumes of data. My question is, is there any way to sleep loop
> client side without giving up 3x performance penalty? Why is that
> that when more local sleep
Hackers,
I have a situation that I am observing where dblink_is_busy returns 1
even though the connection is long gone. tcp keepalives are on and
the connection has been dead for several hours. Looking at the call
for dblink_is_busy, I see that it is a thin wrapper to PQusBusy().
If I attempt t
On Sun, Aug 2, 2020 at 7:18 PM Merlin Moncure wrote:
>
> Hackers,
>
> I have a situation that I am observing where dblink_is_busy returns 1
> even though the connection is long gone. tcp keepalives are on and
> the connection has been dead for several hours. Looking
On Sun, Aug 2, 2020 at 9:55 PM Merlin Moncure wrote:
>
> On Sun, Aug 2, 2020 at 7:18 PM Merlin Moncure wrote:
> >
> > Hackers,
> >
> > I have a situation that I am observing where dblink_is_busy returns 1
> > even though the connection is long gone. tcp keep
On Mon, Apr 23, 2018 at 3:14 PM, Robert Haas wrote:
> In other words, transparent connection pooling is going to require
> some new mechanism, which third-party code will have to know about,
> for tracking every last bit of session state that might need to be
> preserved or cleared. That's going
On Wed, Apr 25, 2018 at 12:34 AM, Christophe Pettus wrote:
>
>> On Apr 24, 2018, at 06:52, Merlin Moncure wrote:
>> Why does it have to be completely transparent?
>
> The main reason to move it into core is to avoid the limitations that a
> non-core pooler has.
The limi
On Wed, Apr 25, 2018 at 9:43 AM, Christophe Pettus wrote:
>
>> On Apr 25, 2018, at 07:00, Merlin Moncure wrote:
>> The limitations headaches that I suffer with pgbouncer project (which
>> I love and use often) are mainly administrative and performance
>> related, not l
On Wed, Apr 25, 2018 at 2:58 PM, Robert Haas wrote:
> On Wed, Apr 25, 2018 at 10:00 AM, Merlin Moncure wrote:
>> systems. If we get that tor free I'd be all for it but reading
>> Robert's email I'm skeptical there are easy wins here. So +1 for
>> further R&
Server is generally running pretty well, and is high volume. This
query is not new and is also medium volume. Database rebooted in
about 4 seconds with no damage; fast enough we didn't even trip alarms
(I noticed this troubleshooting another issue). We are a couple of
bug fixes releases behind b
On Wed, Jul 24, 2019 at 11:01 PM Thomas Munro wrote:
>
> On Thu, Jul 25, 2019 at 2:39 AM Merlin Moncure wrote:
> > Server is generally running pretty well, and is high volume. This
> > query is not new and is also medium volume. Database rebooted in
> > about 4 seco
On Fri, Aug 23, 2019 at 9:26 AM Roberto Mireles
wrote:
>
> Hello team,
>
> This is the first time I post here, if you can provide some help, would be
> much appreciated.
>
> I have an application that can not access the database due to OID value for
> hstore extension is bigger than an integer v
On Sun, Aug 25, 2019 at 9:35 PM Thomas Munro wrote:
>
> On Mon, Aug 26, 2019 at 1:44 PM Justin Pryzby wrote:
> > On Mon, Aug 26, 2019 at 01:09:19PM +1200, Thomas Munro wrote:
> > > On Sun, Aug 25, 2019 at 3:15 PM Peter Geoghegan wrote:
> > > > I was reminded of this issue from last year, which a
On Mon, Aug 26, 2019 at 12:01 PM Tom Lane wrote:
>
> Justin Pryzby writes:
> > On Mon, Aug 26, 2019 at 12:45:24PM -0400, Tom Lane wrote:
> >> However ... there is some pretty interesting info at
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1338673
> >> suggesting that compiling with a late-mo
Hackers,
[apologies if this is the incorrect list or is already discussed material]
I've noticed that mailing list discussions in -hackers and other
mailing lists appear to not be indexed by google -- at all. We are
also not being tracked by any mailing list aggregators -- in contrast
to a decade
On Tue, Aug 27, 2019 at 5:52 PM Merlin Moncure wrote:
>
> On Mon, Aug 26, 2019 at 12:01 PM Tom Lane wrote:
> >
> > Justin Pryzby writes:
> > > On Mon, Aug 26, 2019 at 12:45:24PM -0400, Tom Lane wrote:
> > >> However ... there is some pretty interesting inf
On Wed, Jan 31, 2018 at 1:45 PM, Robert Haas wrote:
> On Wed, Jan 31, 2018 at 1:34 PM, Andres Freund wrote:
>>> The first one is a problem that's not going to go away. If the
>>> problem of JIT being enabled "magically" is something we're concerned
>>> about, we need to figure out a good solutio
On Thu, Feb 1, 2018 at 8:16 PM, Thomas Munro
wrote:
> On Fri, Feb 2, 2018 at 2:05 PM, Andres Freund wrote:
>> On 2018-02-01 09:32:17 -0800, Jeff Davis wrote:
>>> On Wed, Jan 31, 2018 at 12:03 AM, Konstantin Knizhnik
>>> wrote:
>>> > The same problem takes place with old versions of GCC: I have t
On Thu, Jan 25, 2018 at 9:40 AM, Konstantin Knizhnik
wrote:
> As far as I understand generation of native code is now always done for all
> supported expressions and individually by each backend.
> I wonder it will be useful to do more efforts to understand when compilation
> to native code should
On Mon, Nov 25, 2019 at 9:09 AM Konstantin Knizhnik
wrote:
> JIT was not able to significantly (times) increase speed on Q1 query?
> Experiment with VOPS shows that used aggregation algorithm itself is not
> a bottleneck.
> Profile also give no answer for this question.
> Any ideas?
Well, in the
On Wed, Dec 18, 2019 at 12:38 PM Pavel Stehule wrote:
>
> Hi
>
> I had a talk with one boy about development in plpgsql. He uses table's
> functions. More times he uses returns types based on some table type + few
> attributes. Now he use a ugly hack - he create a view on table plus some
> colu
On Sat, Dec 28, 2019 at 12:15 PM Fabien COELHO wrote:
>
>
> Bonsoir Vik,
>
> > I recently came across the need for a gcd function (actually I needed
> > lcm) and was surprised that we didn't have one.
>
> Why not.
Proliferation of code in the public namespace; it can displace code
that is written
On Fri, Jan 3, 2020 at 10:24 AM Robert Haas wrote:
>
> On Fri, Jan 3, 2020 at 10:23 AM Tom Lane wrote:
> > Now, those functions were just exposing libc functionality, so there
> > wasn't a lot of code to write. There might be a good argument that
> > gcd isn't useful enough to justify the amount
On Fri, Jan 3, 2020 at 1:32 PM Robert Haas wrote:
>
> On Fri, Jan 3, 2020 at 2:27 PM Chapman Flack wrote:
> > On 1/3/20 2:11 PM, Robert Haas wrote:
> > > and moving things to another schema does not help with that. It does
> > > potentially help with the namespace pollution issue, but how much of
On Mon, Jan 6, 2020 at 6:52 AM Fabien COELHO wrote:
>
>
> Hello Robert,
>
> >> if (arg1 == PG_INT32_MIN)
> >> if (arg2 == 0 || arg2 == PG_INT32_MIN)
> >>
> >> And possibly a "likely" on the while.
> >
> > I don't think decoration the code with likely() and unlikely() all
> > over the place is
On Wed, Oct 31, 2018 at 10:23 AM Andres Freund wrote:
>
> Hi,
>
> On 2018-10-31 11:13:13 -0400, Andrew Dunstan wrote:
> > I agree that just sending a blob of the internal format isn't a great idea.
>
> It's entirely unacceptable afaict. Besides the whole "exposing
> internals" issue, it's also at
On Fri, Nov 2, 2018 at 10:53 AM Tom Lane wrote:
> Merlin Moncure writes:
> > On Wed, Oct 31, 2018 at 10:23 AM Andres Freund wrote:
> >> It's entirely unacceptable afaict. Besides the whole "exposing
> >> internals" issue, it's also at leas
On Fri, Nov 2, 2018 at 11:15 AM Stephen Frost wrote:
>
> Greetings,
>
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> > On Fri, Nov 2, 2018 at 10:53 AM Tom Lane wrote:
> > > Andres' point about alignment is a pretty good one as well, if it applies
> &g
On Fri, Nov 2, 2018 at 2:34 PM Stephen Frost wrote:
> * Merlin Moncure (mmonc...@gmail.com) wrote:
> As for what language it's written in- I don't think that matters much.
> I'd very much expect it to be more performant to use binary if you're
> working in C,
On Fri, Nov 2, 2018 at 5:15 PM Andrew Dunstan
wrote:
> On 11/02/2018 05:20 PM, Andres Freund wrote:
> > Hi,
> >
> > On 2018-11-02 17:02:24 -0400, Andrew Dunstan wrote:
> >> On 11/02/2018 11:34 AM, Merlin Moncure wrote:
> >>> Binary format consuming ap
On Wed, Feb 28, 2018 at 4:28 PM, Peter Eisentraut
wrote:
> This patch set adds support for INOUT parameters to procedures.
> Currently, INOUT and OUT parameters are not supported.
>
> A top-level CALL returns the output parameters as a result row. In
> PL/pgSQL, I have added special support to pa
On Tue, Mar 20, 2018 at 9:09 AM, Pavel Stehule wrote:
>> Edit: In one case, after dropping the function and recreating it, I
>> got the procedure to return 0 where it had not before, so this smells
>> like a bug.
>> postgres=# call p();
>> 2018-03-20 09:04:50.543 CDT [21494] ERROR: function p() d
On Tue, Mar 20, 2018 at 10:09 AM, Pavel Stehule wrote:
> 2018-03-20 15:18 GMT+01:00 Merlin Moncure :
>> >> postgres=# create or replace procedure p(a inout int default 7) as $$
>> >> begin return; end; $$ language plpgsql;
>> >> CREATE PROCEDURE
>&
On Tue, Mar 20, 2018 at 4:19 PM, Merlin Moncure wrote:
> A) you can't assign output variables with into:
> CALL p(1) INTO i; // gives syntax error
>
> B) you can't assign via assignment
> i := p(1); // gives error, 'use CALL'
>
> C) but you *can*
On Mon, Mar 13, 2023 at 3:33 PM Dave Cramer wrote:
>
> Dave Cramer
>
>
> On Sat, 4 Mar 2023 at 19:39, Dave Cramer wrote:
>
>>
>>
>> On Sat, 4 Mar 2023 at 19:06, Tom Lane wrote:
>>
>>> Jeff Davis writes:
>>> > On Sat, 2023-03-04 at 18:04 -0500, Dave Cramer wrote:
>>> >> Most of the clients know
On Mon, Mar 20, 2023 at 7:11 PM Dave Cramer wrote:
>
>
>
> On Mon, 20 Mar 2023 at 19:10, Merlin Moncure wrote:
>
>>
>>
>> On Mon, Mar 13, 2023 at 3:33 PM Dave Cramer wrote:
>>
>>>
>>> OIDs are a pain to deal with IMO. They will
On Tue, Mar 21, 2023 at 8:22 AM Dave Cramer wrote:
>
> On Tue, 21 Mar 2023 at 07:35, Merlin Moncure wrote:
>
>>
>>
>> On Mon, Mar 20, 2023 at 7:11 PM Dave Cramer wrote:
>>
>>>
>>>
>>>
>>> On Mon, 20 Mar 2023 at 19:10, Merl
On Tue, Mar 21, 2023 at 4:47 PM Jeff Davis wrote:
> On Tue, 2023-03-21 at 09:22 -0400, Dave Cramer wrote:
> > As Jeff mentioned there is a visibility problem if the search path is
> > changed. The simplest solution IMO is to look up the OID at the time
> > the format is requested and use the OID
On Thu, Feb 29, 2024 at 1:49 PM Jeff Davis wrote:
>
> Can we get some input on whether the current MERGE ... RETURNING patch
> is the right approach from a language standpoint?
>
MERGE_CLAUSE_NUMBER() seems really out of place to me, it feels out of
place to identify output set by number rather
On Wed, Mar 29, 2023 at 11:04 AM Jeff Davis wrote:
> I'm not clear on what proposal you are making and/or endorsing?
>
ha -- was just backing up dave's GUC idea.
> 1. Fix our own clients, like psql, to check for binary data they can't
> process.
>
This ought to be impossible IMO. All libpq
On Mon, Apr 3, 2023 at 11:29 AM Dave Cramer wrote:
> > participating clients to receive GUC configured format. I do not
>
>> > think that libpq's result format being able to be overridden by GUC
>>> > is a good idea at all, the library has to to participate, and I
>>> > think can be made to so s
On Thu, Apr 20, 2023 at 2:52 PM Dave Cramer wrote:
>
> As promised here is a patch with defines for all of the protocol messages.
>
I created a protocol.h file and put it in src/includes
> I'm fairly sure that some of the names I used may need to be changed but
> the grunt work of finding and rep
On Tue, Oct 24, 2023 at 2:11 PM Jeff Davis wrote:
> On Wed, 2023-08-23 at 11:58 +0100, Dean Rasheed wrote:
> > Updated version attached, fixing an uninitialized-variable warning
> > from the cfbot.
>
> I took another look and I'm still not comfortable with the special
> IsMergeSupportFunction() f
On Wed, Nov 1, 2023 at 5:12 AM Dean Rasheed
wrote:
> On Tue, 31 Oct 2023 at 23:19, Vik Fearing wrote:
> >
> > On 10/31/23 19:28, Jeff Davis wrote:
> >
> > > Assuming we have one RETURNING clause at the end, then it creates the
> > > problem of how to communicate which WHEN clause a tuple came fr
On Mon, Nov 13, 2023 at 3:14 AM yuansong wrote:
> Enhancing the overall fault tolerance of the entire system for this
> feature is quite important. No one can avoid bugs, and I don't believe that
> this approach is a more advanced one. It might be worth considering adding
> it to the roadmap so t
On Wed, Oct 4, 2023 at 9:17 AM Peter Eisentraut
wrote:
> I think intuitively, this facility ought to work like client_encoding.
> There, the client declares its capabilities, and the server has to
> format the output according to the client's capabilities. That works,
> and it also works through
On Fri, Aug 25, 2023 at 8:35 AM Stephen Frost wrote:
> Greetings,
>
> This is getting a bit far afield in terms of this specific thread, but
> there's an ongoing effort to give PG administrators knobs to be able to
> control how much actual memory is used rather than depending on the
> kernel to
I have 5 servers in a testing environment that are comprise a data
warehousing cluster. They will typically get each get exactly the
same query at approximately the same time. Yesterday, around 1pm, 3
of the five got stuck on the same query. Each of them yields similar
stack traces. This happ
On Fri, Mar 13, 2020 at 2:28 PM Andres Freund wrote:
>
> Hi,
>
> On March 13, 2020 12:08:32 PM PDT, Merlin Moncure wrote:
> >I have 5 servers in a testing environment that are comprise a data
> >warehousing cluster. They will typically get each get exactly the
> &
In the script below, the presence of an IN clause forces the internal
components of the UNION ALL clause to fully compute even though they are
fully optimizable. = ANY doesn't have this issue, so I wonder if there is
any opportunity to convert the 'slow' variant (see below) to the 'fast'
variant.
On Sat, Jun 4, 2022 at 6:23 PM Tomas Vondra
wrote:
> Hi,
>
> At on of the pgcon unconference sessions a couple days ago, I presented
> a bunch of benchmark results comparing performance with different
> data/WAL block size. Most of the OLTP results showed significant gains
> (up to 50%) with smal
On Thu, Jul 27, 2023 at 8:28 AM David Geier wrote:
> Hi,
>
> On 6/7/23 23:37, Andres Freund wrote:
> > I think we're starting to hit quite a few limits related to the process
> model,
> > particularly on bigger machines. The overhead of cross-process context
> > switches is inherently higher than
On Wed, Aug 16, 2023 at 8:55 AM Peter Eisentraut
wrote:
> This warning comes from parse_expr.c transformJsonValueExpr() and is
> triggered for example by the following test case:
>
> SELECT JSON_OBJECT('foo': NULL::json FORMAT JSON);
> WARNING: FORMAT JSON has no effect for json and jsonb types
On Mon, Jun 5, 2023 at 12:25 PM Heikki Linnakangas wrote:
> We currently bend over backwards to make all allocations fixed-sized in
> shared memory. You learn to live with that, but a lot of things would be
> simpler if you could allocate and free in shared memory more freely.
> It's no panacea,
Hackers,
We have a strong need to make a variant to the crosstab interface so
that data that is pivoted one way would be sent through a crosstab
like function so that it would be pivoted another way. For example,
if you had
row 0: a1, a2, a3, k1, c1, c2, ...
row 1: a1, a2, a3, k2, c1, c2, ...
ro
On Fri, Jan 25, 2019 at 3:16 PM David Fetter wrote:
>
> On Fri, Jan 25, 2019 at 02:21:55PM -0600, Merlin Moncure wrote:
> > Hackers,
> >
> > We have a strong need to make a variant to the crosstab interface so
> > that data that is pivoted one way would be se
On Tue, Jan 29, 2019 at 1:53 PM Tom Lane wrote:
>
> Michael Paquier writes:
> > On Mon, Jan 28, 2019 at 05:05:32PM -0500, Tom Lane wrote:
> >> Yeah, I thought about that too, but it doesn't seem like an improvement.
> >> If the query is very long (which isn't unlikely) I think people would
> >> p
On Tuesday, January 29, 2019, Tom Lane wrote:
> Merlin Moncure writes:
> > On Tue, Jan 29, 2019 at 1:53 PM Tom Lane wrote:
> >> I propose that we implement and document this as
> >> WITH ctename AS [ MATERIALIZE { ON | OFF } ] ( query )
>
> > I hate to bi
On Thu, Feb 14, 2019 at 10:02 AM Alvaro Herrera
wrote:
>
> On 2019-Feb-14, Peter Eisentraut wrote:
>
> > On 14/02/2019 16:11, Tom Lane wrote:
> > > ... so, have we beaten this topic to death yet? Can we make a decision?
> > >
> > > Personally, I'd be happy with either of the last two patch versio
On Fri, Jan 25, 2019 at 9:14 PM Morris de Oryx
wrote:
>
> Hello, I'm not a C coder and can't helpbut I love cross-tab/pivot
tables. They're the best, and just fantastic for preparing data to feed
into various analysis tools. The tablefunc module is helpful, but a bit
awkward to use (as I remem
On Tue, Feb 26, 2019 at 8:31 AM Joe Conway wrote:
> On 2/25/19 8:34 PM, Merlin Moncure wrote:
> > The interface I'm looking at is:
> > SELECT repivot(
> > query TEXT,
> > static_attributes INT, /* number of static attributes that are
> > unchanged
On Tue, Jul 24, 2018 at 6:10 PM Andres Freund wrote:
> My read of the concensus (in which I am in the majority, so I might be
> biased) is that we do want inlining to be the default. We were thinking
> that it'd be necessary to provide a way to force inlining on the SQL
> level for individual CTEs
On Tue, Jan 3, 2017 at 1:05 PM Peter Eisentraut
wrote:
>
> On 11/7/16 5:31 PM, Merlin Moncure wrote:
> > Regardless, it seems like you might be on to something, and I'm
> > inclined to patch your change, test it, and roll it out to production.
> > If it helps or at l
On Tue, Feb 18, 2020 at 12:10 PM Nagaraj Raj wrote:
>
> Below are the same configurations ins .conf file before and after updagrade
>
> show max_connections; = 1743
> show shared_buffers = "4057840kB"
> show effective_cache_size = "8115688kB"
> show maintenance_work_mem = "259MB"
> show checkpoin
On Sun, Feb 23, 2020 at 7:59 PM Dave Cramer wrote:
>
> I think the fact that this is a violation of the SQL SPEC lends considerable
> credence to the argument for changing the behaviour.
> Since this can lead to losing a transaction I think there is even more reason
> to look at changing the beh
On Mon, Feb 24, 2020 at 4:06 PM Vladimir Sitnikov
wrote:
>
> Merlin>My biggest sense of alarm with the proposed change is that it could
> Merlin>leave applications in a state where the transaction is hanging there
>
> How come?
> The spec says commit ends the transaction.
> Can you please clarify
On Fri, Sep 25, 2020 at 7:32 PM Li Japin wrote:
>
>
>
> > On Sep 26, 2020, at 8:09 AM, Julien Rouhaud wrote:
> >
> > Hi,
> >
> > On Sat, Sep 26, 2020 at 12:14 AM Li Japin wrote:
> >>
> >> Hi, hackers!
> >>
> >> I find the palloc0() is similar to the palloc(), we can use palloc()
> >> inside pal
On Thu, Apr 26, 2018 at 6:04 AM, Konstantin Knizhnik
wrote:
> On 25.04.2018 20:02, Merlin Moncure wrote:
>> Yep. The main workaround today is to disable them. Having said that,
>> it's not that difficult to imagine hooking prepared statement creation
>> to a backend s
On Fri, Apr 27, 2018 at 10:05 AM, Konstantin Knizhnik
wrote:
> On 27.04.2018 16:49, Merlin Moncure wrote:
>> *) How are you pinning client connections to an application managed
>> transaction? (IMNSHO, this feature is useless without being able to do
>> that)
>
>
On Fri, Apr 27, 2018 at 11:44 AM, Konstantin Knizhnik
wrote:
>
>
> On 27.04.2018 18:33, Merlin Moncure wrote:
>> On Fri, Apr 27, 2018 at 10:05 AM, Konstantin Knizhnik
>> wrote:
>>> On 27.04.2018 16:49, Merlin Moncure wrote:
>> I'm confused here...coul
On Thu, May 3, 2018 at 12:01 PM, Robert Haas wrote:
> On Fri, Apr 27, 2018 at 4:43 PM, Merlin Moncure wrote:
>> What _I_ (maybe not others) want is a
>> faster pgbouncer that is integrated into the database; IMO it does
>> everything exactly right.
>
> I have to admit
On Fri, May 4, 2018 at 2:25 PM, Robert Haas wrote:
> On Fri, May 4, 2018 at 11:22 AM, Merlin Moncure wrote:
>> If we are breaking 1:1 backend:session relationship, what controls
>> would we have to manage resource consumption?
>
> I mean, if you have a large number of sess
On Wed, May 9, 2018 at 11:00 AM Robert Haas wrote:
> Independently of that, it would be probably also useful to avoid
> bumping the reference count multiple times when a buffer is accessed
> by the same backend several times in quick succession. Perhaps this
> could even be as simple as maintain
On Wed, May 30, 2018 at 9:26 PM Robert Haas wrote:
> The FDW approach, of which I have been a supporter for some years now,
> is really aiming at a different target, which is to allow efficient
> analytics queries across a multi-node cluster. I think we're getting
> pretty close to being able to
On Fri, Jun 22, 2018 at 12:34 PM Bruce Momjian wrote:
>
> On Fri, Jun 1, 2018 at 11:29:43AM -0500, Merlin Moncure wrote:
> > FWIW, Distributed analytical queries is the right market to be in.
> > This is the field in which I work, and this is where the action is at.
> &g
On Wed, Nov 8, 2017 at 5:48 PM, Simon Riggs wrote:
> On 31 October 2017 at 15:38, Peter Eisentraut
> wrote:
>> Here is a patch that implements transaction control in PL/Python
>> procedures. (This patch goes on top of "SQL procedures" patch v1.)
>
> The patch is incredibly short for such a featu
On Tue, Nov 14, 2017 at 12:09 PM, Peter Eisentraut
wrote:
> On 11/14/17 09:27, Merlin Moncure wrote:
>> *) Will it be possible to do operations like this in pl/pgsql?
>>
>> BEGIN
>> SELECT INTO r * FROM foo;
>>
>> START TRANSACTION; -- perhaps we ought
On Tue, Nov 14, 2017 at 5:27 PM, Peter Eisentraut
wrote:
> On 11/14/17 16:33, Merlin Moncure wrote:
>>> One detail in your example is that when you enter the procedure, you are
>>> already in a transaction, so you would have to run either COMMIT or
>>> ROLLBAC
On Wed, Nov 15, 2017 at 4:45 AM, Andreas Joseph Krogh
wrote:
> På onsdag 15. november 2017 kl. 10:41:45, skrev Pavel Stehule
> :
>
> Hi
>
> I finished new pager, that can be interesting for postgresql expert users.
> Thanks for making this, "-X --no-mouse" made my day.
This was my first bugfix/su
On Wed, Nov 15, 2017 at 7:38 AM, Merlin Moncure wrote:
> On Tue, Nov 14, 2017 at 5:27 PM, Peter Eisentraut
>>> Can we zero in on this? The question implied, 'can you do this
>>> without being in a transaction'? PERFORM do_stuff() is a implicit
>>>
On Wed, Nov 15, 2017 at 3:42 PM, Peter Eisentraut
wrote:
> On 11/15/17 09:54, Merlin Moncure wrote:
>> ... I noticed that:
>> *) now() did not advance with commit and,
>> *) xact_start via pg_stat_activity did not advance
>>
>> Shouldn't both of those advanc
On Thu, Nov 16, 2017 at 12:36 PM, Peter Eisentraut
wrote:
> On 11/16/17 07:04, legrand legrand wrote:
>> We are just opening the "close cursors on/at commit" specification ;o)
>>
>> - MS SQL server: cursor_close_on_commit
>> - Firebird: close_cursors_at_commit
>> - DB2: "with hold" syntax
>> - ..
On Thu, Nov 16, 2017 at 11:04 AM, Pavel Stehule wrote:
> 2017-11-16 16:40 GMT+01:00 Aaron W. Swenson :
>> I likes it. I likes it a lot.
>>
>> And, you’ve got a PR on GitHub from me.
>>
>> It’s available on Gentoo now!
This would be great package for inclusion in pgdg packaging as well.
Dependenci
On Thu, Nov 16, 2017 at 5:35 PM, Simon Riggs wrote:
> On 14 November 2017 at 13:09, Peter Eisentraut
> wrote:
>
>>> *) Will pg_cancel_backend() cancel the currently executing statement
>>> or the procedure? (I guess probably the procedure but I'm curious)
>>
>> Same as the way it currently works.
Hackers,
Currently the only way that I know of to consume async notifications
via SQL (as opposed to a client application) is via dblink_get_notify.
This method isn't very good; it requires some extra support coding,
eats a connection and a backend, and doesn't have any timeout
facilities. The la
On Tue, Nov 21, 2017 at 7:59 AM, Robert Haas wrote:
> On Fri, Nov 17, 2017 at 9:49 AM, Merlin Moncure wrote:
>> Currently the only way that I know of to consume async notifications
>> via SQL (as opposed to a client application) is via dblink_get_notify.
>> This metho
On Tue, Nov 21, 2017 at 12:20 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Nov 21, 2017 at 11:32 AM, Merlin Moncure wrote:
>>> I am very much looking at the new stored procedure functionality and
>>> imaging a loop like this:
>>>
&
On Tue, Nov 21, 2017 at 2:16 PM, Merlin Moncure wrote:
> On Tue, Nov 21, 2017 at 12:20 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Tue, Nov 21, 2017 at 11:32 AM, Merlin Moncure wrote:
>>>> I am very much looking at the new stored procedure functionality and
On Wed, Dec 6, 2017 at 8:41 AM, Peter Eisentraut
wrote:
> On 12/5/17 13:33, Robert Haas wrote:
>> On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut
>> wrote:
>>> I think ROLLBACK in a cursor loop might not make sense, because the
>>> cursor query itself could have side effects, so a rollback would
On Thursday, December 14, 2017, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Hi,
> We allow a function to be invoked as part of PERFORM statement in plpgsql
> do $$
> begin perform pg_relation_size('t1'); end; $$ language plpgsql;
> DO
>
> But we do not allow a procedure to be invoke
On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane wrote:
> Ashutosh Bapat writes:
>> We allow a function to be invoked as part of PERFORM statement in plpgsql
>> ...
>> But we do not allow a procedure to be invoked this way
>
>> Procedures fit that category and like functions, I think, we should
>> allow
On Thu, Dec 14, 2017 at 10:46 AM, Pavel Stehule wrote:
>
>
> 2017-12-14 17:10 GMT+01:00 David G. Johnston :
>>
>> On Thu, Dec 14, 2017 at 8:22 AM, Merlin Moncure
>> wrote:
>>>
>>> On Thu, Dec 14, 2017 at 8:38 AM, Tom Lane wrote:
>>> >
1 - 100 of 117 matches
Mail list logo
