On Thu, 17 Jan 2019 at 03:42, David Rowley wrote:
> 39. I don't see analyze_mcv_list() being used anywhere around this comment:
>
> * If we can fit all the items onto the MCV list, do that. Otherwise use
> * analyze_mcv_list to decide how many items to keep in the MCV list, just
> * like for the s
On Sun, Dec 02, 2018 at 09:35:06PM -0800, Noah Misch wrote:
> On Tue, Sep 25, 2018 at 08:05:12AM -0700, Noah Misch wrote:
> > On Mon, Sep 24, 2018 at 01:53:05PM -0400, Tom Lane wrote:
> > > Overall, I agree that neither of these approaches are exactly attractive.
> > > We're paying a heck of a lot
There appears to be a problem with how this affects current logging
behavior.
I'm using
pgbench -M extended -S -T 10 bench
to test the extended protocol.
Unpatched, with log_statement=all, you get something like
LOG: execute : SELECT abalance FROM pgbench_accounts WHERE aid
= $1;
DETAIL:
On Thu, 17 Jan 2019 at 17:18, Amit Langote
wrote:
>
> On 2019/01/04 9:53, David Rowley wrote:
> > Without PREPAREd statements, if the planner itself was unable to prune
> > the partitions it would already have obtained the lock during
> > planning, so AcquireExecutorLocks(), in this case, would bu
Hello, sorry for the absence.
At Fri, 11 Jan 2019 11:36:43 -0500, Robert Haas wrote
in
> On Thu, Jan 10, 2019 at 9:10 PM Kohei KaiGai wrote:
> > 2019年1月11日(金) 5:52 Robert Haas :
> > > On Wed, Jan 9, 2019 at 12:44 AM Kohei KaiGai wrote:
> > > > So, is it sufficient if set_rel_pathlist_hook is
Hello Tom,
Although we've got a few NetBSD and OpenBSD buildfarm critters,
none of them are doing --enable-tap-tests. If they were, we'd
have noticed the pgbench regression tests falling over:
[...]
I am, TBH, inclined to fix this by removing that test case rather
than teaching it another s
Latest patch, simpler but answers the key questions as code comments
On Mon, Dec 3, 2018 at 6:56 AM Chris Travers
wrote:
> On Thu, Nov 29, 2018 at 8:46 PM Dmitry Dolgov <9erthali...@gmail.com>
> wrote:
>
>> > On Wed, Oct 10, 2018 at 7:10 PM Chris Travers
>> wrote:
>> >
>> >> More generally, I'd
Thank you Imai-san for testing. Sorry it totally slipped my mind to reply
to this email.
On 2019/01/09 11:08, Imai, Yoshikazu wrote:
> I wonder why force_custom_plan is faster than auto after applied the patch.
>
> When we use PREPARE-EXECUTE, a generic plan is created and used if its cost is
>
On 1/16/19 10:09 AM, Masahiko Sawada wrote:
Since we set xact_is_sampled only when transaction starts and see it
during transaction we cannot disable logging during transaction and
vice versa. I can imagine the use case where user wants to disable
logging during transaction. So it might be better
Tsunakawa, Takayuki wrote:
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > The problem here of course is that whoever invented target_session_attrs
> > was unconcerned with following that precedent, so what we have is
> > "target_session_attrs=(any | read-write)".
> > Are we prepared to add some a
I've started looking over 0002. Here are a few things so far:
1. I think this should be pg_statistic_ext.stxhistogram?
Values of the pg_histogram can be obtained only from the
pg_statistic.stxhistogram column.
2. I don't think this bms_copy is needed anymore. I think it was
previously
On Fri, Jan 4, 2019 at 3:08 PM David Rowley
wrote:
> On Mon, 31 Dec 2018 at 18:58, Surafel Temesgen
> wrote:
> > On Fri, Dec 28, 2018 at 6:46 PM Fabien COELHO
> wrote:
> >> > At first i also try to do it like that but it seems the function will
> >> > became long and more complex to me
> >>
> >
On Tue, 15 Jan 2019 at 23:21, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Dave Cramer [mailto:p...@fastcrypt.com]
> > The original desire should have been the ability to connect to a
> > primary or a standby. So, I think we should go back to the original
> thinking
On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote:
> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> >> But pg_is_in_recovery() returns true even for a promoting standby. So
> >> you have to wait and retry to send pg_is_in_recovery() until it
> >> finishes the promotion to find out it is now a
On Thu, 17 Jan 2019 at 05:59, Laurenz Albe wrote:
> Tsunakawa, Takayuki wrote:
> > From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> > > The problem here of course is that whoever invented
> target_session_attrs
> > > was unconcerned with following that precedent, so what we have is
> > > "target_sess
I attached files of new version of the patch, I applied your tweaks.
> XXX All dictionaries, but only when there's invalid dictionary?
I've made a little optimization. I introduced hashvalue into
TSDictionaryCacheEntry. Now released only DSM of altered or dropped
dictionaries.
> > /* XXX no
On 2019-Jan-16, Dmitry Dolgov wrote:
> Proposed idea is to refactor out all/optional arguments into a separate data
> structure, so that adding/removing a new argument wouldn't change that much of
> unrelated code. Then for every invocation of ArchiveEntry this structure needs
> to be prepared be
On 2019-Jan-11, Andres Freund wrote:
> Just as an example of why I think this isn't great:
Hmm, to me, the first example is much better because of *vertical* space
-- I can have the whole API in one screenful. In the other example, the
same number of functions take many more lines. The fact tha
Alvaro Herrera writes:
> On 2019-Jan-16, Dmitry Dolgov wrote:
>> ArchiveEntry((ArchiveArgs){.tablespace = 3,
>> .dumpFn = somefunc,
>> ...});
> Is there real savings to be had by doing this? What would be the
> arguments to each function? Off-hand, I'm not liking this idea too
> much.
I'm not
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 not sure I see the
usefulness of forcing inlining other than if we by default do not inline
when a CTE is referenced multiple times.
Do you ima
On 1/11/19 8:47 PM, Mitar wrote:
In create_ctas_internal() why do you copy the relation even when you do
not modify it?
I was modelling this after code in view.c [1]. I can move copy into the "if".
Makes sense.
Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from
ExecCreateTabl
Andreas Karlsson writes:
> 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 not sure I see the
> usefulness of forcing inlining other than if we by default do not inline
> when a CTE is refer
On Wed, Jan 16, 2019 at 8:49 AM James Coleman wrote:
>
> On Tue, Jan 15, 2019 at 11:37 PM Tom Lane wrote:
> > Well, as I said upthread, it seems like we need to think a bit more
> > carefully about what it is that clause_is_strict_for is testing ---
> > and if that ends up finding that some other
Andreas Karlsson writes:
> On 1/11/19 8:47 PM, Mitar wrote:
>>> Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from
>>> ExecCreateTableAs()?
>> The comment there said that this is not really necessary for security:
>> "This is not necessary for security, but this keeps the behavior
On Sun, Jan 13, 2019 at 11:41 AM Tom Lane wrote:
> Putting a limit on the size of the syscaches doesn't accomplish anything
> except to add cycles if your cache working set is below the limit, or
> make performance fall off a cliff if it's above the limit.
If you're running on a Turing machine, s
On 2019-01-17 10:23:39 -0500, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Jan-16, Dmitry Dolgov wrote:
> >> ArchiveEntry((ArchiveArgs){.tablespace = 3,
> >> .dumpFn = somefunc,
> >> ...});
>
> > Is there real savings to be had by doing this? What would be the
> > arguments to each functi
Hi,
On 2019-01-17 10:50:56 +0100, Chris Travers wrote:
> diff --git a/src/backend/utils/init/globals.c
> b/src/backend/utils/init/globals.c
> index c6939779b9..5ed715589e 100644
> --- a/src/backend/utils/init/globals.c
> +++ b/src/backend/utils/init/globals.c
> @@ -27,12 +27,35 @@
>
> Protocol
On Wed, Jan 16, 2019 at 10:35 PM Amit Kapila wrote:
> Yes, I think it would be good if you can explain the concept of
> local-map with the help of this example.
> Then let's not add a reference to the version number in this case. I
Okay, done in v14. I kept your spelling of the new macro. One m
On 1/17/19 4:57 PM, Tom Lane wrote:
Andreas Karlsson writes:
On 1/11/19 8:47 PM, Mitar wrote:
Is it really ok to just remove SECURITY_RESTRICTED_OPERATION from
ExecCreateTableAs()?
The comment there said that this is not really necessary for security:
"This is not necessary for security, bu
On Thu, Jan 17, 2019 at 6:38 PM Andres Freund wrote:
> Hi,
>
> On 2019-01-17 10:50:56 +0100, Chris Travers wrote:
> > diff --git a/src/backend/utils/init/globals.c
> b/src/backend/utils/init/globals.c
> > index c6939779b9..5ed715589e 100644
> > --- a/src/backend/utils/init/globals.c
> > +++ b/src
Hi,
On 2018-10-09 16:04:35 +0200, Peter Eisentraut wrote:
> More generally, I'd like this material to be code comments. It's the
> kind of stuff that gets outdated before long if it's kept separate.
I'm not sure I buy this here - we don't have (but perhaps should?) a
convenient location for an o
Greetings,
* Andres Freund (and...@anarazel.de) wrote:
> On 2019-01-17 10:23:39 -0500, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > On 2019-Jan-16, Dmitry Dolgov wrote:
> > >> ArchiveEntry((ArchiveArgs){.tablespace = 3,
> > >> .dumpFn = somefunc,
> > >> ...});
> >
> > > Is there real savings
Hi,
On 2019-01-17 09:29:04 -0800, Andres Freund wrote:
> On 2019-01-17 10:23:39 -0500, Tom Lane wrote:
> > I don't buy the argument that this would move the goalposts in terms
> > of how much work it is to add a new argument. You'd still end up
> > touching every call site.
>
> Why? A lot of arg
On Thu, Jan 17, 2019 at 7:08 PM Andres Freund wrote:
> Hi,
>
> On 2018-10-09 16:04:35 +0200, Peter Eisentraut wrote:
> > More generally, I'd like this material to be code comments. It's the
> > kind of stuff that gets outdated before long if it's kept separate.
>
> I'm not sure I buy this here -
Andreas Karlsson writes:
> On 1/17/19 4:57 PM, Tom Lane wrote:
>> What is the stumbling block to just leaving that alone?
> I think the issue Mitar ran into is that the temporary materialized view
> is created in the rStartup callback of the receiver which happens after
> SECURITY_RESTRICTED_OP
On Thu, Jan 17, 2019 at 11:33:35AM -0500, Robert Haas wrote:
> The flaw in your thinking, as it seems to me, is that in your concern
> for "the likelihood that cache flushes will simply remove entries
> we'll soon have to rebuild," you're apparently unwilling to consider
> the possibility of worklo
Peter Geoghegan writes:
> On Tue, Dec 18, 2018 at 2:26 PM Tom Lane wrote:
>> Hm, that definitely leads me to feel that we've got bug(s) in
>> dependency.c. I'll take a look sometime soon.
> Thanks!
> I'm greatly relieved that I probably won't have to become an expert on
> dependency.c after all
ch overlapping
statics.
> 9. examine_equality_clause() assumes it'll get a Var. I see we should
> only allow clauses that pass statext_is_compatible_clause_internal(),
> so maybe it's worth an Assert(IsA(var, Var)) along with a comment to
> mention anything else could not have been allowed.
Maybe.
> 10. Does examine_equality_clause need 'root' as an argument?
Probably not. I guess it's a residue some older version.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
0001-multivariate-MCV-lists-20190117.patch.gz
Description: application/gzip
0002-multivariate-histograms-20190117.patch.gz
Description: application/gzip
On 2019-01-17 06:04, Tom Lane wrote:
Although we've got a few NetBSD and OpenBSD buildfarm critters,
none of them are doing --enable-tap-tests. If they were, we'd
have noticed the pgbench regression tests falling over:
For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio)
a
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
> On 2019-01-17 06:04, Tom Lane wrote:
>> Although we've got a few NetBSD and OpenBSD buildfarm critters,
>> none of them are doing --enable-tap-tests. If they were, we'd
>> have noticed the pgbench regression tests falling over:
> For what it's worth I
On 2019-01-17 22:16, Tom Lane wrote:
For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio)
and NetBSD 7 (sidewinder) animals now.
Oh, thanks! I'm guessing they'll fail their next runs, but I'll
wait to see confirmation of that before I do anything about the
test bug.
Th
On 2019-01-17 22:19, Mikael Kjellström wrote:
On 2019-01-17 22:16, Tom Lane wrote:
For what it's worth I've enabled tap-tests for my OpenBSD 5.9 (curculio)
and NetBSD 7 (sidewinder) animals now.
Oh, thanks! I'm guessing they'll fail their next runs, but I'll
wait to see confirmation of th
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
> It says:
> configure: error: Additional Perl modules are required to run TAP tests
> so how do I find out with Perl modules that are required?
If you look into the configure log it should say just above that,
but I'm betting you just need p5-IPC-Run.
On 2019-01-17 22:42, Tom Lane wrote:
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
It says:
configure: error: Additional Perl modules are required to run TAP tests
so how do I find out with Perl modules that are required?
If you look into the configure log it should say just above that,
but
I wrote:
> I propose that we handle this case by adding a new DEPFLAG_IS_SUBOBJECT
> flag to the column object's flags, denoting that we know the whole table
> will be dropped later. The only effect of this flag is to suppress
> reporting of the column object in reportDependentObjects.
Here's a p
On 2019-01-17 22:47, Mikael Kjellström wrote:
On 2019-01-17 22:42, Tom Lane wrote:
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
It says:
configure: error: Additional Perl modules are required to run TAP tests
so how do I find out with Perl modules that are required?
If you look into the con
On 2019-Jan-17, Tom Lane wrote:
> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code
> has no hesitation about making multiple entries of that kind. After
> rather cursorily looking at that code, I'm leaning to the position
> that DEPENDENCY_INTERNAL_AUTO is broken-by-design a
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
>> Let's see if it works better this time.
> Hmmm, nope:
> 2019-01-17 23:09:20.343 CET [9129] FATAL: could not create semaphores:
> No space left on device
Yeah, you might've been able to get by with OpenBSD/NetBSD's default
semaphore settings before
Alvaro Herrera writes:
> On 2019-Jan-17, Tom Lane wrote:
>> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code
>> has no hesitation about making multiple entries of that kind. After
>> rather cursorily looking at that code, I'm leaning to the position
>> that DEPENDENCY_INTERN
On 2019-01-17 23:23, Tom Lane wrote:
Yeah, you might've been able to get by with OpenBSD/NetBSD's default
semaphore settings before, but they really only let one postmaster
run at a time; and the TAP tests want to start more than one.
For me it seems to work to append this to /etc/sysctl.conf:
On 1/11/19 8:47 PM, Mitar wrote:
Thanks for doing the review!
I did some functional testing today and everything seems to work as
expected other than that the tab completion for psql seems to be missing.
Andreas
On 2019-Jan-17, Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2019-Jan-17, Tom Lane wrote:
> >> DEPENDENCY_INTERNAL_AUTO, however, broke this completely, as the code
> >> has no hesitation about making multiple entries of that kind. After
> >> rather cursorily looking at that code, I'm leanin
On 18/01/2019 08:48, Bruce Momjian wrote:
On Thu, Jan 17, 2019 at 11:33:35AM -0500, Robert Haas wrote:
The flaw in your thinking, as it seems to me, is that in your concern
for "the likelihood that cache flushes will simply remove entries
we'll soon have to rebuild," you're apparently unwilling
On 2019-01-17 23:37, Mikael Kjellström wrote:
On 2019-01-17 23:23, Tom Lane wrote:
Yeah, you might've been able to get by with OpenBSD/NetBSD's default
semaphore settings before, but they really only let one postmaster
run at a time; and the TAP tests want to start more than one.
For me it s
On 2019-Jan-09, Amit Langote wrote:
> 1. Foreign keys of partitions stop working correctly after being detached
> from the parent table
> This happens because the action triggers defined on the PK relation (pk)
> refers to p as the referencing relation. On detaching p1 from p, p1's
> data is no
On 2019-01-17 23:54, Mikael Kjellström wrote:
But it looks like in NetBSD the options are called:
netbsd7-pgbf# sysctl -a | grep semmn
kern.ipc.semmni = 10
kern.ipc.semmns = 60
kern.ipc.semmnu = 30
so I will try and set that in /etc/sysctl.conf and reboot and see what
happens.
That seems
> On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote:
>
>> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
>> >> But pg_is_in_recovery() returns true even for a promoting standby. So
>> >> you have to wait and retry to send pg_is_in_recovery() until it
>> >> finishes the promotion to find out it i
On 2019-01-18 00:00, Mikael Kjellström wrote:
I just started another run on sidewinder (NetBSD 7), let's see how that
goes.
but the OpenBSD machine went further and now fails on:
pgbenchCheck instead.
Is that the failure you expected to get?
And now also the NetBSD machine failed on pgb
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
>> But it looks like in NetBSD the options are called:
Sorry about that, I copied-and-pasted from the openbsd machine I was
looking at without remembering that netbsd is just a shade different.
> but the OpenBSD machine went further and now fails on:
>
Alvaro Herrera writes:
> On 2019-Jan-17, Tom Lane wrote:
>> Hm. Still, I can't believe that it's appropriate for a partitioned index
>> to have exactly the same kind of dependency on the master index as it
>> does on the associated table.
> So there are three necessary features:
> * The partitio
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
> And now also the NetBSD machine failed on pgbenchCheck.
Indeed, as expected.
> should I leave it as it is for now?
Please. I'll push a fix for the broken test case in a bit --- I
just wanted to confirm that somebody else's machines agreed that
it's
You introduced new macros IsHeapRelation and IsViewRelation, but I don't
want to introduce such API. Such things have been heavily contested and
I don't to have one more thing to worry about for this patch, so please
just put the relkind directly in the code.
On 2019-Jan-07, Nikolay Shaplov wrote
On Thu, Jan 17, 2019 at 3:20 PM Tom Lane wrote:
> Alvaro Herrera writes:
> > There is a symmetry to these that led me to have the same kind of
> > dependency from the index partition to the other two.
>
> It's symmetric as long as you suppose that the above are the only
> requirements. However,
On 2019-01-18 00:31, Tom Lane wrote:
=?UTF-8?Q?Mikael_Kjellstr=c3=b6m?= writes:
And now also the NetBSD machine failed on pgbenchCheck.
Indeed, as expected.
Ok.
should I leave it as it is for now?
Please. I'll push a fix for the broken test case in a bit --- I
just wanted to confirm
> "Andrew" == Andrew Gierth writes:
Andrew> Because it turns out that Windows (at least the version running
Andrew> on Appveyor) completely fucks this up; strtof() is apparently
Andrew> returning infinity or zero _without setting errno_ for values
Andrew> out of range for float: input of
I wrote:
> Also, I am suspicious that this implementation fails on point 3
> anyway ... If nothing else, it looks like ALTER OBJECT DEPENDS ON
> EXTENSION can be used to attach a random dependency to just
> about anything.
Yup:
regression=# drop table if exists idxpart cascade;
DROP TABLE
regress
On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote:
> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote:
> >
> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> >> >> But pg_is_in_recovery() returns true even for a promoting standby. So
> >> >> you have to wait and retry to send pg_is_in_reco
On Thu, Jan 17, 2019 at 12:42 PM Tom Lane wrote:
> So I poked around for awhile with running the regression tests under
> ignore_system_indexes. There seem to be a number of issues involved
> here. To a significant extent, they aren't bugs, at least not according
> to the original conception of
From: Dave Cramer [mailto:p...@fastcrypt.com]
> >> 2) If there's no node on which pg_is_in_recovery() returns false,
> then
> >>we need to retry until we find it. To not retry forever, there
> >>should be a timeout counter parameter.
> Checking the code I see we actually
> On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote:
>
>> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii wrote:
>> >
>> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
>> >> >> But pg_is_in_recovery() returns true even for a promoting standby. So
>> >> >> you have to wait and retry to send pg_i
Fabien COELHO writes:
>> I am, TBH, inclined to fix this by removing that test case rather
>> than teaching it another spelling to accept. I think it's very
>> hard to make the case that tests like this one are anything but
>> a waste of developer and buildfarm time. When they are also a
>> port
On Thu, Jan 17, 2019 at 01:04:44PM +, Magnus Hagander wrote:
> Remove references to Majordomo
>
> Lists are not handled by Majordomo anymore and haven't been for a while,
> so remove the reference and instead direct people to the list server.
Wouldn't it be better to also switch the reference
On Thu, 17 Jan 2019 at 19:15, Tatsuo Ishii wrote:
> > On Thu, 17 Jan 2019 at 18:03, Tatsuo Ishii wrote:
> >
> >> > On Wed, 16 Jan 2019 at 01:02, Tatsuo Ishii
> wrote:
> >> >
> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> >> >> >> But pg_is_in_recovery() returns true even for a promo
On Thu, 17 Jan 2019 at 19:09, Tsunakawa, Takayuki <
tsunakawa.ta...@jp.fujitsu.com> wrote:
> From: Dave Cramer [mailto:p...@fastcrypt.com]
> > >> 2) If there's no node on which pg_is_in_recovery() returns
> false,
> > then
> > >>we need to retry until we find it. To not retry forev
>> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
>> >> >> >> But pg_is_in_recovery() returns true even for a promoting
>> standby. So
>> >> >> >> you have to wait and retry to send pg_is_in_recovery() until it
>> >> >> >> finishes the promotion to find out it is now a primary. I am not
>>
On Thu, 17 Jan 2019 at 19:38, Tatsuo Ishii wrote:
> >> >> >> > From: Tatsuo Ishii [mailto:is...@sraoss.co.jp]
> >> >> >> >> But pg_is_in_recovery() returns true even for a promoting
> >> standby. So
> >> >> >> >> you have to wait and retry to send pg_is_in_recovery() until it
> >> >> >> >> finish
Peter Geoghegan writes:
> On Thu, Jan 17, 2019 at 12:42 PM Tom Lane wrote:
>> Now, perhaps we should make such stability a design goal, as it'd allow
>> us to get rid of some "suppress the cascade outputs" hacks in the
>> regression tests. But it's a bit of a new feature. If we wanted to
>> do
On Thu, Jan 17, 2019 at 07:21:08PM -0500, Tom Lane wrote:
> Sorry, I don't buy this line of argument. Reasonable test design requires
> making cost/benefit tradeoffs: the cost to run the test over and over,
> and the cost to maintain the test itself (e.g. fix portability issues in
> it) have to be
>> > I'm curious; under what circumstances would the above occur?
>>
>> Former primary goes down and one of standbys is promoting but it is
>> not promoted to new primary yet.
>>
>
> seems like JDBC might have some work to do...Thanks
>
> I'm going to wait to implement until we resolve this discu
On Thu, 17 Jan 2019 at 19:56, Tatsuo Ishii wrote:
> >> > I'm curious; under what circumstances would the above occur?
> >>
> >> Former primary goes down and one of standbys is promoting but it is
> >> not promoted to new primary yet.
> >>
> >
> > seems like JDBC might have some work to do...Thank
On Thu, Jan 17, 2019 at 4:40 PM Tom Lane wrote:
> Yeah, that's the policy we've followed so far, but I remain concerned
> about its effects on the regression tests. There are a lot of places
> where we print full DROP CASCADE output because "it hasn't failed yet".
> I fear every one of those is a
On Thu, Jan 17, 2019 at 5:09 PM Peter Geoghegan wrote:
> In the kludgey patch that I posted, the 4-byte value is manufactured
> artificially within a backend in descending order. That may have a
> slight advantage over object oid, even after the pg_depend correctness
> issues are addressed. A fixe
On Tue, Jan 15, 2019 at 6:00 PM Masahiko Sawada
wrote:
>
> Rebased.
>
I started reviewing the patch, I didn't finish my review yet.
Following are some of the comments.
+PARALLEL N
+
+
+ Execute index vacuum and cleanup index in parallel with
I doubt that user can understand t
Hi!
On Thu, Jan 17, 2019 at 9:53 AM Andreas Karlsson wrote:
> > What is the stumbling block to just leaving that alone?
>
> I think the issue Mitar ran into is that the temporary materialized view
> is created in the rStartup callback of the receiver which happens after
> SECURITY_RESTRICTED_OPER
Hi!
On Thu, Jan 17, 2019 at 2:40 PM Andreas Karlsson wrote:
> I did some functional testing today and everything seems to work as
> expected other than that the tab completion for psql seems to be missing.
Thanks. I can add those as soon as I figure how. :-)
So what are next steps here besides
Hi all,
While working on the recent issues with 2PC and temporary objects I
have added a test case based on current_schema() for the first time in
history, and the buildfarm complained about it, as mentioned here:
https://www.postgresql.org/message-id/20190118005949.gd1...@paquier.xyz
The has bee
From: Laurenz Albe [mailto:laurenz.a...@cybertec.at]
> I think that transaction_read_only is good.
>
> If it is set to false, we are sure to be on a replication primary or
> stand-alone server, which is enough to know for the load balancing use case.
As Tatsuo-san said, setting default_transactio
Hi,
Attached small patch fixes the function name heap_vacuum_rel in the comment.
s/vacuum_heap_rel/heap_vacuum_rel/
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_heap_vacuum_rel.patch
Description: Binary data
I've found that a couple of different OpenBSD 6.4 machines fall over
badly in the ecpg regression tests, with output like
test sql/parser ... ok
test thread/thread... stdout stderr FAILED (test process was
terminated by signal 6: Abort trap)
test thread/thread_im
On Thu, Jan 17, 2019 at 5:49 AM Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > * Michael Paquier (mich...@paquier.xyz) wrote:
> > >> On Tue, Jan 15, 2019 at 10:53:30AM -0500, Tom Lane wrote:
> > >>> On reflection, maybe the problem is
On Fri, 18 Jan 2019 at 01:15, Surafel Temesgen wrote:
> The attache patch use your method mostly
I disagree with the "mostly" part. As far as I can see, you took the
idea and then made a series of changes to completely break it. For
bonus points, you put back my comment change to make it incorr
Hi all,
I am a bit stuck and I think it's best to try to explain where.
I'm still rebasing the patches for the changes Tom made to support
parameterised TID paths for joins. While the addition of join support
itself does not really touch the same code, the modernisation -- in
particular, returni
This one builds ok on appveyor with at least three different VS
versions. Though I've not tried the exact combination of commands
used by cfbot... yet.
--
Andrew (irc:RhodiumToad)
diff --git a/configure b/configure
index 06fc3c6835..e3176e24e9 100755
--- a/configure
+++ b/configure
@@ -15802,6 +
On Wed, 16 Jan 2019 at 17:45, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> Hi,
>
> During the discussion in [1] an idea about refactoring ArchiveEntry was
> suggested. The reason is that currently this function has significant number
> of
> arguments that are "optional", and every change that
On Tue, 15 Jan 2019 at 17:58, Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Jan 15, 2019 at 10:52 AM Amit Khandekar
> > wrote:
> >
> > Need to bump K_VERS_MINOR as well.
>
> I've bumped it up, but somehow this change escaped the previous version. Now
> should be there, thanks!
>
> >
On Fri, Jan 18, 2019 at 12:50:15PM +0900, Masahiko Sawada wrote:
> Attached small patch fixes the function name heap_vacuum_rel in the comment.
>
> s/vacuum_heap_rel/heap_vacuum_rel/
Fixed, thanks.
--
Michael
signature.asc
Description: PGP signature
On Thu, Jan 17, 2019 at 5:15 AM Surafel Temesgen wrote:
> On Fri, Jan 4, 2019 at 3:08 PM David Rowley
> wrote:
>>
>> On Mon, 31 Dec 2018 at 18:58, Surafel Temesgen wrote:
>>
>>
>> 2. Is --insert-multi a good name? What if they do --insert-multi=1?
>> That's not very "multi". Is --rows-per-inse
Imai-san,
From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
> On 2019/01/09 11:08, Imai, Yoshikazu wrote:
> > I wonder why force_custom_plan is faster than auto after applied the patch.
> >
> > When we use PREPARE-EXECUTE, a generic plan is created and used if its
> cost is
> > cheaper tha
On 2019/01/18 7:54, Alvaro Herrera wrote:
> On 2019-Jan-09, Amit Langote wrote:
>
>> 1. Foreign keys of partitions stop working correctly after being detached
>> from the parent table
>
>> This happens because the action triggers defined on the PK relation (pk)
>> refers to p as the referencing r
Tsunakawa-san,
On 2019/01/18 14:12, Tsunakawa, Takayuki wrote:
> From: Amit Langote [mailto:langote_amit...@lab.ntt.co.jp]
>> Are you saying that, when using auto mode, all executions of the query
>> starting from 7th are slower than the first 5 executions? That is, the
>> latency of creating and
1 - 100 of 112 matches
Mail list logo
