to core anyway (or open source)
> why wouldn't we just do that? Why wouldn't EDB develop directly within the
> Pg infrastructure. Why wouldn't we build teams around the best and
> brightest between EDB, 2Q and Citus?
>
> Egos.
>
> Consider PgLogical, who is working on this outside of
ch is the root cause of those
secondary effects.
I don't think the current focus on manually intensive DDL partitioning is
the right way forwards. I did once; I don't now.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
zzing or a way to backtrack to find what broke. Not much point
finding bugs we can't identify later.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 28 April 2016 at 22:30, David G. Johnston <david.g.johns...@gmail.com>
wrote:
> On Thursday, April 28, 2016, Simon Riggs <si...@2ndquadrant.com> wrote:
>
>> On 27 April 2016 at 17:04, Craig Ringer <cr...@2ndquadrant.com> wrote:
>>
>>> On 27 Apri
orruption!)
>>
>>
> Looks good.
>
> The docs on fsync are already good, it's just a matter of making people
> think twice and actually look at them.
>
If fsync=off and you turn it on, does it fsync anything at that point?
Or does it mean only that future fsyncs will
t;
> Let me know if you'd like me to update the TODO.
>
If you've got an itch, expecting someone else to scratch it is less likely
to succeed.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 18 April 2016 at 13:15, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 18 April 2016 at 12:43, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>
>> On Sat, Apr 16, 2016 at 5:37 AM, Alvaro Herrera
>> <alvhe...@2ndquadrant.com> wrote:
>> > A
, an alternate solution may be better.
If things are sequential, both sides can +1 as appropriate. So an extra
message isn't required to confirm that. We can resync with optional
additional info at various points. Requesting cancellation of a former
sequence number can still be blocked.
we try postgresql.
The default setting would be simply 'postgresql', so no match -> syntax
error.
We could make that easier by making the postgresql parser a plugin itself.
So to produce a new one you just copy the files, modify them as needed then
insert a new record into pg_language as a
what we should do. For
> HEAD, let's add that in the commit record.
>
(non-reply just because of travel)
OK, I'll write up a patch today to fix, with a view to backpatching.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 15 April 2016 at 20:01, Andres Freund <and...@anarazel.de> wrote:
> On 2016-04-15 19:59:06 +0100, Simon Riggs wrote:
> > For me, the issue is that we need to do something to catch bugs. The
> > existing code does not have any test at all to check whether we are doin
st at all to check whether we are doing
the wrong thing - it just lets the wrong thing happen.
Fixing it by forcing a new behaviour might be the right thing to do going
forwards, but I don't much like the idea of forcing new behaviour in back
branches. It might fix this bug, but can easily cause others.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
how that's a
> conflict.
>
If everything is going to be discussed here, that's great, no conflict.
I've got lots of changes I would personally like to make, but we need to
get something in first before we start doing more.
I'll look back at the review comments, thanks.
--
Simon R
On 14 April 2016 at 02:05, Andres Freund <and...@anarazel.de> wrote:
> Hi,
>
> On 2016-04-13 09:38:39 +0100, Simon Riggs wrote:
> > If we want this in 9.7
>
> I desperately want logical replication for 9.7. And I'm planning to put
> in a good chunk of work to make t
On 13 April 2016 at 17:48, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Apr 13, 2016 at 4:38 AM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> > Anyway, who agrees with the overall design of pglogical and who does not?
>
> I haven't spent very much tim
to build up a library of test cases over
time to assist with that.
If we agree this is worth further work, I'll take responsibility for it in
9.7.
Anyway, who agrees with the overall design of pglogical and who does not?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.
On 12 April 2016 at 13:53, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Apr 11, 2016 at 5:45 PM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> > On 8 April 2016 at 17:49, Robert Haas <robertmh...@gmail.com> wrote:
> >> With the patch, you can - i
On 12 April 2016 at 07:58, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Tue, Apr 12, 2016 at 3:15 AM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
>
>> On 8 April 2016 at 17:49, Robert Haas <robertmh...@gmail.com> wrote:
>>
>>
>>> With
o apply when things might change the answer from a
SELECT, whereas this affects only the default for a plan.
Can I change this to a lower setting? I would have done this before
applying the patch, but you beat me to it.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.
> multiplication 1? An image histogram 1000?
>
We don't have a clear methodology for how to do this.
It's a single parameter to allow you to achieve the plans that work
optimally. Hopefully that is simple enough for everyone to use and yet
flexible enough to make a difference.
If its not wha
very similar function SyncRepGetOldestSyncRecPtr() in
> syncrep.c. Which makes me think that GetOldestWALSendPointer()
> no longer needs to be maintained. So, is it time to remove that unused
> function?
>
Seems sensible cleanup to me.
--
Simon Riggshttp://www.2ndQuadrant.com/
<htt
will write a patch doing this if there are no objections. I
> think this is justifiable as clean-up for 9.6.
>
Yeh, sort has changed enough now that fixes weren't going to backpatch
cleanly, so its a good time to do cleanup.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www
riously
> considered.
>
I would likely have said this myself but didn't even get that far.
Your contribution was useful and went further than anybody else's review,
so thank you.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
mprovement.
I can't commit a patch that has a reported bug against it, nor can we fix
the problem if we can't reproduce it.
If we do get a committable patch, that is then the time to make a case to
RMT, but not before.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 8 April 2016 at 20:13, Tom Lane <t...@sss.pgh.pa.us> wrote:
> I will make it a high priority for 9.7, though.
>
That is my plan also. I've already started reviewing the non-planner parts
anyway, specifically patch 0002.
--
Simon Riggshttp://www.2ndQuadrant.com/
rallelism unless they manhandle
> their configuration settings to force it.
>
Does this concern apply to this patch, or to the general situation for 9.6.
Please suggest what you would like to see.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
eadlines don't matter and
that's not a useful position.
2) If you commit what you have, someone else might be able to see a bug you
cannot
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
st framework needs a WaitForLSN function to allow us to know
for certain that something has been delivered.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 7 April 2016 at 12:23, Simon Riggs <si...@2ndquadrant.com> 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 colum
to remove that parameter that before release.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> Ping.
>
We agree its a bug, so the deadline doesn't need to constrain us.
I suggest we should apply what we have then fix the rest later when we work
out how.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 6 April 2016 at 22:28, David Rowley <david.row...@2ndquadrant.com> wrote:
> On 7 April 2016 at 09:25, Simon Riggs <si...@2ndquadrant.com> wrote:
> > On 5 April 2016 at 19:33, Robert Haas <robertmh...@gmail.com> wrote:
> >
> >>
> >> Committe
ow? I don't see anything about combining aggs in the
git log and this is still showing as UnCommitted in the CF app.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 6 April 2016 at 15:17, Andres Freund <and...@anarazel.de> wrote:
> On 2016-04-06 14:30:21 +0100, Simon Riggs wrote:
> > On 6 April 2016 at 14:15, Craig Ringer <cr...@2ndquadrant.com> wrote:
> > ...
> >
> > Nice summary
> >
> > F
ed for a while,
so I'll call that "good catch" then.
Perhaps easy to solve, but how do we test it is solved?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ts in 9.6 would prevent us from
having something else later, if someone else writes it.
We don't need to add this to core. Each plugin can independently write is
own failover code. Works, but doesn't seem like the right approach for open
source.
=> I think we should add Failover Slots to 9.6
d consensus is
not appropriate and certainly not clear. We did all agree on the point that
the earlier fix cannot be backpatched, so if it is as grevious a problem as
described many users will not now benefit.
I will revert my earlier patch now.
--
Simon Riggshttp://www.2ndQuadrant.c
On 6 April 2016 at 13:27, Andres Freund <and...@anarazel.de> wrote:
> On 2016-04-06 13:11:40 +0100, Simon Riggs wrote:
> > On 6 April 2016 at 10:09, Andres Freund <and...@anarazel.de> wrote:
> > > On 2016-04-06 10:04:42 +0100, Simon Riggs wrote:
> > > The i
On 6 April 2016 at 10:09, Andres Freund <and...@anarazel.de> wrote:
> On 2016-04-06 10:04:42 +0100, Simon Riggs wrote:
> > On 6 April 2016 at 09:45, Andres Freund <and...@anarazel.de> wrote:
> >
> > > On 2016-04-06 09:18:54 +0100, Simon Riggs wrote:
> >
On 6 April 2016 at 12:24, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Apr 6, 2016 at 4:18 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
> >> FWIW, I vote also for reverting this patch. This has been committed
> >> without any real discussions..
> &g
ase explain how we cope without this, so if a problem remains we can fix
by the freeze.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ient to cover my concerns about what others might expect
from this feature. Could we add similar wording to the docs?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 6 April 2016 at 09:45, Andres Freund <and...@anarazel.de> wrote:
> On 2016-04-06 09:18:54 +0100, Simon Riggs wrote:
> > Rather than take that option, I went to the trouble of writing a patch
> that
> > does the same thing but simpler, less invasive and more maintainab
On 5 April 2016 at 01:18, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Mon, Apr 4, 2016 at 4:50 PM, Andres Freund <and...@anarazel.de> wrote:
> > On 2016-04-04 08:44:47 +0100, Simon Riggs wrote:
> >> That patch does exactly the same thing as the pa
lock wait mode where it sits in the normal lock
queue BUT other lock requestors are allowed to queue jump past it. That
should be just a few lines changed in the lock conflict checker and some
sleight of hand in the lock queue code.
That way we avoid the busy-wait loop and multiple DEFER
> N could make sense. ;-(
However, in most cases, k > N would not make sense and we should issue a
WARNING.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 5 April 2016 at 11:23, Fujii Masao <masao.fu...@gmail.com> wrote:
> On Tue, Apr 5, 2016 at 6:09 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> > On 5 April 2016 at 08:58, Amit Langote <langote_amit...@lab.ntt.co.jp>
> > wrote:
> >
> >>
>
e beginning of SyncRepReleaseWaiters(),
> they don't need to perform any operations that the patch adds
> (e.g., find out which standbys are synchronous).
>
I was thinking about the overhead of scanning through the full list of
WALSenders for each message, when it is a sync standby.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
h a code you suspect a bug. Not mentioning that
> > static code analyzers (I'm currently experimenting with Clang and PVS
> > Studio) complain about code like this.
>
> There's different comments in both branches...
Then one or both of the comments is incomplete.
--
Simon Riggs
On 5 April 2016 at 10:10, Fujii Masao <masao.fu...@gmail.com> wrote:
> On Mon, Apr 4, 2016 at 6:45 PM, Andres Freund <and...@anarazel.de> wrote:
> > On 2016-04-04 10:35:34 +0100, Simon Riggs wrote:
> >> On 4 April 2016 at 09:28, Fujii Masao <masao.fu...@gma
ange SyncRepGetOldestSyncRecPtr() so that it returns
the k'th oldest pointer of any named standby. Then use that to wake up user
backends. So the change requires only slightly modified logic in a very
isolated part of the code, almost all of which would be code inserts to
cope with the new
On 4 April 2016 at 10:35, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 4 April 2016 at 09:28, Fujii Masao <masao.fu...@gmail.com> wrote:
>
>
>> Barring any objections, I'll commit this patch.
>>
>
> That sounds good.
>
> May I have one more day
ething like {26.6,435.12} rather than \x1234...
>
> Thoughts?
Rewriting something that works fine just before the deadline isn't a good
plan.
"Might be better" isn't enough.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 4 April 2016 at 10:45, Andres Freund <and...@anarazel.de> wrote:
>
> Simon, perhaps you could hold the above question in your mind while
> looking through this?
>
Sure, np.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Post
thing at
all to say on it.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3 April 2016 at 22:44, Simon Riggs <si...@2ndquadrant.com> wrote:
> Detailed comments in the planner part of the patch. The discussion around
> this patch isn't reflected enough in the patch.
>
I think we should record that the planner uses the constraint, even if the
constr
so have marked it Ready For Committer.
I marked myself as Committer to show there was interest in this. If anyone
else would like to commit it, I am happy for you to do so.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x
n discouraged for many years, so
asking a long term contributor to avoid sending multiple minor patches is
in line with that.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 3 April 2016 at 22:09, Tomas Vondra <tomas.von...@2ndquadrant.com> wrote:
> On 04/03/2016 10:06 PM, Simon Riggs wrote:
>
>> On 14 March 2016 at 19:42, Tomas Vondra <tomas.von...@2ndquadrant.com
>> <mailto:tomas.von...@2ndquadrant.com>> wrote:
>>
>&
On 3 April 2016 at 21:32, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 14 March 2016 at 17:46, David Steele <da...@pgmasters.net> wrote:
>
>> On 2/24/16 12:40 AM, Michael Paquier wrote:
>>
>> This has the merit to be clear, thanks for the input. Whatever
This can always be refactored in the
> future if/when the use of flags spreads.
>
XLogInsertExtended() is the one I would commit, if.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
this be 1) Tomas, 2) Tomas + David ?
I'd be inclined to see a little more explanatory docs on this.
Have we done any tests on planning overhead for cases where multiple FKs
exist?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ges won't be available in core until late 2017 now.
Given that, please save up all your desired changes to pgbench and submit
in one go nearer the next CF. Thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remot
d get
> run all the time rather than just when somebody feels like it (which is
> probably almost never, if at all).
>
> Would somebody like to volunteer?
>
That was under my maintenance, so I'm happy to do that, as long as its
after freeze.
--
Simon Riggshttp://ww
ed in over a month and is clearly not in final form
> as it exists today.
>
> Therefore, I have marked this Returned with Feedback. I look forward
> to returning to this topic for 9.7, and I'm willing to step up to the
> plate and review this more aggressively at that time, with
On 21 March 2016 at 14:35, David Fetter <da...@fetter.org> wrote:
> On Mon, Mar 21, 2016 at 01:33:28PM +, Robert Haas wrote:
> > Support parallel aggregation.
>
> ...and there was much rejoicing!
>
+1
Well done all.
--
Simon Riggshttp://www.2ndQ
, the members of the RMT are Álvaro Herrera,
Robert Haas, and Noah Misch.
Please give them your full support in making this another high quality
release for PostgreSQL.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remo
On 10 March 2016 at 11:38, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 10 March 2016 at 09:22, Michael Paquier <michael.paqu...@gmail.com>
> wrote:
>
>> On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin <r...@simply.name>
>> wrote:
>> > Let’s
reams I strongly
> suspect people will want to use it for "real" work rather than have to
> modify each client driver to support replication protocol extensions.
>
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 10 March 2016 at 20:36, Thomas Munro <thomas.mu...@enterprisedb.com>
wrote:
> On Fri, Mar 11, 2016 at 8:50 AM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
> > On 3 February 2016 at 23:12, Thomas Munro <thomas.mu...@enterprisedb.com
> >
> > wrote:
>
in a couple of weeks and I'd like to
see this in there.
Let's set good standards for responsiveness and correctness.
I'd also like to see some theory in comments and an explanation of why
we're doing this (code).
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.
hat has no downside for users, I respectfully
> disagree.
Not sure what y'all are discussing, but I should add that I would have
committed this based solely upon Vik's +1.
My objection was made, then overruled; that works because the objection
wasn't "it won't work", only a prefer
gt;> actually, and I don't see a single clear +1 vote for this
> >> functionality upthread. (Apologies if I've missed one.) In the
> >> absence of a few of those, I recommend we reject this.
> >
> > +1
>
> I'm meh for this patch.
>
"meh" == +1
I
ng down/reality and a good spellcheck.
If someone takes this on soon it can go into 9.6, otherwise I vote to
reject this early to avoid wasting review time.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 25 February 2016 at 07:42, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
> Hello,
>
> At Wed, 17 Feb 2016 09:13:01 +0000, Simon Riggs <si...@2ndquadrant.com>
> wrote in <
> canp8+jlbge_ybxulgzxvce44oob8v0t93e5_inhvbde2pxk...@mail.gmail.com>
you've been around long enough to know that patches need docs and
tests. And as Robert says, comments that show you've done the analysis to
show you know the patch is safe.
Some parts of this patch could be resubmitted in a later CF with some time
and attention spent on it, but it isn't in a good eno
lier patch.
This could be easily back-patched more easily.
toast_recheck.v1.patch
Adds recheck code for toast access. I'm not certain this is necessary, but
here it is. No problems found with it.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
Postgr
On 10 March 2016 at 06:27, Michael Paquier <michael.paqu...@gmail.com>
wrote:
> On Thu, Mar 10, 2016 at 1:29 AM, David Steele <da...@pgmasters.net> wrote:
> > On 1/8/16 9:34 AM, Alvaro Herrera wrote:
> >> Simon Riggs wrote:
> >>>
> >>
On 3 March 2016 at 10:11, Tobias Florek <postg...@ibotty.net> wrote:
> Hi,
>
> > Reverted patch in HEAD and 9.5
>
> Is there an ETA?
>
I just committed the fix to the repo.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/
On 2 March 2016 at 10:57, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 1 March 2016 at 20:03, Tom Lane <t...@sss.pgh.pa.us> wrote:
>
>
>> In any event, I am now of the opinion that this patch needs to be reverted
>> outright and returned to the authors
clearly something fixable.
ISTM that we are clearly "going for it"; everybody agrees we should apply
the patch now.
The longer we hold off on applying it, the longer we wait for dependent
changes.
My vote is apply it early (i.e. now!) and clean up as we go.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
. I don't want to add the last CF workload
with this.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> > numeric column to integer, so I'm not very sure where to look. Who's
> > touched btree key comparison logic lately?
> >
> > (Problem is reproducible in 9.5 and HEAD, but not 9.4.)
>
>
> Bisects down to:
>
> 606c0123d627b37d5ac3f7c2c97cd715dde7842f is the fi
k going in at the last minute. Not
with relish, just so that understanding isn't limited to the usual suspects
of feature-crime.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
more so if the impact is caused by one minor table that nobody much cares
about.
What I see as more practical is reducing the scope of "safe transactions"
down to "safe scopes", where particular tables or sets of tables are known
safe at particular times, so we know more about which
On 27 February 2016 at 07:52, Konstantin Knizhnik <k.knizh...@postgrespro.ru
> wrote:
> On 02/27/2016 04:16 AM, Simon Riggs wrote:
>
> On 27 February 2016 at 00:33, Simon Riggs <si...@2ndquadrant.com> wrote:
>
>> On 27 February 2016 at 00:29, Andres Fre
rmediate states becoming visible. So that would be the
preferred mechanism.
Collecting a list of transactions that must be applied before the current
one could be accumulated during SSI processing and added to the commit
record. But reordering the transaction apply is something we'd need to get
som
On 27 February 2016 at 01:23, Andres Freund <and...@anarazel.de> wrote:
> On 2016-02-27 01:16:34 +0000, Simon Riggs wrote:
> > If the above is true, then the proposed fix wouldn't work either.
> >
> > No point in sending a cache invalidation message on the standby if y
On 27 February 2016 at 00:33, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 27 February 2016 at 00:29, Andres Freund <and...@anarazel.de> wrote:
>
>> On 2016-02-26 18:05:55 +0300, Konstantin Knizhnik wrote:
>> > The reason of the problem is that invalidat
he. But as far as this transaction is not assigned XID,
> no
> > transaction record is created in WAL and send to replicas. As a result,
> > replica doesn't receive this invalidation messages.
>
> Ugh, that's a fairly ugly bug.
Looking now.
--
Simon Riggshttp://www.
be saying that SSI allows transactions to commit in a
non-serializable order.
Do you have a test case?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
gt; table row count for a given FDW table, but that then leaks into the
> user-application driving these queries.
>
Look at TABLESAMPLE, which does mostly what you're asking.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 25 February 2016 at 18:42, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Feb 25, 2016 at 11:38 PM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
>
>> On 24 February 2016 at 23:26, Amit Kapila <amit.kapil...@gmail.com>
>> wrote:
>>
the tests are repeated twice or thrice, it
> is easily visible.
>
Not seen that on the original patch I posted. 6150a1b0 contains multiple
changes to the lwlock structures, one written by me, others by Andres.
Perhaps we should revert that patch and re-apply the various changes in
multiple commits so
t my hope is that we recognize that multiple use cases can be
supported rather than a single fixed architecture. It seems likely to me
that the PostgreSQL project will do what it does best - take multiple
comments and merge those into a combined system that is better than any of
the individual single
lf, which seems to do the job, so apologies to
give this opinion on your work, I do hope it doesn't put you off further
contributions.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
nt patch to put in
some diagnostics if such cases show up again, which could happen now we
have user-defined timeouts.
What surprises me is that I can't see this patch ever worked as submitted,
when run on an assert-enabled build.
If you want this backpatched, please submit versions th
On 14 February 2016 at 00:03, Jeff Janes <jeff.ja...@gmail.com> wrote:
> I've attached a new version, incorporating comments from Tom and Michael.
>
Applied, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Develop
amounts of memory. Or do you have some evidence that it does?
I think we should fix it, but not backpatch.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
s finished?
>
> How about looking into pg_control? ControlFileData->state ought to have
> the correct information.
>
+1
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
501 - 600 of 8408 matches
Mail list logo
