On Sat, Dec 6, 2014 at 10:43 AM, David Rowley wrote:
> On 4 December 2014 at 19:35, Amit Kapila wrote:
>>
>> Attached patch is just to facilitate the discussion about the
>> parallel seq scan and may be some other dependent tasks like
>> sharing of various states like combocid, snapshot with para
On Sat, Dec 6, 2014 at 12:27 AM, Jim Nasby wrote:
> On 12/5/14, 9:08 AM, José Luis Tallón wrote:
>>
>>
>> More over, when load goes up, the relative cost of parallel working
should go up as well.
>> Something like:
>> p = number of cores
>> l = 1min-load
>>
>> additional_cost = tupl
On Fri, Dec 5, 2014 at 8:43 PM, Stephen Frost wrote:
>
> José,
>
> * José Luis Tallón (jltal...@adv-solutions.net) wrote:
> > On 12/04/2014 07:35 AM, Amit Kapila wrote:
> > >The number of worker backends that can be used for
> > >parallel seq scan can be configured by using a new GUC
> > >parallel
On Fri, Dec 5, 2014 at 8:46 PM, Stephen Frost wrote:
>
> Amit,
>
> * Amit Kapila (amit.kapil...@gmail.com) wrote:
> > postgres=# explain select c1 from t1;
> > QUERY PLAN
> > --
> > Seq Scan on t1 (cost=0.00..101.00 rows=1
On 4 December 2014 at 19:35, Amit Kapila wrote:
>
> Attached patch is just to facilitate the discussion about the
> parallel seq scan and may be some other dependent tasks like
> sharing of various states like combocid, snapshot with parallel
> workers. It is by no means ready to do any complex
On Fri, Dec 5, 2014 at 8:38 PM, José Luis Tallón
wrote:
>
> On 12/04/2014 07:35 AM, Amit Kapila wrote:
>>
>> [snip]
>>
>> The number of worker backends that can be used for
>> parallel seq scan can be configured by using a new GUC
>> parallel_seqscan_degree, the default value of which is zero
>> a
On 12/5/14, 5:49 PM, Josh Berkus wrote:
On 12/05/2014 02:41 PM, Jim Nasby wrote:
Perhaps we should also officially recommend production servers be setup
to create core files. AFAIK the only downside is the time it would take
to write a core that's huge because of shared buffers, but perhaps
ther
On Fri, Dec 5, 2014 at 3:49 PM, Josh Berkus wrote:
> to enable core dumps on the production replicas because writing out the
> 16GB of shared buffers they had took over 10 minutes in a test.
No one ever thinks it'll happen to them anyway - recommending enabling
core dumps seems like a waste of ti
On 12/05/2014 02:41 PM, Jim Nasby wrote:
> Perhaps we should also officially recommend production servers be setup
> to create core files. AFAIK the only downside is the time it would take
> to write a core that's huge because of shared buffers, but perhaps
> there's some way to avoid writing those
Peter Geoghegan writes:
> On Fri, Dec 5, 2014 at 2:41 PM, Jim Nasby wrote:
>> Perhaps we should also officially recommend production servers be setup to
>> create core files. AFAIK the only downside is the time it would take to
>> write a core that's huge because of shared buffers
> I don't thin
On Fri, Dec 5, 2014 at 2:41 PM, Jim Nasby wrote:
> Perhaps we should also officially recommend production servers be setup to
> create core files. AFAIK the only downside is the time it would take to
> write a core that's huge because of shared buffers
I don't think that's every going to be pract
On 12/5/14, 4:11 PM, Peter Geoghegan wrote:
On Fri, Dec 5, 2014 at 1:29 PM, Josh Berkus wrote:
We made some changes which decreased query cancel (optimizing queries,
turning on hot_standby_feedback) and we haven't seen a segfault since
then. As far as the user is concerned, this solves the pro
Stephen,
Thanks for the feedback.
> > diff --git a/src/backend/access/transam/xlogfuncs.c
> b/src/backend/access/transam/xlogfuncs.c
> > --- 56,62
> >
> > backupidstr = text_to_cstring(backupid);
> >
> > ! if (!superuser() && !check_role_attribute(GetUserId(),
> ROLE_ATTR_REPLICAT
On Fri, Dec 5, 2014 at 1:29 PM, Josh Berkus wrote:
>> We made some changes which decreased query cancel (optimizing queries,
>> turning on hot_standby_feedback) and we haven't seen a segfault since
>> then. As far as the user is concerned, this solves the problem, so I'm
>> never going to get a t
On 12/05/2014 12:54 PM, Josh Berkus wrote:
> Hackers,
>
> This is not a complete enough report for a diagnosis. I'm posting it
> here just in case someone else sees something like it, and having an
> additional report will help figure out the underlying issue.
>
> * 700GB database with around 5,
Hackers,
This is not a complete enough report for a diagnosis. I'm posting it
here just in case someone else sees something like it, and having an
additional report will help figure out the underlying issue.
* 700GB database with around 5,000 writes per second
* 8 replicas handling around 10,000
On Fri, Dec 5, 2014 at 04:10:12PM -0300, Alvaro Herrera wrote:
> Well, ALTER TABLE is special: you can give several subcommands, and each
> subcommand can be one of a rather long list of possible subcommands.
> Testing every combination would mean a combinatorial explosion, which
> would indeed be
On Fri, Dec 5, 2014 at 12:33 PM, Robert Haas wrote:
>> Well, if an alias is used, and you refer to an attribute using a
>> non-alias name (i.e. the original table name), then you'll already get
>> an error suggesting that the alias be used instead -- of course,
>> that's nothing new. It doesn't ma
On Wed, Dec 3, 2014 at 9:21 PM, Peter Geoghegan wrote:
> On Tue, Dec 2, 2014 at 1:11 PM, Robert Haas wrote:
>> Basically, the case in which I think it's helpful to issue a
>> suggestion here is when the user has used the table name rather than
>> the alias name. I wonder if it's worth checking f
On Fri, Dec 5, 2014 at 3:05 PM, Jim Nasby wrote:
>> On what basis do you expect that? Every time you use a view, you're
>> using a pg_node_tree. Nobody's ever complained that having to reload
>> the pg_node_tree column was too slow, and I see no reason to suppose
>> that things would be any diff
On 12/5/14, 2:02 PM, Robert Haas wrote:
On Fri, Dec 5, 2014 at 2:52 PM, Jim Nasby wrote:
The other option would be to use some custom rowtype to store boundary
values and have a method that can form a boundary tuple from a real one.
Either way, I suspect this is better than frequently evaluatin
On Fri, Dec 5, 2014 at 1:01 AM, Anssi Kääriäinen
wrote:
> If Django is going to use the INSERT ... ON CONFLICT UPDATE variant in
> Django for the existing save() method, then it needs to know if the
> result was an UPDATE or INSERT. If we are going to use this for other
> operations (for example b
On Fri, Dec 5, 2014 at 2:52 PM, Jim Nasby wrote:
> The other option would be to use some custom rowtype to store boundary
> values and have a method that can form a boundary tuple from a real one.
> Either way, I suspect this is better than frequently evaluating
> pg_node_trees.
On what basis do
On 12/5/14, 1:22 PM, Jim Nasby wrote:
On 12/5/14, 3:42 AM, Amit Langote wrote:
> I think you are right. I think in this case we need something similar
>to column pg_index.indexprs which is of type pg_node_tree(which
>seems to be already suggested by Robert). So may be we can proceed
>with this
On 12/5/14, 3:42 AM, Amit Langote wrote:
> I think you are right. I think in this case we need something similar
>to column pg_index.indexprs which is of type pg_node_tree(which
>seems to be already suggested by Robert). So may be we can proceed
>with this type and see if any one else has bette
Bruce Momjian wrote:
> On Fri, Dec 5, 2014 at 09:29:59AM -0300, Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > On Fri, Nov 28, 2014 at 01:43:36PM +0900, Ian Barwick wrote:
> > > > Standard regression tests are helpful because patch authors include new
> > > > test
> > > > cases in the patch
On Fri, Dec 5, 2014 at 09:29:59AM -0300, Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > On Fri, Nov 28, 2014 at 01:43:36PM +0900, Ian Barwick wrote:
> > > Standard regression tests are helpful because patch authors include new
> > > test
> > > cases in the patches that stress their new options
On 12/5/14, 9:08 AM, José Luis Tallón wrote:
More over, when load goes up, the relative cost of parallel working should go
up as well.
Something like:
p = number of cores
l = 1min-load
additional_cost = tuple estimate * cpu_tuple_cost * (l+1)/(c-1)
(for c>1, of course)
...
Adam,
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
> I have attached an updated patch that incorporates the feedback and
> recommendations provided.
Thanks. Comments below.
> diff --git a/src/backend/access/transam/xlogfuncs.c
> b/src/backend/access/transam/xlogfuncs.c
>
On Fri, Dec 5, 2014 at 1:07 PM, Peter Geoghegan wrote:
> Agreed. Importantly, we won't have painted ourselves into a corner
> where we cannot add it later, now that RETURNING projects updates
> tuples, too (V1.5 established that).
Yeah, it seems fine to postpone that to a later version, as long a
On Fri, Dec 5, 2014 at 10:00 AM, Josh Berkus wrote:
> I thought the point of INSERT ... ON CONFLICT update was so that you
> didn't have to care if it was a new row or not?
>
> If you do care, it seems like it makes more sense to do your own INSERTs
> and UPDATEs, as Django currently does.
>
> I w
* Magnus Hagander (mag...@hagander.net) wrote:
> On Wed, Nov 26, 2014 at 8:01 PM, Stephen Frost wrote:
> > As such, I'd like to propose changing the default to be
> > 'include_realm=1'.
>
> Per our previous discussions, but to make sure it's also on record for
> others, +1 for this suggestion
All,
I have attached an updated patch that incorporates the feedback and
recommendations provided.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend/acces
On 12/05/2014 07:59 AM, Robert Haas wrote:
> I think it's probably an important distinction, for the kinds of
> reasons Anssi mentions, but we should look for some method other than
> a system column of indicating it. Maybe there's a magic function that
> returns a Boolean which you can call, or m
On Fri, Dec 5, 2014 at 1:49 AM, Rahila Syed wrote:
>>If that's really true, we could consider having no configuration any
>>time, and just compressing always. But I'm skeptical that it's
>>actually true.
>
> I was referring to this for CPU utilization:
> http://www.postgresql.org/message-id/14104
On Fri, Dec 5, 2014 at 3:11 AM, Amit Langote
wrote:
>> I think you are right. I think in this case we need something similar
>> to column pg_index.indexprs which is of type pg_node_tree(which
>> seems to be already suggested by Robert). So may be we can proceed
>> with this type and see if any on
On Fri, Dec 5, 2014 at 2:18 AM, Amit Kapila wrote:
> Do we really need to support dml or pg_dump for individual partitions?
I think we do. It's quite reasonable for a DBA (or developer or
whatever) to want to dump all the data that's in a single partition;
for example, maybe they have the table
On Tue, Dec 2, 2014 at 10:43 PM, Amit Langote
wrote:
>> So, we're going to support exactly two levels of partitioning?
>> partitions with partissub=false and subpartitions with partissub=true?
>> Why not support only one level of partitioning here but then let the
>> children have their own pg_pa
On Sat, Dec 6, 2014 at 12:49 AM, Robert Haas wrote:
> On Thu, Dec 4, 2014 at 8:45 AM, Michael Paquier
> wrote:
> >> Here is patch which renames action_at_recovery_target to
> >> recovery_target_action everywhere.
> > Thanks, Looks good to me.
> >
> > A couple of things that would be good to docu
On Thu, Dec 4, 2014 at 1:27 PM, Peter Geoghegan wrote:
> On Thu, Dec 4, 2014 at 3:04 AM, Craig Ringer wrote:
>> Yes, I think that's pretty important. With a negative attno so it's
>> treated as a "hidden" col that must be explicitly named to be shown and
>> won't be confused with user columns.
>
On Thu, Dec 4, 2014 at 8:45 AM, Michael Paquier
wrote:
>> Here is patch which renames action_at_recovery_target to
>> recovery_target_action everywhere.
> Thanks, Looks good to me.
>
> A couple of things that would be good to document as well in
> recovery-config.sgml:
> - the fact that pause_at_r
On Wed, Dec 3, 2014 at 5:17 PM, Tom Lane wrote:
> David Fetter writes:
>> On Wed, Dec 03, 2014 at 05:52:03PM -0500, Tom Lane wrote:
>>> What do you mean "reconstruct the enum"?
>
>> Capture its state at the time when IMPORT FOREIGN SCHEMA is executed.
>> Right now, if you try IMPORT SCHEMA on a f
On 2014-12-06 00:10:11 +0900, Michael Paquier wrote:
> On Sat, Dec 6, 2014 at 12:06 AM, Michael Paquier
> wrote:
>
> >
> >
> >
> > On Fri, Dec 5, 2014 at 11:10 PM, Rahila Syed
> > wrote:
> >
> >> I attempted quick review and could not come up with much except this
> >>
> >> + /*
> >> +* Ca
Amit,
* Amit Kapila (amit.kapil...@gmail.com) wrote:
> postgres=# explain select c1 from t1;
> QUERY PLAN
> --
> Seq Scan on t1 (cost=0.00..101.00 rows=100 width=4)
> (1 row)
>
>
> postgres=# set parallel_seqscan_degree=
José,
* José Luis Tallón (jltal...@adv-solutions.net) wrote:
> On 12/04/2014 07:35 AM, Amit Kapila wrote:
> >The number of worker backends that can be used for
> >parallel seq scan can be configured by using a new GUC
> >parallel_seqscan_degree, the default value of which is zero
> >and it means p
On Sat, Dec 6, 2014 at 12:06 AM, Michael Paquier
wrote:
>
>
>
> On Fri, Dec 5, 2014 at 11:10 PM, Rahila Syed
> wrote:
>
>> I attempted quick review and could not come up with much except this
>>
>> + /*
>> +* Calculate the amount of FPI data in the record. Each backup block
>> +* takes
On 12/04/2014 07:35 AM, Amit Kapila wrote:
[snip]
The number of worker backends that can be used for
parallel seq scan can be configured by using a new GUC
parallel_seqscan_degree, the default value of which is zero
and it means parallel seq scan will not be considered unless
user configures thi
On Fri, Dec 5, 2014 at 11:10 PM, Rahila Syed
wrote:
> I attempted quick review and could not come up with much except this
>
> + /*
> +* Calculate the amount of FPI data in the record. Each backup block
> +* takes up BLCKSZ bytes, minus the "hole" length.
> +*
> +* XXX: We peek
[ reviving a very old thread ]
On Tue, Feb 10, 2009 at 4:11 PM, Tom Lane wrote:
> Alvaro Herrera writes:
>> For example, maybe we could keep track of counts of snapshots removed
>> since the last xmin calculation, and only run this routine if the number
>> is different from zero (or some small p
On Fri, Dec 5, 2014 at 7:12 PM, Heikki Linnakangas
wrote:
> On 12/05/2014 04:54 AM, Michael Paquier wrote:
>
>> Hi all,
>>
>> While reading the code in this area this morning, I noticed that
>> wal_log_hints and track_commit_timestamp are not mentioned in the desc
>> routine of XLOG_CHANGE_PARAME
* Andres Freund (and...@2ndquadrant.com) wrote:
> Is the 'Only allow superusers to signal superuser-owned backends' check
> actually safe that way? I personally try to never use a superuser role
> as the login user, but grant my account a superuser role that doesn't
> inherit. But IIRC PGPROC->role
On 2014-12-05 09:28:13 -0500, Stephen Frost wrote:
> static int
> pg_signal_backend(int pid, int sig)
> {
> @@ -113,7 +117,12 @@ pg_signal_backend(int pid, int sig)
> return SIGNAL_BACKEND_ERROR;
> }
>
> - if (!(superuser() || proc->roleId == GetUserId()))
> + /* On
* Stephen Frost (sfr...@snowman.net) wrote:
> * Stephen Frost (sfr...@snowman.net) wrote:
> > > 3. It messes around with pg_signal_backend(). There are currently no
> > > cases in which pg_signal_backend() throws an error, which is good,
> > > because it lets you write queries against pg_stat_acti
I attempted quick review and could not come up with much except this
+ /*
+* Calculate the amount of FPI data in the record. Each backup block
+* takes up BLCKSZ bytes, minus the "hole" length.
+*
+* XXX: We peek into xlogreader's private decoded backup blocks for the
+* hole
On 12/01/2014 02:44 PM, Teodor Sigaev wrote:
Initial message:
http://www.postgresql.org/message-id/5447b3ff.2080...@sigaev.ru
Second version fixes a forgotten changes in pg_am.
+ /* Get the information we need about each relevant datatypes */
+
+ if (OidIsValid(ca
* Robert Haas (robertmh...@gmail.com) wrote:
> On Thu, Dec 4, 2014 at 3:59 PM, Stephen Frost wrote:
> > I have a hard time wrapping my head around what a *lot* of our users ask
> > when they see a given error message, but if our error message is 'you
> > must have a pear-shaped object to run this
On 11/27/2014 02:28 PM, Mats Erik Andersson wrote:
Hello there,
I would like to improve error recovery of initdb when the
password file is empty. The present code declares "Error 0"
as the cause of failure. It suffices to use ferrer() since
fgets() returns NULL also at a premature EOF.
Thanks,
Bruce Momjian wrote:
> On Fri, Nov 28, 2014 at 01:43:36PM +0900, Ian Barwick wrote:
> > Standard regression tests are helpful because patch authors include new test
> > cases in the patches that stress their new options or commands. This new
> > test
> > framework needs to be something that inter
On Fri, Nov 28, 2014 at 01:43:36PM +0900, Ian Barwick wrote:
> Standard regression tests are helpful because patch authors include new test
> cases in the patches that stress their new options or commands. This new test
> framework needs to be something that internally runs the regression tests an
On 2 December 2014 at 15:36, Craig Ringer wrote:
> On 12/01/2014 09:51 PM, Marco Nenciarini wrote:
> > I think this is a leftover, as you don't use elog afterwards.
>
> Good catch, fixed.
>
>
I've looked over this again and tested it on a windows 8.1 machine. I
cannot find any problems
The only
On 12/05/2014 02:30 AM, Matt Newell wrote:
The explanation of PQgetFirstQuery makes it sound pretty hard to match
up the result with the query. You have to pay attention to PQisBusy.
PQgetFirstQuery should also be valid after
calling PQgetResult and then you don't have to worry about PQisBusy
On 12/05/2014 07:29 AM, Adam Brightwell wrote:
All,
I've noticed that 'check-world' fails for dummy_seclabel after a 'clean'.
I believe that in commit da34731, the EXTRA_CLEAN statement should have
been removed from 'src/test/modules/dummy_seclabel/Makefile' as well.
Ah, that's why those files
On 12/05/2014 04:54 AM, Michael Paquier wrote:
Hi all,
While reading the code in this area this morning, I noticed that
wal_log_hints and track_commit_timestamp are not mentioned in the desc
routine of XLOG_CHANGE_PARAMETER. Also, it is not mentioned in
postgresql.conf.sample that a value update
From: Amit Kapila [mailto:amit.kapil...@gmail.com]
Sent: Friday, December 05, 2014 5:10 PM
To: Amit Langote
Cc: Jim Nasby; Robert Haas; Andres Freund; Alvaro Herrera; Bruce Momjian; Pg
Hackers
Subject: Re: [HACKERS] On partitioning
On Fri, Dec 5, 2014 at 12:27 PM, Amit Langote
wrote:
> From:
On 12/05/2014 02:31 AM, Andres Freund wrote:
On 2014-12-05 08:58:33 +0900, Michael Paquier wrote:
On Fri, Dec 5, 2014 at 8:09 AM, Andres Freund
wrote:
On 2014-12-04 16:26:02 +0200, Heikki Linnakangas wrote:
Yeah, that's broken.
I propose the attached. Or does anyone want to argue for adding
On Fri, 2014-12-05 at 00:21 -0800, Peter Geoghegan wrote:
> On Thu, Dec 4, 2014 at 10:27 PM, Anssi Kääriäinen
> wrote:
> > For Django's use case this is a requirement. We must inform the user if
> > the save() action created a new row or if it modified an existing one.
>
> Can you explain that in
On Thu, Dec 04, 2014 at 02:42:41PM +0200, Heikki Linnakangas wrote:
> On 10/06/2014 04:21 PM, Heikki Linnakangas wrote:
> >This probably needs some further cleanup before it's ready for
> >committing. One issues is that it creates a temporary cluster that
> >listens for TCP connections on localhost
On Thu, Dec 4, 2014 at 10:27 PM, Anssi Kääriäinen
wrote:
> For Django's use case this is a requirement. We must inform the user if
> the save() action created a new row or if it modified an existing one.
Can you explain that in more detail, please?
> Another way to do this would be to expose the
From: Amit Kapila [mailto:amit.kapil...@gmail.com]
On Fri, Dec 5, 2014 at 12:27 PM, Amit Langote
wrote:
> From: Amit Kapila [mailto:amit.kapil...@gmail.com]
> On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote
> wrote:
> >
> > > The more SQL way would be records (composite types). That would make
On Fri, Dec 5, 2014 at 12:27 PM, Amit Langote
wrote:
> From: Amit Kapila [mailto:amit.kapil...@gmail.com]
> On Thu, Dec 4, 2014 at 10:46 AM, Amit Langote <
langote_amit...@lab.ntt.co.jp> wrote:
> >
> > > The more SQL way would be records (composite types). That would make
> > > catalog inspection
70 matches
Mail list logo
