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.2ndQuadrant.com/
On 27 February 2016 at 00:33, Simon Riggs wrote:
> On 27 February 2016 at 00:29, Andres Freund wrote:
>
>> On 2016-02-26 18:05:55 +0300, Konstantin Knizhnik wrote:
>> > The reason of the problem is that invalidation messages are not
>> delivered to
>> >
On 27 February 2016 at 01:23, Andres Freund 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 you
> > hav
intermediate 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
some
On 27 February 2016 at 07:52, Konstantin Knizhnik wrote:
> On 02/27/2016 04:16 AM, Simon Riggs wrote:
>
> On 27 February 2016 at 00:33, Simon Riggs wrote:
>
>> On 27 February 2016 at 00:29, Andres Freund wrote:
>>
>>> On 2016-02-26 18:05:55 +0300, Konstantin Kn
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
r of patches that still require work 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
ook. 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 first bad commit
> commit 606c0123d627b37d5ac3f7c2c97cd715dde7842f
&g
#x27;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
ikes. The read-only test is an 0.5% hit which isn't great, but the
> read-write test is about 5% which I think is clearly not OK. What's
> your plan for doing something about that?
>
Whether artefact of test, or real problem, clearly something fixable.
ISTM that w
On 2 March 2016 at 10:57, Simon Riggs wrote:
> On 1 March 2016 at 20:03, Tom Lane wrote:
>
>
>> In any event, I am now of the opinion that this patch needs to be reverted
>> outright and returned to the authors for redesign. There are too many
>> things wrong with
On 3 March 2016 at 10:11, Tobias Florek 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/>
PostgreSQL Developmen
On 10 March 2016 at 06:27, Michael Paquier
wrote:
> On Thu, Mar 10, 2016 at 1:29 AM, David Steele wrote:
> > On 1/8/16 9:34 AM, Alvaro Herrera wrote:
> >> Simon Riggs wrote:
> >>>
> >>> On 8 January 2016 at 13:36, Alvaro Herrera
> >>
e 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/>
PostgreSQL Development, 24x7 Support, Remote DBA
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 enough state for last CF.
--
Simon Riggs
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
> wrote in <
> canp8+jlbge_ybxulgzxvce44oob8v0t93e5_inhvbde2pxk...@mail.gmail.com>
> > On 17 February
pellcheck.
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
ote 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 thought it meant -1
--
Simon Riggs
gt; 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 preference so I'm happy.
But I
27;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.2ndquadrant.com/>
On 10 March 2016 at 20:36, Thomas Munro
wrote:
> On Fri, Mar 11, 2016 at 8:50 AM, Simon Riggs
> wrote:
> > On 3 February 2016 at 23:12, Thomas Munro >
> > wrote:
> >
> >>
> >> It quacks suspiciously like a bug.
> >
> >
> > Agreed
especially for !postgresql downstreams 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 11:38, Simon Riggs wrote:
> On 10 March 2016 at 09:22, Michael Paquier
> wrote:
>
>> On Thu, Mar 10, 2016 at 10:00 AM, Vladimir Borodin
>> wrote:
>> > Let’s do immediately after you will send a new version of your patch? Or
>> > even
, 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,
On 21 March 2016 at 14:35, David Fetter 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.2ndQuadrant.com/
<http:
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 an eye
> toward com
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://www.2ndQuadran
On 12 January 2016 at 18:14, Andres Freund wrote:
> Hi,
Thank you for the additional review.
> On 2016-01-11 19:39:14 +, Simon Riggs wrote:
> > Currently, the patch reuses all of the code related to reading/write
> state
> > files, so it is the minimal patch t
On 12 January 2016 at 12:53, Michael Paquier
wrote:
> On Tue, Jan 12, 2016 at 5:21 PM, Simon Riggs
> wrote:
> > Should we just move the code somewhere just to imply it is generic? Seems
> > pointless refactoring to me.
>
> Er, why not xlogutils.c? Having the 2PC co
On 13 January 2016 at 14:48, Noah Misch wrote:
> I've noticed commits, from a few of you, carrying pgindent changes to lines
> the patch would not otherwise change.
Could we review again why this matters?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2
the slot.
>
It sounds like this is already possible.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 16 January 2016 at 02:10, Noah Misch wrote:
> On Wed, Jan 13, 2016 at 12:13:11PM -0500, Tom Lane wrote:
> > Simon Riggs writes:
> > > On 13 January 2016 at 14:48, Noah Misch wrote:
> > >> I've noticed commits, from a few of you, carrying pgindent change
his if we are going to
discuss it here?
ISTM the wrong starting point to discuss plans in an unplanned way and
assume that everyone has time to take part today, right now.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Supp
release on time (Sept).
The main problem is the length of the integration phase, which is mostly
where nothing happens. We need to manage that process just as we do with
CFs.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
;peer review", we need peers that review.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
erform actions and yet aren't available.
Ultimately, we should decide to simply turn off that feature and release
anyway.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ng looks more like the 8.X series of release
> dates. Everyone might be fine with that, but we had better be prepared
> for November-February major release dates going forward.
>
I don't mind what month we pick, as long as we stick to the schedule.
--
Simon Riggshtt
On 20 January 2016 at 19:45, Robert Haas wrote:
> On Wed, Jan 20, 2016 at 2:26 PM, Tom Lane wrote:
> > and...@anarazel.de (Andres Freund) writes:
> >> On 2016-01-20 18:53:54 +, Simon Riggs wrote:
> >>> What is the point in having a special mailing
On 20 January 2016 at 20:29, Joshua D. Drake wrote:
> On 01/20/2016 10:53 AM, Simon Riggs wrote:
>
>> On 20 January 2016 at 15:40, Bruce Momjian > <mailto:br...@momjian.us>> wrote:
>>
>> Many people where happy with our consistent releasing major releases
we did the same thing for monotonic inserts into a btree, the
performance of ruling out any contents in the pending list would be O(1),
so it is more feasible than you say.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
un off into a
> > new standbydef.h that can be included from front-end code?
>
>
> That is how I've done it.
>
> The lock cancel patch applies over the header split patch.
>
This looks good to me, apart from some WhitespaceCrime.
Header split applied, will test and apply the main patch this week.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 5 January 2016 at 06:45, Simon Riggs wrote:
> On 4 January 2016 at 20:44, Alvaro Herrera
> wrote:
>
>
>> Maybe
>> there are more ALTER TABLE subcommands that should be setting something
>> up? In cases where multiple subcommands are being run, it might be
>&
hin this buffer is O(log(N)). But we can test
whether we need to search in the buffer at all with O(1).
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 21 January 2016 at 16:31, Robert Haas wrote:
> On Fri, Jan 1, 2016 at 7:50 PM, Simon Riggs wrote:
> > Failover Slots
> > In the current patch, any slot defined on a master will generate WAL,
> > leading to a pending-slot being present on all standby nodes. When a
>
t; imo. Additionally, afaics, it will only ever be 0 or 1.
>
Even better, we could make it add >1
> I think we should either remove that part of the log output, or make it
> display the number of segments added since the beginning of the
> checkpoint.
>
--
Simon Riggs
ng and
maintaining PostgreSQL. Whether the names are properly attributed will
always be a time-consuming task, but I will oppose any attempt to remove or
obscure evidence of who develops PostgreSQL, wherever that occurs.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndqua
On 22 January 2016 at 05:07, Noah Misch wrote:
> On Wed, Jan 20, 2016 at 06:58:24PM +0000, Simon Riggs wrote:
> > The main problem is the length of the integration phase, which is mostly
> > where nothing happens.
>
> The open items wiki page saw steady change from 30 A
for infinity.
>
+1
ERROR infinite result sets are not supported, yet
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
on.
(My suggested name for the new level is "replica"...)
2. Deprecate "archive" and "hot_standby" so that those will be removed in a
later release.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
bug break recovery,
> archiving and physical replication. And that doesn't seem to be acceptable.
> This is why we have to develop these as separate features.
>
> Should we think more about naming? Does two kinds of generic records
> confuse people?
>
Logical messages
Gene
ining we don't spend hours
performing them. Allowing very large values would make that even more
strange.
I would put a limit of 100,000 seconds = 27 hours.
Some systems offer a recovery_time_objective setting that is used to
control how frequently checkpoints occur. That might be a more u
you, allowing that problem to be
solved. We don't usually discuss that option here, since this is an
engineering list.
Since you've written the email here, I'd ask that you join our community
and use your knowledge and passion to make things happen.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t; smaller other value.
>
Hmm, looks like the != part attempted to wrap, but just didn't get it right.
Your patch looks right to me, so I will commit, barring objections... with
backpatch. Likely to 9.0, AFAICS.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://ww
stand in the way of someone else figuring out
> what makes sense there, but I don't intend to do it; and I don't think
> that the quick hacks I did over the last couple days make a reasonable
> basis for a permanent patch.
>
I think its worth adding log messages, but only wh
s record how many workers were available during
execution?
Is there a way to prevent execution if too few parallel workers are
available?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
to new. Why choose to break all extensions that do this? We could
easily keep this by making the old API assign locks out of a chunk called
"Old Extension API". Deprecate the old API and remove in a later release.
Like pretty much every other API we support.
We must respect that Extensio
ssage text. That would allow people to identify
messages without relying on people labelling everything correctly, as well
as writing filters that do not depend upon language.
I'm guessing this would require making the pre-translated error text
available to plugins as well as translated form.
t;messgage_id in my patch is
> just what offers the pre-translated error text to plugins.
OK, now I understand the patch, I am happy to apply it.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
t shows Standby or Master,
obviously not updated on crash.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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
y. 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
On 14 February 2016 at 00:03, Jeff Janes 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 Development, 24x7 Support, Rem
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 that apply cleanly and
test them. I'm less inclined to do tha
comments on the patch itself, 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
is the
timescale, but 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 tha
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 we can see
On 25 February 2016 at 18:42, Amit Kapila wrote:
> On Thu, Feb 25, 2016 at 11:38 PM, Simon Riggs
> wrote:
>
>> On 24 February 2016 at 23:26, Amit Kapila
>> wrote:
>>
>>> From past few weeks, we were facing some performance degradation in the
>>>
ven 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
> commit order to some other order (based on, for example, read-write
> dependencies) is not complete. If it does support that, it gives
> us a way forward for presenting consistent data on logical
> replicas.
>
You appear to be saying that SSI allows transactions to commit in a
non-seri
lutions, and also used by other databases, such as Oracle.
Corruption on the master would often cause errors that would prevent
writes and therefore those changes wouldn't even be made, let alone be
replicated.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Developme
I'm quite concerned about that as well.
This objection would apply to all other proposals as well, FDW etc..
Do you see some way to add flexibility yet without adding a branch
point in the code?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Re
On 22 August 2016 at 13:44, Kuntal Ghosh wrote:
> Please let me know your thoughts on this.
Do the regression tests pass with this option enabled?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
S
On 23 August 2016 at 08:56, Michael Paquier wrote:
> On Tue, Aug 23, 2016 at 7:34 AM, Gabriele Bartolini
> wrote:
I'd suggest rewording it a bit instead, please see attached.
> And of course this needs a backpatch.
Agreed, but I'd move all the comments above the bloc
s generated prior to starting to search.
Everything else looks in good order.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
On 22 August 2016 at 16:56, Simon Riggs wrote:
> On 22 August 2016 at 13:44, Kuntal Ghosh wrote:
>
>> Please let me know your thoughts on this.
>
> Do the regression tests pass with this option enabled?
Hi,
I'd like to be a reviewer on this. Please can you add this on
e the pain of change, should we also consider making WAL
files variable length? What do we gain by having the files all the
same size? ISTM better to have WAL files that vary in length up to 1GB
in size.
(This is all about XLOG_SEG_SIZE; I presume XLOG_BLCKSZ can stay as it
is, right?)
--
S
it is self evident, cos it
certainly isn't.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http:
anything.
> 5. Generalize the page type identification technique.
Why not do this first?
There are some coding guideline stuff to check as well.
Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ill be issuing more than one DDL command at
a time, so they'll be writing a script anyway.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ce.
That helps the few people who made such mistakes, but doesn't cause
massive change as a result.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On 27 August 2016 at 07:36, Amit Kapila wrote:
> On Fri, Aug 26, 2016 at 9:26 PM, Simon Riggs wrote:
>>
>> I think you should add this as part of the default testing for both
>> check and installcheck. I can't imagine why we'd have it and not use
>>
On 23 August 2016 at 14:57, Michael Paquier wrote:
> On Tue, Aug 23, 2016 at 9:48 PM, Gabriele Bartolini
> wrote:
>> Hi Simon and Michael,
>>
>> 2016-08-23 10:39 GMT+02:00 Simon Riggs :
>>>
>>> Agreed, but I'd move all the comments above
On 29 August 2016 at 12:34, Tom Lane wrote:
> Simon Riggs writes:
>> Fix pg_receivexlog --synchronous
>
> The buildfarm says you broke the 9.5 branch.
>
> In general, pushing inessential patches just a few hours before a wrap
> deadline is a dangerous business. Pushing
t dependent upon RmgrID at all.
If there are various special cases that we need to cater for, ISTM
they would be flaws in the existing WAL implementation rather than
anything we would want to perpetuate. I hope we'll spend time fixing
them rather than add loads of weird code to work around the
impe
quot;promote"
* Remove user configurable "trigger_file" mechanism - use
"promote.trigger" for all cases
* Remove Fallback promote mechanism, so all promotion is now "fast" in xlog.c
* Rename CheckForStandbyTrigger() to CheckForPromoteTrigger() for clarity
(Patch: rec
for only some functions.
What happens if your function calls some other function with
side-effects? How would you roll that back? How would you mark
functions for the general case?
Functions with side effects can't be tested with simple unit tests;
that has nothing to do with autonomous tra
patch to CF1.
>
> +1 for the idea. Looking at the patch it is taking a sane approach.
Apart from this one liner change we look good to go.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-
On 1 September 2016 at 06:34, Michael Paquier wrote:
> On Thu, Sep 1, 2016 at 1:15 AM, Simon Riggs wrote:
>> This is a summary of proposed changes to the recovery.conf API for
>> v10. These are based in part on earlier discussions, and represent a
>> minimal modifica
ntangle that right now, I'm posting what I have as-is, and I'll post
> an updated version tomorrow.
Thanks.
archive_cleanup_command no longer needs to be in shmem. Checkpointer
will have its own copy of the value.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL
On 1 September 2016 at 11:16, Robert Haas wrote:
> On Wed, Aug 31, 2016 at 7:02 PM, Simon Riggs wrote:
>> I'd prefer a solution that was not dependent upon RmgrID at all.
>>
>> If there are various special cases that we need to cater for, ISTM
>> they wo
it in the next CF. (Of course, I think they should just be
>> committed, but I would, wouldn't I?)
>>
>>
>
> I think the doc one should definitely go in and possibly be back-patched all
> the way to 9.4. I didn't look at the other one.
I agree the doc patch should g
On 12 April 2016 at 14:11, Simon Riggs wrote:
> On 12 April 2016 at 13:53, Robert Haas wrote:
>>
>> On Mon, Apr 11, 2016 at 5:45 PM, Simon Riggs
>> wrote:
>> > On 8 April 2016 at 17:49, Robert Haas wrote:
>> >> With the patch, you can - if you wish -
ery safe feeling.
I think the primary use for an rmgr filter might well be PostgreSQL developers.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.
for the new
CF, so review can start.
Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://ww
On 5 April 2016 at 18:34, Rod Taylor wrote:
>
>
> On Tue, Apr 5, 2016 at 1:10 PM, Simon Riggs wrote:
>>>
>>> If a lock is successfully obtained on one table, but not on all tables,
>>> it releases that lock and will retry to get them as a group in the fut
On 2 September 2016 at 13:16, Craig Ringer wrote:
> So I've moved it to xlog.c...
I'm pretty sure it shouldn't live in xlog.c, but there may be some
good reason I can't see yet.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 2
lement ATs
this way?
If somebody believes there is a better way for ATs, that is just an
optimization of the limits and can occur later, if the people who
believe there is a better way can prove that is the case and come up
with a patch. It's OK for features to go in now and have better
infrastr
e longer than the concept of pg_hba.conf,
which seems likely to become part of ALTER SYSTEM in future, so we
wouldn't really want the word "file" in there.
I've not seen anything yet to make me think a commit for this wouldn't
happen once we've worked the detail.
Thanks
On 24 August 2016 at 05:50, Michael Paquier wrote:
>>> Everything else looks in good order.
Committed. Thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailin
On 4 September 2016 at 04:50, Michael Paquier wrote:
> On Sun, Sep 4, 2016 at 8:05 AM, Michael Paquier
> wrote:
>> On Sun, Sep 4, 2016 at 1:57 AM, Simon Riggs wrote:
>>> On 24 August 2016 at 05:50, Michael Paquier
>>> wrote:
>>>
>>>>>&g
1 - 100 of 8500 matches
Mail list logo
