Rob Butler <[EMAIL PROTECTED]> wrote on 18.04.2005, 15:05:20:
>
> > I'd say it's very not cool :) It's not we all
> > expected from PITR.
> > I recall now Simon mentioned about that and have it
> > in his TODO.
> > Other thing I don't un
oduced
DB2_EVALUNCOMMITTED and DB2_SKIPINSERTED flags provide PostgreSQL like
behaviour, new in the very latest release.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
priate response.
I'll correct this... though (for me) low prio fix should be done by
around last week Oct.
Apologies to Olivier and thanks to Bruce for re-raising the issue.
Best Regards,
Simon Riggs
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
ues against an
earlier thought to introduce more fine grained values for the
bgwriter's parameters, ISTM]
Also, what will Vacuum delay do to the O(N) effect of
FlushRelationBuffers when called by VACUUM? Will the locks be held for
longer?
I think we should do some tests while running a VACUUM
omes
more viable when it has an important problem to solve.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
s the stopping point mentioned in the docs.
> recovery_target_inclusive
This parameter allows you to specify whether you should stop AT/ON (i.e.
inclusive [<=]) or just before the recovery_target (i.e. exclusive
[<]).
I'll add a few more lines to the chapter to include those descr
Alvaro Herrera <[EMAIL PROTECTED]> wrote on 01.12.2004, 15:08:11:
> On Wed, Dec 01, 2004 at 10:03:40AM +0000, Simon Riggs wrote:
>
> > Please shave 20% off everybody's aggregation queries, ugly or not.
> > You'll see a lot of happy people.
>
> When w
. That would allow people who
understood the risk to disable the robustness in favour of performance
- which would be relatively safe when using the built-in aggregate
functions.
I'll commit to doing some hard testing on this, if we agree to implement
it.
Thanks, Best Regards, Simon Riggs
-
orner of
the code is seems very high.
I'm pleased we found this, but changing it should be deferred till at
least 8.1. Perhaps a TODO item could read "investigating lwlock
scheduling algorithms"? We might yet find that there is no single right
answer and we need di
ng on. If
the bgwriter isn't writing enough, flushing the cache is pointless. If
the bgwriter is writing too much, then thats a waste and likely causing
buffer list contention.
> Simon, one of the problems with the OSDL-DBT2 test is that it's too steady.
> DBT2 gives a constant s
ist, as is the case in 8.0RC1,
allowing the bgwriter to act more frequently at lower cost.
There's some evidence that the second algorithm may be better, but may
have other characteristics or side-effects that we don't yet know. So
At this stage of the game, I'm happier not t
icient, even for benchmarks.
> We need a tuned bgwriter for this though.
Well, yes, you're right. ...but the bug limiting us to 255 files
restricts us there for higher performance situations.
Best Regards, Simon Riggs
---(end of broadcast)-
which option to pick. Without a set of
programs, or some driving force, the wrong one could be picked.
Spill-to-disk would not be that bad, since WARNINGs could appear in the
log. That's much better than doing a lock escalation, definitely.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
the lists, say every 50ms
to avoid backends having to write a buffer
2) less frequent, deeper cleaning actions, to minimise the effect of
checkpoints, which could be done every 10th cycle e.g. 500ms
(numbers would vary according to workload...)
But, like I said: change, but minimal ch
g the first 1% "over and over again" makes it sound like it is
the same list of blocks that are being cleaned. It may be the same
linked list data structure, but that is dynamically changing to contain
completely different blocks from the last time you looked.
Best Regards, Simon Riggs
---
Reinhard Max wrote on 12.01.2005, 11:17:52:
> On Wed, 12 Jan 2005 at 08:23, Simon Riggs wrote:
>
> > Not sure what is going on here: why is SUSE not listed on the supported
> > platforms list? (still)
> >
> > ...is it because Reinhard seems resistant
>
>
so I apologise now to both of you, and
to the list and hope this ends here.
We all look forward to SUSE being a listed port.
Best Regards, Simon Riggs
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
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 +, 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
1 - 100 of 8523 matches
Mail list logo
