Tsunakawa-san
Thanks for giving the information.
I didn't use it yet, but I just used perf to clarify the difference of before
and after the creation of the generic plan, and I noticed that usage of
hash_seq_search() is increased about 3% in EXECUTE queries after the creation
of the generic pla
From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> BTW, I found another spot in descriptor.c where ecpglib is using
> setlocale() for the same purpose. Perhaps that one's not reachable
> in threaded apps, but I didn't see any obvious reason to think so,
> so I changed it too.
Ouch, thanks. And I'm sor
From: Kyotaro HORIGUCHI [mailto:horiguchi.kyot...@lab.ntt.co.jp]
> Although this doesn't put a hard cap on memory usage, it is indirectly and
> softly limited by the cache_prune_min_age and cache_memory_target, which
> determins how large a cache can grow until pruning happens. They are
> per-cache
On Sat, Jan 19, 2019 at 03:01:07AM +0100, Vik Fearing wrote:
> On 19/01/2019 02:33, Michael Paquier wrote:
>> On Fri, Jan 18, 2019 at 07:58:06PM +0100, Vik Fearing wrote:
>>> My vote is to have homogeneous syntax for all of this, and so put it in
>>> parentheses, but we should also allow CREATE IND
On Thu, Jan 17, 2019 at 02:55:39PM +0900, Michael Paquier wrote:
> Personally I see pgxs as something completely different than what COPT
> and PROFILE are as we are talking about two different facilities: one
> which is part of the core installation, and the other which can be
> used for extension
On Mon, Jan 21, 2019 at 10:09:09PM +, Bossart, Nathan wrote:
> Here's a new patch set that should address the feedback in this
> thread. The changes in this version include:
>
> - 0001 is a small fix to the 'vacuumdb --disable-page-skipping'
>documentation. My suggestion is to keep it s
Imai-san,
If the time for EXECUTE differs cleary before and after the creation of the
generic plan, why don't you try to count the function calls for each EXECUTE?
Although I haven't tried it, but you can probably do it with SystemTap, like
this:
probe process("your_postgres_path").function("
On Tue, Jan 22, 2019 at 01:43:32PM +0900, Amit Langote wrote:
> Hi,
>
> Attached find a patch to fix $subject.
It is like that since 31bc604. Andres, would you take care of it? It
is your commit after all..
--
Michael
signature.asc
Description: PGP signature
On Tue, Jan 22, 2019 at 01:47:05PM +0900, Masahiko Sawada wrote:
> Or can we make the test script set force_parallel_mode = off? Since
> the failure case is a very rare in real world I think that it might be
> better to change the test scripts rather than changing properly of
> current_schema().
P
On 22/01/2019 02:40, Andreas Karlsson wrote:
On 1/18/19 9:34 PM, Robert Haas wrote:
On Thu, Jan 17, 2019 at 10:48 AM Andreas Karlsson
wrote:
On 1/11/19 8:10 PM, Robert Haas wrote:
WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query...
Hm, when would one want "NOT MATERIALIZED"? I am no
On Sat, Jan 19, 2019 at 5:05 AM Robert Haas wrote:
>
> On Thu, Jan 17, 2019 at 8:08 PM Tom Lane wrote:
> > > Anyway, it seems to me that this is pointing out to another issue:
> > > current_schema() can trigger a namespace creation, hence shouldn't we
> > > mark it as PARALLEL UNSAFE and make sur
Hi,
Attached find a patch to fix $subject.
Thanks,
Amit
diff --git a/src/backend/jit/llvm/llvmjit_error.cpp
b/src/backend/jit/llvm/llvmjit_error.cpp
index ba3907c452..9c6e8026e7 100644
--- a/src/backend/jit/llvm/llvmjit_error.cpp
+++ b/src/backend/jit/llvm/llvmjit_error.cpp
@@ -9,7 +9,7 @@
* C
On Sat, Jan 12, 2019 at 5:02 PM Amit Kapila wrote:
>
> Fair enough. I think that for now (and maybe for the first version
> that can be committed) we might want to use heap tuple format. There
> will be some overhead but I think code-wise, things will be simpler.
> I have prototyped it for Inser
On 2019/01/22 8:30, Alvaro Herrera wrote:
> Hi Amit,
>
> Will you please rebase 0002? Please add your proposed tests cases to
> it, too.
Done. See the attached patches for HEAD and PG 11.
Thanks,
Amit
From 432c4551990d0da1c77b6b9523296b0a2a0a5119 Mon Sep 17 00:00:00 2001
From: amit
Date: Tue
Thanks for making those changes.
On Fri, 18 Jan 2019 at 10:03, Tomas Vondra wrote:
> A couple of items remains:
>
> > 15. I see you broke out the remainder of the code from
> > clauselist_selectivity() into clauselist_selectivity_simple(). The
> > comment looks like just a copy and paste from t
>
> > For this particular purpose, I don't immediately see why you need a
> > hook in both places. If ReadBuffer is called with P_NEW, aren't we
> > guaranteed to end up in smgrextend()?
> Yes, that's a bit awkward.
Hi Michael, we revisit the ReadBuffer hook and remove it in the latest
patch.
R
On 1/10/19 2:28 AM, Andreas Karlsson wrote:
Here is a new version of the patch with added tests, improved comments,
some minor code cleanup and most importantly slightly changed logic for
when we should inline.
Add ctematerialized to the JumbleExpr() in pg_stat_statements on
suggestion from A
On 01/21/19 21:45, Tom Lane wrote:
> are concerned, but for cross-extension references it seems a
> lot better to be looking for "postgis / function_foo_int_int"
> than for "postgis / 3".
I wonder if postgis might offer a .h file with FUNCTION_POSTGIS_FOO_INT_INT
defined as 3, which extensions int
On Wed, Dec 12, 2018 at 07:30:18AM -0700, Bear Giles wrote:
> BTW another solution is SSO, e.g., Kerberos. I still need to submit a patch to
> pgsql to handle it better(*) but with postgresql itself you sign into the
> system and then the database server will just know who you are. You don't have
>
On Tue, Dec 11, 2018 at 09:56:54AM -0500, Tom Lane wrote:
> Michael Banck writes:
> > The same was requested in https://dba.stackexchange.com/questions/91252/
> > how-to-know-when-postgresql-password-is-changed so I was wondering
> > whether this would be a welcome change/addition, or whether peop
On 1/21/19 3:25 PM, Tom Lane wrote:
> "Joshua D. Drake" writes:
>> On 1/21/19 12:05 PM, Tom Lane wrote:
>>> Is there a newer version of mingw that does have this functionality?
>> Apparently this can be done with thee 64bit version:
>> https://stackoverflow.com/questions/33647271/how-to-use-conf
Chapman Flack writes:
> On 01/21/19 18:52, Tom Lane wrote:
>> I'm probably going to push forward with the OID mapping idea instead.
> As it happens, I'd been recently thinking[1] about a way that certain
> SQL/XML functionality could be provided by a pluggable selection of
> different extensions.
On Tue, Jan 22, 2019 at 12:15 PM Andres Freund wrote:
> Hi,
>
> Thanks!
>
> On 2019-01-22 11:51:57 +1100, Haribabu Kommi wrote:
> > Attached the patch for removal of scan_update_snapshot
> > and also the rebased patch of reduction in use of t_tableOid.
>
> I'll soon look at the latter.
>
Thanks.
I measured the latency of queries executed before and after creating generic
plan with master + v15-patch.
In this test, table is partitioned into 4k partitions.
I executed 400,0001 queries by pgbench.
I changed the timing of creating generic plan at 1st, 10,001st, 20,001st,
50,001st, ..., 390,0
On 01/21/19 18:52, Tom Lane wrote:
> I'm probably going to push forward with the OID mapping idea instead.
As it happens, I'd been recently thinking[1] about a way that certain
SQL/XML functionality could be provided by a pluggable selection of
different extensions.
And I think a use case like th
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> I thought about extending the extension infrastructure to provide
> Tom> some way of retrieving relevant OIDs. We could imagine, for
> Tom> instance, that an extension script has a way to say "this function
> Tom> is object number three
On 1/21/19 3:31 AM, Andreas Karlsson wrote:
Here is a a stab at refactoring this so the object creation does not
happen in a callback.
Rebased my patch on top of Andres's pluggable storage patches. Plus some
minor style changes.
Andreas
diff --git a/src/backend/commands/createas.c b/src/back
On 1/22/19 1:35 AM, John Naylor wrote:
> On Sun, Jan 20, 2019 at 2:31 PM Tomas Vondra
> wrote:
>> Attached is v6 of the patch, adopting "settings" instead of "guc".
>
> Ok, looks good. I tried changing config values with the .conf file,
> alter system, and alter database, and tried a few queri
> "Tom" == Tom Lane writes:
Tom> I thought about extending the extension infrastructure to provide
Tom> some way of retrieving relevant OIDs. We could imagine, for
Tom> instance, that an extension script has a way to say "this function
Tom> is object number three within this extension", a
Hi,
Thanks!
On 2019-01-22 11:51:57 +1100, Haribabu Kommi wrote:
> Attached the patch for removal of scan_update_snapshot
> and also the rebased patch of reduction in use of t_tableOid.
I'll soon look at the latter.
> > - consider removing table_gimmegimmeslot()
> > - add substantial docs for e
On Mon, Jan 21, 2019 at 1:01 PM Andres Freund wrote:
> Hi,
>
> On 2018-12-10 18:13:40 -0800, Andres Freund wrote:
> > On 2018-11-26 17:55:57 -0800, Andres Freund wrote:
> > > FWIW, now that oids are removed, and the tuple table slot abstraction
> > > got in, I'm working on rebasing the pluggable
Andres Freund writes:
> On 2019-01-21 18:52:05 -0500, Tom Lane wrote:
>> Yes, I said in so many words that I was proposing increasing
>> FirstNormalObjectId. I do not think the issues with pg_upgrade itself
>> are insoluble --- it would need some historical knowledge about what
>> FirstNormalObje
On Sun, Jan 20, 2019 at 2:31 PM Tomas Vondra
wrote:
> Attached is v6 of the patch, adopting "settings" instead of "guc".
Ok, looks good. I tried changing config values with the .conf file,
alter system, and alter database, and tried a few queries with
auto_explain. I made a pass through the confi
On Mon, Jan 21, 2019 at 02:58:39PM -0300, Alvaro Herrera wrote:
> "... operated on temp namespace" doesn't look good; seems to me to be
> missing an article, for one thing, but really I'm not sure that
> 'namespace' is the term to be using here. I'd say "... operated on
> temporary objects" instea
Hi,
On 2019-01-21 18:52:05 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-01-20 18:50:33 -0500, Tom Lane wrote:
> >> In [1] I propose that we should allow extensions to get their hands
> >> on the ability to transform function calls as per "protransform" and
> >> to generate lossy ind
On Tue, 22 Jan 2019 at 12:27, Tom Lane wrote:
>
> David Rowley writes:
> > (This is pretty minor, but I struggled to ignore it)
> > In RelationGetIndexAttrBitmap() a comment claims /* We return our
> > original working copy for caller to play with */. 3 of the 4 possible
> > Bitmapsets follow tha
Andres Freund writes:
> On 2019-01-20 18:50:33 -0500, Tom Lane wrote:
>> In [1] I propose that we should allow extensions to get their hands
>> on the ability to transform function calls as per "protransform" and
>> to generate lossy index quals based on items in WHERE clauses. The
>> APIs to giv
Hi,
In two places in the XMLTABLE implementation (XmlTableFetchRow, iterating
through a nodeset returned by the row_expression, and XmlTableGetValue,
going through a nodeset returned by the column_expression), the iteration
proceeds in index order through xpathobj->nodesetval->nodeTab.
The same h
Hi,
On 2019-01-21 20:25:46 -0300, Alvaro Herrera wrote:
> Hello
>
> On 2019-Jan-21, Andres Freund wrote:
>
> > On 2019-01-21 19:40:17 -0300, Alvaro Herrera wrote:
> > > On 2019-Jan-21, Tom Lane wrote:
> > >
> > > > Alvaro Herrera writes:
> > >
> > > > > At https://postgr.es/m/201901182216.nr5
Andres Freund writes:
> On 2019-01-21 18:14:31 -0500, Tom Lane wrote:
>> I don't think that's relevant. The issues there were about whether
>> a pg_index row update ought to cause an invalidation of the relcache
>> entry for the index's table (not the one for the index, which it
>> already takes
Hi,
On 2019-01-21 18:14:31 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Given
> > https://www.postgresql.org/message-id/20190121193300.gknn7p4pmmjg7nqf%40alap3.anarazel.de
> > and the concerns voiced in the thread quoted therein, I'm a bit
> > surprised that you just went ahead with this,
Hi Amit,
Will you please rebase 0002? Please add your proposed tests cases to
it, too.
Thanks,
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> On Jan 21, 2019, at 3:27 PM, Andres Freund wrote:
>
> Hi,
>
> On 2019-01-21 15:21:29 -0800, Paul Ramsey wrote:
>> As a practical matter, most of the exact-test functions have a
>> preamble that checks the bbox, so in the seqscan case having the
>> operator along for the ride isn’t any advan
Hi,
On 2019-01-21 15:21:29 -0800, Paul Ramsey wrote:
> As a practical matter, most of the exact-test functions have a
> preamble that checks the bbox, so in the seqscan case having the
> operator along for the ride isn’t any advantage. In any event, if we
> do have exact tests w/o a lossy preamble
David Rowley writes:
> (This is pretty minor, but I struggled to ignore it)
> In RelationGetIndexAttrBitmap() a comment claims /* We return our
> original working copy for caller to play with */. 3 of the 4 possible
> Bitmapsets follow that comment but for some reason, we make a copy of
> the prim
Hello
On 2019-Jan-21, Andres Freund wrote:
> On 2019-01-21 19:40:17 -0300, Alvaro Herrera wrote:
> > On 2019-Jan-21, Tom Lane wrote:
> >
> > > Alvaro Herrera writes:
> >
> > > > At https://postgr.es/m/201901182216.nr5clsxrn624@alvherre.pgsql I posted
> > > > a simplistic for the specific probl
> On Jan 21, 2019, at 3:17 PM, Andres Freund wrote:
>
> Hi,
>
> On 2019-01-19 20:53:55 -0500, Tom Lane wrote:
>> I wrote:
>>> Paul Ramsey writes:
Is there a rule of thumb we can use in costing our wrappers to ensure that
they always inline?
>>
>>> Not really, which is a weak spot
Hi,
On 2019-01-19 20:53:55 -0500, Tom Lane wrote:
> I wrote:
> > Paul Ramsey writes:
> >> Is there a rule of thumb we can use in costing our wrappers to ensure that
> >> they always inline?
>
> > Not really, which is a weak spot of this whole approach.
>
> BTW, it suddenly strikes me that at
Andres Freund writes:
> Given
> https://www.postgresql.org/message-id/20190121193300.gknn7p4pmmjg7nqf%40alap3.anarazel.de
> and the concerns voiced in the thread quoted therein, I'm a bit
> surprised that you just went ahead with this, and backpatched it to boot.
I don't think that's relevant.
Pushed now, thanks.
--
Álvaro Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hi,
On 2019-01-20 18:50:33 -0500, Tom Lane wrote:
> In [1] I propose that we should allow extensions to get their hands
> on the ability to transform function calls as per "protransform" and
> to generate lossy index quals based on items in WHERE clauses. The
> APIs to give an extension control a
(This is pretty minor, but I struggled to ignore it)
In RelationGetIndexAttrBitmap() a comment claims /* We return our
original working copy for caller to play with */. 3 of the 4 possible
Bitmapsets follow that comment but for some reason, we make a copy of
the primary key attrs before returning.
Hi,
On 2019-01-21 19:40:17 -0300, Alvaro Herrera wrote:
> On 2019-Jan-21, Tom Lane wrote:
>
> > Alvaro Herrera writes:
>
> > > At https://postgr.es/m/201901182216.nr5clsxrn624@alvherre.pgsql I posted
> > > a simplistic for the specific problem I found by calling
> > > CacheInvalidateRelcache in
On 2019-Jan-21, Tom Lane wrote:
> Alvaro Herrera writes:
> > At https://postgr.es/m/201901182216.nr5clsxrn624@alvherre.pgsql I posted
> > a simplistic for the specific problem I found by calling
> > CacheInvalidateRelcache in the problem spot. But I'm wondering if the
> > correct fix isn't to h
On 1/21/19 7:51 PM, Andres Freund wrote:
> Hi,
>
> On 2019-01-21 16:22:11 +0100, Tomas Vondra wrote:
>>
>>
>> On 1/21/19 4:33 AM, Tomas Vondra wrote:
>>>
>>>
>>> On 1/21/19 3:12 AM, Andres Freund wrote:
On 2019-01-20 18:08:05 -0800, Andres Freund wrote:
> On 2019-01-20 21:00:21 -0500,
I knew that XLogRecordPageWithFreeSpace() is only called by heapam.c,
but I figured indexes had their own logic to xlog free space. While
investigating something else I found that brin indexes, at least, on
the secondary have no FSMs. Is this deliberate?
--
John Naylorhttps://www.
On Mon, Jan 21, 2019 at 6:32 AM Amit Kapila wrote:
> So we won't allow transfer of FSM files if their size is below
> HEAP_FSM_CREATION_THRESHOLD. What will be its behavior in link mode?
> It seems that the old files will remain there. Will it create any
> problem when we try to create the files
On Fri, Jan 18, 2019 at 4:06 PM Peter Geoghegan wrote:
> > * Objects-to-drop output from DROP ROLE is still unstable. I suppose
> > this would be fixed by also doing sorting in that code path, but
> > I've not looked into it.
>
> The nbtree patch is not dependent on doing better here, since the
>
On Wed, Dec 5, 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
> fixes the ones where it seemed reasonable to end with a period.
Bonsoir Daniel,
sql> SELECT 1 \g /BAD
/BAD: Permission denied
sql> \echo :ERROR
false
That seems broken, because it's pointless to leave out a class of errors
from ERROR.
Yep. That is my point, but fixing it requires to decide whether it is okay
to change ERROR documentation and
On Fri, Jan 18, 2019 at 05:09:41PM -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-18 19:57:03 -0500, Robert Haas wrote:
> > On Fri, Jan 18, 2019 at 4:23 PM and...@anarazel.de
> > wrote:
> > > My proposal for this was to attach a 'generation' to cache entries. Upon
> > > access cache entries ar
Hi Andrey,
Thank you for the review! I have updated the patch according to your
comments and remarks. Please, find new version attached.
On 2019-01-07 12:12, Andrey Borodin wrote:
Here are some my notes:
1. RestoreArchivedWAL() shares a lot of code with
RestoreArchivedFile(). Is it possible\vi
Andres Freund writes:
> We could just refuse to support thread safety on mingw if that's not
> supported? Or is that too aggressive?
Nah, we already had that discussion upthread. Given the lack of
prior complaints, we shouldn't break cases that are working today.
For instance, as long as setloc
"Joshua D. Drake" writes:
> On 1/21/19 12:05 PM, Tom Lane wrote:
>> Is there a newer version of mingw that does have this functionality?
> Apparently this can be done with thee 64bit version:
> https://stackoverflow.com/questions/33647271/how-to-use-configthreadlocale-in-mingw
Hmm, the followup
Hi,
On 2019-01-21 15:05:23 -0500, Tom Lane wrote:
> Andres Freund writes:
> > Seems jacana might not have like this change?
> > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28
>
> Hmm. So mingw doesn't provide access to _configthreadlocale().
> That's
On 1/21/19 12:05 PM, Tom Lane wrote:
Andres Freund writes:
Seems jacana might not have like this change?
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28
Hmm. So mingw doesn't provide access to _configthreadlocale().
That's unfortunate, at least if w
Alvaro Herrera writes:
> While working on bugfixes for FK problems in partitioned tables, I came
> across some behavior that appears to stem from our inclusion of foreign
> keys in relcache, without sufficient care for invalidating the relcache
> entries when the foreign key set for the table chan
Andres Freund writes:
> Seems jacana might not have like this change?
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jacana&dt=2019-01-21%2019%3A01%3A28
Hmm. So mingw doesn't provide access to _configthreadlocale().
That's unfortunate, at least if we think that mingw is still a viable
On 2019-01-21 12:09:30 -0500, Tom Lane wrote:
> "Tsunakawa, Takayuki" writes:
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> >> So like this ...
>
> > How quick! Thank you. I've reviewed the code for both Unix and Windows,
> > and it looks OK. I haven't built the patch, but expect the build
Hi,
On 2019-01-21 16:27:50 -0300, Alvaro Herrera wrote:
> While working on bugfixes for FK problems in partitioned tables, I came
> across some behavior that appears to stem from our inclusion of foreign
> keys in relcache, without sufficient care for invalidating the relcache
> entries when the f
Hello
While working on bugfixes for FK problems in partitioned tables, I came
across some behavior that appears to stem from our inclusion of foreign
keys in relcache, without sufficient care for invalidating the relcache
entries when the foreign key set for the table changes. (Namely, a
partitio
On 01/21/19 13:14, Joshua D. Drake wrote:
>> Of course, the text would also be clickable, right? I think putting the
>> URL in a footnote is good in that case; it works both on screen and on
>> paper, which should alleviate JD's concerns.
>
> Yeah I could see that. I thought about that but was wo
On 2019-01-18 14:19:41 -0800, Andres Freund wrote:
> Hi,
>
> On 2019-01-16 08:20:37 -0800, Andres Freund wrote:
> > On January 16, 2019 8:08:09 AM PST, Robert Haas
> > wrote:
> > >On Tue, Jan 15, 2019 at 10:23 PM Haribabu Kommi
> > > wrote:
> > >> access/relation.[c|h] name is fine. Or how about
Hi,
On 2019-01-21 16:22:11 +0100, Tomas Vondra wrote:
>
>
> On 1/21/19 4:33 AM, Tomas Vondra wrote:
> >
> >
> > On 1/21/19 3:12 AM, Andres Freund wrote:
> >> On 2019-01-20 18:08:05 -0800, Andres Freund wrote:
> >>> On 2019-01-20 21:00:21 -0500, Tomas Vondra wrote:
>
>
> On 1/20/
On 2019-Jan-21, Joshua D. Drake wrote:
> On 1/21/19 10:01 AM, Alvaro Herrera wrote:
> > On 2019-Jan-21, Chapman Flack wrote:
> >
> > > But the point's well taken that in /printed output/, that's of no use.
> > > Which is, in a sense, an inconsistency: in one format, you can follow the
> > > links
On 1/21/19 10:11 AM, Chapman Flack wrote:
On 01/21/19 12:07, Joshua D. Drake wrote:
Who is really going to "print" our docs? If they do print the
docs, they are likely not going to "type in" a long URL.
QR code in footnote (ducks and runs).
Funny, although I know why you said that. I don't th
On 1/21/19 10:01 AM, Alvaro Herrera wrote:
On 2019-Jan-21, Chapman Flack wrote:
But the point's well taken that in /printed output/, that's of no use.
Which is, in a sense, an inconsistency: in one format, you can follow the
links, while in another, you're out of luck.
Maybe a simpler transfor
On 01/21/19 12:07, Joshua D. Drake wrote:
> Who is really going to "print" our docs? If they do print the
> docs, they are likely not going to "type in" a long URL.
QR code in footnote (ducks and runs).
On 2019-Jan-21, Chapman Flack wrote:
> But the point's well taken that in /printed output/, that's of no use.
> Which is, in a sense, an inconsistency: in one format, you can follow the
> links, while in another, you're out of luck.
>
> Maybe a simpler transform for printed output, rather than co
On 2019-Jan-18, Michael Paquier wrote:
> Keeping both messages makes the error handling at PREPARE time perhaps
> a bit cleaner to make the difference about schema-level access or
> table-level access, still I'd rather simplify the code and just only
> keep the schema-level change as something we
> Thanks for reviewing! I've pushed this now (to HEAD only for the
> moment),
> we'll see what the buildfarm thinks.
>
> BTW, I found another spot in descriptor.c where ecpglib is using
> setlocale() for the same purpose. Perhaps that one's not reachable
> in threaded apps, but I didn't see any
On 2018-Dec-27, Magnus Hagander wrote:
> On Fri, Dec 21, 2018 at 4:17 PM Alvaro Herrera
> wrote:
>
> > On 2018-Dec-21, Tom Lane wrote:
> >
> > > Alvaro Herrera writes:
> > > > I propose the following patch, which will make those links stable --
> > > > then we can add the following links to the
On Mon, Jan 21, 2019 at 6:05 PM Oleg Bartunov wrote:
> On Mon, Jan 21, 2019 at 1:40 AM Alexander Korotkov
> wrote:
> >
> > On Sun, Jan 20, 2019 at 6:30 AM Alexander Korotkov
> > wrote:
> > > I'll continue revising this patchset. Nikita, could you please write
> > > tests for 3-argument versions
Hi,
On 2019-01-21 17:02:15 +0530, Rushabh Lathia wrote:
> Hi,
>
> I found that ALTER TRIGGER .. RENAME TO is broken and it's
> unable to rename the trigger. Looking further seems renametrig()
> function, copy the new trigger name into wrong tuple. This is
> broken with below commit:
>
> commit
"Tsunakawa, Takayuki" writes:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> So like this ...
> How quick! Thank you. I've reviewed the code for both Unix and Windows, and
> it looks OK. I haven't built the patch, but expect the buildfarm to do the
> test.
Thanks for reviewing! I've pushe
On 1/21/19 8:46 AM, Chapman Flack wrote:
On 01/21/19 09:12, Alvaro Herrera wrote:
(thinks to self half-seriously about an XSL transform for generating
printed output that could preserve link-texted links, add raised numbers,
and produce a numbered URLs section at the back)
Well, if you have th
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Magnus Hagander writes:
> > On Sat, Jan 19, 2019 at 7:19 PM Stephen Frost wrote:
> >> Does this also implicitly mean we've just agreed to push back the
> >> retirement of the @postgresql.org aliases for the lists until v11 is
> >> EOL..?
>
> >
On 01/21/19 09:12, Alvaro Herrera wrote:
>> (thinks to self half-seriously about an XSL transform for generating
>> printed output that could preserve link-texted links, add raised numbers,
>> and produce a numbered URLs section at the back)
>
> Well, if you have the time and inclination, and you
On 21.01.2019 17:56, Tomas Vondra wrote:
On 1/21/19 12:51 PM, Arthur Zakirov wrote:
I'll try to implement the syntax, you suggested earlier:
ALTER TEXT SEARCH DICTIONARY x UNLOAD/RELOAD
The main point here is that UNLOAD/RELOAD can't release the memory
immediately, because some other backend m
On 1/21/19 11:18 AM, Fabien COELHO wrote:
>
> Hello Tom,
>
>> Well, glob does have some metacharacters, so not doing any quoting
>> at all still leaves us with failure modes.
>>
>> I did a little bit of googling on this subject last night, and it
>> seems that at least some people believe that th
Hello Tom,
Well, glob does have some metacharacters, so not doing any quoting
at all still leaves us with failure modes.
I did a little bit of googling on this subject last night, and it
seems that at least some people believe that the answer is to not
use glob, period, but read the directory
Hello Andrew,
About windows-specific issues, from File::Glob man page:
""" On DOSISH systems, backslash is a valid directory separator
character. In this case, use of backslash as a quoting character (via
GLOB_QUOTE) interferes with the use of backslash as a directory
separator. ... """
It se
Andrew Dunstan writes:
> Perhaps it would be OK we changed back the glob line to use $prefix
> instead of $qprefix, but kept the use of $qprefix in the later regex.
Well, glob does have some metacharacters, so not doing any quoting
at all still leaves us with failure modes.
I did a little bit of
On 1/21/19 4:50 AM, Fabien COELHO wrote:
>
> Hello Tom,
>
>> Hm, so bowerbird (a Windows machine) has been failing the pgbench tests
>> since this went in, cf
>>
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-01-20%2004%3A57%3A01
>>
>>
>> I'm just guessing, but I sus
Andreas Karlsson writes:
> I have a minor biksheddish question about the syntax.
> You proposed:
> WITH cte_name [[NOT] MATERIALIZED] AS (query) main_query
> While Andrew proposed:
> WITH cte_name AS [[NOT] MATERIALIZED] (query) main_query
> Do people have any preference between these two?
FWIW,
On 1/21/19 4:33 AM, Tomas Vondra wrote:
>
>
> On 1/21/19 3:12 AM, Andres Freund wrote:
>> On 2019-01-20 18:08:05 -0800, Andres Freund wrote:
>>> On 2019-01-20 21:00:21 -0500, Tomas Vondra wrote:
On 1/20/19 8:24 PM, Andres Freund wrote:
> Hi,
>
> On 2019-01-20 00:24:05
On Mon, Jan 21, 2019 at 1:40 AM Alexander Korotkov
wrote:
>
> On Sun, Jan 20, 2019 at 6:30 AM Alexander Korotkov
> wrote:
> > I'll continue revising this patchset. Nikita, could you please write
> > tests for 3-argument versions of functions? Also, please answer the
> > question regarding "id"
On 1/21/19 12:51 PM, Arthur Zakirov wrote:
> On 21.01.2019 02:43, Tomas Vondra wrote:
>> On 1/20/19 11:21 PM, Andres Freund wrote:
>>> On 2019-01-20 23:15:35 +0100, Tomas Vondra wrote:
Thanks. I've reviewed v17 today and I haven't discovered any new issues
so far. If everything goes fine
Hi,
On 1/21/19 4:01 AM, Amit Langote wrote:
Rebased again due to 8d8dcead1295.
Passes check-world on 8d8dcead1295.
I ran a work load on the series, measuring the time to load the data
plus the run-time to complete the work load.
LoadRun
master3m39s 144s
1778 3m12s
On 2019-Jan-19, Chapman Flack wrote:
> I have noticed a couple of things:
>
> - 'SQL' is often marked up as SQL, but far from always.
>
> - no such markup is applied to 'JSON' or 'XML' at all, at least
> not in func.sgml.
I think these inconsistencies just stem from lack of a strong reviewer
h
1 - 100 of 121 matches
Mail list logo
