On Wed, Nov 21, 2018 at 10:05:34AM -0500, Robert Haas wrote:
> On Tue, Nov 20, 2018 at 1:21 AM Takahashi, Ryohei
> wrote:
> > My customer uses PostgreSQL on Windows and hits the problem that following
> > log is written to the server logs too frequently (250 thousand times per
> > day).
> >
On Sat, Nov 24, 2018 at 10:18:17AM +0900, Michael Paquier wrote:
> On Sat, Nov 24, 2018 at 12:32:36PM +1300, David Rowley wrote:
>> On Fri, 23 Nov 2018 at 17:03, David Rowley
>> wrote:
>> > Here's a patch for that. Parking here until January's commitfest.
>>
>> And another, now rebased atop of
On Sat, Nov 17, 2018 at 10:15:08PM +0100, Daniel Gustafsson wrote:
> > On 15 Nov 2018, at 22:42, Tom Lane wrote:
>
> > Further point about that: pg_regress's method of creating a temp
> > directory under /tmp is secure only on machines with the stickybit
> > set on /tmp; otherwise it's possible
>I have let this stuff cool down for a couple of days, still it seems to me
>that having one single column makes the most sense when it comes when
>looking at a mostly idle system. I'll try to finish this one at the
>beginning of next week, for now I am marking as ready for committer.
Thank you
On Tue, Dec 04, 2018 at 04:24:25PM +0900, myungkyu.lim wrote:
> I think purpose of this field,
> that react interval check and debugging on idle system.
> So, merging both is better.
I have let this stuff cool down for a couple of days, still it seems to
me that having one single column makes
Samuel Cochran writes:
> System Integrity Protection strips dynamic linker (dyld) environment
> variables, such as DYLD_LIBRARY_PATH, during exec(2) [1]
Yeah. I wish Apple would just fix that silliness ... I'll spare you the
rant about why it's stupid, but it is. (BTW, last I looked, it's not
On Thu, Dec 6, 2018 at 1:27 PM Alvaro Herrera
wrote:
> On 2018-Dec-06, Amit Langote wrote:
>
> > The partitionwise join related
> > changes in PG 11 moved the add_child_rel_equivalences call in
> > set_append_rel_size such that child EC members would be added even before
> > checking if the
Hi,
> TODO:
> I will add the feature called "logging level" on next version patch. I will
> attach it as soon as possible.
I created v4 patch. Please find attached the patch.
This patch developed "logminlevel" parameter. level1 and level2 can be set,
level1 is the default.
If level1 is set, it
Hi folks
Forgive me if I'm getting the mailing list etiquette wrong — first time poster.
I ended up sitting next to Thomas Munro at PGDU 2018 and talking about testing.
While trying to get `make check` running on my macbook, I think I may have
fixed this issue.
System Integrity Protection
Hi,
There was an invisible space, so I removed it.
I registered with 2019-01 commitfest.
Best regards,
-
Ryohei Nagaura
> -Original Message-
> From: Nagaura, Ryohei [mailto:nagaura.ryo...@jp.fujitsu.com]
> Sent: Thursday, December 6, 2018 2:20 PM
> To: 'Fabien
On 06.12.2018 11:52, Peter Geoghegan wrote:
On Wed, Dec 5, 2018 at 10:35 PM Andrey Lepikhov
wrote:
This solution changes pg_depend relation for solve a problem, which
exists only in regression tests. Very rarely it can be in the
partitioning cases. Or is it not?
I don't think it's a
On Thu, Dec 6, 2018 at 10:53 PM John Naylor wrote:
>
> I've added an additional regression test for finding the right block
> and removed a test I thought was redundant. I've kept the test file in
> its own schedule.
>
+# --
+# fsm does a vacuum, and running it in parallel seems to
On Thu, Dec 6, 2018 at 9:32 PM Robert Haas wrote:
>
> On Thu, Dec 6, 2018 at 10:53 AM Pavel Stehule wrote:
> > čt 6. 12. 2018 v 16:26 odesílatel Robert Haas
> > napsal:
> >> On Thu, Dec 6, 2018 at 10:23 AM Pavel Stehule
> >> wrote:
> >> > I have a problem to imagine it. When fill factor will
On Thu, Dec 06, 2018 at 10:48:59PM -0300, Alvaro Herrera wrote:
> I think adding a pg_partition_root() call to as many pg_partition_tree
> tests as you modified is overkill ... OTOH I'd have one test that
> invokes pg_partition_tree(pg_partition_root(some-partition)) to verify
> that starting from
I think adding a pg_partition_root() call to as many pg_partition_tree
tests as you modified is overkill ... OTOH I'd have one test that
invokes pg_partition_tree(pg_partition_root(some-partition)) to verify
that starting from any point in the tree you get the whole tree.
I haven't actually tried
Hi all,
Álvaro has given faced a use case where it would be useful to have a
function which is able to return the top-most parent of a partition
tree:
https://postgr.es/m/20181204184159.eue3wlchqrkh4vsc@alvherre.pgsql
This has been mentioned as well on the thread where was discussed
Hi all,
While testing another patch, I have bumped into the issue of
$subject... I should have put some more negative testing from the start
on this stuff, here is a culprit query when passing directly an OID:
select pg_partition_tree(0);
I think that we should make the function return NULL if
Hi, Amit
Thanks for the quick modification.
On Wed, Dec 5, 2018 at 8:26 PM, Amit Langote wrote:
> > 1.
...
> > 5.
> > 0003: line 1620-1621
> >
> > + * After creating the RelOptInfo for the given child RT index, it goes on
> > to
> > + * initialize some of its fields base on the parent
On Fri, Dec 07, 2018 at 01:27:52AM +0100, Daniel Gustafsson wrote:
> Oh.. sorry about that, I should’ve known better. Thanks for tidying up!
No problem. Thanks for the report and for caring on the matter. So do
I.
--
Michael
signature.asc
Description: PGP signature
> On 6 Dec 2018, at 23:51, Michael Paquier wrote:
>
> On Thu, Dec 06, 2018 at 09:44:22AM -0300, Alvaro Herrera wrote:
>> LGTM.
>
> Thanks Álvaro for the additional lookup. I have committed the patch,
> after updating the regression test output as this stuff was forgotten,
> but that was easy
On Thu, Dec 06, 2018 at 06:55:52PM -0300, Alvaro Herrera wrote:
> Some time ago, after partitioned indexes had been pushed, I realized
> that even though I didn't want them to have relfilenodes, they did. And
> looking closer I noticed that *a lot* of relation kinds that didn't need
>
On 12/6/18, 4:54 PM, "Michael Paquier" wrote:
> On Thu, Dec 06, 2018 at 02:43:35PM +0900, Michael Paquier wrote:
>> Why? A WARNING would be logged if the first unlink() fails, and
>> another, different WARNING would be logged if the subsequent fsync
>> fails. It looks enough to me to make a
On Sun, Sep 23, 2018 at 10:12 PM Andrey Borodin wrote:
> (0001-GiST-verification-function-for-amcheck-v2.patch)
Thanks for working on this. Some feedback:
* You do this:
> +/* Check of an internal page. Hold locks on two pages at a time
> (parent+child). */
This isn't consistent with what
On Thu, Dec 06, 2018 at 01:26:30PM -0300, Alvaro Herrera wrote:
> That means I can just get pg_partition_root() done first, and try to
> write the queries using that instead of WITH RECURSIVE.
FWIW, I was just writing a patch about this one, so I was going to spawn
a new thread today :)
Let's
On Thu, Dec 06, 2018 at 02:43:35PM +0900, Michael Paquier wrote:
> Why? A WARNING would be logged if the first unlink() fails, and
> another, different WARNING would be logged if the subsequent fsync
> fails. It looks enough to me to make a distinction between both. Now,
> you may have a point
On Thu, Dec 06, 2018 at 09:44:22AM -0300, Alvaro Herrera wrote:
> LGTM.
Thanks Álvaro for the additional lookup. I have committed the patch,
after updating the regression test output as this stuff was forgotten,
but that was easy enough to fix.
--
Michael
signature.asc
Description: PGP
Hi,
On 2018-12-06 18:55:52 -0300, Alvaro Herrera wrote:
> Some time ago, after partitioned indexes had been pushed, I realized
> that even though I didn't want them to have relfilenodes, they did. And
> looking closer I noticed that *a lot* of relation kinds that didn't need
> relfilenodes, had
Currently, the following query
SELECT q.b = row(2)
FROM unnest(ARRAY[row(1, row(2))]) AS q(a int, b record);
would fail with
ERROR: column "b" has pseudo-type record
This is due to CheckAttributeNamesTypes() being used on a function
coldeflist as if it was a real relation
Just on cleanliness grounds, I propose to rewrite the function in
$SUBJECT. I came across this while reviewing some already-committed
patch for partition pruning, and it's been sitting in my laptop ever
since.
I think the current coding is too convoluted and hard to follow. The
patch makes it
On Sun, Dec 2, 2018 at 4:21 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
> > About the status of the patch, to me it should be RWF. It's been
> > moved to the next CF several times with no progress besides rebases.
>
> Let me disagree. Judging from the commentaries in this discussion it could
Some time ago, after partitioned indexes had been pushed, I realized
that even though I didn't want them to have relfilenodes, they did. And
looking closer I noticed that *a lot* of relation kinds that didn't need
relfilenodes, had them anyway.
This patch fixes that; if no relfilenode is needed,
On Thu, Dec 6, 2018 at 12:51 PM Alexander Korotkov wrote:
> So, algorithm introduced by 218f51584d5 is broken. It tries to
> guarantee that there are no inserters in the subtree by placing
> cleanup lock to subtree root, assuming that inserter holds pins on the
> path from root to leaf. But due
On Sun, Dec 2, 2018 at 7:03 AM Rafia Sabih
wrote:
>
> The idea looks good and believing your performance evaluation it seems
> like a practical one too.
Thank you kindly for the review!
> A comment explaining how this check differs for is_slice case would be
helpful.
> Looks like PG indentation
On Thu, Dec 6, 2018 at 10:56 PM Alexander Korotkov wrote:
> On Tue, Dec 4, 2018 at 8:01 PM Andres Freund wrote:
> > On 2018-11-10 17:42:16 -0800, Peter Geoghegan wrote:
> > > On Wed, Nov 7, 2018 at 5:46 PM Peter Geoghegan wrote:
> > > > Teodor: Do you think that the issue is fixable? It looks
Same patch, commit message added. Adding to commitfest.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 2cbe6fe5ac7617e424a63b820a6a2c83b712bab5 Mon Sep 17 00:00:00 2001
From: Alvaro Herrera
Date: Thu, 6
On 2018-Dec-06, Lætitia Avrot wrote:
> > I'd rename the action in ON DELETE/UPDATE to referential_action, both in
> > alter_table and in create_table (the latter just for consistency).
>
> I love that "option 3" ! So clever!
Thanks :-) I checked the SQL standard after sending that email, and
>
>
> I'd rename the action in ON DELETE/UPDATE to referential_action, both in
> alter_table and in create_table (the latter just for consistency).
>
I love that "option 3" ! So clever!
On Tue, Dec 4, 2018 at 8:01 PM Andres Freund wrote:
> On 2018-11-10 17:42:16 -0800, Peter Geoghegan wrote:
> > On Wed, Nov 7, 2018 at 5:46 PM Peter Geoghegan wrote:
> > > Teodor: Do you think that the issue is fixable? It looks like there
> > > are serious issues with the design of 218f51584d5
Attached is a complete patch for one of the tasks discussed in [1],
namely dropping CoerceToDomain nodes from plan trees if their domains
have no constraints that need to be checked.
After I fleshed out the original patch to include sinval signaling for
changes of domain constraints, I was
I noticed that there is no information for GRANT in
pg_event_trigger_ddl_commands(). I am trying to determine which
table/schema is being altered. Is there any way to do this either with
built-in functionality, or extending the current code in event_trigger.c?
Is the reason for this limitation
On 2018-Dec-06, Lætitia Avrot wrote:
> Any thought ? Which option do you prefer ? I can write the patch, but I'd
> like to know what you think about that.
I'd rename the action in ON DELETE/UPDATE to referential_action, both in
alter_table and in create_table (the latter just for consistency).
Robert Haas writes:
> On Thu, Dec 6, 2018 at 12:03 PM Tom Lane wrote:
>> [ further experimentation... ] It looks like if you prepare
>> a query and then just execute it repeatedly in one transaction,
>> you'd not reach AIM (as long as you were getting generic plans).
>> Possibly that's a gap
Hi,
I was trying to answer a former colleague question about postgres' default
behaviour when deleting or updating when she pointed out that Postgres
alter table documentation page used twice the 'action' keywords for two
different things.
And indeed she is right :
- it's used to described any
čt 6. 12. 2018 v 18:17 odesílatel Robert Haas
napsal:
> On Thu, Dec 6, 2018 at 12:13 PM Pavel Stehule
> wrote:
> > My idea about plpgsql PRAGMA is very close to PL/SQL or Ada PRAGMA. This
> is not runtime statement - the information from this command will be
> assigned to related object -
On 12/3/18, Amit Kapila wrote:
> On Mon, Dec 3, 2018 at 11:15 AM John Naylor wrote:
>> Per your recent comment, we no longer check relation size if we waited
>> on a relation extension lock, so this is essentially a reversion to an
>> earlier version.
>>
>
> fsm_local_set is being called from
On Thu, Dec 6, 2018 at 12:13 PM Pavel Stehule wrote:
> My idea about plpgsql PRAGMA is very close to PL/SQL or Ada PRAGMA. This is
> not runtime statement - the information from this command will be assigned to
> related object - function, block, command at parser time.
That's sensible, but
čt 6. 12. 2018 v 18:05 odesílatel Pavel Stehule
napsal:
>
>
> čt 6. 12. 2018 v 17:57 odesílatel Robert Haas
> napsal:
>
>> On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris
>> wrote:
>> > IIRC, PRAGMA in Ada was compile-time only. How would you foresee it
>> affecting runtime?
>>
>> Well, I
On Thu, Dec 6, 2018 at 12:03 PM Tom Lane wrote:
> In my testing, that still hits AIM() during parserOpenTable().
Oh, I see. relation_openrv_extended() calls it.
> [ further experimentation... ] It looks like if you prepare
> a query and then just execute it repeatedly in one transaction,
>
čt 6. 12. 2018 v 17:57 odesílatel Robert Haas
napsal:
> On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris
> wrote:
> > IIRC, PRAGMA in Ada was compile-time only. How would you foresee it
> affecting runtime?
>
> Well, I don't know what Ada does with PRAGMA exactly, but look at
> these examples
Robert Haas writes:
> On Thu, Dec 6, 2018 at 11:32 AM Tom Lane wrote:
>> It's fairly hard to imagine practical cases where we'd not call
>> AcceptInvalidationMessages at least once per query, so I'm not
>> very sure what you're on about.
> Unless I'm confused, it happens any time you run a
Ahh. Gotcha. Makes sense.
On Thu, Dec 6, 2018 at 11:57 AM Robert Haas wrote:
> On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris
> wrote:
> > IIRC, PRAGMA in Ada was compile-time only. How would you foresee it
> affecting runtime?
>
> Well, I don't know what Ada does with PRAGMA exactly, but
On Thu, Dec 6, 2018 at 11:55 AM Tom Lane wrote:
> How about saying that you must give an opclass name if you want to
> specify options, ie the syntax is
>
> [ opclass_name [ ( options... ) ] ]
>
> I'm not necessarily wedded to that, but it seems worth throwing
> out the idea.
Agreed,
On Thu, Dec 6, 2018 at 11:39 AM Jonah H. Harris wrote:
> IIRC, PRAGMA in Ada was compile-time only. How would you foresee it affecting
> runtime?
Well, I don't know what Ada does with PRAGMA exactly, but look at
these examples from Oracle:
http://psoug.org/definition/pragma.htm
You wouldn't
Robert Haas writes:
> On Wed, Dec 5, 2018 at 6:58 PM Nikita Glukhov wrote:
>> "opclass (options)" looks the most natural to me. But we still need some
>> keyword before the parentheses when the opclass is not specified since we
>> can't distinguish "func_name (func_params)" and "col_name
On Thu, Dec 6, 2018 at 11:32 AM Tom Lane wrote:
> Robert Haas writes:
> > I'm not thrilled about depending on sinval without locking,
> > particularly given that my proposal to make sure we
> > AcceptInvalidationMessages() at least once per query was shouted down.
>
> It's fairly hard to imagine
čt 6. 12. 2018 v 17:27 odesílatel Robert Haas
napsal:
> On Tue, Dec 4, 2018 at 12:13 PM Pavel Stehule
> wrote:
> > I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
> >
> > It is working well, but because it does static analyse only, sometimes
> it can produces false alarms or it
On Wed, Dec 5, 2018 at 6:58 PM Nikita Glukhov wrote:
> I agree that we should distinguish per-index and per-column options, but they
> can also be AM-specific and opclass-specific.
True, but an index is bound to a single AM, and a column is bound to a
single opclass which is bound to a single
Hello!
Thank you for questions!
> I've got few questions:
> 1. How will the subscription work for inherited tables? Do we need tests for
> that?
For subscription created with `FOR TABLE` we can't support inherit tables
because subscriber don't know anything about inherit. In new patch i remove
IIRC, PRAGMA in Ada was compile-time only. How would you foresee it
affecting runtime?
On Thu, Dec 6, 2018 at 11:27 AM Robert Haas wrote:
> On Tue, Dec 4, 2018 at 12:13 PM Pavel Stehule
> wrote:
> > I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
> >
> > It is working well, but
Robert Haas writes:
> I'm not thrilled about depending on sinval without locking,
> particularly given that my proposal to make sure we
> AcceptInvalidationMessages() at least once per query was shouted down.
It's fairly hard to imagine practical cases where we'd not call
On Tue, Dec 4, 2018 at 12:13 PM Pavel Stehule wrote:
> I wrote plpgsql_check https://github.com/okbob/plpgsql_check.
>
> It is working well, but because it does static analyse only, sometimes it can
> produces false alarms or it should to stop a analyse, because there are not
> necessary data.
On 2018-Dec-06, Robert Haas wrote:
> On Wed, Dec 5, 2018 at 11:30 AM Alvaro Herrera
> wrote:
> > I added this patch to commitfest in order to get more opinions,
> > particularly on whether to backpatch this. I might commit sooner than
> > that if others care to comment.
>
> I don't think this
On Wed, Dec 5, 2018 at 11:30 AM Alvaro Herrera wrote:
> I added this patch to commitfest in order to get more opinions,
> particularly on whether to backpatch this. I might commit sooner than
> that if others care to comment.
I don't think this is a bug fix, and therefore I oppose back-patching
On Wed, Dec 5, 2018 at 1:41 PM Tom Lane wrote:
> Ah, yes, that is a case where we might have enough knowledge to prove
> the test redundant --- but considering that we explicitly discourage
> domain NOT NULL as bad style and not fully supported, I can't get
> excited about it. I suppose in some
Greetings,
* Pavel Raiskup (prais...@redhat.com) wrote:
> On Wednesday, December 5, 2018 4:59:18 PM CET Stephen Frost wrote:
> > This change doesn't seem to make any sense to me..? If anything, seems
> > like we'd end up overallocating memory *after* this change, where we
> > don't today (though
Greetings,
* Kyotaro HORIGUCHI (horiguchi.kyot...@lab.ntt.co.jp) wrote:
> At Tue, 4 Dec 2018 11:37:16 -0500, Stephen Frost wrote
> in <20181204163716.gr3...@tamriel.snowman.net>
> > Thanks to everyone for sharing their thoughts here, the goal is simply
> > to try and have the comments as clear
čt 6. 12. 2018 v 17:02 odesílatel Robert Haas
napsal:
> On Thu, Dec 6, 2018 at 10:53 AM Pavel Stehule
> wrote:
> > čt 6. 12. 2018 v 16:26 odesílatel Robert Haas
> napsal:
> >> On Thu, Dec 6, 2018 at 10:23 AM Pavel Stehule
> wrote:
> >> > I have a problem to imagine it. When fill factor will
On Thu, Dec 6, 2018 at 10:53 AM Pavel Stehule wrote:
> čt 6. 12. 2018 v 16:26 odesílatel Robert Haas napsal:
>> On Thu, Dec 6, 2018 at 10:23 AM Pavel Stehule
>> wrote:
>> > I have a problem to imagine it. When fill factor will be low, then there
>> > is high risk of high fragmentation - or
čt 6. 12. 2018 v 16:26 odesílatel Robert Haas
napsal:
> On Thu, Dec 6, 2018 at 10:23 AM Pavel Stehule
> wrote:
> > I have a problem to imagine it. When fill factor will be low, then there
> is high risk of high fragmentation - or there some body should to do
> defragmentation.
>
> I don't
On Wed, Nov 28, 2018 at 6:17 PM Tomas Vondra
wrote:
> > Comparing with overhead of setting snapshot before evaluating every row
> > and considering this
> >
> > kind of usage is not frequent it seems to me the behavior is acceptable
>
> I'm not really buying the argument that this behavior is
On Thu, Dec 6, 2018 at 10:23 AM Pavel Stehule wrote:
> I have a problem to imagine it. When fill factor will be low, then there is
> high risk of high fragmentation - or there some body should to do
> defragmentation.
I don't understand this.
--
Robert Haas
EnterpriseDB:
čt 6. 12. 2018 v 16:12 odesílatel Robert Haas
napsal:
> On Thu, Dec 6, 2018 at 2:11 AM Pavel Stehule
> wrote:
> >> > I am sorry, I know zero about zheap - does zheap use fill factor? if
> yes, why?
> >>
> >> Good question. It is required because tuples can expand (Update tuple
> >> to bigger
On Thu, Dec 06, 2018 at 05:01:26AM -0300, Alvaro Herrera wrote:
> On 2018-Dec-06, David Fetter wrote:
>
> > There's a bit of a philosophical issue here, or a mathematical one,
> > whichever way you want to put it. Does it actually make sense to have
> > the behavior of one "semicolon" spill onto
On Thu, Dec 6, 2018 at 2:11 AM Pavel Stehule wrote:
>> > I am sorry, I know zero about zheap - does zheap use fill factor? if yes,
>> > why?
>>
>> Good question. It is required because tuples can expand (Update tuple
>> to bigger length). In such cases, we try to perform in-place update
>> if
ALTER DOMAIN ADD CONSTRAINT goes to some effort to verify that existing
stored data of the domain type meets the new constraint. (It's not
bulletproof, because it can't see uncommitted data, but at least it
tries.) However, what if the user tries to change the behavior of
an existing constraint
Hi Álvaro,
> On 6. Dec 2018, at 13:56, Alvaro Herrera wrote:
>
> To Oleksii's question, I think if you want to repeat the first query
> over and over, you'd use something like this:
>
> select format('select now() as execution_time, %L as generation_time', now())
> as query \gset
> :query
Alvaro Herrera wrote:
> Hmm, thanks. AFAICS your hack reexecutes the initial query over and
> over, instead of obtaining a fresh query each time.
I see. That hack is about injecting something programmatically
into the query buffer, but it seems you'd need to do that in a loop.
And if
On 2018-Dec-06, Daniel Verite wrote:
> I think you could achieve more or less the result with a pre-gexec
> hack like that:
Hmm, thanks. AFAICS your hack reexecutes the initial query over and
over, instead of obtaining a fresh query each time.
--
Álvaro Herrera
Alvaro Herrera wrote:
> Honestly, I don't see the mathematicality in this. It either works, or
> it doesn't -- and from my POV right now it doesn't. Are you saying we
> need a \gexecwatch for this to work?
>
> I can of course solve my problem with a simple python program, but psql
> is
čt 6. 12. 2018 v 13:56 odesílatel Alvaro Herrera
napsal:
> On 2018-Dec-06, Pavel Stehule wrote:
>
> > čt 6. 12. 2018 v 12:26 odesílatel Oleksii Kliukin
> > napsal:
>
> > > The other question is whether such a command would execute the original
> > > query every time watch is invoked. Consider,
On 2018-Dec-06, Pavel Stehule wrote:
> čt 6. 12. 2018 v 12:26 odesílatel Oleksii Kliukin
> napsal:
> > The other question is whether such a command would execute the original
> > query every time watch is invoked. Consider, e.g. the following one:
> >
> > select format('select now() as
Hi Oleksii
On 2018-Dec-06, Oleksii Kliukin wrote:
> The other question is whether such a command would execute the
> original query every time watch is invoked. Consider, e.g. the
> following one:
>
> select format('select now() as execution_time, %L as generation_time', now())
> \gexec
>
On 2018-Dec-06, Daniel Gustafsson wrote:
> > On 6 Dec 2018, at 05:46, Michael Paquier wrote:
> >
> > On Wed, Dec 05, 2018 at 05:22:25PM +0100, Daniel Gustafsson wrote:
> >> While looking at error messages downstream, I noticed a few hints and
> >> details
> >> in postgres which aren’t
čt 6. 12. 2018 v 12:26 odesílatel Oleksii Kliukin
napsal:
>
>
> > On 6. Dec 2018, at 09:01, Alvaro Herrera
> wrote:
> >
> > On 2018-Dec-06, David Fetter wrote:
> >
> >> There's a bit of a philosophical issue here, or a mathematical one,
> >> whichever way you want to put it. Does it actually
On Thu, Dec 06, 2018 at 09:42:26AM +0100, Daniel Gustafsson wrote:
> Ah, for some reason I hadn’t thought about looking at the GUCs. I agree with
> your findings, patch updated.
Thanks Daniel, that looks fine to me at quick glance. I'll try to get
that committed tomorrow my time if there are no
> On 6. Dec 2018, at 09:01, Alvaro Herrera wrote:
>
> On 2018-Dec-06, David Fetter wrote:
>
>> There's a bit of a philosophical issue here, or a mathematical one,
>> whichever way you want to put it. Does it actually make sense to have
>> the behavior of one "semicolon" spill onto another?
> On 6 Dec 2018, at 05:46, Michael Paquier wrote:
>
> On Wed, Dec 05, 2018 at 05:22:25PM +0100, Daniel Gustafsson wrote:
>> While looking at error messages downstream, I noticed a few hints and details
>> in postgres which aren’t punctuated as per the style guide. The attached
>> patch
>>
On 2018-Dec-06, David Fetter wrote:
> There's a bit of a philosophical issue here, or a mathematical one,
> whichever way you want to put it. Does it actually make sense to have
> the behavior of one "semicolon" spill onto another?
Honestly, I don't see the mathematicality in this. It either
88 matches
Mail list logo
