Hi,
>From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com]
>Sent: Friday, April 26, 2019 11:50 PM
>Well, after developing PoC, I realized that this PoC doesn't solve the local
>process is
>crashed before the context becomes shared because local process keeps track of
>pointer to
On Wed, May 8, 2019 at 3:53 PM Tom Lane wrote:
> Thomas Munro writes:
> > Reproduced here. Once the system reaches a state where it's leaking
> > (which happens only occasionally for me during installcheck-parallel),
> > it keeps leaking for future SSI transactions. The cause is
> >
At Wed, 08 May 2019 13:06:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190508.130636.184826233.horiguchi.kyot...@lab.ntt.co.jp>
> At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
> wrote in
>
At Tue, 07 May 2019 20:47:28 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20190507.204728.233299873.horiguchi.kyot...@lab.ntt.co.jp>
> Hello.
>
> At Tue, 7 May 2019 14:39:55 +0530, Rajkumar Raghuwanshi
> wrote in
>
> > Hi,
> > As this issue is reproducible without
Thomas Munro writes:
> Reproduced here. Once the system reaches a state where it's leaking
> (which happens only occasionally for me during installcheck-parallel),
> it keeps leaking for future SSI transactions. The cause is
> SxactGlobalXmin getting stuck. The attached fixes it for me. I
(2019/02/25 19:59), Etsuro Fujita wrote:
(2019/02/22 23:10), Antonin Houska wrote:
Etsuro Fujita wrote:
As mentioned in the near thread, I think there is another oversight in
the cost estimation for aggregate pushdown paths in postgres_fdw, IIUC.
When costing an aggregate pushdown path using
On Wed, May 8, 2019 at 6:56 AM Thomas Munro wrote:
> On Wed, May 8, 2019 at 5:46 AM Tom Lane wrote:
> > I'd have to say that my first suspicion falls on bb16aba50 ...
>
> Investigating.
Reproduced here. Once the system reaches a state where it's leaking
(which happens only occasionally for me
On Mon, May 6, 2019 at 4:11 PM Peter Geoghegan wrote:
> I am tempted to move the call to _bt_truncate() out of _bt_split()
> entirely on HEAD, possibly relocating it to
> nbtsplitloc.c/_bt_findsplitloc(). That way, there is a clearer
> separation between how split points are chosen, suffix
On Tue, May 7, 2019 at 6:59 AM Tomas Vondra
wrote:
> On Tue, May 07, 2019 at 04:28:36PM +1200, Thomas Munro wrote:
> >On Tue, May 7, 2019 at 3:15 PM Tomas Vondra
> > wrote:
> >> On Tue, May 07, 2019 at 01:48:40PM +1200, Thomas Munro wrote:
> >> Switching to some other algorithm during execution
On Wed, May 8, 2019 at 2:41 AM Fujii Masao wrote:
>
> Hi,
>
> vacuumdb command supports the corresponding options to
> any VACUUM parameters except INDEX_CLEANUP and TRUNCATE
> that were added recently. Should vacuumdb also support those
> new parameters, i.e., add --index-cleanup and --truncate
On Mon, May 6, 2019 at 8:15 PM Tomas Vondra
wrote:
> Nope, that's not how it works. It's the array of batches that gets
> sliced, not the batches themselves.
>
> It does slightly increase the amount of data we need to shuffle between
> the temp files, because we can't write the data directly to
Donald Dong writes:
> I was expecting the plans generated by standard_join_search to have lower
> costs
> than the plans from GEQO. But after the results I have from a join order
> benchmark show that GEQO produces plans with lower costs most of the time!
> I wonder what is causing this
On Tue, May 07, 2019 at 06:45:36PM -0400, Tom Lane wrote:
> Yeah. CREATE INDEX CONCURRENTLY has always had a deadlock hazard,
> so it's hardly surprising that REINDEX CONCURRENTLY does too.
> I don't think that fixing that is in-scope for v12, even if we had
> an idea how to do it, which we
Hi,
I was expecting the plans generated by standard_join_search to have lower costs
than the plans from GEQO. But after the results I have from a join order
benchmark show that GEQO produces plans with lower costs most of the time!
I wonder what is causing this observation? From my
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm generally in favor of doing something like what Tom is suggesting
> > with VERBOSE, but I also feel like it should be the default for formats
> > like JSON. If you're asking for the output in JSON, then we really
Greetings,
* David Fetter (da...@fetter.org) wrote:
> On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > > One idea that comes to mind is that VERBOSE could be redefined as
> > > some sort of package of primitive options, including all of
Andres Freund writes:
> On 2019-05-07 12:25:43 +0900, Michael Paquier wrote:
>> Then session 2 deadlocks while session 3 finishes correctly. I don't
>> know if this is a class of problems we'd want to address for v12, but
>> if we do then CIC (and DROP INDEX CONCURRENTLY?) could benefit from
>>
On Tue, May 07, 2019 at 06:12:56PM -0400, Stephen Frost wrote:
> Greetings,
>
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >
> > One idea that comes to mind is that VERBOSE could be redefined as
> > some sort of package of primitive options, including all of the
> > "additional information"
Stephen Frost writes:
> I'm generally in favor of doing something like what Tom is suggesting
> with VERBOSE, but I also feel like it should be the default for formats
> like JSON. If you're asking for the output in JSON, then we really
> should include everything that a flag like VERBOSE would
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Andres Freund writes:
> > As I said, I don't think ALL is a good idea under any name. Like it
> > just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS,
> > SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's
> >
Andres Freund writes:
> As I said, I don't think ALL is a good idea under any name. Like it
> just makes no sense to have ANALYZE, SUMMARY, VERBOSE, BUFFERS,
> SETTINGS, FORMAT controlled by one option, unless you call it DWIM. It's
> several separate axis (query is executed or not (ANALYZE),
On Tue, May 7, 2019 at 5:35 PM Tom Lane wrote:
> Alexander Korotkov writes:
> > Attached patchset contains revised commit messages. I'm going to
> > commit this on no objections.
>
> Sorry for slow response --- I was tied up with release preparations.
>
> The -5 patches look pretty good. A
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > Having our test framework deny us useful features just strikes me as
> > bizarre.
>
> This is presuming that it's useful, which is debatable IMO.
> I think most people will find it useless noise almost all of the
Hi,
On 2019-05-07 23:23:55 +0200, David Fetter wrote:
> Would you agree that there's a problem here as I described as
> motivation for people who operate databases?
Yea, but I don't think the solution is where you seek it. I think the
problem is that our defaults for EXPLAIN, in particular
Stephen Frost writes:
> Having our test framework deny us useful features just strikes me as
> bizarre.
This is presuming that it's useful, which is debatable IMO.
I think most people will find it useless noise almost all of the time.
regards, tom lane
On Tue, May 7, 2019 at 9:31 AM David Fetter wrote:
> If you're tuning a query interactively, it's a lot simpler to prepend,
> for example,
>
> EXPLAIN (ALL, FORMAT JSON)
>
> to it than to prepend something along the lines of
>
> EXPLAIN(ANALYZE, VERBOSE, COSTS, BUFFERS, SETTINGS, TIMING,
I wrote:
> is_publishable_class has a test "relid >= FirstNormalObjectId",
> which I think we should drop, for two reasons:
> 1. It makes the comment claiming that this function tests the same
> things as check_publication_add_relation a lie.
> 2. The comment about it claims that the purpose is
On Tue, May 07, 2019 at 09:44:30AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 18:34:11 +0200, David Fetter wrote:
> > On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> > > On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > > > It can get a little tedious turning on (or
I wrote:
> After looking around a bit, I propose that we invent
> "IsCatalogRelationOid(Oid reloid)" (not wedded to that name), which
> is a wrapper around IsCatalogClass() that does the needful syscache
> lookup for you. Aside from this use-case, it could be used in
> sepgsql/dml.c, which I see
Greetings,
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 7, 2019 at 11:30 AM Stephen Frost wrote:
> > > Not unless you want to break every regression test that uses \d.
> > > Instability of the output is also a reason not to show the
> > > toast table's name in the parent's \d[+].
>
On Mon, May 6, 2019 at 1:56 PM Bruce Momjian wrote:
> Is there a reason pg_checksums is plural and not singular, i.e.,
> pg_checksum? I know it is being renamed for PG 12. It might have
> needed to be plural when it was pg_verify_checksums.
That is a good question, IMHO. I am not sure whether
On Tue, May 7, 2019 at 11:30 AM Stephen Frost wrote:
> > Not unless you want to break every regression test that uses \d.
> > Instability of the output is also a reason not to show the
> > toast table's name in the parent's \d[+].
>
> So we need a way to turn it off. That doesn't seem like it'd
Hi,
On 2016-04-06 12:57:16 +0200, Andres Freund wrote:
> While benchmarking on hydra
> (c.f.
> http://archives.postgresql.org/message-id/20160406104352.5bn3ehkcsceja65c%40alap3.anarazel.de),
> which has quite slow IO, I was once more annoyed by how incredibly long
> the vacuum at the the end of
Andrew Dunstan writes:
> On 5/7/19 1:46 PM, Tom Lane wrote:
>> After running the core regression tests with installcheck-parallel,
>> the pg_locks view sometimes shows me apparently-orphaned SIReadLock
>> entries. They accumulate over repeated test runs.
> Should we have a test for that run
On 5/7/19 1:46 PM, Tom Lane wrote:
> After running the core regression tests with installcheck-parallel,
> the pg_locks view sometimes shows me apparently-orphaned SIReadLock
> entries. They accumulate over repeated test runs.
Should we have a test for that run at/near the end of the
On Tue, May 07, 2019 at 09:46:07AM -0400, Tom Lane wrote:
Ian Barwick writes:
Commit cc8d4151 [*] introduced a dependency between some functions in
libpgcommon and libpgfeutils,
This seems rather seriously broken. I do not think the answer is to
create a global dependency on libpgfeutils.
is_publishable_class has a test "relid >= FirstNormalObjectId",
which I think we should drop, for two reasons:
1. It makes the comment claiming that this function tests the same
things as check_publication_add_relation a lie.
2. The comment about it claims that the purpose is to reject
On Wed, May 8, 2019 at 5:46 AM Tom Lane wrote:
> After running the core regression tests with installcheck-parallel,
> the pg_locks view sometimes shows me apparently-orphaned SIReadLock
> entries. [...]
Ugh.
> I'd have to say that my first suspicion falls on bb16aba50 ...
Investigating.
--
After running the core regression tests with installcheck-parallel,
the pg_locks view sometimes shows me apparently-orphaned SIReadLock
entries. They accumulate over repeated test runs. Right now,
for example, I see
regression=# select * from pg_locks;
locktype | database | relation | page |
Hi,
vacuumdb command supports the corresponding options to
any VACUUM parameters except INDEX_CLEANUP and TRUNCATE
that were added recently. Should vacuumdb also support those
new parameters, i.e., add --index-cleanup and --truncate options
to the command?
Regards,
--
Fujii Masao
On Tue, May 07, 2019 at 06:47:59PM +0200, David Fetter wrote:
> On Tue, May 07, 2019 at 09:39:57AM -0400, Andrew Dunstan wrote:
> >
> > On 5/6/19 10:42 PM, David Fetter wrote:
> > > On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
> > >> Hi.
> > >>
> > >> At Sun, 28 Apr 2019
On Mon, Apr 8, 2019 at 8:15 PM Julien Rouhaud wrote:
>
> On Mon, Apr 8, 2019 at 12:22 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 3:58 PM Julien
On Tue, May 7, 2019 at 5:33 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 7:29 PM Masahiko Sawada wrote:
> >
> > On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 5:15 PM
On Tue, May 7, 2019 at 12:27 AM Heikki Linnakangas wrote:
> I don't understand that reasoning. Yes, _bt_pagedel() will complain if
> it finds a half-dead internal page. But how does that mean that
> _bt_lock_branch_parent() can't encounter one?
I suppose that in theory it could, but only if you
On Tue, May 07, 2019 at 09:39:57AM -0400, Andrew Dunstan wrote:
>
> On 5/6/19 10:42 PM, David Fetter wrote:
> > On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
> >> Hi.
> >>
> >> At Sun, 28 Apr 2019 17:07:16 +0200, David Fetter wrote
> >> in
Hi,
On 2019-05-07 18:34:11 +0200, David Fetter wrote:
> On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> > On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > > It can get a little tedious turning on (or off) all the boolean
> > > options to EXPLAIN, so please find attached a
On Tue, May 07, 2019 at 08:41:47AM -0700, Andres Freund wrote:
> Hi,
>
> On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> > It can get a little tedious turning on (or off) all the boolean
> > options to EXPLAIN, so please find attached a shortcut.
>
> I'm not convinced this is a good idea -
On Tue, May 07, 2019 at 11:03:23AM +0200, Rafia Sabih wrote:
> On Tue, 7 May 2019 at 09:30, David Fetter wrote:
> >
> > Folks,
> >
> > It can get a little tedious turning on (or off) all the boolean
> > options to EXPLAIN, so please find attached a shortcut.
>
> I don't understand this, do you
On Tue, May 07, 2019 at 11:13:15AM +0300, Sergei Kornilov wrote:
> Hi
>
> I liked this idea.
>
> + timing_set = true;
> + es->timing = defGetBoolean(opt);
> + summary_set = true;
> + es->timing = defGetBoolean(opt);
On Tue, May 7, 2019 at 2:39 PM Daniel Gustafsson wrote:
> Spotted two minor typos when skimming through code, and a sentence on
> returnvalue which seemed a bit odd since executeJsonPath() can exit on
> ereport(). The attached diff fixes the typos and suggests a new wording.
>
Pushed. Thanks!
Hi,
On 2019-05-07 12:12:37 -0400, Tom Lane wrote:
> Why do you think there's no limit? We ordinarily do
> RelationGetNumberOfBlocks at least once per query on a table
Well, for the main fork. Which already could have shrunk below the size
that led the FSM to be created. And we only do
Hi,
On 2019-05-07 12:14:43 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-07 12:07:37 -0400, Tom Lane wrote:
> >> The number of deadlock failures is kind of annoying, so I'd rather remove
> >> the tests from HEAD sooner than later. What issues around that do you
> >> think remain
Andres Freund writes:
> On 2019-05-07 12:07:37 -0400, Tom Lane wrote:
>> The number of deadlock failures is kind of annoying, so I'd rather remove
>> the tests from HEAD sooner than later. What issues around that do you
>> think remain that these tests would be helpful for?
> I was wondering
Andres Freund writes:
> On 2019-05-07 12:04:11 -0400, Tom Lane wrote:
>> I do not think sinval messaging is going to be sufficient to avoid that
>> problem. sinval is only useful to tell you about changes if you first
>> take a lock strong enough to guarantee that no interesting change is
>>
Hi,
On 2019-05-07 12:07:37 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Yea, that might be right. I'm planning to leave the tests in until a
> > bunch of the open REINDEX issues are resolved. Not super likely that
> > it'd break something, but probably worth anyway?
>
> The number of
Andres Freund writes:
> Yea, that might be right. I'm planning to leave the tests in until a
> bunch of the open REINDEX issues are resolved. Not super likely that
> it'd break something, but probably worth anyway?
The number of deadlock failures is kind of annoying, so I'd rather remove
the
Hi,
On 2019-05-07 12:04:11 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2019-05-07 09:34:42 -0400, Tom Lane wrote:
> >> I'm inclined to wonder why bother with invals at all.
>
> > But when updating the free space for the first four blocks, we're going
> > to either have to do an
Hi,
On 2019-05-07 12:25:43 +0900, Michael Paquier wrote:
> On Tue, May 07, 2019 at 12:07:56PM +0900, Michael Paquier wrote:
> > Now, what do we do about the potential deadlock issues in
> > WaitForOlderSnapshots? The attached is an isolation test able to
> > reproduce the deadlock within
Andres Freund writes:
> On 2019-05-07 09:34:42 -0400, Tom Lane wrote:
>> I'm inclined to wonder why bother with invals at all.
> But when updating the free space for the first four blocks, we're going
> to either have to do an smgrexists() to check whether somebody
> concurrently created the
Hi,
On 2019-05-07 10:50:19 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I for sure thought I earlier had an idea that'd actually work. But
> > either I've lost it, or it didn't actually work. But perhaps somebody
> > else can come up with something based on the above strawman ideas?
>
>
Hi,
On 2019-05-07 09:34:42 -0400, Tom Lane wrote:
> I'm inclined to wonder why bother with invals at all. The odds are
> quite good that no other backend will care (which, I imagine, is the
> reasoning behind why the original patch was designed like it was).
> A table that has a lot of
Hi,
On 2019-05-07 09:30:47 +0200, David Fetter wrote:
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
I'm not convinced this is a good idea - it seems likely that we'll add
conflicting options at some point, and then
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Tom Lane (t...@sss.pgh.pa.us) wrote:
> >> Rafia Sabih writes:
> >>> IMHO, what makes more sense is to show the name of associated toast
> >>> table in the \dt+ of the normal table.
>
> >> I'm not for that: it's
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Rafia Sabih writes:
>>> IMHO, what makes more sense is to show the name of associated toast
>>> table in the \dt+ of the normal table.
>> I'm not for that: it's useless information in at least 99.44% of cases.
> I don't think
On Tue, May 07, 2019 at 10:42:36AM -0400, Tom Lane wrote:
Tomas Vondra writes:
On Mon, May 06, 2019 at 11:18:28PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Do we actually check how many duplicates are there during planning?
Certainly that's part of the planner's cost estimates ... but
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Rafia Sabih writes:
> > On Fri, 3 May 2019 at 16:27, Justin Pryzby wrote:
> >> Thanks - what about also showing the associated non-toast table ?
>
> > IMHO, what makes more sense is to show the name of associated toast
> > table in the \dt+
Andres Freund writes:
> I for sure thought I earlier had an idea that'd actually work. But
> either I've lost it, or it didn't actually work. But perhaps somebody
> else can come up with something based on the above strawman ideas?
Both of those ideas fail if an autovacuum starts up after you're
Tomas Vondra writes:
> On Mon, May 06, 2019 at 11:18:28PM -0400, Tom Lane wrote:
>> Tomas Vondra writes:
>>> Do we actually check how many duplicates are there during planning?
>> Certainly that's part of the planner's cost estimates ... but it's
>> only as good as the planner's statistical
Alexander Korotkov writes:
> Attached patchset contains revised commit messages. I'm going to
> commit this on no objections.
Sorry for slow response --- I was tied up with release preparations.
The -5 patches look pretty good. A couple of nits:
@@ -774,9 +749,7 @@
On Tue, May 07, 2019 at 04:28:36PM +1200, Thomas Munro wrote:
On Tue, May 7, 2019 at 3:15 PM Tomas Vondra
wrote:
On Tue, May 07, 2019 at 01:48:40PM +1200, Thomas Munro wrote:
>Seems expensive for large numbers of slices -- you need to join the
>outer batch against each inner slice.
Nope,
Ian Barwick writes:
> Commit cc8d4151 [*] introduced a dependency between some functions in
> libpgcommon and libpgfeutils,
This seems rather seriously broken. I do not think the answer is to
create a global dependency on libpgfeutils.
regards, tom lane
Amit Kapila writes:
> On Mon, May 6, 2019 at 8:57 PM Andres Freund wrote:
>> On 2019-05-06 11:10:15 -0400, Robert Haas wrote:
>>> I think it's legitimate to question whether sending additional
>>> invalidation messages as part of the design of this feature is a good
>>> idea.
>> I don't think
On 5/6/19 10:42 PM, David Fetter wrote:
> On Tue, May 07, 2019 at 11:05:32AM +0900, Kyotaro HORIGUCHI wrote:
>> Hi.
>>
>> At Sun, 28 Apr 2019 17:07:16 +0200, David Fetter wrote in
>> <20190428150716.gp28...@fetter.org>
>>> Our test coverage needs all the help it can get.
>>>
>>> This patch,
On Mon, May 06, 2019 at 11:18:28PM -0400, Tom Lane wrote:
Tomas Vondra writes:
Do we actually check how many duplicates are there during planning?
Certainly that's part of the planner's cost estimates ... but it's
only as good as the planner's statistical knowledge.
I'm looking at the
Hi Meskes-san
There are two points.
(1)
I attach a new patch. Please review it.
- Preproc replaces any prepared_name to "$0" and changes it to an
input-variable
for PREARE with typelist and EXECUTE with paramlist.
$0 is replaced in ecpg_build_params().
It's enable not to change
Spotted two minor typos when skimming through code, and a sentence on
returnvalue which seemed a bit odd since executeJsonPath() can exit on
ereport(). The attached diff fixes the typos and suggests a new wording.
cheers ./daniel
typo-jsonpath_exec.diff
Description: Binary data
Hello.
At Tue, 7 May 2019 14:39:55 +0530, Rajkumar Raghuwanshi
wrote in
> Hi,
> As this issue is reproducible without partition-wise aggregate also,
> changing email subject from "Statistical aggregate functions are not
> working with partitionwise aggregate " to "Statistical aggregate
Hi,
As this issue is reproducible without partition-wise aggregate also,
changing email subject from "Statistical aggregate functions are not
working with partitionwise aggregate " to "Statistical aggregate functions
are not working with PARTIAL aggregation".
original reported test case and
On Tue, 7 May 2019 at 09:30, David Fetter wrote:
>
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
>
I don't understand this, do you mind explaining a bit may be with an
example on how you want it to work.
--
On 2019/04/26 23:12, Alvaro Herrera wrote:
> On 2019-Apr-25, Amit Langote wrote:
>
>> BTW, this will need to be back-patched to 11.
>
> Done, thanks for the patch. I added the test in master, but obviously
> it doesn't work in pg11, so I just verified manually that relispartition
> is set
On Mon, Apr 8, 2019 at 7:29 PM Masahiko Sawada wrote:
>
> On Mon, Apr 8, 2019 at 7:22 PM Fujii Masao wrote:
> >
> > On Mon, Apr 8, 2019 at 5:30 PM Masahiko Sawada
> > wrote:
> > >
> > > On Mon, Apr 8, 2019 at 5:15 PM Fujii Masao wrote:
> > > >
> > > > On Mon, Apr 8, 2019 at 3:58 PM Julien
Hi
I liked this idea.
+ timing_set = true;
+ es->timing = defGetBoolean(opt);
+ summary_set = true;
+ es->timing = defGetBoolean(opt);
second es->timing should be es->summary, right?
regards, Sergei
On Tue, May 7, 2019 at 4:00 PM Michael Paquier wrote:
>
> On Tue, May 07, 2019 at 03:41:50PM +0800, John Naylor wrote:
> > Attached is an attempt to match surrounding code. More broadly,
> > though, it seems the "ID info" comments belong with the SET_LOCKTAG_*
> > macros rather than with the
On 2019/04/27 3:57, Tom Lane wrote:
> Alvaro Herrera writes:
>> Um, this one doesn't apply because of yesterday's 87259588d0ab.
>
> Before we spend too much time on minutiae, we should ask ourselves whether
> this patch is even going in the right direction. I'm not sure.
>
> One point is that
On Fri, May 3, 2019 at 12:09 AM Robert Haas wrote:
>
> On Tue, Apr 16, 2019 at 4:00 PM Tom Lane wrote:
> > I wrote:
> > > I'm thinking that we really need to upgrade vacuum's reporting totals
> > > so that it accounts in some more-honest way for pre-existing dead
> > > line pointers. The patch
On Tue, May 07, 2019 at 03:41:50PM +0800, John Naylor wrote:
> Attached is an attempt to match surrounding code. More broadly,
> though, it seems the "ID info" comments belong with the SET_LOCKTAG_*
> macros rather than with the LockTagType enum members.
+ LOCKTAG_SPECULATIVE_TOKEN, /* for
On Sun, May 05, 2019 at 05:45:53PM -0400, Tom Lane wrote:
> In the other place, checking IsSystemNamespace isn't even
> approximately the correct way to proceed, since it fails to reject
> reindexing system catalogs' toast tables.
Good point. I overlooked that part. It is easy enough to have a
On Tue, May 07, 2019 at 09:30:47AM +0200, David Fetter wrote:
> Folks,
>
> It can get a little tedious turning on (or off) all the boolean
> options to EXPLAIN, so please find attached a shortcut.
>
> Best,
> David.
It helps to have a working patch for this.
Best,
David.
--
David Fetter
On Mon, 6 May 2019 at 22:39, Ashwin Agrawal wrote:
>
> On Mon, May 6, 2019 at 7:14 AM Andres Freund wrote:
> >
> > Hi,
> >
> > On May 6, 2019 3:40:55 AM PDT, Rafia Sabih
> > wrote:
> > >I was trying the toyam patch and on make check it failed with
> > >segmentation fault at
> > >
> > >static
On Mon, 6 May 2019 at 16:14, Andres Freund wrote:
>
> Hi,
>
> On May 6, 2019 3:40:55 AM PDT, Rafia Sabih wrote:
> >On Tue, 9 Apr 2019 at 15:17, Heikki Linnakangas
> >wrote:
> >>
> >> On 08/04/2019 20:37, Andres Freund wrote:
> >> > On 2019-04-08 15:34:46 +0300, Heikki Linnakangas wrote:
> >> >>
Attached is an attempt to match surrounding code. More broadly,
though, it seems the "ID info" comments belong with the SET_LOCKTAG_*
macros rather than with the LockTagType enum members.
--
John Naylorhttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
Folks,
It can get a little tedious turning on (or off) all the boolean
options to EXPLAIN, so please find attached a shortcut.
Best,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
>From
On 05/05/2019 01:38, Peter Geoghegan wrote:
On Fri, Mar 1, 2019 at 3:59 PM Peter Geoghegan wrote:
/*
* Perform the same check on this internal level that
* _bt_mark_page_halfdead performed on the leaf level.
*/
if
On 2019/04/27 0:02, Tom Lane wrote:
> Amit Langote writes:
>> I couldn't find old discussions or source code comments about this, but
>> has someone encountered the following error and wondered whether it's
>> working that way for a reason?
>
>> select a::text, b from foo order by 1, 2 collate
Hi.
At Tue, 30 Apr 2019 14:33:47 +0800, Paul Guo wrote in
> I updated the original patch to
It's reasonable not to touch copydir.
> 1) skip copydir() if either src path or dst parent path is missing in
> dbase_redo(). Both missing cases seem to be possible. For the src path
> missing case,
On Wed, May 1, 2019 at 9:30 AM Robert Haas wrote:
>
> Replying to myself to resend to the list, since my previous attempt
> seems to have been eaten by a grue.
>
> On Tue, Apr 30, 2019 at 1:01 PM Robert Haas wrote:
> >
> > On Tue, Apr 30, 2019 at 1:38 AM Masahiko Sawada
> > wrote:
> > > It
On Mon, May 6, 2019 at 8:57 PM Andres Freund wrote:
> On 2019-05-06 11:10:15 -0400, Robert Haas wrote:
>
> > I think it's legitimate to question whether sending additional
> > invalidation messages as part of the design of this feature is a good
> > idea. If it happens frequently, it could
97 matches
Mail list logo
