On 13 November 2018 at 19:46, John Naylor wrote:
> On 11/8/18, David Rowley wrote:
>> On 8 November 2018 at 22:46, Peter Eisentraut
>> wrote:
>>> Could you adjust this to use fewer capital letters, unless they start
>>> sentences or similar?
>>
>> Yeah. Changed in the attached.
>
> Looks good
On Wed, Oct 17, 2018 at 3:27 PM Amit Kapila wrote:
>
> On Mon, Oct 15, 2018 at 6:09 PM Amit Kapila wrote:
> >
> > On Sun, Sep 2, 2018 at 12:19 AM Thomas Munro
> > wrote:
> > > I have also pushed a new WIP version of the lower level undo log
> > > storage layer patch set to a public branch[1].
(2018/11/12 20:41), Etsuro Fujita wrote:
(2018/11/12 18:52), Kyotaro HORIGUCHI wrote:
I read the Thomas's messages as "TTIO/TTOU are not
needed to our busines and we don't have a reason to restore them
before calling external programs other than just plaster
seemingly consistency." And I agree
Hi
We have good API and tools for monitoring slow queries. What is very good.
But I miss a monitoring fast queries what is usually major number and where
relatively small slowdown can to produce unhappy latencies on user
interface. More, the slowdowns here can shows some issues of database
On Tue, Nov 13, 2018 at 12:04 PM John Naylor wrote:
>
> On 11/13/18, Amit Kapila wrote:
> > On Tue, Nov 13, 2018 at 5:38 AM Michael Paquier
> > wrote:
> >>
> >> On Mon, Nov 12, 2018 at 09:42:45PM +0700, John Naylor wrote:
> >> > Looks like it. A quick search revealed "parallel worker" and
On 11/13/18, Amit Kapila wrote:
> On Tue, Nov 13, 2018 at 12:04 PM John Naylor wrote:
>>
>> On 11/13/18, Amit Kapila wrote:
>> > On Tue, Nov 13, 2018 at 5:38 AM Michael Paquier
>> > wrote:
>> >>
>> >> On Mon, Nov 12, 2018 at 09:42:45PM +0700, John Naylor wrote:
>> >> > Looks like it. A quick
Thank you for the comment.
From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
>> I'm thinking to go with plan 1. No need to think about address
>> translation seems tempting. Plan 2 (as well as plan 3) looks a big project.
>
>The existing function dsa_create_in_place() interface was
Hi all,
We implement disk quota feature on Postgresql as an extension(link:
https://github.com/greenplum-db/diskquota),
If you are interested, try and use it to limit the amount of disk space that
a schema or a role can use in Postgresql.
Any feedback or question are appreciated.
Overview
"the context that was active when the function was called" is typically
expressed simply as "the current memory context". Perhaps the whole
phrase can be reduced to "The object returned by this function is wholly
allocated in the current memory context"?
--
Álvaro Herrera
Hello Pavel,
What about using wait events and a trigger on pg_stat_activity ?
just :
* create a functions to get current query signature (queryid) for a pid
(not the top_level_query given for pl/pgsql blocks or triggers but the
active one)
* add some kind of active events to track planning
On 2018-Nov-13, Dmitry Dolgov wrote:
> > On Sun, 4 Nov 2018 at 19:03, Sergei Kornilov wrote:
> >
> > > If not properly cataloguing NOT NULL constraints would be fixed, can it
> > > potentially conflict with the current patch or not?
> > We already doing same stuff for "alter table attach
> On Sun, 4 Nov 2018 at 19:03, Sergei Kornilov wrote:
>
> > If not properly cataloguing NOT NULL constraints would be fixed, can it
> > potentially conflict with the current patch or not?
> We already doing same stuff for "alter table attach partition" and in this
> patch i use exactly this
On 01/05/2018 18:39, David G. Johnston wrote:
> note: there is either an extra space between the two closing brackets
> or a missing space before startseg
I have committed a fix for this.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote
On Tue, Nov 13, 2018 at 11:32 AM Haribabu Kommi
wrote:
>
> On Mon, Nov 12, 2018 at 6:34 PM Amit Kapila wrote:
>> > I can revert it back to void,
>> >
>>
>> +1, as we don't see any good reason to break backward compatibility.
>
>
> Thanks for the review.
> Attached the updated patch with return
On Tue, Nov 13, 2018 at 09:58:08AM -0300, Alvaro Herrera wrote:
> "the context that was active when the function was called" is typically
> expressed simply as "the current memory context". Perhaps the whole
> phrase can be reduced to "The object returned by this function is wholly
> allocated in
While working on making extension modules built reproducibly, I
noticed that extra flags passed via COPT (notably -ffile-prefix-map)
do not get added to CXXFLAGS.
This causes postgresql-hll to still store the full build path in the
.so file built:
From: Thomas Munro [mailto:thomas.mu...@enterprisedb.com]
>
>On Tue, Nov 13, 2018 at 9:45 AM Robert Haas wrote:
>> On Thu, Nov 8, 2018 at 9:05 PM Thomas Munro
>> wrote:
>> > * I had some ideas about some kind of "allocation rollback" interface:
>> > you begin an "allocation transaction",
On 2018-11-13 00:57, Tom Lane wrote:
> =?UTF-8?Q?J=c3=bcrgen_Strobel?= writes:
>> On 2018-11-12 17:33, Tom Lane wrote:
>>> I'm not entirely convinced that I buy that argument, especially not in
>>> a case like this where it introduces logical inconsistencies where there
>>> otherwise wouldn't be
Hi
I am try to enhance plpgsql_check about profiler functionality and I have
to solve how to identify every plpgsql statement across different sessions.
There is lineno, but surely it should not be unique. I propose introduce
stmtid to every statement structure. This number will be unique inside
On Tue, Nov 13, 2018 at 3:37 PM John Naylor wrote:
>
> On 11/13/18, Amit Kapila wrote:
> >
> > Don't you need to remove background worker?
>
> It's handled in pgstat_get_backend_desc(), so I assumed not. If that's
> just a place holder, then it's probably better left out, as in the
> attached.
>
On Mon, Nov 12, 2018 at 11:55 PM Jeremy Finzel wrote:
>
> I believe I found a race condition in WaitForBackgroundWorkerStartup in the
> case where it encounters an ERROR during startup. I found that depending on
> the speed of the system, it will unreliably return either status BGWH_STOPPED
>
On 11/13/18, Amit Kapila wrote:
> On Tue, Nov 13, 2018 at 3:37 PM John Naylor wrote:
>>
>> On 11/13/18, Amit Kapila wrote:
>> >
>> > Don't you need to remove background worker?
>>
>> It's handled in pgstat_get_backend_desc(), so I assumed not. If that's
>> just a place holder, then it's
út 13. 11. 2018 v 13:12 odesílatel legrand legrand <
legrand_legr...@hotmail.com> napsal:
> Hello Pavel,
>
> What about using wait events and a trigger on pg_stat_activity ?
>
pg_stat_activity should not to show fresh data. Using pg_stat_activity can
be too expensive for fast queries
> just :
Hi,
On 11/12/18 6:17 PM, David Rowley wrote:
On 9 November 2018 at 19:18, Amit Langote wrote:
I have a comment regarding how you chose to make
PartitionTupleRouting private.
Using the v14_to_v15 diff, I could quickly see that there are many diffs
changing PartitionTupleRouting to struct
On Mon, 2018-11-12 at 20:10 +0900, Kyotaro HORIGUCHI wrote:
> At Fri, 9 Nov 2018 14:16:31 +0100, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote in <
> 803f2d96-3b4b-f357-9a2e-45443212f...@2ndquadrant.com>
> >
> >
> > On 11/9/18 9:33 AM, Kyotaro HORIGUCHI wrote:
> > > Hello. This is rebased
On Fri, Nov 9, 2018 at 11:14 AM Paul Ramsey
wrote:
> > Neglected to include the footnotes...
>
> As I promised at PgConf.eu, here's a follow-up email about PostGIS
> parallelism and function inlining (an odd combination, it is true).
>
> So, context:
>
> - We want PostGIS to parallelize more. In
On 11/9/18, 6:11 PM, "Michael Paquier" wrote:
> This thread needed a new patch to answer to the previous comment from
> Nathan, and it was not marked as waiting on author. Sorry I got
> confused with the CF status and I have missed Nathan's update, which
> mentions a good idea. So attached is
On Sun, Nov 11, 2018 at 9:59 PM Thomas Munro
wrote:
> There is one major problem with this patch
If there's only one, you're doing great! Although admittedly this
seems like a big one...
> 1. Go back to the current pressure-valve strategy: make the sending
> side perform the fsync(), if it
Hello
Thank you! Here is patch update addressing your comments.
> - useless whitespace change in xlog.c
Oops, did not notice. Fixed.
> - I think we can drop logRecoveryParameters(). Users can now inspect
> those parameters using the normal GUC mechanisms. (They were all DEBUG2
> anyway, so it's
On 2018-Nov-13, Michael Paquier wrote:
> On Tue, Nov 13, 2018 at 09:58:08AM -0300, Alvaro Herrera wrote:
> > "the context that was active when the function was called" is typically
> > expressed simply as "the current memory context". Perhaps the whole
> > phrase can be reduced to "The object
So while investigating a case of this warning (in
UpdateMinRecoveryPoint):
"xlog min recovery request %X/%X is past current point %X/%X"
I noticed that it is issued even in cases where we know that
minRecoveryPoint is not yet valid, for example because we're waiting to
see XLOG_BACKUP_END before
On Tue, Nov 13, 2018 at 6:17 AM Amit Kapila wrote:
> On Mon, Nov 12, 2018 at 11:55 PM Jeremy Finzel wrote:
> >
> > I believe I found a race condition in WaitForBackgroundWorkerStartup in
> the case where it encounters an ERROR during startup. I found that
> depending on the speed of the
On Tue, 2018-11-13 at 13:44 +0100, Jürgen Strobel wrote:
> On 2018-11-13 00:57, Tom Lane wrote:
> > =?UTF-8?Q?J=c3=bcrgen_Strobel?=
> > writes:
> > > On 2018-11-12 17:33, Tom Lane wrote:
> > > > I'm not entirely convinced that I buy that argument, especially
> > > > not in
> > > > a case like
John Naylor writes:
> Commit 21c8ee7946 was one of several that sync'd the backend scanner
> with the psql scanner, with the commit message stating "Someday it'd
> be nice to make ecpg's pgc.l more easily diff'able too, but today is
> not that day." Attached is a set of patches to make progress
On Tue, Nov 13, 2018 at 1:07 PM Andres Freund wrote:
> On 2018-11-13 12:04:23 -0500, Robert Haas wrote:
> > I still feel like this whole pass-the-fds-to-the-checkpointer thing is
> > a bit of a fool's errand, though. I mean, there's no guarantee that
> > the first FD that gets passed to the
Le lun. 5 nov. 2018 à 15:37, Jean-Christophe Arnu a
écrit :
>
>
> Le dim. 4 nov. 2018 à 18:01, Jean-Christophe Arnu a
> écrit :
>
>> Le ven. 2 nov. 2018 à 08:37, Peter Eisentraut <
>> peter.eisentr...@2ndquadrant.com> a écrit :
>>
>>> On 26/10/2018 15:53, Jean-Christophe Arnu wrote:
>>> >
Hi,
On 2018-11-13 12:04:23 -0500, Robert Haas wrote:
> I still feel like this whole pass-the-fds-to-the-checkpointer thing is
> a bit of a fool's errand, though. I mean, there's no guarantee that
> the first FD that gets passed to the checkpointer is the first one
> opened, or even the first one
On Tue, 2018-11-13 at 07:57 -0600, Jeremy Finzel wrote:
> ...
>
> I'm unclear on what counts as "worker initialization". The error is
> happening in the worker_spi_main function, not in the
> worker_spi_launch function. So does an immediate error in
> worker_spi_main count as part of the worker
On Mon, Nov 5, 2018 at 7:46 PM Andrey Lepikhov
wrote:
> Problem No. 1 will be amplified with new asynchronous operations,
> background workers and distributing query execution. It is not problem
> of DBMS. The solution is change the tests: include sorting of query
> results, sorting of system
On Tue, Nov 13, 2018 at 10:59:15AM -0300, Alvaro Herrera wrote:
> I gave the patch a read and it looks reasonable to me.
>
> Memory management in RelationBuildPartitionDesc is crummy, but I don't
> think it's this patch's fault.
I agree, and that shows up pretty clearly after the refactoring is
"Higuchi, Daisuke" writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> So I think that we ought to unconditionally make the sqlda value's digit
>> buffer look just like the one we're copying, even when ndigits = 0,
>> which just requires removing the tests on ndigits.
> I agree with you.
On Tue, Nov 13, 2018 at 09:39:55PM +0100, Tomas Vondra wrote:
> So -1 to this from me. I'd just swap the fields in the copy dir message
> and call it a day.
+1. Using the opposite order when what is actually a database path is
kind of confusing..
--
Michael
signature.asc
Description: PGP
On Tue, Nov 13, 2018 at 10:59 PM Ideriha, Takeshi
wrote:
> Can I check my understanding?
> The situation you are talking about is the following:
> Data structure A and B will be allocated on DSA. Data A has a pointer to B.
> Another data X is already allocated on some area (might be on local
Hi,
On 2018-11-13 11:40:05 +0100, Christoph Berg wrote:
> While working on making extension modules built reproducibly, I
> noticed that extra flags passed via COPT (notably -ffile-prefix-map)
> do not get added to CXXFLAGS.
PROFILE I can see, but COPT I'm less sure. The name suggests it's about
Andres Freund writes:
> On 2018-11-13 11:40:05 +0100, Christoph Berg wrote:
>> While working on making extension modules built reproducibly, I
>> noticed that extra flags passed via COPT (notably -ffile-prefix-map)
>> do not get added to CXXFLAGS.
> PROFILE I can see, but COPT I'm less sure. The
I wrote:
> BTW, I'd been hoping that we could avoid rotate-to-local-and-back
> in Vik's desired case, but after further thought I suspect the only
> real optimization that's possible compared to writing it out with
> two AT TIME ZONE constructs is to do the zone name lookup just once.
> As an
Note: the original email from David went to my spam folder, and it also
didn't show up on the archives (I assume caught by a spam filter there
also?)
Thanks for taking this on!
>
> As far as you can tell, is the default correct at 100?
>
I'm not sure what a good way of measuring it would be
On Wed, Nov 14, 2018 at 12:26 AM Amit Kapila
wrote:
> On Tue, Nov 13, 2018 at 11:32 AM Haribabu Kommi
> wrote:
> >
> > On Mon, Nov 12, 2018 at 6:34 PM Amit Kapila
> wrote:
> >> > I can revert it back to void,
> >> >
> >>
> >> +1, as we don't see any good reason to break backward compatibility.
Hi Hackers -
The command
$ postgres --config-file="/etc/postgresql/10/main/postgresql.conf"
can fail with the following error:
postgres: superuser_reserved_connections must be less than max_connections
even if max_connections > superuser_reserved_connections in that config file
This is due
(Replies to a couple of different messages below)
On Wed, Nov 14, 2018 at 6:04 AM Robert Haas wrote:
> On Sun, Nov 11, 2018 at 9:59 PM Thomas Munro
> wrote:
> > There is one major problem with this patch
>
> If there's only one, you're doing great! Although admittedly this
> seems like a big
Hi,
On 2018/11/13 22:59, Alvaro Herrera wrote:
> On 2018-Nov-13, Michael Paquier wrote:
>
>> On Tue, Nov 13, 2018 at 09:58:08AM -0300, Alvaro Herrera wrote:
>>> "the context that was active when the function was called" is typically
>>> expressed simply as "the current memory context". Perhaps
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>I took a quick look at this.
Thank you for review.
>So I think that we ought to unconditionally make the sqlda value's digit
>buffer look just like the one we're copying, even when ndigits = 0,
>which just requires removing the tests on ndigits.
I
Hi,
On 2018-11-13 17:27:17 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-11-13 11:40:05 +0100, Christoph Berg wrote:
> >> While working on making extension modules built reproducibly, I
> >> noticed that extra flags passed via COPT (notably -ffile-prefix-map)
> >> do not get added
Hi,
On 2018-11-13 17:33:01 -0500, Tom Lane wrote:
> Jordan Deitch writes:
> > $ postgres --config-file="/etc/postgresql/10/main/postgresql.conf"
> > can fail with the following error:
> > postgres: superuser_reserved_connections must be less than max_connections
>
> > This is due to the
On 2018/11/14 0:32, Jesper Pedersen wrote:
> Hi,
>
> On 11/12/18 6:17 PM, David Rowley wrote:
>> On 9 November 2018 at 19:18, Amit Langote
>> wrote:
>>> I have a comment regarding how you chose to make
>>> PartitionTupleRouting private.
>>>
>>> Using the v14_to_v15 diff, I could quickly see that
Andres Freund writes:
> On 2018-11-13 17:33:01 -0500, Tom Lane wrote:
>> Seems to me it'd result in an impossibly unwieldy message, especially
>> once you realize you might have to deal with other value sources than
>> files. Adhering to the translatability guidelines (ie, "don't construct
>>
On Mon, Nov 12, 2018 at 09:39:01AM -0500, Tom Lane wrote:
> Thomas Munro writes:
> > On Mon, Nov 12, 2018 at 9:34 PM Noah Misch wrote:
> >> Compared to the old code, the new code requires more wall time to visit
> >> every
> >> possible seed value. New code xor's the PID bits into the
Hello hackers,
Currently, we're working on the serializable implementations for
zheap. As mentioned in README-SSI documentation[1], there is one
difference in SSI implementation of PostgreSQL that can differentiate
the conflict detection behaviour with other storage engines that
supports updates
On Tue, Nov 13, 2018 at 04:08:04PM -0500, Tom Lane wrote:
> Well, if it is an issue then it's an issue for back branches too.
> It's fine, I think, as long as the warning stays a warning ...
> but there are lots of ways in which trying to print a warning
> might turn into an error.
At the end I
On Wed, Nov 14, 2018 at 6:34 PM Noah Misch wrote:
> On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
> > > What counts is the ease of predicting a complete seed. HEAD's algorithm
> > > has
> > > ~13 trivially-predictable bits,
Hi All,
First, kudos to the creators of Ltree, a very useful tool.
My labels have dots, blanks, apostrophes, commas and other special
characters.
I was wondering if there is a way to modify ltree to allow labels with
special characters - including blanks and dots! -
Also, I would like to
Thanks for looking at this again.
On 14 November 2018 at 13:47, Amit Langote
wrote:
> +if (dispatchidx >= proute->dispatch_allocsize)
> +{
> +/* Expand allocated space. */
> +proute->dispatch_allocsize *= 2;
> +proute->partition_dispatch_info =
Thanks for updating the patch.
On 2018/11/14 13:16, David Rowley wrote:
> Thanks for looking at this again.
>
> On 14 November 2018 at 13:47, Amit Langote
> wrote:
>> +if (dispatchidx >= proute->dispatch_allocsize)
>> +{
>> +/* Expand allocated space. */
>> +
On Tue, Nov 13, 2018 at 11:48 PM Tomas Vondra
wrote:
>
> On Tue, 2018-11-13 at 07:57 -0600, Jeremy Finzel wrote:
> > ...
> >
> > I'm unclear on what counts as "worker initialization". The error is
> > happening in the worker_spi_main function, not in the
> > worker_spi_launch function. So does
Hello.
At Thu, 11 Oct 2018 17:04:53 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20181011.170453.123148806.horiguchi.kyot...@lab.ntt.co.jp>
> At Thu, 11 Oct 2018 13:42:35 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
>
On Tue, Nov 13, 2018 at 1:29 PM Peter Geoghegan wrote:
> A solution does occur to me that I'm kind of embarrassed to suggest,
> but that would nonetheless probably do the job:
> Why not vary the objsubid value among entries that don't use it
> anyway, so that they have a negative integer
On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
> On Mon, Nov 12, 2018 at 09:39:01AM -0500, Tom Lane wrote:
> > Thomas Munro writes:
> > > On Mon, Nov 12, 2018 at 9:34 PM Noah Misch wrote:
> > >> Compared to the old code, the new code requires more wall time to visit
> > >> every
> > >>
On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
> > On Mon, Nov 12, 2018 at 09:39:01AM -0500, Tom Lane wrote:
> > > I doubt that's a good idea; to a first approximation, it would mean that
> > > half the seed depends only on the
On Mon, Nov 5, 2018 at 5:09 PM Dilip Kumar wrote:
>
> On Mon, Sep 3, 2018 at 11:26 AM Dilip Kumar wrote:
>
> Thomas has already posted the latest version of undo log patches on
> 'Cleaning up orphaned files using undo logs' thread[1]. So I have
> rebased the undo-interface patch also. This
On 11/14/18, Tom Lane wrote:
> Looks like good stuff, pushed with a small additional amount of work.
Thanks.
>> -Does ECPG still need its own functions for mm_alloc() and
>> mm_strdup(), if we have equivalents in src/common?
>
> The error handling isn't the same, so I don't think we can just
On Wed, Nov 14, 2018 at 08:22:42PM +1300, Thomas Munro wrote:
> On Wed, Nov 14, 2018 at 6:34 PM Noah Misch wrote:
> > On Wed, Nov 14, 2018 at 05:50:26PM +1300, Thomas Munro wrote:
> > > On Wed, Nov 14, 2018 at 3:24 PM Noah Misch wrote:
> > > > What counts is the ease of predicting a complete
On Tue, 2018-11-13 at 18:53 +0100, Jean-Christophe Arnu wrote:
> Le lun. 5 nov. 2018 à 15:37, Jean-Christophe Arnu
> a
> écrit :
>
> >
> >
> > Le dim. 4 nov. 2018 à 18:01, Jean-Christophe Arnu > > a
> > écrit :
> >
> > > Le ven. 2 nov. 2018 à 08:37, Peter Eisentraut <
> > >
Michael Paquier writes:
> On Mon, Nov 12, 2018 at 08:17:29PM -0500, Tom Lane wrote:
>> I think the real bug here is that a bunch of potentially-failable
>> operations have been thrown in before we've finished initializing the
>> TransactionState to minimal sanity. (Inserting code with the aid of
On Mon, 2018-11-12 at 11:33 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > One of the guiding principles that I think we should hold for
> > partitioning is that operating directly into the partition should
> > be
> > seen as only an optimization compared to inserting into the parent
> >
Hi,
On 2018-11-12 15:58:41 +1300, Thomas Munro wrote:
> There is one major problem with this patch: BufferSync(), run in the
> checkpointer, can deadlock against a backend that holds a buffer lock
> and is blocked in SendFsyncRequest(). To break this deadlock, we need
> way out of it on either
On 13/11/2018 18:53, Jean-Christophe Arnu wrote:
> May I request any update on my (not so important) proposal ?
Other opinions out there perhaps? I think your proposals are good, but
I'm not sure to what extent people are automatically parsing the
pg_waldump output and are relying on a
On 2018-Nov-13, Peter Eisentraut wrote:
> On 13/11/2018 18:53, Jean-Christophe Arnu wrote:
> > May I request any update on my (not so important) proposal ?
>
> Other opinions out there perhaps? I think your proposals are good, but
> I'm not sure to what extent people are automatically parsing
Hi,
On 2018-11-13 17:18:32 -0300, Alvaro Herrera wrote:
> On 2018-Nov-13, Peter Eisentraut wrote:
>
> > On 13/11/2018 18:53, Jean-Christophe Arnu wrote:
> > > May I request any update on my (not so important) proposal ?
> >
> > Other opinions out there perhaps? I think your proposals are good,
On Tue, 2018-11-13 at 12:24 -0800, Andres Freund wrote:
> Hi,
>
> On 2018-11-13 17:18:32 -0300, Alvaro Herrera wrote:
> > On 2018-Nov-13, Peter Eisentraut wrote:
> >
> > > On 13/11/2018 18:53, Jean-Christophe Arnu wrote:
> > > > May I request any update on my (not so important) proposal ?
> > >
On 2018-Nov-13, Tom Lane wrote:
> More generally, I wonder if it'd be practical to make pgc.l backup-free
> altogether. I'm not sure that the resulting gain in lexing speed would
> really be of interest to anyone,
Maybe time to compile the ecpg test cases during "make check-world"?
--
Álvaro
Alvaro Herrera writes:
> On 2018-Nov-13, Tom Lane wrote:
>> More generally, I wonder if it'd be practical to make pgc.l backup-free
>> altogether. I'm not sure that the resulting gain in lexing speed would
>> really be of interest to anyone,
> Maybe time to compile the ecpg test cases during
While fooling with John Naylor's ecpg lexer sync patch, my attention
was drawn to the "realfail1" flex rule, which triggers when we see
digits immediately followed by "e", but no exponent after that:
{realfail1}{
/*
* throw back the [Ee], and treat
On Tue, 2018-11-13 at 13:55 +0100, Pavel Stehule wrote:
> út 13. 11. 2018 v 13:12 odesílatel legrand legrand <
> legrand_legr...@hotmail.com> napsal:
>
> > Hello Pavel,
> >
> > What about using wait events and a trigger on pg_stat_activity ?
> >
>
> pg_stat_activity should not to show fresh
83 matches
Mail list logo
