On 28 December 2017 at 01:45, Jeff Janes wrote:
> If we stored just a few more values, their inclusion in the MCV would mean
> they are depleted from the residual count, correctly lowering the estimate
> we would get for very rare values not included in the sample.
I agree with this thought.
>
(2018/01/18 15:40), Etsuro Fujita wrote:
(2018/01/18 7:09), Robert Haas wrote:
On Wed, Jan 17, 2018 at 4:08 PM, Tom Lane wrote:
It's debatable perhaps -- I tend to err in the other direction.
But likewise, I don't care deeply. Just push it ...
Done.
I noticed that this test case added by th
On 19 January 2018 at 05:38, Masahiko Sawada wrote:
> Hi,
>
> Attached patch for fixing a typo in slotfuncs.c
>
> s/possition/position/
Fixed, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Jan 18, 2018 at 06:54:18PM +0900, Amit Langote wrote:
> I think having pg_partition_root() and pg_partition_parent() will give
> users enough to get useful views as follows:
So... pg_partition_root() gives you access to the highest relation in
the hierarchy, and pg_partition_parent() gives
Hi,
Attached patch for fixing a typo in slotfuncs.c
s/possition/position/
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
fix_typo_in_slotfuncs_c.patch
Description: Binary data
On Tue, Jan 16, 2018 at 09:55:16AM -0500, Peter Eisentraut wrote:
> Here you go. Those changes actually meant that genbki.pl doesn't need
> to be touched by this patch at all, so that's a small win.
Thanks for the updated version. I have spent some time looking at what
you are proposing here.
In
Thank you Horiguchi-san!
On 2018/01/19 12:00, Kyotaro HORIGUCHI wrote:
> At Thu, 18 Jan 2018 11:41:00 -0800, Andres Freund wrote:
>> Hi Amit,
>>
>> It seems your mail system continually adds "[Sender Address Forgery]"
>> prefixes to messages. E.g. this mail now has
>> Subject: Re: [Sender Address
Hello,
At Thu, 18 Jan 2018 11:41:00 -0800, Andres Freund wrote in
<20180118194100.dy3kxdtktsbvm...@alap3.anarazel.de>
> Hi Amit,
>
> It seems your mail system continually adds "[Sender Address Forgery]"
> prefixes to messages. E.g. this mail now has
> Subject: Re: [Sender Address Forgery]Re: [S
Hello,
Thank you for the complrehensive explanation, Michael.
I happened to see another instance of this failure on one of our
client site. The precise steps lead to the situation is not
available but it is reported that it had occurred without
immediate shutdown. As far as I know just starting t
On Thu, Jan 18, 2018 at 9:22 AM, Robert Haas wrote:
> I just went back to the thread on "parallel.c oblivion of
> worker-startup failures" and refreshed my memory about what's going on
> over there. What's going on over there is (1) currently,
> nworkers_launched can be over-reported in a scenari
On Thu, Jan 18, 2018 at 03:58:31PM -0800, Ashwin Agrawal wrote:
> src/tools/make_etags creates link to TAGS file from each and every
> directory in source tree. It works fine without all those links in each and
> every directory in source code so remove the extra work and annoyance.
>
> diff --git
Hello.
At Fri, 19 Jan 2018 01:16:56 +0300, Alexander Korotkov
wrote in
> On Thu, Jan 18, 2018 at 8:48 AM, Kyotaro HORIGUCHI <
> horiguchi.kyot...@lab.ntt.co.jp> wrote:
> > Index only scan is not usable in the case since the first index
> > column cannot be rechecked but check_index_only makes
On Thu, Jan 18, 2018 at 02:04:45PM +, Ryan Murphy wrote:
> I had not tried this before with my unpatched build of postgres. (In
> retrospect of course I should have). I expected my superuser to be
> able to perform this task, but it seems that for security reasons we
> presently don't allow a
On Fri, Jan 19, 2018 at 10:35 AM, Tom Lane wrote:
> I wrote:
> > What I think we should do for the time being is to have pg_dump treat
> > database tablespace as a property it can't adjust after creation, just
> > as it can't adjust locale or encoding. That's a loss of functionality
> > for pg_d
src/tools/make_etags creates link to TAGS file from each and every
directory in source tree. It works fine without all those links in each and
every directory in source code so remove the extra work and annoyance.
diff --git a/src/tools/make_etags b/src/tools/make_etags
index 3ce96bc3ca..2bfd1314f
Robert Haas writes:
> On Wed, Jan 17, 2018 at 3:50 PM, Nikolay Shaplov wrote:
>> This patch raises error if user tries o set or change toast.* option for a
>> table that does not have a TOST relation.
> I think there is a problem with this idea, which is that the rules for
> whether or not a giv
I wrote:
> What I think we should do for the time being is to have pg_dump treat
> database tablespace as a property it can't adjust after creation, just
> as it can't adjust locale or encoding. That's a loss of functionality
> for pg_dumpall/pg_upgrade compared to where we are today, in that if
>
... okay, so the reason why --set-db-properties isn't as general-purpose
a switch as you might think finally penetrated my thick skull :-(
The problem is that, as the patch is currently constituted, that will
result in emitting a lot of "ALTER DATABASE foo" type commands. If
somebody tries to loa
Here is a rebase, plus some more changes:
I have improved the error message to tell from where the value was provided.
I have removed the test to the exact values produced from the expression test
run.
I have added a test which run from the same seed value several times
and checks that the
On Thu, Jan 18, 2018 at 8:48 AM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> At Wed, 17 Jan 2018 22:26:15 +0300, Sergei Kornilov
> wrote in <412861516217...@web38o.yandex.ru>
> > Hello
> > I can reproduce on actual 9.6.6, 10.1 and fresh master build
> > (9c7d06d60680c7f00d931233
Robert Haas writes:
> On Wed, Jan 17, 2018 at 6:50 PM, Tom Lane wrote:
>> * As the patch stands, --set-db-properties is implicit when you specify
>> -C, and in fact the patch goes to the trouble of throwing an error if you
>> try to specify both switches. I'm inclined to think this might be a ba
Here's a patch to add pg_dump tests. This verifies that the
CREATE INDEX on parent and partition appear, as well as ALTER INDEX ..
ATTACH PARTITION.
While doing this, I noticed a small bug: the ALTER INDEX would not be
dumped when only one of the schemas are specified to pg_dump (schema of
parent
On Wed, Jan 17, 2018 at 6:50 PM, Tom Lane wrote:
> * As the patch stands, --set-db-properties is implicit when you specify
> -C, and in fact the patch goes to the trouble of throwing an error if you
> try to specify both switches. I'm inclined to think this might be a bad
> idea. What about sayi
On Wed, Jan 17, 2018 at 3:50 PM, Nikolay Shaplov wrote:
> This patch raises error if user tries o set or change toast.* option for a
> table that does not have a TOST relation.
>
> I believe it is the only right thing to do, as now if you set toast reloption
> for table that does not have TOAST t
>
>
> >
> > But other situations seem un-handle-able to me:
> >
> > SELECT remote_func1(l.x) FROM local_table l WHERE l.active = true;
>
> Do we have any way, or any plan to make a way, to push the set (SELECT
> x FROM local_table WHERE active = true) to the remote side for
> execution there? Obvi
Hi,
On 2018-01-18 20:58:27 +0900, Michael Paquier wrote:
> On Wed, Jan 17, 2018 at 07:38:32AM -0500, Stephen Frost wrote:
> > Thanks for looking at this patch previously. This patch is still in
> > Needs Review but it's not clear if that's correct or not, but this seems
> > to be a bug-fix, so it
Hi Amit,
It seems your mail system continually adds "[Sender Address Forgery]"
prefixes to messages. E.g. this mail now has
Subject: Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [Sender
Address Forgery]Re: [HACKERS] path toward faster partition pruning
as its subject, whereas the m
On Thu, Jan 18, 2018 at 10:17 AM, Robert Haas wrote:
>> Should I go ahead and restore builds on catalogs, and remove those
>> comments, on the assumption that your patch will be committed before
>> mine? Obviously parallel index builds on catalogs don't matter. OTOH,
>> why not? Perhaps it's like
Stephen Frost wrote:
> Greetings!
>
> I've gone through and cleaned up our GSoC 2018 Wiki page:
>
> https://wiki.postgresql.org/wiki/GSoC_2018
>
> Please review! If you have any last-minute items, please add them!
>
> We could use some more mentors!
I'm staying away this time. Last year I add
On Thu, Jan 18, 2018 at 10:27 AM, Robert Haas wrote:
> On Thu, Jan 18, 2018 at 1:14 PM, Peter Geoghegan wrote:
>> That seems pretty far fetched.
>
> I don't think it is, and there are plenty of other examples. All you
> need is a query plan that involves significant CPU work both below the
> Gat
On Thu, Jan 18, 2018 at 6:14 AM, Amit Kapila wrote:
> I see your point. OTOH, I think we should have something for testing
> purpose as that helps in catching the bugs and makes it easy to write
> tests that cover worker part of the code.
This is about the question of whether or not we want to a
Robert Haas writes:
> Anyway, that's really an academic debate. My real point is: I do not
> think we should reject out of hand the idea that a patch introducing
> some new notation to deal with this might be acceptable. I am not
> volunteering to write such a patch, and anyone who tries should
On Thu, Jan 18, 2018 at 1:14 PM, Peter Geoghegan wrote:
> That seems pretty far fetched.
I don't think it is, and there are plenty of other examples. All you
need is a query plan that involves significant CPU work both below the
Gather node and above the Gather node. It's not difficult to find
On Thu, Jan 18, 2018 at 1:03 PM, Tom Lane wrote:
> Sure. Part of the equation here is that (IMO anyway) int128 isn't
> sufficiently performance-critical to us to justify putting enormous
> amounts of work into trying to make it go on non-mainstream platforms.
> It's possible that that could chang
On Wed, Jan 17, 2018 at 10:22 PM, Peter Geoghegan wrote:
> If you think it's worth the cycles, then I have no objection. I will
> point out that this means that everything that I say about
> ReindexIsProcessingIndex() no longer applies, because the relevant
> state will now be propagated. It doesn
On Thu, Jan 18, 2018 at 6:21 AM, Robert Haas wrote:
> Amit's reply to this part drew my attention to it. I think this is
> entirely false. Consider an aggregate that doesn't support partial
> aggregation, and a plan that looks like this:
>
> Aggregate
> -> Gather
> -> Parallel Seq Scan
> F
Robert Haas writes:
> On Thu, Jan 18, 2018 at 12:24 PM, Tom Lane wrote:
>> Really, this is something that the compiler ought to do for us, IMO.
>> If the gcc guys don't want to be bothered, OK, but that tells you more
>> about the priority they place on SPARC support than anything else.
> Of cou
On 18-01-2018 20:34, Tom Lane wrote:
I wrote:
...
But ... let's not panic, but wait and see the final result of the
discussion on the gcc PR. Jakub at least seems to think it ought
to be a supportable case.
What you could do in the meantime is work on finding a variation of
Victor's test that w
On Thu, Jan 18, 2018 at 12:24 PM, Tom Lane wrote:
> Marina Polyakova writes:
>> On 18-01-2018 19:53, Tom Lane wrote:
>>> So basically, we're outta luck and we have to consider __int128 as
>>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>>> $host_cpu. At least that means
On 18-01-2018 20:24, Tom Lane wrote:
Marina Polyakova writes:
On 18-01-2018 19:53, Tom Lane wrote:
So basically, we're outta luck and we have to consider __int128 as
unsupportable on SPARC. I'm inclined to mechanize that as a test on
$host_cpu. At least that means we don't need an AC_RUN tes
Peter Eisentraut writes:
> So I'm proposing the attached alternative patch, which creates
> constraint triggers to be TRIGGER_FIRES_ALWAYS by default.
> Thoughts?
Hm, the general idea seems attractive, but I'm not sure we want
this behavioral change for user-created triggers. Can we make it
happ
I wrote:
> Marina Polyakova writes:
>> On 18-01-2018 19:53, Tom Lane wrote:
>>> So basically, we're outta luck and we have to consider __int128 as
>>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
>> %-))
Marina Polyakova writes:
> On 18-01-2018 19:53, Tom Lane wrote:
>> So basically, we're outta luck and we have to consider __int128 as
>> unsupportable on SPARC. I'm inclined to mechanize that as a test on
>> $host_cpu. At least that means we don't need an AC_RUN test ;-)
> %-)) :-)
> Can I do s
On Thu, Jan 18, 2018 at 5:49 AM, Thomas Munro
wrote:
> I'm mostly away from my computer this week -- sorry about that,
Yeah, seriously. Since when it is OK for hackers to ever be away from
their computers? :-)
> The idea I mentioned would only work if nworkers_launched is never
> over-reported
Greetings,
* Atri Sharma (atri.j...@gmail.com) wrote:
> I can help with the Sorting project.
Great! I've added you as a mentor.
Thanks!
Stephen
signature.asc
Description: PGP signature
On 12/29/17 07:01, Marco Nenciarini wrote:
> The current behavior of session_replication_role = replica with TRUNCATE
> is not the same of with the other commands.
> It does not check FKs for INSERT/UPDATE/DELETE but it does for TRUNCATE,
> so one cannot execute TRUNCATE on a table when it is possi
I can help with the Sorting project.
On Thu, Jan 18, 2018 at 10:29 PM, Stephen Frost wrote:
> Greetings!
>
> I've gone through and cleaned up our GSoC 2018 Wiki page:
>
> https://wiki.postgresql.org/wiki/GSoC_2018
>
> Please review! If you have any last-minute items, please add them!
>
> We coul
On 18-01-2018 19:53, Tom Lane wrote:
Marina Polyakova writes:
On 18-01-2018 17:56, Tom Lane wrote:
Weird. Maybe the gcc bug only manifests with certain optimization
flags? That's not what I'd have expected from Victor's theory about
why the code is wrong, but if it only shows up some of the
Greetings!
I've gone through and cleaned up our GSoC 2018 Wiki page:
https://wiki.postgresql.org/wiki/GSoC_2018
Please review! If you have any last-minute items, please add them!
We could use some more mentors! If you would have some time over the
summer to help with mentoring a GSoC project
Marina Polyakova writes:
> On 18-01-2018 17:56, Tom Lane wrote:
>> Weird. Maybe the gcc bug only manifests with certain optimization
>> flags? That's not what I'd have expected from Victor's theory about
>> why the code is wrong, but if it only shows up some of the time,
>> it's hard to think of
On 17 January 2018 at 17:07, Petr Jelinek wrote:
> Things I am less convinced about:
>
> The patch will cascade truncation on downstream if cascade was specified
> on the upstream, that can potentially be dangerous and we either should
> not do it and only truncate the tables which were truncated
On 31 December 2017 at 11:06, Peter Geoghegan wrote:
> On Sun, Dec 31, 2017 at 6:44 AM, Pavan Deolasee
> wrote:
>> Here is a patch that implements the idea. If the last insert happens to be
>> in the rightmost block of an index, then we cache the block and check that
>> first for the next insert.
On 14 January 2018 at 23:15, Petr Jelinek wrote:
> Updated version attached.
Applied, thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 18-01-2018 17:56, Tom Lane wrote:
Marina Polyakova writes:
Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
and using the configuration command from [1], I got:
checking for __int128... yes
checking for __int128 alignment bug... broken
...
And make check-world passes. V
On 01/12/2018 06:59 AM, Edmund Horner wrote:
> Hi, here's a new patch.
Thanks, and sorry for the delay. I have reviewed this patch, but
haven't had time to put my thoughts together in a coherent message yet.
I will be able to do that tomorrow.
Thank you for your patience.
--
Vik Fearing
On 01/18/2018 01:07 AM, Tom Lane wrote:
> Edmund Horner writes:
>> On 15 January 2018 at 15:45, Andres Freund wrote:
>>> All worries like this are supposed to check the server version.
>
>> In psql there are around 200 such tab completion queries, none of
>> which checks the server version. Man
On 1/17/18 11:33, Petr Jelinek wrote:
>> P.S: I'm struggling to understand why we have two possible values of
>> session_replication_role settings that behave identically (origin and
>> local). I'm unable to see any difference according to the code or the
>> documentation, so I'm wondering if we sh
Tom Lane wrote:
> Antonin Houska writes:
> > Tom Lane wrote:
> >> At one time, I think, readLen told how much data in readBuf was
> >> actually valid. It seems not to be used for that anymore, but
> >> I don't much like the idea that readBuf is only partially filled
> >> but there is *no* pers
Michael Paquier wrote:
> On Thu, Apr 9, 2015 at 7:05 PM, Antonin Houska wrote:
> > While playing with xlogreader, I was lucky enough to see one of the many
> > record validations to fail. After having some fun with gdb, I found out that
> > in some cases the reader does not enforce enough data t
On Thu, Dec 21, 2017 at 9:13 AM, Amit Kapila wrote:
> I am not against using the way specific to parallel context layer as
> described by you above. However, I was trying to see if there is
> some general purpose solution as the low-impact way is not very
> straightforward. I think you can go a
Victor Wagner writes:
> It seems that I've made some unreproducible mistake last night
> applying your patch. Marina repeapplied it later and everything works.
Ah, thanks for following up. I'll adjust the comment to include the
gcc PR and push it shortly.
regards, tom
On Thu, 18 Jan 2018 09:56:48 -0500
Tom Lane wrote:
> Marina Polyakova writes:
> > Applying your patch on commit
> > f033462d8f77c40b7d6b33c5116e50118fb4699d and using the
> > configuration command from [1], I got: checking for __int128... yes
> > checking for __int128 alignment bug... broken
> >
On 18 January 2018 at 23:56, Amit Langote wrote:
>> I've not fully worked out how run-time pruning
>> will use this as it'll need another version of
>> get_partitions_from_clauses but passes in a PartScanClauseInfo
>> instead, and does not call extract_partition_key_clauses. That area
>> probably
Hi Konstantin,
On 01/18/2018 03:48 PM, Konstantin Knizhnik wrote:
> On 17.01.2018 19:09, Konstantin Knizhnik wrote:
>> Hi hackers,
>>
>> ...
>
I haven't looked at the code yet, but after reading your message I have
a simple question - gow iss this going to work with SSL? If you're only
passing a
> 0001:
>
> - You removed the check of parallelity check of
> line_interpt_line(old line_interpt_internal) but line_parallel
> is not changed so the consistency between the two functions are
> lost. It is better to be another patch file (maybe 0004?).
I am making line_parallel() use line_int
On Thu, Jan 18, 2018 at 11:48 AM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
> Attached please find new version of the patch with few fixes.
> And more results at NUMA system with 144 cores and 3Tb of RAM.
>
> Read-only pgbench (-S):
>
>
> #Connections\kTPS
> Vanilla Postgres
> Sess
Marina Polyakova writes:
> Applying your patch on commit f033462d8f77c40b7d6b33c5116e50118fb4699d
> and using the configuration command from [1], I got:
> checking for __int128... yes
> checking for __int128 alignment bug... broken
> ...
> And make check-world passes. Victor said that he used a m
On Thu, 18 Jan 2018 01:47:46 -0500
Tom Lane wrote:
> Victor Wagner writes:
> > Tom Lane wrote:
> > checking for __int128 alignment bug... ok
> > As far as I understand your patch, there should be:
> > checking for __int128 alignment bug... broken
>
> Yes, that's what I expected to happen.
On 17.01.2018 19:09, Konstantin Knizhnik wrote:
Hi hackers,
My recent experiments with pthread version of Postgres show that
although pthread offers some performance advantages comparing with
processes for large number of connections, them still can not
eliminate need in connection pooling. L
On 17-01-2018 18:50, Marina Polyakova wrote:
On 17-01-2018 18:28, Tom Lane wrote:
BTW, now that you've demonstrated that the bug exists in a current
gcc release, you should definitely file a bug at
https://gcc.gnu.org/bugzilla/
I think you can just give them int128test2.c as-is as a test case.
Hi!
> 18 янв. 2018 г., в 18:57, Anastasia Lubennikova
> написал(а):
>
> What is amcheck_next ?
amcheck_next is external version of amcheck, maintained by Peter G. on his
github. It checks one more thing: that every heap tuple has twin in B-tree, so
called heapallindexed check.
Version V3 of yo
On Wed, Jan 17, 2018 at 10:22 PM, Peter Geoghegan wrote:
> As I said in a prior e-mail, even parallel query's use of
> parallel_leader_participation is consistent with what I propose here,
> practically speaking, because a partial path without leader
> participation will always lose to a serial se
On Thu, Jan 18, 2018 at 8:52 AM, Peter Geoghegan wrote:
> On Wed, Jan 17, 2018 at 10:40 AM, Robert Haas wrote:
>
>>> (It might make sense to allow this if parallel_leader_participation
>>> was *purely* a testing GUC, only for use by by backend hackers, but
>>> AFAICT it isn't.)
>>
>> As applied t
Just circling back on this.
I did have a question that came up about the behavior of the server as it is
without the patch. I logged into psql with my superuser "postgres":
postgres=# select pg_read_file('/Users/postgres/temp');
ERROR: absolute path not allowed
I had not tried this be
On Wed, Jan 17, 2018 at 1:18 AM, Robert Haas wrote:
> On Tue, Jan 16, 2018 at 3:56 AM, Jeevan Chalke
> wrote:
> > I will make your suggested changes that is merge create_sort_agg_path()
> and
> > create_hash_agg_path(). Will name that function as
> > create_sort_and_hash_agg_paths().
>
> I sugge
On Thu, Jan 18, 2018 at 03:27:43PM +0300, Anna Akenteva wrote:
> Would it be possible to fix it the same way in REL9_6_STABLE and maybe other
> older versions too?
Yes, this was part of an investigation that led to 052cc223 to improve
OOM handling, which involved way more code paths than just this
On 1/12/18 23:19, Tomas Vondra wrote:
> Wouldn't the 'toplevel_by_lsn' be suitable for this? Subtransactions
> don't really commit independently, but as part of the toplevel xact. And
> that list is ordered by LSN, which is pretty much exactly the order in
> which we see the transactions.
Yes inde
On Thu, Jan 18, 2018 at 4:19 PM, Thomas Munro
wrote:
> Hi,
>
> I'm mostly away from my computer this week -- sorry about that, but
> here are a couple of quick answers to questions directed at me:
>
> On Thu, Jan 18, 2018 at 4:22 PM, Peter Geoghegan wrote:
>> On Wed, Jan 17, 2018 at 10:40 AM, Rob
After checking some code from REL9_6_STABLE with a static analyzer, I've
found this bit:
src/common/exec.c:586 putenv(strdup(env_path));
...
src/common/exec.c:597 putenv(strdup(env_path));
Theoretically, strdup might return NULL, and we'll send NULL as an
argument to putenv
Hello,
I played more around geometric types and recalled that geometric
types don't have orderings. Also have corrected some other
misunderstanding. Sorry for my confusion and I think I returned
on the way.
At Wed, 17 Jan 2018 18:59:30 +0100, Emre Hasegeli wrote in
> > I'm not sure what you me
Hello.
At Thu, 18 Jan 2018 17:25:05 +0900, Michael Paquier
wrote in <20180118082505.ga84...@paquier.xyz>
> On Thu, Jan 18, 2018 at 12:57:38PM +0500, Andrey Borodin wrote:
> >> Please find the attached patch.
> > I agree with you that current behavior is a bug and your patch seems
> > correct.
>
On Wed, Jan 17, 2018 at 07:38:32AM -0500, Stephen Frost wrote:
> Thanks for looking at this patch previously. This patch is still in
> Needs Review but it's not clear if that's correct or not, but this seems
> to be a bug-fix, so it would be great if we could make some progress on
> it (particular
On Sat, Jan 13, 2018 at 2:16 PM, Tom Lane wrote:
> I wrote:
>> Haribabu Kommi writes:
>>> I checked the latest patch and it is working fine and I don't have any
>>> further comments. Marked the patch as "ready for committer".
>
>> I started to look at this patch,
Thanks!
> ... looking further,
On Wed, Jan 17, 2018 at 05:47:16PM +0200, Graham Leggett wrote:
> I need to test whether a database is empty, in other words “createdb”
> has been executed but no data of any kind appears in that database.
> What is the correct postgresql way to do this?
There is none, because it highly depends on
Hi,
I'm mostly away from my computer this week -- sorry about that, but
here are a couple of quick answers to questions directed at me:
On Thu, Jan 18, 2018 at 4:22 PM, Peter Geoghegan wrote:
> On Wed, Jan 17, 2018 at 10:40 AM, Robert Haas wrote:
>>> While it certainly did occur to me that that
Hello Tom,
From my previous answer, to motivate these tests:
The compromise I'm proposing is to skip time-related stuff if too slow. The
value I see is that it provides coverage for all time-related features. I can
also add a check that the run is *at least* 2 seconds when two seconds are
At Thu, 18 Jan 2018 12:57:38 +0500, Andrey Borodin wrote
in <62c2b9a0-51bc-40ff-9bca-f203784cb...@yandex-team.ru>
> Hello!
> > 18 янв. 2018 г., в 10:48, Kyotaro HORIGUCHI
> > написал(а):
> >
> > Gist imposes the ninth strategy to perform index only scan but
> > planner is not considering that
On 18 January 2018 at 08:59, Konstantin Knizhnik
wrote:
>
>
> On 18.01.2018 11:38, Simon Riggs wrote:
>>
>> On 10 January 2018 at 09:54, Konstantin Knizhnik
>> wrote:
>>
>>> Sorry, issue with documentation is fixed.
>>
>> OK, thanks.
>>
>> Patch appears to work cleanly now.
>>
>> I'm wondering no
On 2018/01/02 22:45, Peter Eisentraut wrote:
> On 12/28/17 16:24, David Rowley wrote:
>>> select pg_partition_root(c.oid), c.relname, pg_table_size(c.oid)
>>> from pg_class c
>>> order by 1
>>>
>>> select pg_partition_root(c.oid), sum(pg_table_size(c.oid))
>>> from pg_class c
>>> group by 1
Thank you!
On 17-01-2018 19:33, Tom Lane wrote:
Attached is a draft patch to incorporate Victor's slimmed-down test
into configure. If you have a chance, could you confirm it does
the right thing on your Sparc machine?
Victor Wagner writes:
It seems that what it does is not exactly a right
On 2018/01/17 22:51, Peter Eisentraut wrote:
> I'm setting this patch to Returned with feedback.
OK. Sorry that I couldn't reply here since the CF started. I have
written some code to implement the pg_partition_root() idea you mentioned
upthread earlier this week, but hasn't been able to share i
Hello Ildar,
Patch v8 applies cleanly and compiles. Global and local "make check ok".
Doc build ok.
For me "random seed" is what is passed to srandom, so the variable
should rather be named hash_seed because there could also be a random
seed (actually, there is in another parallel patch:-). Mo
On 18.01.2018 11:38, Simon Riggs wrote:
On 10 January 2018 at 09:54, Konstantin Knizhnik
wrote:
Sorry, issue with documentation is fixed.
OK, thanks.
Patch appears to work cleanly now.
I'm wondering now about automatically inferring "recheck_on_update =
true" for certain common datatype/o
On 10 January 2018 at 09:54, Konstantin Knizhnik
wrote:
> Sorry, issue with documentation is fixed.
OK, thanks.
Patch appears to work cleanly now.
I'm wondering now about automatically inferring "recheck_on_update =
true" for certain common datatype/operators. It doesn't need to be an
exhausti
On Thu, Jan 18, 2018 at 12:57:38PM +0500, Andrey Borodin wrote:
>> 18 янв. 2018 г., в 10:48, Kyotaro HORIGUCHI
>> написал(а):
>>
>> Gist imposes the ninth strategy to perform index only scan but
>> planner is not considering that
>>
>> Please find the attached patch.
> I agree with you that
Hello everyone!
> 5 янв. 2018 г., в 1:36, Stephen Frost написал(а):
>
> * Stephen Frost (sfr...@snowman.net) wrote:
>> The deadline for Mentoring organizations to apply is: January 23.
>
> We currently only have four (4) projects for 2018 listed on our
> projects page here:
I've added project f
96 matches
Mail list logo
