On Sun, Mar 27, 2016 at 9:01 AM, Tom Lane wrote:
> Peter Geoghegan writes:
>> Will this make it into the next point release? I was rather hoping it would.
>
> I dunno. I certainly haven't reviewed it carefully enough to commit it.
> Perhaps Peter has, but time grows short ...
I have looked at t
On Sun, Mar 27, 2016 at 8:15 AM, Thomas Munro
wrote:
> Realistically I'm not going to have a solution to the third problem
> before the 31st.
Ping.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
On 2016/04/07 15:26, Fujii Masao wrote:
> On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila wrote:
>> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao wrote:
>>> Yes if the variable that we'd like to pass to a backend is BOOL, INT,
>>> REAL, STRING or ENUM. But SyncRepConfig variable is a bit more
>>> comp
On 7 April 2016 at 08:55, Michael Paquier wrote:
> On Sun, Mar 27, 2016 at 8:15 AM, Thomas Munro
> wrote:
> > Realistically I'm not going to have a solution to the third problem
> > before the 31st.
>
> Ping.
>
We agree its a bug, so the deadline doesn't need to constrain us.
I suggest we shou
Thank you Robert. Sure, I will add the updated patch on the next CommitFest
with all the suggested changes.
On Wed, Apr 6, 2016 at 9:06 PM, Robert Haas wrote:
> On Wed, Apr 6, 2016 at 3:32 AM, Asif Naeem wrote:
> >> Oh, I see. I think it's probably not a good idea to skip truncating
> >> those
On Thu, Apr 7, 2016 at 2:15 AM, Jim Nasby wrote:
> On 4/6/16 11:06 AM, Robert Haas wrote:
>
>> This is too late for 9.6 at this point and certainly requires
>> discussion anyway, so please add it to the next CommitFest.
>>
>
> If the goal here is to free up space via truncation when there's a rea
Hi,
I found "Do not include the table's name in the specification of a target column
— for example, UPDATE tab SET tab.col = 1 is invalid." in the
documentation.
Some people usually like to update table by alias. They want to add this
feature.
So I get the source in the gram.y
Hi,
pondering
http://archives.postgresql.org/message-id/CA%2BTgmoZJdA6K7-17K4A48rVB0UPR98HVuaNcfNNLrGsdb1uChg%40mail.gmail.com
et al I was wondering why it's a good idea for pgbench to do
INSTR_TIME_SET_CURRENT(start_time);
srandom((unsigned int) INSTR_TIME_GET_MICROSEC(start_time)
Hi,
On 2016-04-06 21:58:50 -0400, Robert Haas wrote:
> I spent a lot of time testing things on power2 today
Thanks for that!
> It's fairly mysterious to me why there is so much jitter in the
> results on this machine. By doing prewarming in a consistent fashion,
> we make sure that every disk ru
Hello Andres,
et al I was wondering why it's a good idea for pgbench to do
INSTR_TIME_SET_CURRENT(start_time);
srandom((unsigned int) INSTR_TIME_GET_MICROSEC(start_time));
to initialize randomness and then
for (i = 0; i < nthreads; i++)
thread->random_sta
On 2016-04-07 11:56:12 +0200, Fabien COELHO wrote:
> (2) runs which really vary from one to the next, so as
> to have an idea about how much it may vary, what is the
> performance stability.
I don't think this POV makes all that much sense. If you do something
non-comparable, then the r
Hi,
On 2016-04-06 20:03:20 +0200, Petr Jelinek wrote:
> Attached patch adds filtering of both database and origin. Added tests with
> slightly less hardcoding than what you proposed above.
Not a fan of creating & dropping another database - that's really rather
expensive. And we're in a target th
(2) runs which really vary from one to the next, so as
to have an idea about how much it may vary, what is the
performance stability.
I don't think this POV makes all that much sense. If you do something
non-comparable, then the results aren't, uh, comparable. Which also
means there
On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote
wrote:
>
> On 2016/04/07 15:26, Fujii Masao wrote:
> > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila
wrote:
> >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao
wrote:
> >>> Yes if the variable that we'd like to pass to a backend is BOOL, INT,
> >>> REAL,
On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote:
>
> >> (2) runs which really vary from one to the next, so as
> >> to have an idea about how much it may vary, what is the
> >> performance stability.
> >
> >I don't think this POV makes all that much sense. If you do something
> >non-comp
On Thu, Apr 7, 2016 at 3:26 AM, Simon Riggs wrote:
> We agree its a bug, so the deadline doesn't need to constrain us.
I'm not sure there is consensus across the community on that.
> I suggest we should apply what we have then fix the rest later
> when we work out how.
On that, I agree. I wil
Hello Andres,
If you run the test for longer... Or explicitly iterate over IVs. At the
very least we need to make pgbench output the IV used, to have some
chance of repeating tests.
Note that I'm not against providing a way to repeat tests "exactly", and I
have suggested two means: environme
On 7 April 2016 at 00:15, Tomas Vondra wrote:
> Right. Fixed.
0001 committed. I added comments and a fastpath when no triggers are
present.
For 0002, I would be more comfortable adding
enable_fk_plans = on (true) | off
even if we decided to remove that parameter that before release.
--
On Thu, Apr 7, 2016 at 7:29 PM, Amit Kapila wrote:
> On Thu, Apr 7, 2016 at 1:30 PM, Amit Langote
> wrote:
>>
>> On 2016/04/07 15:26, Fujii Masao wrote:
>> > On Thu, Apr 7, 2016 at 2:48 PM, Amit Kapila
>> > wrote:
>> >> On Thu, Apr 7, 2016 at 10:02 AM, Fujii Masao
>> >> wrote:
>> >>> Yes if the
Hi,
On 04/07/2016 01:23 PM, Simon Riggs wrote:
On 7 April 2016 at 00:15, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
Right. Fixed.
0001 committed. I added comments and a fastpath when no triggers are
present.
For 0002, I would be more comfortable adding
enable_fk_plans
On 7 April 2016 at 12:23, Simon Riggs wrote:
> For 0002
>
For find_best_foreign_key_quals() how can this ever match 2 FKs with
different keys?
The fkrel references the foreignrel, which has a single PK. How can the FK
have a different number of columns to the PK?
Assuming that is possible/makes
On Thu, Apr 7, 2016 at 5:56 AM, Fabien COELHO wrote:
> I think that it depends on what you want, which may vary:
>
> (1) "exactly" reproducible runs, but one run may hit a particular
> steady state not representative of what happens in general.
>
> (2) runs which really vary from one to the
On Thu, Apr 7, 2016 at 10:16 AM, Andres Freund wrote:
>
> Hi,
>
> On 2016-04-07 09:14:00 +0530, Amit Kapila wrote:
> > On Sat, Apr 2, 2016 at 5:25 PM, Amit Kapila
wrote:
> > I have ran exactly same test on intel x86 m/c and the results are as
below:
>
> Thanks for running these tests!
>
> > Clien
On 2016-04-07 08:58:16 -0400, Robert Haas wrote:
> On Thu, Apr 7, 2016 at 5:56 AM, Fabien COELHO wrote:
> > I think that it depends on what you want, which may vary:
> >
> > (1) "exactly" reproducible runs, but one run may hit a particular
> > steady state not representative of what happens
On 2016-04-07 18:40:14 +0530, Amit Kapila wrote:
> On Thu, Apr 7, 2016 at 10:16 AM, Andres Freund wrote:
> >
> > Hi,
> >
> > On 2016-04-07 09:14:00 +0530, Amit Kapila wrote:
> > > On Sat, Apr 2, 2016 at 5:25 PM, Amit Kapila
> wrote:
> > > I have ran exactly same test on intel x86 m/c and the resu
On Thu, Apr 7, 2016 at 9:15 AM, Andres Freund wrote:
> It's not about "covering it up"; it's about actually being able to take
> action based on benchmark results, and about practically being able to
> run benchmarks. The argument above means essentially that we need to run
> a significant number
On 2016-03-31 20:21:02 +0300, Alexander Korotkov wrote:
> ! BEGIN_BUFSTATE_CAS_LOOP(bufHdr);
>
> ! Assert(BUF_STATE_GET_REFCOUNT(state) > 0);
> ! wasDirty = (state & BM_DIRTY) ? true : false;
> ! state |= BM_DIRTY | BM_JUST_DIRTIED;
> ! if (state == oldstate)
> !
Andres Freund writes:
> On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote:
>> So I have no mathematical doubt that changing the seed is the right default
>> setting, thus I think that the current behavior is fine. However I'm okay if
>> someone wants to control the randomness for some reason (mayb
On Thu, Apr 7, 2016 at 4:39 AM, postgres_sure wrote:
> Hi,
>
> I found "Do not include the table's name in the specification of a target
> column
> — for example, UPDATE tab SET tab.col = 1 is invalid." in
> the documentation.
>
> Some people usually like to update table by alias.
On Thu, Apr 7, 2016 at 10:42 PM, Kevin Grittner wrote:
> On Thu, Apr 7, 2016 at 3:26 AM, Simon Riggs wrote:
>
>> We agree its a bug, so the deadline doesn't need to constrain us.
>
> I'm not sure there is consensus across the community on that.
>
>> I suggest we should apply what we have then fix
On Thu, Apr 7, 2016 at 4:41 PM, Andres Freund wrote:
> On 2016-03-31 20:21:02 +0300, Alexander Korotkov wrote:
> > ! BEGIN_BUFSTATE_CAS_LOOP(bufHdr);
> >
> > ! Assert(BUF_STATE_GET_REFCOUNT(state) > 0);
> > ! wasDirty = (state & BM_DIRTY) ? true : false;
> > ! state |= BM_DIRTY |
On Wed, Apr 6, 2016 at 5:15 PM, Jim Nasby wrote:
> On 4/6/16 11:06 AM, Robert Haas wrote:
>> This is too late for 9.6 at this point and certainly requires
>> discussion anyway, so please add it to the next CommitFest.
>
> If the goal here is to free up space via truncation when there's a real
> em
On 2016-04-07 09:46:27 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2016-04-07 12:25:58 +0200, Fabien COELHO wrote:
> >> So I have no mathematical doubt that changing the seed is the right default
> >> setting, thus I think that the current behavior is fine. However I'm okay
> >> if
> >>
Sorry for not responding to this thread again sooner. I was on
vacation Thursday-Sunday, and have been playing catch-up since then.
On Sun, Apr 3, 2016 at 8:24 AM, Tomas Vondra
wrote:
> Secondly, master is faster only if there's enough on-CPU cache for the
> replacement sort (for the memtuples h
It means that you can't separate between OS caused, and pgbench order
caused performance differences.
I'm not objecting to adding an option for this; but I think Fabien is
right that it shouldn't be the default.
Yep.
Andres, attached is a simple POC with an option & environment variable
(w
On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier
wrote:
> On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier
> wrote:
>> Here are few things I have noticed:
>> + for (i = 0; i < max_wal_senders; i++)
>> + {
>> + walsnd = &WalSndCtl->walsnds[i];
>> No volatile pointer to prevent code reorder
David Rowley writes:
> I've attached an updated patch which introduces JOIN_INNER_UNIQUE and
> JOIN_LEFT_UNIQUE. So unique inner joins no longer borrow JOIN_SEMI.
OK.
> In EXPLAIN, I named these new join types "Unique Inner" and "Unique
> Left".
Hm. I'm back to being unhappy about the amount o
On 7 April 2016 at 14:48, Merlin Moncure wrote:
>
> On Thu, Apr 7, 2016 at 4:39 AM, postgres_sure wrote:
> > Hi,
> >
> > I found "Do not include the table's name in the specification of a target
> > column
> > — for example, UPDATE tab SET tab.col = 1 is invalid." in
> > the docu
On 7 April 2016 at 15:51, I wrote:
> ::=
> UPDATE
> SET
> WHERE CURRENT OF
I grabbed the wrong section of the doc; I should of course have pasted
the searched version:
::=
UPDATE
SET
[ WHERE ]
M
On Tue, Apr 5, 2016 at 10:34 PM, Craig Ringer wrote:
>> Right, but right now you probably *aren't* do doing any kind of
>> logical decoding from a master server to a standby, because there's
>> squat in the core distribution that could make use of that capability.
>> So you never get as far as dis
On Thu, Apr 7, 2016 at 6:48 PM, Andres Freund wrote:
>
> On 2016-04-07 18:40:14 +0530, Amit Kapila wrote:
> > This is the data with -b tpcb-like@1 with 20-min run for each version
and I
> > could see almost similar results as the data posted in previous e-mail.
> >
> > Client Count/Patch_ver (tps)
Alvaro Herrera wrote:
Thanks for looking into that patch!
> regression=# select * from pg_class \crosstabview relnatts
> \crosstabview: missing second argument
> regression-#
Fixed. This was modelled after the behavior of:
select 1 \badcommand
but I've changed to mimic what happens w
On Mon, Apr 4, 2016 at 8:38 PM, Peter Geoghegan wrote:
> On Sun, Apr 3, 2016 at 2:09 PM, Jeff Janes wrote:
>> Also, HOT-cleanup should stop the bloat increase once the snapshot
>> crosses the old_snapshot_threshold without even needing to wait until
>> the next autovac runs.
>>
>> Does the code i
Geoff Winkless writes:
> I grabbed the wrong section of the doc; I should of course have pasted
> the searched version:
> ::=
> UPDATE
> SET
> [ WHERE ]
> My point is still the same though :)
Don't know which version of the SQL spec you're looki
Fabien COELHO wrote:
> While testing it I had a funny pattern, something like:
>
> pgbench --random-seed=123 -M prepared -T 3 -P 1 -S
> 1.0: 600 tps
> 2.0: 600 tps
> 3.0: 600 tps
The output should include the random seed used, whether it was passed
with --random-seed, environment variabl
On 04/04/2016 09:20 PM, Michael Paquier wrote:
Likely an oversight not tracked by the buildfarm. What are you using here?
It should be a rather unspectactular Debian system. I have tried a
bunch of different compilers and optimization options, without success.
I'll keep looking.
--
Sent
06.04.2016 23:52, Peter Geoghegan:
On Wed, Apr 6, 2016 at 1:50 PM, Peter Geoghegan wrote:
Personally, I like documenting assertions, and will sometimes write
assertions that the compiler could easily optimize away. Maybe going
*that* far is more a matter of personal style, but I think an
assert
On Thu, Apr 7, 2016 at 8:49 AM, Thomas Munro
wrote:
> Here is a version that includes an attempt to describe the
> situation in the documentation.
Pushed with minor adjustments to the docs. Mostly I thought your
new text was more appropriate as just another paragraph than as a
"note". The prev
Magnus Hagander wrote:
> On Wed, Mar 30, 2016 at 7:47 PM, Alvaro Herrera
> wrote:
>
> > José Luis Tallón wrote:
> >
> > > Just wanted to suggest two minor mods to the review e-mails
> > > auto-generated by the app:
> > >
> > > * Prepend a [review] tag to the e-mail subject
> > > ... so th
On 04/07/2016 01:22 AM, Michael Paquier wrote:
On Wed, Mar 23, 2016 at 1:47 AM, David Steele wrote:
On 3/16/16 12:19 PM, David Steele wrote:
Hi Peter,
On 3/9/16 3:08 PM, Michael Paquier wrote:
Here are some comments about 0002
<...>
I think that we had better do something like the attache
On 7 April 2016 at 16:45, Tom Lane wrote:
> Don't know which version of the SQL spec you're looking at,
It was the draft 95 version, cos (being text file) it's easiest to
read :). I'll learn my lesson next time and expand the 2008 one.
> but SQL:2008 has
>
> ::=
> UPDATE [ [ AS ] ]
>
"postgres_sure" writes:
> I found "Do not include the table's name in the specification of a target
> column
> â for example, UPDATE tab SET tab.col = 1 is invalid." in
> the documentation.
> Some people usually like to update table by alias. They want to add this
> feature.
On Thu, Apr 7, 2016 at 6:55 AM, Robert Haas wrote:
>> In reality there will be multiple processes running at the same time (e.g
>> backends when running parallel query), significantly reducing the amount of
>> cache per process, making the replacement sort inefficient and thus
>> eliminating the r
Stephen Frost writes:
> In pg_dump, include pg_catalog and extension ACLs, if changed
This patch added a regression test step that creates some roles
and doesn't drop them again. This is unacceptable, because
(1) it breaks the ability to do "make installcheck" more than once.
(2) it leaves rol
Tom,
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> It'd be possible to fix (1) by adding "drop if exists", but I think the
> whole thing is wrongheaded due to (2). Perhaps the needs of the test
> could be met by granting/revoking some rights explicitly to current_user
> (ie, the test superuser)? That
On 07/04/16 12:26, Andres Freund wrote:
Hi,
On 2016-04-06 20:03:20 +0200, Petr Jelinek wrote:
Attached patch adds filtering of both database and origin. Added tests with
slightly less hardcoding than what you proposed above.
Not a fan of creating & dropping another database - that's really ra
Peter Eisentraut writes:
> On 04/04/2016 09:20 PM, Michael Paquier wrote:
>> Likely an oversight not tracked by the buildfarm. What are you using here?
> It should be a rather unspectactular Debian system. I have tried a
> bunch of different compilers and optimization options, without success.
On Mon, Mar 21, 2016 at 2:01 AM, Peter Geoghegan wrote:
> On Thu, Mar 17, 2016 at 1:13 PM, Robert Haas wrote:
>> OK, I have now committed 0001
>
> I attach a revision of the external quicksort patch and supplementary
> small patches, rebased on top of the master branch.
I spent some time today r
On Thu, Apr 7, 2016 at 1:17 PM, Peter Geoghegan wrote:
>> I certainly agree that GUCs that aren't easy to tune are bad. I'm
>> wondering whether the fact that this one is hard to tune is something
>> that can be fixed. The comments about "padding" - a term I don't
>> like, because it to me impli
On Thu, Apr 7, 2016 at 11:05 AM, Robert Haas wrote:
> I spent some time today reading through the new 0001 and in general I
> think it looks pretty good.
Cool.
> 1. Changing cost_sort to consider disk access as 90% sequential, 10%
> random rather than 75% sequential, 25% random. As far as I can
On 07/04/16 17:32, Robert Haas wrote:
Second, I'm not sure whether it was a good design decision to make
logical slots a special kind of object that sit off to the side,
neither configuration (like postgresql.conf) nor WAL-protected data
(like pg_clog and the data files themselves), but it was ce
David Rowley writes:
> [ unique_joins_2016-04-07.patch ]
Just had a thought about this, which should have crystallized a long
time ago perhaps. Where I'd originally imagined you were going with
this idea is to do what the thread title actually says, and check for
joins in which the *outer* side
Tom Lane wrote:
> Anyway, while refactoring the make_join_rel/add_paths_to_joinrel division
> of labor wouldn't be such a big deal in itself, I don't want to commit a
> change to JoinType only to undo it later; that would be too much churn.
> So I think we need to resolve this question before we c
* Petr Jelinek wrote:
On 07/04/16 00:50, Michael Paquier wrote:
On Thu, Apr 7, 2016 at 7:44 AM, Michael Paquier
wrote:
On Thu, Apr 7, 2016 at 6:11 AM, Petr Jelinek
wrote:
On 06/04/16 22:50, Andrew Dunstan wrote:
* VS2015 appears to create version 12 solution files, not
version 14
* Magnus Hagander wrote:
On Tue, Mar 29, 2016 at 5:09 PM, David Steele wrote:
It seems like this patch should be set "ready for committer". Can one of
the reviewers do that if appropriate?
I'll pick it up to do that as well as committing it.
Magnus, do you intend to commit the patch be
Alvaro Herrera writes:
> Tom Lane wrote:
>> I don't know if you have time to look at this now --- my clock says it's
>> already Friday morning in New Zealand.
> FWIW the feature freeze rules state that it is allowed for a committer
> to request an extension to the feature freeze date for individu
Daniel Verite wrote:
> > regression=# select * from pg_class \crosstabview relnatts
> > \crosstabview: missing second argument
> > regression-#
>
> Fixed. This was modelled after the behavior of:
> select 1 \badcommand
> but I've changed to mimic what happens with:
> select 1 \g /some/invali
All, Andres,
Now that we have begun removing the if (!superuser) checks and instead
relying on the GRANT system to determine who is allowed to call certain
functions, it's time to consider functions beyond the initial set.
In particular, the pg_logical_* functions have superuser checks and
those
Robert, José,
I've rebased this on top of master and added a few additional checks and
regression tests.
I'm planning to continue going over the patch tomorrow morning with
plans to push this before the feature freeze deadline.
Thanks!
Stephen
From a0724d91ffd1a93034d5b5d5df2b4ff54339d763 Mon S
On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote:
>
> * Magnus Hagander wrote:
>
>> On Tue, Mar 29, 2016 at 5:09 PM, David Steele
wrote:
>
>
>>> It seems like this patch should be set "ready for committer". Can one
of
>>> the reviewers do that if appropriate?
>
>
>> I'll pick it up to do that a
I wonder if the business of appending values of multiple columns
separated with spaces is doing us any good. Why not require that
there's a single column in the cell? If the user wants to put things
together, they can use format() or just || the fields together. What
benefit is there to the ' '?
On 04/07/2016 09:50 PM, Stephen Frost wrote:
Robert, José,
I've rebased this on top of master and added a few additional checks and
regression tests.
Applies and compiles cleanly, of course. Passes all 164 tests, too.
- make installcheck-world ok
- interdiff checked, nothing very surprising
*
Alvaro Herrera wrote:
> Daniel Verite wrote:
> > > * A few examples in docs. The psql manpage should have at least two new
> > > examples showing the crosstab features, one with the simplest case you
> > > can think of, and another one showing all the features.
> >
> > Added that in the EXAMPLES
On Thu, Apr 7, 2016 at 1:26 PM, Alvaro Herrera
wrote:
> I wonder if the business of appending values of multiple columns
> separated with spaces is doing us any good. Why not require that
> there's a single column in the cell? If the user wants to put things
> together, they can use format() or
On Wed, Apr 6, 2016 at 9:52 AM, Teodor Sigaev wrote:
> I'm inclining to push v3.1 as one of two winners by size/performance and,
> unlike to pending lock patch, it doesn't change an internal logic of lock
> machinery.
This restricts the memory used by ordinary backends when doing the
cleanup to
On Thu, Apr 7, 2016 at 11:10 AM, Robert Haas wrote:
> I prefer units of tuples, with the GUC itself therefore being
> unitless. I suggest we call the parameter replacement_sort_threshold
> and document that (1) the ideal value may depend on the amount of CPU
> cache available to running processes
Jeff Janes wrote:
> The proposed change removes that throttle, so that inserters will
> immediately see there is already a cleaner and just go back about
> their business. Due to that, unthrottled backends could add to the
> pending list faster than the cleaner can clean it, leading to
> unbounde
On Sun, Apr 3, 2016 at 4:09 PM, Jeff Janes wrote:
> On Wed, Mar 30, 2016 at 12:34 PM, Kevin Grittner wrote:
>> On Sat, Mar 19, 2016 at 1:27 AM, Jeff Janes wrote:
>>> I set the value to 1min.
>>>
>>> I set up a test like this:
>>>
>>> pgbench -i
>>>
>>> pgbench -c4 -j4 -T 3600 &
>>>
>>> ### watc
Daniel Verite wrote:
> > * In the "if (cont.cells[idx] != NULL && cont.cells[idx][0] != '\0')"
> > block (line 497 in the attached), can't we do the same thing by using
> > psprintf?
>
> In that block, we can't pass a cell contents as a valist and be done with
> that cell, because duplicates of (
On Mon, Apr 4, 2016 at 9:15 PM, Peter Geoghegan wrote:
> The patch does this:
>
>> --- a/src/backend/access/heap/pruneheap.c
>> +++ b/src/backend/access/heap/pruneheap.c
>> @@ -92,12 +92,21 @@ heap_page_prune_opt(Relation relation, Buffer buffer)
>> * need to use the horizon that includes sl
On Thu, Apr 7, 2016 at 3:56 PM, Kevin Grittner wrote:
>> Unfortunately, this does stop recycling from
>> happening early for B-Tree pages, even though that's probably safe in
>> principle. This is probably not so bad -- it just needs to be
>> considered when reviewing this patch (the same is true
Magnus Hagander writes:
> On Apr 7, 2016 9:14 PM, "Christian Ullrich" wrote:
>> Magnus, do you intend to commit the patch before the feature freeze?
> It's on my list of things to work on this weekend, yeah.
But the stated feature freeze deadline is tomorrow (Friday), not the
weekend or later.
Jeff Janes writes:
> To summarize the behavior change:
> In the released code, an inserting backend that violates the pending
> list limit will try to clean the list, even if it is already being
> cleaned. It won't accomplish anything useful, but will go through the
> motions until eventually it
I wrote:
> Alvaro Herrera writes:
>> FWIW the feature freeze rules state that it is allowed for a committer
>> to request an extension to the feature freeze date for individual
>> patches:
>> https://www.postgresql.org/message-id/CA%2BTgmoY56w5FOzeEo%2Bi48qehL%2BBsVTwy-Q1M0xjUhUCwgGW7-Q%40mail.gma
On 04/06/2016 04:50 PM, Andrew Dunstan wrote:
On 03/29/2016 09:38 PM, Robert Haas wrote:
On Tue, Mar 29, 2016 at 9:29 PM, Andrew Dunstan
wrote:
I am currently travelling, but my intention is to deal with the
remaining
patches when I'm back home this weekend, unless someone beats me to it.
On Thu, Apr 7, 2016 at 4:33 PM, Tom Lane wrote:
> Jeff Janes writes:
>> To summarize the behavior change:
>
>> In the released code, an inserting backend that violates the pending
>> list limit will try to clean the list, even if it is already being
>> cleaned. It won't accomplish anything usefu
On 03/14/2016 09:44 PM, Peter Geoghegan wrote:
On Mon, Mar 14, 2016 at 4:11 PM, Peter Geoghegan wrote:
Yes, with one small difference: I wouldn't be calling ERR_get_error()
in the common case where SSL_get_error() returns SSL_ERROR_NONE, on
the theory that skipping that case represents no risk.
On Fri, Apr 8, 2016 at 9:29 AM, Andrew Dunstan wrote:
> Not out of the woods yet. Attached is what I got from VS2015 on a fresh W10
> VM, with Michael's patch 0002 and 0004 applied.
Interesting, I have no idea what we are doing differently, and seeing
those errors it seems to me that Petr and I a
On 04/07/2016 03:47 AM, Michael Paquier wrote:
I have looked at this patch. Do we need to worry as well about
SSL_shutdown in disconnection code path? I believe that we don't care
much if an error happens at this point but we surely should consume
any error generated because the SSL context is ke
On Thu, Apr 7, 2016 at 6:08 PM, Peter Eisentraut wrote:
> I wish we could avoid the huge, repeated comment blocks. Perhaps we could
> put them at the top of the files once?
I'm fine with that. Do you want to take care of that, or should I?
> Also, why do you write 0UL instead of just 0?
Becaus
On Fri, Apr 8, 2016 at 10:23 AM, Peter Eisentraut wrote:
> On 04/07/2016 03:47 AM, Michael Paquier wrote:
>>
>> I have looked at this patch. Do we need to worry as well about
>> SSL_shutdown in disconnection code path? I believe that we don't care
>> much if an error happens at this point but we s
On Thu, Apr 7, 2016 at 8:20 AM, Tom Lane wrote:
> Robbie Harwood writes:
>> Tom Lane writes:
>>> Wait a second. So the initial connection-request packet is necessarily
>>> unencrypted under this scheme?
>
>> Yes, by necessity. The username must be sent in the clear, even if only
>> as part of
On 7 April 2016 at 23:32, Robert Haas wrote:
> > Yeah. I understand the reasons for that decision. Per an earlier reply I
> > think we can avoid making them WAL-logged so they can be used on standbys
> > and still achieve usable failover support on physical replicas.
>
> I think at one point we
On Thu, Apr 7, 2016 at 11:10 AM, Robert Haas wrote:
> I prefer units of tuples, with the GUC itself therefore being
> unitless. I suggest we call the parameter replacement_sort_threshold
> and document that (1) the ideal value may depend on the amount of CPU
> cache available to running processes
On Wed, Apr 6, 2016 at 8:23 PM, Fujii Masao wrote:
>
> Okay, I pushed the patch!
> Many thanks to all involved in the development of this feature!
>
Hi,
I spotted a couple of places in the documentation that still implied there
was only one synchronous standby. Please see suggested fixes attach
On Fri, Apr 8, 2016 at 12:55 PM, Thomas Munro
wrote:
> On Wed, Apr 6, 2016 at 8:23 PM, Fujii Masao wrote:
>>
>> Okay, I pushed the patch!
>> Many thanks to all involved in the development of this feature!
>
>
> Hi,
>
> I spotted a couple of places in the documentation that still implied there
> w
On Tue, Apr 05, 2016 at 03:22:03PM +0900, Etsuro Fujita wrote:
> On 2016/04/04 20:35, Michael Paquier wrote:
> >On Mon, Apr 4, 2016 at 7:49 PM, Etsuro Fujita
> > wrote:
> >>Here is a patch to fix this issue. As proposed by Michael, I modified
> >>execute_dml_stmt so that it uses PQsendQueryParams,
On Wed, Apr 6, 2016 at 10:49 PM, Julien Rouhaud
wrote:
>
> On 06/04/2016 07:38, Amit Kapila wrote:
> > On Tue, Apr 5, 2016 at 11:55 PM, Julien Rouhaud
> >>
> >> In alter_table.sgml, I didn't comment the lock level needed to modify
> >> parallel_degree since it requires an access exclusive lock for
On Thu, Apr 7, 2016 at 11:43 PM, Fujii Masao wrote:
> On Wed, Apr 6, 2016 at 5:04 PM, Michael Paquier
> wrote:
>> On Wed, Apr 6, 2016 at 4:08 PM, Michael Paquier
>> wrote:
>>> Here are few things I have noticed:
>>> + for (i = 0; i < max_wal_senders; i++)
>>> + {
>>> + walsnd = &WalSnd
On Apr 8, 2016 1:13 AM, "Tom Lane" wrote:
>
> Magnus Hagander writes:
> > On Apr 7, 2016 9:14 PM, "Christian Ullrich"
wrote:
> >> Magnus, do you intend to commit the patch before the feature freeze?
>
> > It's on my list of things to work on this weekend, yeah.
>
> But the stated feature freeze
1 - 100 of 105 matches
Mail list logo
