>
> Maybe this can be a discussed in a follow-up patch and Corey should
> proceed to finalize the if patch?
In the event that we can leave prompting to a later patch, here are the v12
highlights:
- created conditional.h and conditional.c which contain the functions with
stack-ish push/pop/peek/po
On Fri, Feb 10, 2017 at 8:01 PM, Kuntal Ghosh
wrote:
> On Wed, Jan 4, 2017 at 1:51 PM, Masahiko Sawada wrote:
>
>> Attached patch introduces new GUC parameter parameter
>> vacuum_cleanup_index_scale_factor which specifies the fraction of the
>> table pages containing dead tuple needed to trigger
I noticed that running ALTER TABLE table_name DETACH PARTITION crashes, if
table_name is not a partitioned table. That's because of an Assert in
ATExecDetachPartition(). We really should error out much sooner in this
case, IOW during transformAlterTableStmt(), as is done in the case of
ATTACH PA
On Sat, Feb 11, 2017 at 8:18 PM, Petr Jelinek
wrote:
> On 10/02/17 19:55, Masahiko Sawada wrote:
>> On Thu, Feb 9, 2017 at 12:44 AM, Petr Jelinek
>> wrote:
>>> On 08/02/17 07:40, Masahiko Sawada wrote:
On Wed, Feb 8, 2017 at 9:01 AM, Michael Paquier
wrote:
> On Wed, Feb 8, 2017 at
On Sat, Feb 11, 2017 at 7:00 AM, Robert Haas wrote:
> On Fri, Feb 10, 2017 at 3:30 AM, Simon Riggs wrote:
>> We've added xmin info to pg_stat_activity and pg_stat_replication, but
>> VACUUM doesn't yet report which xmin value it used when it ran.
>>
>> Small patch to add this info to VACUUM outpu
On Fri, Feb 10, 2017 at 4:29 PM, Amit Langote
wrote:
> On 2017/02/10 14:32, Michael Paquier wrote:
>> On Thu, Feb 9, 2017 at 7:21 AM, Corey Huinker
>> wrote:
>
> Thanks Corey and Michael for the reviews!
>
>>> 1. should have these tests named in core functions, like maybe:
>>>
>>> relation_has_v
On Sat, Feb 11, 2017 at 3:03 PM, Pavel Stehule wrote:
> here is new update - check is done before any creating
It may be better to do any checks before dropping existing databases
as well... It would be as well just simpler to complain with a single
error message like "database and template list
On Sun, Feb 12, 2017 at 6:44 AM, Andreas Karlsson wrote:
> On 02/02/2015 03:10 PM, Andres Freund wrote:
>> I think if we should instead just use the new index, repoint the
>> dependencies onto the new oid, and then afterwards, when dropping,
>> rename the new index one onto the old one. That means
On 2017/02/10 19:19, Simon Riggs wrote:
> On 10 February 2017 at 08:18, Amit Langote
> wrote:
>
>> I agree that getting the proposed documentation changes committed would be
>> a step ahead.
>
> Committed. I tested how it works and added documentation that matched
> my experiences, correcting wh
On Tue, Jan 31, 2017 at 11:07 AM, Michael Paquier
wrote:
> On Mon, Jan 30, 2017 at 10:52 PM, Heikki Linnakangas wrote:
>> If that can happen, don't we have the same problem in many other places?
>> Like, all the SLRUs? They don't fsync the directory either.
>
> Right, pg_commit_ts and pg_clog ent
Hi,
I'd like to make it easier to analyze slow queries in ECPG using
log_min_duration_statement. Especially when DBA and C application developer
is different, DBA can feedback slow embedded query to the developer without
difficulty and mistakes.
When our customers log and look into slower quer
On 2/1/17 10:39 PM, Michael Paquier wrote:
On Thu, Feb 2, 2017 at 1:23 PM, Amit Kapila wrote:
Many thanks to you for running the show. I think it might be okay if
one consolidated mail is sent for all the patches that are marked
"Returned with Feedback" or "Rejected" or "Moved to next CF". OT
On 2/3/17 7:34 PM, Andres Freund wrote:
On 2017-02-03 19:26:55 -0600, Jim Nasby wrote:
On 2/3/17 6:20 PM, Andres Freund wrote:
- The ringbuffers in shared buffers can be problematic. One possible way of
solving that is to get rid of ringbuffers entirely and rely on different
initial values for
On 2/7/17 9:16 AM, Daniele Varrazzo wrote:
Thank you for the clarification: I will assume the behaviour cannot be
maintained on PG 10 and think whether the treatment of '{}' is too
magical and drop it instead.
BTW, I would hope that passing '{}' into a defined array field still
works, since an
On 2/7/17 10:49 PM, Tom Lane wrote:
Peter Eisentraut writes:
I would like to propose that we drop support for Python 2.3.
...
We do have buildfarm coverage on prairiedog. However, that runs a >10
year old operating system, so I think it is not representing real usage.
I have no particular obj
On 2/10/17 12:04 AM, Stephen Frost wrote:
They're misleading by having an arbitrary subset of the role attributes
and implying that the role relationships are simpler than they actually
are. Frankly, they're also not being consistently maintained based on
any proper policy, which I find quite ob
On 02/13/2017 02:29 AM, Jim Nasby wrote:
On 2/10/17 6:38 PM, Tomas Vondra wrote:
And no, backups may not be a suitable solution - the failure happens on
a standby, and the page (luckily) is not corrupted on the master. Which
means that perhaps the standby got corrupted by a WAL, which would
affe
On 2/11/17 4:36 AM, Michael Banck wrote:
I guess you're right, I've moved it further down. There is in fact a
message about the xlog location (unless you switch off wal entirely),
but having another one right before that mentioning the completed
checkpoint sounds ok to me.
1) I don't think this
On 2/10/17 2:33 PM, Robert Haas wrote:
That having been said, I think it could certainly be useful to have
more control over what DDL gets logged in foreground processes.
FWIW, this is a significant problem outside of DDL. Once you're past 1-2
levels of nesting SET client_min_messages = DEBUG
On 2/10/17 2:24 PM, Andrew Dunstan wrote:
There's a bunch of these things in /contrib which really ought to be
PGXN extensions (also CUBE, earthdistance, etc.). However, one of the
steps in that would be getting the mainstream platforms to package them
so that users have a reasonable upgrade pat
On 8/22/16 12:24 AM, Andres Freund wrote:
Somewhat naïve question from someone with much less clue about low level
cache behaviour trying to follow along: given that we determine such
padding at compile time, how do we ensure that the cacheline size we're
targeting is right at runtime?
There's b
On 2/10/17 6:38 PM, Tomas Vondra wrote:
And no, backups may not be a suitable solution - the failure happens on
a standby, and the page (luckily) is not corrupted on the master. Which
means that perhaps the standby got corrupted by a WAL, which would
affect the backups too. I can't verify this, t
On 11/14/16 8:51 PM, Tom Lane wrote:
1. The impression I have is that most people write trigger functions
so that they can be shared across multiple uses. That'd be impossible
with anonymous trigger function blocks. So you'd be trading off merging
two commands into one, versus having to write o
On 2/12/17 5:06 PM, David Rowley wrote:
Yet I've worked with OLTP applications
since 2005, and I struggle to recall any many:many joins at all.
Interesting... I've run across it numerous times. In any case, for OLTP
there's other things you can do fairly easily.
Perhaps this optimisation is
On Thursday, February 9, 2017 4:41 AM Robert Haas wrote:
> You should add this to the next CommitFest so it doesn't get missed.
>
> https://commitfest.postgresql.org/
Thank you for your kind advice!
I have added this patch to the CommitFest 2017-03.
Regards,
Okano Naoki
Fujitsu
--
Sent via pg
Tomas Vondra pointed out to me that there's an error in parallel.sgml
which confuses the inner and outer sides of the join.
I've attached a patch which fixes this, although I think I'm still
missing the point to text's explanation of why Merge Join is not
included due to it having to sort the inne
On 13 February 2017 at 06:32, Tom Lane wrote:
> It's not so much poor choices as the cost of the optimization attempt ---
> if there's a K-relation OR clause, this will increase the cost of planning
> by a factor approaching K+1, whether or not you get a better plan out of
> it. I ran the regress
On Sun, Feb 12, 2017 at 10:35:04AM +, Dean Rasheed wrote:
> On 11 February 2017 at 01:17, Tomas Vondra
> wrote:
> > Thanks for the feedback, I'll fix this. I've allowed myself to be a bit
> > sloppy because the number of attributes in the statistics is currently
> > limited to 8, so the overf
On Fri, Feb 10, 2017 at 5:07 PM, Robert Haas wrote:
> But also, I'm not really sure whether this conversion makes sense. I
> mean, any build system is going to require some work, and accordingly
> our present build systems require some work. cmake will require
> different work, but not necessar
David Rowley writes:
> This is very interesting. Couldn't this be even more generic and
> instead of looking at just the jointree quals, also look at the join
> conditions too, as I think you can use this to also transforms queries
> such as:
The hard part of that is to remember exactly where you
In a discussion at
https://www.postgresql.org/message-id/55d51b54.4050...@joh.to we talked
about adding RADIUS fallback servers. It never got to the point of it being
done.
PFA a patch that implements this.
It supports multiple RADIUS servers. For all other parameters (secret,
port, identifier) o
On 12 February 2017 at 13:30, Tom Lane wrote:
> I wrote a POC patch for this on a long airplane ride. It's not complete,
> and I'm sure there are bugs as well, but it makes your example case
> better. What I did about the de-duplication issue is to de-dup using
> the CTIDs of all baserels in the
On 11 February 2017 at 01:17, Tomas Vondra wrote:
> Thanks for the feedback, I'll fix this. I've allowed myself to be a bit
> sloppy because the number of attributes in the statistics is currently
> limited to 8, so the overflows are currently not an issue. But it doesn't
> hurt to make it future-
Hello Greg,
So you'd just want to know nesting depth, with no indicator of true/false?
Even that's more than bash does, for example: [...]
Indeed, there is nothing in "bash" prompt about nesting control
structures. However other shells have such indications: "zsh" has "%_",
"tcsh" has "%R
34 matches
Mail list logo
