looking deeper: does this code also run for temp objects? Can
it be optimized for that case a little better?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-h
In what way does it not apply? Do you have a failure case?
--
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 subscr
ed a
> GUC along those lines, as well as docs. How does this look?
>
> It's late in the release cycle, but it would be nice to sneak this into v10.
> Using weak 1024 bit DH parameters is arguably a security issue; it was
> originally reported as such. There's a work-around for o
ned table seeing 1000 records all with roughly the same
name isn't helpful output from \d
\d would show tables but not partitions
\d would show partitions exist and how many
\d+ would show partition details
So the information would be available, just at different levels of
detail, just as
e shown in \d output, then I'd be happy if they were
>> identified as such rather than just 'table' (e.g 'partition table').
>
> +1.
+1 to remove partitions from \d display
With 1000 partitions that would just be annoying
--
Simon Riggshttp://www.2ndQuadrant.com/
y.
Surely NO SCROLL and WITH HOLD cursors would work fine?
--
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
TAP tests down from 2m50s
> (after the patches I posted yesterday) to 1m30s.
Patch looks good
> I think there's still gold to be mined, because "top" is still
> showing pretty low CPU load over most of the run, but this is
> lots better than 4m30s.
Thanks for looking into this
usal reads against writes to PoolM1 but not PoolM2,
yet PoolS2 does not provide causal reads against PoolM1 orPoolM2.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list
On 23 June 2017 at 19:25, Andres Freund <and...@anarazel.de> wrote:
> On 2017-06-23 19:21:57 +0100, Simon Riggs wrote:
>> On 23 June 2017 at 08:23, Simon Riggs <si...@2ndquadrant.com> wrote:
>> > On 23 June 2017 at 08:21, Andres Freund <and...@anarazel.de> wrote
On 23 June 2017 at 08:23, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 23 June 2017 at 08:21, Andres Freund <and...@anarazel.de> wrote:
>> On 2017-06-07 10:17:31 -0700, Andres Freund wrote:
>>> On 2017-05-08 09:12:13 -0400, Tom Lane wrote:
>>> >
On 23 June 2017 at 08:18, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 23 June 2017 at 06:45, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
>
>> I discovered a thinko in the new replication lag interpolation code
>> that can cause a strange number to be rep
On 21 June 2017 at 15:18, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 21 June 2017 at 16:15, Yugo Nagata <nag...@sraoss.co.jp> wrote:
>> On Wed, 21 Jun 2017 19:08:35 +0530
>> Kuntal Ghosh <kuntalghosh.2...@gmail.com> wrote:
>>
>>> O
On 23 June 2017 at 08:21, Andres Freund <and...@anarazel.de> wrote:
> On 2017-06-07 10:17:31 -0700, Andres Freund wrote:
>> On 2017-05-08 09:12:13 -0400, Tom Lane wrote:
>> > Simon Riggs <si...@2ndquadrant.com> writes:
>> > > So rearranged code a little t
On 23 June 2017 at 06:45, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> I discovered a thinko in the new replication lag interpolation code
> that can cause a strange number to be reported occasionally.
Thanks, will review.
--
Simon Riggshttp://www.2nd
> Attached is a patch for the documentation fix.
>> >
>> Please attach the patch as well. :-)
>
> I'm sorry, I forgot it. I attahed this.
Thanks, will apply.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Trai
ciate your efforts
> toward speedy resolution. Thanks.
>
> [1]
> https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
Thanks for letting me know. I'm on leave at present, so won't be able
to get to this until June 20, though will make it a prio
ne
> (sometimes with DYLD_LIBRARY_PATH, if needed) but when run via
> pg_regress, nothing worked.
I've not had that problem, though running it hasn't been trouble free.
So I guess there must be some sequence of actions that works.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Deve
Postgres11 then we must have a fully working patch
by start of Sept 2017, plus some analysis of all of the various
breakage points we are expecting to see. So lets do the analysis, so
we know how deep the mud is before we decide to walk through it.
--
Simon Riggshttp://www.2ndQu
an give an error if used against pre-10 data directory.
>
> I think it's just horribly dangerous to run any version of
> pg_resetxlog/pg_resetwal against any major version other than its
> own.
Just check the name of the directory so that pg_resetwal will refuse
to run against pg_x
On 27 May 2017 at 09:44, Erik Rijkers <e...@xs4all.nl> wrote:
> I am very curious at your results.
We take your bug report on good faith, but we still haven't seen
details of the problem or how to recreate it.
Please post some details. Thanks.
--
Simon Riggsh
On 26 May 2017 at 08:27, Erik Rijkers <e...@xs4all.nl> wrote:
> On 2017-05-26 08:58, Simon Riggs wrote:
>>
>> On 26 May 2017 at 07:10, Erik Rijkers <e...@xs4all.nl> wrote:
>>
>>> - Do you agree this number of failures is far too high?
>>> - Am I t
On 26 May 2017 at 07:10, Erik Rijkers <e...@xs4all.nl> wrote:
> - Do you agree this number of failures is far too high?
> - Am I the only one finding so many failures?
What type of failure are you getting?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Devel
On 11 May 2017 at 18:29, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 11 May 2017 at 18:13, Andres Freund <and...@anarazel.de> wrote:
>
>>>New patch, v3.
>>>
>>>Applying in 90 minutes, barring objections.
>>
>> Could you please wait till
ush today. I'd also like to take a
> look before...
Sure.
--
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 subscrip
from commit -> main either
1. 24 hours after commit
2. or earlier if we have a full set of green results from people
running the full suite on the commit tree
That way we don't have to polute the main tree with all this jumping around.
Many alternate ideas possible.
--
Simon Riggs
t; +* to avoid flooding the lag tracker on busy servers.
>> +*/
New patch, v3.
Applying in 90 minutes, barring objections.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Add-support-for-t
s for that, it has set me back some way but I'm better now and
have caught up with other matters. Petr nudged me to look at this
thread again yesterday, so I had been looking at this over last few
days.
Attached patch is Petr's patch, slightly rebased with added pacing
delay, similar to that used by
ittle to keep it lean.
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://www.postgresql.org/mailpref/pgsql-hackers
f clauses.
+1
> I would document it with the
> USING clause at the end, and have that be what psql supports and pg_dump
> produces. Since there are no WITH options now we should leave that out
> until it's required.
Let's record the target syntax in parser comments so we can just slot
thi
comments about it, nor handling of
intermediate messages while we process a large transaction.
I'll look at adding some pacing code in WalSndUpdateProgress()
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent
ug, but if it causes people to avoid running tests
then it is clearly a reliability issue.
I don't see anything to gain by waiting a year to apply this, so +1 to
move on it now.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
y step (3) above, which
is identifiable because it contains LSN of snapshot.
3. Read initial LSN from message then re-scan from LSN until
xl_running_xacts message collecting any commits/aborts and removing
them from snapshot.
No new WAL messages, no locking problem, race condition handled.
--
Simon
but without holding locks while
we log XLOG_RUNNING_XACTS, something that was considered painful for
Hot Standby.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hacke
.
Passes with and without Nikhil's new test.
I plan to apply both patches tomorrow morning my time to give time for
further comments.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
2PC_rework.v2.patch
Descrip
te for us to discuss.
--
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
On 25 April 2017 at 16:28, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Simon Riggs <si...@2ndquadrant.com> writes:
>> I can't see any reason now why overwriteOK should exist at all. I'm
>> guessing that the whole "overwriteOK" idea was an incorrect response
>
On 23 April 2017 at 17:17, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Simon Riggs <si...@2ndquadrant.com> writes:
>>> Also, when I fix that, it gets further but still crashes at the same
>>> Assert in SubTransSetParent. The proximate cause this time seems to be
>&
the wrong one.
Snapshots work differently on standbys - we store all known running
xids, so the test still passes correctly, even when overflowed.
I'd call that just plain luck. We behave correctly, but for the wrong
reasons, at least in this case.
> I don't see anything prevent wrong result
On 23 April 2017 at 18:41, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 23 April 2017 at 17:17, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Simon Riggs <si...@2ndquadrant.com> writes:
>>>> Also, when I fix that, it gets further but still crashes at th
On 23 April 2017 at 17:17, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Simon Riggs <si...@2ndquadrant.com> writes:
>>> Also, when I fix that, it gets further but still crashes at the same
>>> Assert in SubTransSetParent. The proximate cause this time seems to be
>&
hat, keeping a part
> of each of those words.
...and got that answer also.
For us "functional dependency" would sound like something to do with
functions (e.g. CREATE FUNCTION), so just "dependency" appears to me
to be the best term for this.
There are multiple statistics f
This just turned into a much larger can of worms than I expected.
> How can it be that processes are getting assertion crashes and yet the
> test framework reports success anyway? That's impossibly
> broken/unacceptable.
Agreed, thanks for fixing.
--
Simon Riggshttp:/
ay that I don't see how it could result in persistent
> corruption however - the subtrans lookups are only done for
> (snapshot->xmin, snapshot->xmax] and subtrans is truncated
> regularly. But these days CHECKPOINT_END_OF_RECOVERY isn't obligatory
> anymore, so that might be d
as "false", but in reality the subtrans link in
> question has already been set.
Not sure about that, investigating.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers ma
TE STATISTICS s1 (dependencies, ndistinct) WITH (options) ON (a,
b) FROM t1 WHERE partial-stuff;
2.
USING keyword, no brackets
CREATE STATISTICS s1 USING (dependencies, ndistinct) ON (a, b) FROM t1
WHERE partial-stuff;
and if there are options, use the WITH for the optional parameters like this
CREATE STATISTICS
On 22 April 2017 at 06:45, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> Thanks. I'm away from my computer right now but will investigate this
> and send a fix later today.
Thanks. I'll review later today.
--
Simon Riggshttp://www.2ndQuadrant.com
lier too. You have to look at RFC
> 5803 and RFC 3112 together. RFC 3112 says that the overall format is
> "$$", and RFC5803 says that for SCRAM, scheme is
> "SCRAM-SHA-256" (for our variant), authInfo is ":" and
> authValue is ":"
>
> Th
On 21 April 2017 at 14:20, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Fri, Apr 21, 2017 at 10:02 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 21 April 2017 at 10:20, Heikki Linnakangas <hlinn...@iki.fi> wrote:
>>> But looking more close
you explain where you are looking? I don't see that in RFC5803
--
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:
frastructure doesn't exist in
PG10" in a couple of years.
So I suggest we have
ApplyMessageContext - cleaned after every message
ApplyTransactionContext - cleaned at EOXact
ApplyContext - persistent
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x
On 18 April 2017 at 09:25, Heikki Linnakangas <hlinn...@iki.fi> wrote:
> On 04/18/2017 11:15 AM, Simon Riggs wrote:
>>
>> As a potential open item, if we treat "md5" as ">= md5"
>> should we not also treat "password" as ">=passwo
On 18 April 2017 at 13:12, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Tue, Apr 18, 2017 at 7:54 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> Yeh, this is better. Pushed.
>
> I have been outraced on this one, the error is obvious once you see it ;)
Didn
ing that one, thanks for the patch.
--
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.or
On 18 April 2017 at 09:51, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 17 April 2017 at 16:33, Jeff Janes <jeff.ja...@gmail.com> wrote:
>> On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier <michael.paqu...@gmail.com>
>> wrote:
>>>
>>>
>
this to the open items list.
Pushed, 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
it just makes sure that the next XID never gets updated if
>> there are no 2PC files.
>
>
> Yes, that fixes the reported case when 2PC are not being used.
Thanks Jeff.
I certainly prefer the simplicity of Michael's approach. I'll move to commit.
--
Simon Riggsh
as "md5 or better".
+1
As a potential open item, if we treat "md5" as ">= md5"
should we not also treat "password" as ">=password"?
It seems strange that we still support "password" and yet tell
everyonenot to use it.
I'd
e with accurate docs, great comments and a helpful team.
I'd love to see detailed cases where another project is better in a
measurable way; I am willing to learn from that.
Any journey to expertise takes 10,000 hours. There is no way to shorten that.
What aspect of your journey caused
On 15 April 2017 at 23:37, Jeff Janes <jeff.ja...@gmail.com> wrote:
> After this commit, I get crash recovery failures when using prepared
> transactions.
>
> commit 728bd991c3c4389fb39c45dcb0fe57e4a1dccd71
> Author: Simon Riggs <si...@2ndquadrant.com>
> Date:
ot. What I find particularly
>> wrong here is that we are initialising maxsubxid to current value of
>> ShmemVariableCache->nextXid when the function enters, but this block would
>> then again increment ShmemVariableCache->nextXid, when there are no prepared
>> transactio
tion.
It makes sense to describe all similar techniques in one section of the docs.
--
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
On 14 April 2017 at 14:02, Robert Haas <robertmh...@gmail.com> wrote:
> On Fri, Apr 14, 2017 at 3:43 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> Oh, just looks very different to what we discussed, so I presumed more
>> changes were coming.
>
> I waited quite
On 14 April 2017 at 08:39, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote:
> On 2017/04/14 16:25, Simon Riggs wrote:
>> On 14 April 2017 at 08:13, Amit Langote <langote_amit...@lab.ntt.co.jp>
>> wrote:
>>
>>> Attached patch gets rid of a "
s priority when synchronous_standby_names is empty
> or a priority-based sync replication is configured. But with the patch, when
> a quorum-based one is specified, NULL is reported for that.
> Isn't this confusing?
To me, yes, it is confusing.
--
Simon Riggshttp://www.2ndQuadrant.com/
Post
doc changes, rather than keep making single minor changes?
(I had understood that we were going to add more docs together, but I
was awaiting your restructuring patch)
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Servic
On 13 April 2017 at 09:27, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote:
> Attached patch modifies a sentence in the inval.c header comment to
> mention that operations on a pg_index tuple also registers relcache flush
> operation.
Correctly observed. Patch pushed.
> DETAIL: 90 transactions to finish.
>
>> Am I the only one who is annoyed by this phrase?
>
> Our style guidelines say that detail messages should be complete
> sentences, so I don't like your proposal too much.
>
> Maybe "N transactions remain to finish." ?
waiting f
is seems OK and unlikely to have wider impact.
The "race condition" we're speaking about is by design, not a bug.
I think the initial comment could be slightly better worded; if I
didn't already know what is being discussed, I wouldnt be too much
further forwards from those comments.
-
PG10, with backpatch to 9.4 (or
as far as it goes).
Objections to commit?
--
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 cha
k for
us to send a protocol message, maybe a NotificationResponse, but there
isn't any material difference between those two protocol messages.
Rather than the special case code in the patch, I imagine more generic
code like this...
if (sessionInterruptPending)
ProcessSessionInterrupt();
I'm happy
On 6 April 2017 at 17:41, David Rowley <david.row...@2ndquadrant.com> wrote:
> On 7 April 2017 at 00:47, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 5 April 2017 at 18:48, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Simon Riggs <si...@2ndquadrant.com>
On 6 April 2017 at 16:15, Álvaro Hernández Tortosa <a...@8kdata.com> wrote:
> Per the SCRAM RFC, it is the server who advertises and the client who
> picks.
Yes, but what does the RFC say about how to handle servers with an pg_hba.conf?
How and what will we advertise?
--
being a protocol break by having the server's default
> assumption being that the client can handle all pre-SCRAM auth protocols.
+1
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hacker
; 'scram' in pg_hba.conf instead of 'sasl'...
I'd like to see us replace "scram" with "sasl=scram-sha-256".
So when we extend it in future, we already have the syntax in place to
support "sasl=newmethod", rather than introduce syntax that we already
know will become outd
? I don't know exactly
> if the results of GSoC project should be committed , but as a research
> project it's certainly would be useful for the community.
+1
Arseny, thank you for your contributions.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x
On 5 April 2017 at 18:48, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Simon Riggs <si...@2ndquadrant.com> writes:
>> Collect and use multi-column dependency stats
>
> The buildfarm is unhappy about the fact that this changed the API
> for clauselist_selectivity(). I am
tatistics as
+800ms on 2 million row sample.
--
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.p
s would mean compiling with
> --with-wal-segsize 16, 32, 64, 128, 256, run make check-world both
> sequentially and in parallel, and take note of a) passing, b) run time,
> c) disk space.)
I've committed the rest of Beena's patch to allow this testing to
occur up to 1024MB.
--
Simon Riggs
uded.
Patch ready to be applied directly barring objections.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
create_statistics_lock_reduction.v1.patch
Description: Binary data
--
Sent via pgsql-hackers mai
ot approach this with the
viewpoint that I or others want it to be rejected, lets work forwards
and get some solid changes that will improve the world without causing
problems.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training
On 4 April 2017 at 22:47, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Wed, Apr 5, 2017 at 3:36 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 27 March 2017 at 15:36, Beena Emerson <memissemer...@gmail.com> wrote:
>>
>>> 02-increase-max-wal
change (only).
No commitment yet to increasing wal-segsize in the way this patch has it.
--
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
use* of the
deadline seems weird.
How about we just leave everything until the deadline, then apply the
sword swiftly to anything that remains?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hacke
more
>> benchmarking here.
>>
>>
>> No objections.
>
> This submission has been moved to CF 2017-07.
Please note that I'm expecting to re-commit my earlier patch once
fixed up, since it had all-positive test results.
--
Simon Riggshttp://www.2ndQu
re.
The question is not whether this is ready today, but will it be
trusted and safe to use by Sept. Given the RMT, I would say yes, it
can be.
So I say we should commit WARM in PG10, with some restrictions.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24
is adds a small
amount of time to a background process executed every 10 secs,
generates no new WAL records.
So I don't see any reason not to commit this feature, after the minor
corrections.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remo
On 30 March 2017 at 18:29, Simon Riggs <si...@2ndquadrant.com> wrote:
> Moving to commit this over the next hour. Last chance...
Done. Great work Dave, thanks everybody.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA,
all happy
> with it \o/. Thank you to them for taking the time out of the
> conference to go through it with me.
Moving to commit this over the next hour. Last chance...
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
On 30 March 2017 at 15:27, Andres Freund <and...@anarazel.de> wrote:
> On 2017-03-30 15:26:02 +0100, Simon Riggs wrote:
>> On 30 March 2017 at 09:07, Craig Ringer <cr...@2ndquadrant.com> wrote:
>>
>> > Attached.
>>
>> * Cleaned up in 3 places
On 30 March 2017 at 09:07, Craig Ringer <cr...@2ndquadrant.com> wrote:
> Attached.
* Cleaned up in 3 places
* Added code for faked up RunningTransactions in xlog.c
* Ensure catalog_xmin doesn't go backwards
All else looks good. Comments before commit?
--
Simon Riggsh
patch about half the length it is.
Let me know what you think.
--
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 su
On 28 March 2017 at 15:38, Andres Freund <and...@anarazel.de> wrote:
> On 2017-03-28 15:32:49 +0100, Simon Riggs wrote:
>> On 28 March 2017 at 03:53, Craig Ringer <cr...@2ndquadrant.com> wrote:
>> > On 28 March 2017 at 09:25, Andres Freund <and...@anarazel.de&g
code it.
I don't think its for us to say what the plugin is allowed to do. We
decided on a plugin architecture, so we have to trust that the plugin
author resolves the issues. We can document them so those choices are
clear.
This doesn't differ in any respect from any other resource it might
need yet
roposal.
+1
I aim to commit something today. If you have other viewpoints, so say
now. There aren't many days left to express views and do anything
about them, so lets do it.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Se
On 23 March 2017 at 13:16, Dave Page <dp...@pgadmin.org> wrote:
> Thanks - updated patch attached.
I've edited the comments and docs on this patch, so attach a new
version with similar name.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppor
in takes locks it had better make sure it can get the locks
or timeout. But that's true of any resource the plugin needs access to
and can't obtain when needed.
This issue could occur now if the transaction tool a session lock on a
catalog table.
--
Simon Riggshttp://www.2ndQuadrant.com/
On 23 March 2017 at 13:16, Dave Page <dp...@pgadmin.org> wrote:
> Thanks - updated patch attached.
No problems with the patch so far.
I'd like some tests though...
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
On 7 March 2017 at 23:31, Josh Berkus <j...@berkus.org> wrote:
> On 03/02/2017 07:13 AM, David Steele wrote:
>> Hi Simon,
>>
>> On 2/25/17 2:43 PM, Simon Riggs wrote:
>>> On 25 February 2017 at 13:58, Michael Paquier <michael.paqu...@gmail.com>
>
On 27 March 2017 at 09:03, Craig Ringer <cr...@2ndquadrant.com> wrote:
> I think this one's ready to go.
Looks like something I could commit. Full review by me while offline
today, aiming to commit tomorrow barring issues raised.
--
Simon Riggshttp://www.2ndQua
having 1GB as the max
filesize.
New filename format can come in PG11 allowing much wider range of WAL
filesizes, bigger and smaller.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing
101 - 200 of 8408 matches
Mail list logo
