On 13/12/2018 20:17, David Steele wrote:
> On 12/13/18 2:02 PM, Peter Eisentraut wrote:
>> On 12/12/2018 05:09, David Steele wrote:
>>> I think the patch stands on its own. Exclusive backup mode is broken
>>> and is know to cause problems in the field.
>>
>> Is this breakage documented anywhere fo
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
dump-alter-index-stats-v2.patch looks pretty much reasonable to me, p
On 12/12/2018 16:57, Tom Lane wrote:
> diff --git a/src/backend/commands/analyze.c b/src/backend/commands/analyze.c
> index b8445dc..dcbd04c 100644
> *** a/src/backend/commands/analyze.c
> --- b/src/backend/commands/analyze.c
> *** examine_attribute(Relation onerel, int a
> *** 904,914
Hao Wu wrote:
> I have an extension for postgresql. The extension works across some
> databases, and needs to save some data.
> The data might be modified dynamically by the extension, and all the changed
> result must be saved. I have considered some methods.
> 1. Use GUC
> I find no easy way to
On 13/12/2018 13:26, Kyotaro HORIGUCHI wrote:
> Though I didn't look into individual change, this kind of
> refactoring looks good to me. But the syntax looks
> somewhat.. uh..
>
> I'm not sure it is actually workable, but I suspect that what we
> need here is just a shortcut of 'PG_CATCH();{PG_RE
Hi
> I would recommend waiting for the conclusion of other thread before
> moving on with this one.
Agreed.
I mark this patch as Waiting on Author. Not quite correct for waiting another
discussion, but most suitable.
> We could also consider using
> the show hook function of a parameter to print
Hi
Not sure i can be reviewer since this was initially my proposal.
I vote +1 for this patch. Code looks good and i think we have no reason to
leave RequestXLogStreaming as-is.
regards, Sergei
On Fri, Dec 14, 2018 at 11:32 AM Rushabh Lathia
wrote:
>
> While looking code further around this, I realized that we need
> similar kind of fix for bitmap as well as index only scan as well.
>
I think if we want to move forward with this patch, we need to first
investigate the deadlock hazard me
Hi,
every now and then I have to investigate an execution plan that is
strange in some way and I can't reproduce the same behavior. Usually
it's simply due to data distribution changing since the problem was
observed (say, after a nightly batch load/update).
In many cases it however may be due to
Hi,
There are some catalog views which do not show the partitioned table and
its index entry.
One of them is "pg_indexes" which failed to show the partitioned index.
Attached the patch which fixes the same.
Other views such as pg_stat*,pg_statio_* has the same problem for
partitioned tables and i
On 2018-Dec-14, Peter Eisentraut wrote:
> On 14/12/2018 01:23, Michael Paquier wrote:
> > On Thu, Dec 13, 2018 at 07:14:57PM -0500, Stephen Frost wrote:
> >> Based on at least a quick looking around, the actual grammar rule seems
> >> to match my recollection[1], adverbs should typically go AFTER
Meskes-san
Maybe I understand your comments about compatibility.
I will try to implement for sqlda.
# I am not goot at library version mechanism.
# I will learn about it.
Regards
Ryo Matsumura
On Fri, Dec 14, 2018 at 12:23:09PM +0300, Sergei Kornilov wrote:
> Not sure i can be reviewer since this was initially my proposal.
No issues from me if you wish to review the code. In my opinion, it is
not a problem if you are a reviewer as I wrote the code.
> I vote +1 for this patch. Code loo
pá 14. 12. 2018 v 12:41 odesílatel Tomas Vondra <
tomas.von...@2ndquadrant.com> napsal:
> Hi,
>
> every now and then I have to investigate an execution plan that is
> strange in some way and I can't reproduce the same behavior. Usually
> it's simply due to data distribution changing since the prob
On 12/14/18 5:10 AM, Tom Lane wrote:
> Tomas Vondra writes:
>> On 11/8/18 1:07 PM, Tomas Vondra wrote:
>>> Not sure what to do about this - maybe we should wildcard this first
>>> frame, to accept all wcsnlen variants. Opinions?
>
>> I've committed this with the first frame wirldcarded, and backp
On 12/14/18 3:01 AM, Peter Eisentraut wrote:
> On 13/12/2018 20:17, David Steele wrote:
>> On 12/13/18 2:02 PM, Peter Eisentraut wrote:
>>> On 12/12/2018 05:09, David Steele wrote:
I think the patch stands on its own. Exclusive backup mode is broken
and is know to cause problems in the f
> On 12/13/18, Tom Lane wrote:
> Looking at the existing entries, it seems like we'd have to have
> one special case: schema public has OID 2200 but is intentionally
> not pinned.
setup_depend() mentions other exceptions, but only this one currently has any
effect as far as I can see:
"pg_da
On 12/13/18 7:15 PM, Michael Paquier wrote:
> On Thu, Dec 13, 2018 at 11:53:53AM -0500, David Steele wrote:
>> I also think we should consider back-patching this change. It's hard to
>> imagine that archive commands would have trouble with this reordering
>> and the current ordering causes real pa
On 12/14/18 2:05 PM, Jim Finnerty wrote:
> You might want to only include the GUCs that are query tuning parameters,
> i.e., those returned by:
>
> SELECT name, setting, category
> FROM pg_settings
> WHERE category LIKE 'Query Tuning%'
> ORDER BY category, name;
>
Good idea! Thanks.
regards
--
Greetings,
* Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote:
> On 14/12/2018 01:14, Stephen Frost wrote:
> reindex table CONCURRENTLY test;
> >>
> >> By the way, does this syntax make sense? I haven't seen a discussion on
> >> this anywhere in the various threads. I keep thinking
On Fri, Dec 14, 2018 at 12:28 AM Pavel Stehule
wrote:
>
>
> čt 13. 12. 2018 v 10:23 odesílatel Simon Riggs
> napsal:
>
>> Thoughts?
>>
>
> looks great
>
Agreed. This sounds well-thought-out and rather simple to implement.
--
Jonah H. Harris
On 2018-Dec-14, Stephen Frost wrote:
> That wasn't what was asked and I don't think I see a problem with having
> concurrently be allowed in the parentheses. For comparison, it's not
> like "explain analyze select ..." or "explain buffers select" is
> terribly good grammatical form.
... and we d
Greetings,
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> On 2018-Dec-14, Stephen Frost wrote:
>
> > That wasn't what was asked and I don't think I see a problem with having
> > concurrently be allowed in the parentheses. For comparison, it's not
> > like "explain analyze select ..." or "e
Peter Eisentraut writes:
> On 12/12/2018 16:57, Tom Lane wrote:
>> +stats->attrcollid = exprCollation(index_expr);
>> +/* XXX should we consult indcollation instead? */
> After looking through this again, I think the answer here is "yes".
Yeah, I was leaning towards that
On 12/14/18 3:01 PM, Tomas Vondra wrote:
> On 12/14/18 2:05 PM, Jim Finnerty wrote:
>> You might want to only include the GUCs that are query tuning parameters,
>> i.e., those returned by:
>>
>> SELECT name, setting, category
>> FROM pg_settings
>> WHERE category LIKE 'Query Tuning%'
>> ORDER BY
Tomas Vondra writes:
> ... I propose to extend EXPLAIN output with an additional option, which
> would include information about modified GUCs in the execution plan
> (disabled by default, of course):
I'm a bit suspicious about whether this'll have any actual value,
if it's disabled by default (w
On 12/14/18 4:21 PM, Tom Lane wrote:
> Tomas Vondra writes:
>> ... I propose to extend EXPLAIN output with an additional option, which
>> would include information about modified GUCs in the execution plan
>> (disabled by default, of course):
>
> I'm a bit suspicious about whether this'll have
Greetings,
* Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote:
> On 23/11/2018 03:02, Stephen Frost wrote:
> > * Euler Taveira (eu...@timbira.com.br) wrote:
> >> 2018-02-28 21:54 GMT-03:00 Craig Ringer :
> >>> Good idea. I haven't read this yet, but one thing to make sure you've
> >>> handled is
Peter Eisentraut writes:
> The fundamental problem, as I see it, is that the macro expansion needs
> to produce the "finally" code twice: Once in the else (error) branch of
> the setjmp, and once in the non-error code path, either after the
> if-setjmp, or in the try block. But to be able to do t
Greetings,
* Tomas Vondra (tomas.von...@2ndquadrant.com) wrote:
> On 11/23/18 8:03 PM, Stephen Frost wrote:
> > * Fabrízio de Royes Mello (fabriziome...@gmail.com) wrote:
> >> On Fri, Nov 23, 2018 at 4:13 PM Petr Jelinek
> >> wrote:
> If carefully documented I see no problem with it... we al
Tomas Vondra writes:
> On 12/14/18 5:10 AM, Tom Lane wrote:
>> So I just got around to trying to do some valgrind testing for the first
>> time in a couple of months, and what I find is that this patch completely
>> breaks valgrind for me ...
>> This is valgrind 3.8.1 (RHEL6's version), so not ble
On Thu, Dec 13, 2018 at 10:40:59PM +0300, Alexander Korotkov wrote:
> On Thu, Dec 13, 2018 at 8:06 PM Andrey Borodin wrote:
> > That's the same variable, one place is definition while other is potential
> > misuse.
> > Seems like these 2 lines [0]
> >
> > + if (BufferIsValid(lbuffer))
> > +
We recently ran into a funny situation, where autovacuum would not
remove very old temp tables. The relfrozenxid of those tables was about
to reach the max freeze age, so monitoring started to complain. It
turned out that autovacuum saw that the backendId was used by a live
backend ... but that s
I have observed that the following pattern is repeating in our data
management programs:
UPDATE
event
SET
fuid = ${fuid},
venue_id = ${venueId},
url = ${url}
WHERE
id = ${id} AND
fuid IS != ${fuid} AND
venue_id IS != ${venueId} AND
url IS DISTINCT FROM ${url};
Note: "url" can be n
On Fri, Dec 14, 2018 at 11:29 AM Alvaro Herrera
wrote:
> I think the best way to fix this is to call RemoveTempRelations()
> unconditionally at session start (without doing the rest of the temp
> table setup, just the removal.)
That would certainly simplify things. I think I thought about that a
On 2018-Nov-09, Michael Paquier wrote:
> On Thu, Nov 08, 2018 at 12:13:31PM -0300, Alvaro Herrera wrote:
> > Right, that too. Fortunately I think compilers warn about
> > mismatching indentation nowadays, at least in some cases.
>
> I don't recall seeing a compiler warning about that, but I do
On Fri, Dec 14, 2018 at 8:27 AM David Steele wrote:
> If the server crashes during a backup, the server probably won't
> restart. We say "may" here but if your backup runs more than a few
> checkpoints it's more like won't. The remedy is to go manually delete a
> file the user may have never hea
On 2018-Dec-14, Robert Haas wrote:
> On Fri, Dec 14, 2018 at 11:29 AM Alvaro Herrera
> wrote:
> > I think the best way to fix this is to call RemoveTempRelations()
> > unconditionally at session start (without doing the rest of the temp
> > table setup, just the removal.)
>
> That would certainl
On Fri, Dec 14, 2018 at 12:27 PM Alvaro Herrera
wrote:
> Hmm, I think in the case covered by your commit, that is a session that
> crashes with a few thousands of temp tables, this new patch might cause
> a failure to open a new session altogether.
Oh, good point. Or if the catalog is corrupted.
Robert Haas writes:
> On Fri, Dec 14, 2018 at 11:29 AM Alvaro Herrera
> wrote:
>> I think the best way to fix this is to call RemoveTempRelations()
>> unconditionally at session start (without doing the rest of the temp
>> table setup, just the removal.)
> That would certainly simplify things.
> "Thomas" == Thomas Munro writes:
>>> Do we have any reason for the restriction beyond stylistic preference?
>> No. Robert and Tom were against allowing mixing declarations and
>> code, a few more against // comments. I don't quite agree with
>> either, but getting to the rest of C99 se
On Fri, Dec 14, 2018 at 12:57 PM Tom Lane wrote:
> I seem to recall discussions about having crash recovery go around
> and clean out temp tables. That seems like a better plan than
> penalizing every session start with this.
Well, crash recovery already removes the files, but it can't really
re
On 11/30/18, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> Unfortunately, patch doesn't compile anymore due:
>
> varlena.c: In function ‘text_position_next_internal’:
> varlena.c:1337:13: error: ‘start_ptr’ undeclared (first use in this
> function)
> Assert(start_ptr >= haystack && start_ptr <=
Andrew Gierth writes:
> "Thomas" == Thomas Munro writes:
> Thomas> -1 for making superficial changes to code that we are
> Thomas> "vendoring", unless it is known to be dead/abandoned and we're
> Thomas> definitively forking it. It just makes it harder to track
> Thomas> upstream's bug fixes
Hi,
On 2018-12-14 13:25:29 -0500, Tom Lane wrote:
> Our track record in borrowing code from "upstream" projects is pretty
> miserable: almost without exception, we've found ourselves stuck with
> maintaining such code ourselves after a few years. I don't see any
> reason to think that wouldn't be
Robert Haas writes:
> On Fri, Dec 14, 2018 at 12:57 PM Tom Lane wrote:
>> I seem to recall discussions about having crash recovery go around
>> and clean out temp tables. That seems like a better plan than
>> penalizing every session start with this.
> Well, crash recovery already removes the f
On Fri, Dec 14, 2018 at 4:43 AM Andres Freund wrote:
> This leads me to think that we possibly should move computation of the
> last removed xid from recovery to the primary, during the generation of
> the xl_btree_delete WAL record.
Do I understand correctly that we need this xid computation, be
Hi,
On 2018-12-14 13:35:50 -0500, Tom Lane wrote:
> Hm. It *could*, if we wanted it to run some transactions after
> finishing recovery.
How, we don't have infrastructure for changing databases yet?
> But I guess I wonder why bother; if the disk
> space is gone then there's not that much reaso
On Wed, Nov 28, 2018 at 1:43 PM Alvaro Herrera wrote:
> Right, I think option 4 is a clear improvement over option 1. I can get
> behind that one. Since not many people care to vote, I think this tips
> the scales enough to that side.
I'm showing up very late to the party here, but I like optio
On Fri, Dec 14, 2018 at 6:35 PM Tom Lane wrote:
> Hm. It *could*, if we wanted it to run some transactions after
> finishing recovery.
It'd have to launch a separate process per database. That would be
useful infrastructure for other things, too, like automatic catalog
upgrades in minor release
Hi,
On 2018-12-14 21:39:48 +0300, Alexander Korotkov wrote:
> On Fri, Dec 14, 2018 at 4:43 AM Andres Freund wrote:
> > This leads me to think that we possibly should move computation of the
> > last removed xid from recovery to the primary, during the generation of
> > the xl_btree_delete WAL rec
Andres Freund writes:
> On 2018-12-14 13:25:29 -0500, Tom Lane wrote:
>> The maintenance track record of this github repo appears to span six
>> months, and it's now been about four months since the last commit.
>> It might be abandonware already.
> The last commit was a month ago, no? November 6
Hi,
On 2018-12-14 13:47:53 -0500, Tom Lane wrote:
> Andres Freund writes:
> > It's been absorbed into MSVC's standard library and a bunch of other
> > projects, so there's certainly some other prominent adoption.
>
> If we think that's going on, maybe we should just sit tight till glibc
> absorb
> "Tom" == Tom Lane writes:
Tom> The maintenance track record of this github repo appears to span
Tom> six months,
The algorithm was only published six months ago.
--
Andrew (irc:RhodiumToad)
In pursuit of places that might not be on board with non-default
collations, I tried sticking
Assert(PG_GET_COLLATION() == C_COLLATION_OID);
into nameeq() and the other name comparison functions, in my build with
type name's typcollation changed to "C". I'm down to one place in the
core regr
Andrew Gierth writes:
> "Tom" == Tom Lane writes:
> Tom> The maintenance track record of this github repo appears to span
> Tom> six months,
> The algorithm was only published six months ago.
Doesn't really affect my point: there's little reason to believe that
there will be an active upstrea
> "Tom" == Tom Lane writes:
Tom> (Still, you might want to try to automate and document the coding
Tom> format conversion steps, along the line of what I've done recently
Tom> for our copy of tzcode.)
Working around our declaration-after-statement prohibition required
manually moving some
On Thu, Dec 13, 2018 at 9:42 AM Simon Riggs wrote:
> At present we have a timestamp of 'infinity' and infinite ranges, but no
> infinite interval
>
> SELECT 'infinity'::timestamp;
> works
>
> SELECT 'infinity'::interval;
> ERROR: invalid input syntax for type interval: "infinity"
>
> Seems a str
On Fri, 14 Dec 2018 at 14:25, Tom Lane wrote:
> Now, it's certainly true that nameeq() doesn't need a collation spec
> today, any more than texteq() does, because both types legislate that
> equality is bitwise. But if we leave ExecBuildGroupingEqual like this,
> we're mandating that no type any
On Thu, Dec 13, 2018 at 12:17 AM Michael Paquier wrote:
> On Wed, Dec 12, 2018 at 07:54:05AM -0500, David Steele wrote:
> > The LSN switch point is often the same even when servers are going to
> > different timelines. If the LSN is different enough then the problem
> > solves itself since the .p
Isaac Morland writes:
> On Fri, 14 Dec 2018 at 14:25, Tom Lane wrote:
>> Now, it's certainly true that nameeq() doesn't need a collation spec
>> today, any more than texteq() does, because both types legislate that
>> equality is bitwise. But if we leave ExecBuildGroupingEqual like this,
>> we'r
> "Andres" == Andres Freund writes:
>> Is this a path we really want to go down? I'm not convinced the
>> cost/benefit ratio is attractive.
Andres> float->text conversion is one of the major bottlenecks when
Andres> backing up postgres, it's definitely a pain-point in practice.
Also an
Hi,
On 2018-12-14 14:25:30 -0500, Tom Lane wrote:
> In pursuit of places that might not be on board with non-default
> collations, I tried sticking
>
> Assert(PG_GET_COLLATION() == C_COLLATION_OID);
>
> into nameeq() and the other name comparison functions, in my build with
> type name's typ
On Fri, 14 Dec 2018 at 15:16, Robert Haas wrote:
> Why? I consider it somewhat of a wart that timestamps allow infinity
> - it adds special case coding all over the place. Allowing intervals
> to be infinite as well seems like it'll just create more special cases
> without really solving anyth
Andres Freund writes:
> On 2018-12-14 14:25:30 -0500, Tom Lane wrote:
>> Now, it's certainly true that nameeq() doesn't need a collation spec
>> today, any more than texteq() does, because both types legislate that
>> equality is bitwise. But if we leave ExecBuildGroupingEqual like this,
>> we're
Isaac Morland writes:
> I would be interested if you have an example where the ability of
> date/timestamp values to be infinite adds special case coding.
I think Robert is talking about the implementation functions for
timestamp-related operations, which typically do have to special-case
infinit
On 12/1/18, Dmitry Dolgov <9erthali...@gmail.com> wrote:
> I see that the author keeps patch updated, but I'm a bit worried because of
> lack of full review since probably May. I'm moving it to the next CF, let's
> see
> if there would be more feedback.
>
> P.S. adding Daniel, since he is assigned
On 12/14/18 4:58 PM, Tom Lane wrote:
> ...
>
> In general, I'm not particularly on board with our valgrind.supp
> carrying suppressions for code outside our own code base: I think
> that's assuming WAY too much about which version of what is installed
> on a particular box.
>
Fair point.
> Ma
On 12/14/18, John Naylor wrote:
> I signed up to be a reviewer, and I will be busy next month, so I went
> ahead and fixed the typo in the patch that broke assert-enabled
> builds. While at it, I standardized on the spelling "start_ptr" in a
> few places to match the rest of the file. It's a bit c
On Wed, Dec 12, 2018 at 8:00 PM Tom Lane wrote:
> By chance I noticed that postgres_fdw's postgresGetForeignPlan() assumes
> --- without any checking --- that the outer_plan it's given for a join
> relation must have a NestLoop, MergeJoin, or HashJoin node at the top.
> That's been wrong at least
On Fri, Dec 14, 2018 at 9:11 PM Tom Lane wrote:
> Isaac Morland writes:
> > I would be interested if you have an example where the ability of
> > date/timestamp values to be infinite adds special case coding.
>
> I think Robert is talking about the implementation functions for
> timestamp-related
On Fri, Dec 14, 2018 at 05:21:49PM +0530, Suraj Kharage wrote:
> There are some catalog views which do not show the partitioned table and
> its index entry.
> One of them is "pg_indexes" which failed to show the partitioned index.
> Attached the patch which fixes the same.
I tend to agree with you
Hello,
I'd like to propose a patch to log bind parameter values not only when
logging duration,
but also on error (timeout in particular) or in whatever situation the
statement normally gets logged.
This mostly could be useful when the request originator doesn't log them
either, so it's hard
Hi,
On 2018-10-09 12:18:02 -0700, Andres Freund wrote:
> Here's an updated version of the patch. Besides a rebase the biggest
> change is that I've wrapped:
>
> On 2018-06-05 10:29:52 -0700, Andres Freund wrote:
> > There's some added uglyness, which I hope we can polish a bit
> > further. Right
On 12/14/18 3:26 PM, Robert Haas wrote:
> On Thu, Dec 13, 2018 at 12:17 AM Michael Paquier wrote:
>> On Wed, Dec 12, 2018 at 07:54:05AM -0500, David Steele wrote:
>>> The LSN switch point is often the same even when servers are going to
>>> different timelines. If the LSN is different enough then
On 12/14/18 4:35 PM, Tomas Vondra wrote:
> On 12/14/18 4:58 PM, Tom Lane wrote:
>> ...
>>
>> In general, I'm not particularly on board with our valgrind.supp
>> carrying suppressions for code outside our own code base: I think
>> that's assuming WAY too much about which version of what is install
> "Andres" == Andres Freund writes:
>> I think it'd probably good to add accessors for value/nullness in
>> arguments that hide the difference between > sake of extension authors. Would probably mostly make sense if we
>> backpatched those for compatibility.
Speaking as an affected extens
On Fri, Dec 14, 2018 at 06:05:18PM -0500, David Steele wrote:
> On 12/14/18 3:26 PM, Robert Haas wrote:
>> The new TLI is the only thing that is guaranteed to be unique with
>> each new promotion, and I would guess that it is therefore the right
>> thing to use to disambiguate them.
>
> This is th
On Fri, Dec 14, 2018 at 08:43:20AM -0500, David Steele wrote:
> On 12/13/18 7:15 PM, Michael Paquier wrote:
>> I would like to hear opinion from other though if we should consider
>> that as an improvement or an actual bug fix. Changing the order of the
>> files to map with what the startup proces
Hi,
On 2018-12-13 20:21:12 -0500, Tom Lane wrote:
> Andres Freund writes:
> > [ separation of FirstBootstrapObjectId and FirstGenbkiObjectId ]
>
> It seems like we should also add a check to genbki.pl that the ending
> value of GenbkiNextOid is <= FirstBootstrapObjectId, so that we'll
> certainl
On Fri, Dec 14, 2018 at 02:20:27PM +0900, Amit Langote wrote:
> Given that pg_partition_root will return a valid result for any relation
> that can be part of a partition tree, it seems strange that the above
> sentence says "for the given partitioned table or partitioned index". It
> should perha
On Thu, Dec 13, 2018 at 5:42 PM Andres Freund wrote:
> This leads me to think that we possibly should move computation of the
> last removed xid from recovery to the primary, during the generation of
> the xl_btree_delete WAL record.
For the record, I share your sense that this isn't a great desi
On 2018-Dec-13, Tom Lane wrote:
> We could take it a bit further and not make the 'p' entries for such
> OIDs in the first place, greatly reducing the size of pg_depend in
> typical installations. Perhaps that'd confuse clients that look at
> that catalog, though.
The number of 'p' entries in pg
Hi,
On 2018-12-14 22:54:14 -0300, Alvaro Herrera wrote:
> On 2018-Dec-13, Tom Lane wrote:
> > Looking at the existing entries, it seems like we'd have to have
> > one special case: schema public has OID 2200 but is intentionally
> > not pinned. I wouldn't have a hard time with teaching isObjectPi
On 2018-Dec-14, Robert Haas wrote:
> On Fri, Dec 14, 2018 at 12:27 PM Alvaro Herrera
> wrote:
> > Maybe it'd be better to change temp table removal to always drop
> > max_locks_per_transaction objects at a time (ie. commit/start a new
> > transaction every so many objects).
>
> We're basically
On 2018-Dec-14, Robert Haas wrote:
> On Fri, Dec 14, 2018 at 6:35 PM Tom Lane wrote:
> > Hm. It *could*, if we wanted it to run some transactions after
> > finishing recovery.
>
> It'd have to launch a separate process per database. That would be
> useful infrastructure for other things, too,
On Sat, Dec 15, 2018 at 12:14 AM Robert Haas wrote:
>
> On Wed, Nov 28, 2018 at 1:43 PM Alvaro Herrera
> wrote:
> > Right, I think option 4 is a clear improvement over option 1. I can get
> > behind that one. Since not many people care to vote, I think this tips
> > the scales enough to that s
On Fri, Dec 14, 2018 at 11:06:32PM -0300, Alvaro Herrera wrote:
> I did propose in my OP the idea of a PGPROC boolean flag that indicates
> whether the temp namespace has been set up. If not, have autovac remove
> those tables. I like this option better, but I fear it adds more
> ProcArrayLock co
As pointed out by John Naylor [1], it seems during bootstrap mode, we
are always creating FSM files which are not required. In commit's
b9d01fe288 and 3908473c80, we have added some code where we allowed
the creation of files during mdopen even if they didn't exist during
the bootstrap mode. The
On Thu, Dec 13, 2018 at 3:18 AM John Naylor wrote:
>
> On 11/24/18, Amit Kapila wrote:
> > 4. You have mentioned above that "system catalogs created during
> > bootstrap still have a FSM if they have any data." and I can also see
> > this behavior, have you investigated this point further?
>
> I
90 matches
Mail list logo
