On Wed, Nov 21, 2018 at 11:32:46AM -0500, Stephen Frost wrote:
> * Christoph Berg (christoph.b...@credativ.de) wrote:
>> it has bugged me for a long time that there's no clear "PostgreSQL is
>> starting" message in the server log file. I'd like to change that for
>> two reasons:
>
> +1
+1. One
On Thu, Dec 06, 2018 at 11:18:12PM +, Bossart, Nathan wrote:
> That seems reasonable to me.
Thanks, committed after renaming a couple of variables, after adding a
comment about the use of unlink() and also adding a comment explaining
what the different retry counters are here for.
--
Michael
On Sun, Dec 9, 2018 at 6:24 AM Justin Pryzby wrote:
>
> The docs say:
> https://www.postgresql.org/docs/current/runtime-config-query.html
> |min_parallel_table_scan_size Sets the minimum amount of table data that must
> be scanned in order for a parallel scan to be considered. [...]
>
> I'd like
On Mon, Dec 10, 2018 at 02:15:07AM +, Takahashi, Ryohei wrote:
>> We can change pgwin32_ReserveSharedMemoryRegion() to take an argument "int
>> loglevel". Then the caller first calls it with LOG, and DEBUGx afterwards.
>> It may also be helpful for the caller to output "LOG: tried %d times
On Mon, Dec 10, 2018 at 02:05:29AM +1300, David Rowley wrote:
> On Fri, 7 Dec 2018 at 20:15, Michael Paquier wrote:
>> -ATExecPartedIdxSetTableSpace(Relation rel, Oid newTableSpace)
>> +ATExecSetTableSpaceNoStorage(Relation rel, Oid newTableSpace)
>> NoStorage looks strange as routine name for
Hi Noah, Magnus and Tsunakawa-san,
Thank you for replying.
> Can you adopt pgbouncer, to reduce
> the frequency of starting new backend processes? That should improve your
> performance, too.
Actually, before I found that F-secure causes this message,
I recommend my customer to use
From: Andres Freund [mailto:and...@anarazel.de]
> Isn't the realistic scenario for migrations that people will turn this
> feature on on a more global basis? If they need to do per transaction choices,
> that makes this much less useful for easy migrations.
Agreed. My approach of per transaction
From: Magnus Hagander [mailto:mag...@hagander.net]
> In this particular case, it seems it *was* helpful, no? That's how you found
> out the customer used a broken antivirus product, which may certainly also
> cause *other* issues.
>
> Some sort of rate limiting to reduce the volume might help,
Andres Freund writes:
> On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
>> Well, that's just a different very-easily-broken assumption. There are
>> a lot of things that make auto-assigned OIDs unstable, and I do not think
>> that we want to guarantee that they'll hold still across a release
On Sun, Dec 09, 2018 at 12:49:18PM -0500, Stephen Frost wrote:
> Looks alright on a quick glance, but shouldn't you also update the
> comment..?
The comment on HEAD or with the patch is that:
/* Only allow relation types that can appear in partition trees. */
This still looks adapted to me.
On Sun, Dec 09, 2018 at 02:07:29PM -0500, Tom Lane wrote:
> Stephen Frost writes:
>> I don't entirely buy off on the argument that it's code that's 'highly
>> unlikely to break once written' though- we do add new relkinds from time
>> to time, for example. Perhaps we could have these functions
Hi,
On 2018-12-09 17:14:42 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
> >> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > I'm a bit dubious that this is a good idea. It's handy, at least for
> > forensic situations, that the system catalogs
Andres Freund writes:
> On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
>> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> I'm a bit dubious that this is a good idea. It's handy, at least for
> forensic situations, that the system catalogs have stable OIDs.
> Hm, but won't they have that for major
Hi,
On 2018-12-09 15:42:57 -0500, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > John Naylor writes:
> > > Commit 96cdeae07 added toast tables to most catalogs. One disadvantage
> > > is that the toast declarations require hard-coded oids, even though
> > > only shared
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> John Naylor writes:
> > Commit 96cdeae07 added toast tables to most catalogs. One disadvantage
> > is that the toast declarations require hard-coded oids, even though
> > only shared catalogs actually need stable oids. Now that we can assign
>
Hi,
On 2018-12-09 14:49:35 -0500, Tom Lane wrote:
> If the passed-in type OID isn't one of the very short list that
> TupleDescInitBuiltinEntry supports, it will silently hand back
> a broken TupleDesc, rather than throwing an error. How can
> this possibly be considered good code?
+1
If the passed-in type OID isn't one of the very short list that
TupleDescInitBuiltinEntry supports, it will silently hand back
a broken TupleDesc, rather than throwing an error. How can
this possibly be considered good code?
(So far as I can see, none of the extant callers could hit
such an
On Sat, Dec 8, 2018 at 12:48 PM Andrey Borodin wrote:
> > 8 дек. 2018 г., в 6:54, Alexander Korotkov
> > написал(а):
> >
> > Yep, please find attached draft patch.
>
> Patch seems good to me, I'll check it in more detail.
> The patch gets posting item at FirstOffsetNumber instead of
>
Hi list,
I was messing around a bit with BRIN code and found some cleanups to be made:
1. Remove dead code in brin_form_tuple
2. Add missing Datum conversion macros
3. Use AttrNumber type in places using 1-based attribute numbers
Though it's not hard to find cases all over source code similar to
Stephen Frost writes:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> ... especially in code that's highly unlikely to break once written.
> I don't entirely buy off on the argument that it's code that's 'highly
> unlikely to break once written' though- we do add new relkinds from time
> to time,
Hello
I review code and documentation and i have few notes. Did you register this
patch in CF app?
I found one error in phase 4. Simple reproducer:
> create table test (i int);
> create index this_is_very_large_exactly_maxnamelen_index_name_wink_wink_wink
> on test (i);
> create index
Greetings,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Michael Paquier (mich...@paquier.xyz) wrote:
> >> On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
> >>> I wonder if we maybe should have a regression test for every such
> >>> function which just
John Naylor writes:
> Commit 96cdeae07 added toast tables to most catalogs. One disadvantage
> is that the toast declarations require hard-coded oids, even though
> only shared catalogs actually need stable oids. Now that we can assign
> oids on the fly, it makes sense to do so for toast tables
Hi
ne 9. 12. 2018 v 18:50 odesílatel Tom Lane napsal:
> I've been experimenting with the task proposed in [1] of expanding
> the text_ops operator family to include type "name" as well as
> cross-type text vs. name operators. These operators would need to
> offer collation-aware sorting, since
Stephen Frost writes:
> * Michael Paquier (mich...@paquier.xyz) wrote:
>> On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
>>> I wonder if we maybe should have a regression test for every such
>>> function which just queries the catalog in a way to force the function
>>> to be
I've been experimenting with the task proposed in [1] of expanding
the text_ops operator family to include type "name" as well as
cross-type text vs. name operators. These operators would need to
offer collation-aware sorting, since that's exactly the difference
between text_ops and the
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sun, Dec 09, 2018 at 08:15:07AM +0900, Michael Paquier wrote:
> > On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
> >> We should really have a more clearly defined policy around this, but my
> >> recollection is that we
Greetings,
* Michael Paquier (mich...@paquier.xyz) wrote:
> On Sat, Dec 08, 2018 at 08:46:08AM -0500, Stephen Frost wrote:
> > I wonder if we maybe should have a regression test for every such
> > function which just queries the catalog in a way to force the function
> > to be called for every
On Sun, Dec 9, 2018 at 8:13 PM David Rowley
wrote:
> listp1 was scanned twice (loops=2), listp2 was scanned just once.
>
> Now it is true that if the subplan was executed 0 times that it will
> appear as "(never executed)", but do we really need to explain in this
> area that "(never executed)"
Thank you for looking at this.
On Fri, 7 Dec 2018 at 20:15, Michael Paquier wrote:
> -ATExecPartedIdxSetTableSpace(Relation rel, Oid newTableSpace)
> +ATExecSetTableSpaceNoStorage(Relation rel, Oid newTableSpace)
> NoStorage looks strange as routine name for this case. Would something
> like
On Wed, 5 Dec 2018 at 20:24, Amit Langote wrote:
> Documentation of run-time pruning tells readers to inspect "nloops"
> property of the EXPLAIN ANALYZE output, but I think that's a typo of
> "loops" which is actually output ("internal variable to track that
> property is indeed nloops).
I
31 matches
Mail list logo
