On Mon, Dec 23, 2024 at 11:01 PM Michael Paquier
wrote:
> On Mon, Dec 23, 2024 at 10:06:58PM -0600, Merlin Moncure wrote:
> > I'm aware of that and will set it -- it's the only option if I'm
> following
> > you. The way I've been doing things late
On Mon, Dec 23, 2024 at 3:58 PM Tom Lane wrote:
> Merlin Moncure writes:
> > Can this simply be disabled for stored procedures as a special case? I'm
> > hoping this might do something useful that is also safe. Curious if
> anyone
> > has any thoughts on this.
>
Hello,
I've noticed that in pg_stat_statements, stored procedures are almost
always given a unique query id unless the query is textually identical.
pg_stat_statements.c makes this pretty clear as procedures are considered
utility statements and no normalization analysis is done against them.
Cli
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 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, 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 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 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
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 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 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 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,
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 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 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 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 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 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 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
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, 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
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 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
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 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 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 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 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 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
> >> ---
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 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 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 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
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 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
> &
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 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 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 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 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 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 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 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 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 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 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 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
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 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
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 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 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
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 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 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 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 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 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 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
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 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 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 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 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 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 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 Wed, Sep 26, 2018 at 10:55 AM Alvaro Herrera
wrote:
>
> On 2018-Sep-26, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > On 2018-Sep-26, Tom Lane wrote:
> > >> I agree that it would be surprising for transaction timestamp to be newer
> > >> than statement timestamp. So for now at least, I'd
On Mon, Sep 17, 2018 at 7:45 AM Jonathan S. Katz wrote:
>
> Hi,
>
> On 9/2/18 4:32 PM, Robert Haas wrote:
> > On Thu, Aug 30, 2018 at 4:14 PM, Dave Cramer wrote:
> >> Reading this from the (JDBC) drivers perspective, which is probably a
> >> fairly
> >> popular one,
> >> We now have a standard t
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, 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 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 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 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, 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 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 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 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&
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 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 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 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 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 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 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 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 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 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, Dec 14, 2017 at 11:56 AM, Pavel Stehule wrote:
>
>
> 2017-12-14 18:33 GMT+01:00 Merlin Moncure :
>>
>> 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 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:
>>> >
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 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 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 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 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 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
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 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.
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 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
>> - ..
1 - 100 of 106 matches
Mail list logo
