On 31 July 2014 15:48, Heikki Linnakangas wrote:
> On 07/31/2014 05:19 PM, Simon Riggs wrote:
>>
>> On 31 July 2014 14:59, Heikki Linnakangas
>> wrote:
>>
>>> Move log_newpage and log_newpage_buffer to xlog.c.
>>
>>
>> Got a feeling this was
...
LABEL: foo incremental 1
INCREMENTAL 2
START WAL LOCATION: %X/%X
CHECKPOINT LOCATION: %X/%X
BACKUP METHOD: streamed
BACKUP FROM: standby
START TIME:
LABEL: foo incremental 2
... etc ...
which we interpret as showing the original base backup, then the first
increment, then the second in
we read the whole file without
finding a later LSN then we don't need to re-copy. That means we read
each file twice, which is slower, but the file is at most 1GB in size,
we we can assume will be mostly in memory for the second read.
As Marco says, that can be optimized using filesyst
On 6 August 2014 03:16, Bruce Momjian wrote:
> On Wed, Aug 6, 2014 at 09:17:35AM +0900, Michael Paquier wrote:
>> On Wed, Aug 6, 2014 at 9:04 AM, Simon Riggs wrote:
>> >
>> > On 5 August 2014 22:38, Claudio Freire wrote:
>> > Thinking some more, there seems
solution the less likely it is to integrate with external backup
providers. Oracle's RMAN requires specific support in external
software. 10 years after Postgres PITR we still see many vendors
showing "PostgreSQL Backup Supported" as meaning pg_dump only.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, 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
filter part comes in though, so -1 to "block filter", not least
because it doesn't have a good abbreviation (bfin??).
A better description would be "block range index" since we are
indexing a range of blocks (not just one block). Perhaps a better one
would be simply
f
> a new tuple and updating the revmap, so no garbage is left behind.
What happens if the transaction that does this aborts? Surely that
means the new value is itself garbage? What cleans up that?
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Suppo
uire
exclusive lock. If LSN is the same, no need for datatype specific
re-checks at all.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
e tweak this after commit? Delaying commit
just means less time for other people to see, test, understand tune
and fix. I see you (Heikki) doing lots of incremental development,
lots of small commits. Can't we do this one the same?
--
Simon Riggs http://www.2ndQua
not be applied yet and not
without further changess, per review.
--
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
t should be done, but this patch doesn't implement that.
Robert raises the possible problem that removing the Append wouldn't
work when the parent and child attribute numbers don't match. Surely
that never happens with partitions, by definition?
--
Simon Riggs
On 21 March 2017 at 16:33, Robert Haas wrote:
> On Tue, Mar 21, 2017 at 12:19 PM, Simon Riggs wrote:
>> On 16 March 2017 at 10:03, Amit Langote
>> wrote:
>>> On 2017/03/15 7:09, Robert Haas wrote:
>>
>>>> I think that eliding the Append node when th
e worried by possible performance of new lock, but its
not intended to be run frequently, so its OK.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgre
On 21 March 2017 at 17:32, David Steele wrote:
> Hi Thomas,
>
> On 3/15/17 8:38 PM, Simon Riggs wrote:
>>
>> On 16 March 2017 at 08:02, Thomas Munro
>> wrote:
>>
>>> I agree that these states exist, but we disagree on what 'lag' real
On 22 March 2017 at 11:03, Thomas Munro wrote:
> Hah. Apologies for the delay -- I will post a patch with
> documentation as requested within 24 hours.
Thanks very much. I'll reserve time to commit it tomorrow, all else being good.
--
Simon Riggshttp://www.2ndQ
On 20 March 2017 at 08:31, David Rowley wrote:
> On 18 March 2017 at 21:59, Simon Riggs wrote:
>> As Amit says, I don't see the gain from adding that to each xact state.
>>
>> I'd suggest refactoring my patch so that the existign
>> MyXactAccessedTempRel beco
oes. Wonder if this is a good price to pay for releasing
> the locks earlier?
We'd be performing the same number of loops as we do now. It's just
now they would have a purpose.
But we aren't doing it at all unless the top level xid has at least
one AEL, so the bulk of the pro
be acceptable, then its not long enough.
It would be better if you could outline a specific approach so he can
code it. Coding takes about a day for most things, since Craig knows
the code and what we're trying to achieve.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL D
is automatically from the master, which was
rejected. So the only other way is manually. We need one or the other.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing lis
ith comments by Petr and Andres made re the relevant code
> addressed.
I've reduced your two patches back to one with a smaller blast radius.
I'll commit this tomorrow morning, barring objections.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development
ag "vacuumFlags" doesn't
> only use it for vacuum operation. I feel this variable can be renamed
> as just "flags", but anyway that is a different patch.
Good point. Should be an open item.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Dev
ould be confusing to say "in progress" for
when it is our current xid, since the user might wait until it is
complete and then wait forever. Prefer it if it said "in progress -
current transaction"
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Developme
at as a minor cleanup/open item after
this 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 changes to your subscription:
On 23 March 2017 at 06:42, Simon Riggs wrote:
> On 23 March 2017 at 01:02, Thomas Munro wrote:
>
>> Thanks! Please find attached v7, which includes a note we can point
>> at when someone asks why it doesn't show 00:00:00, as requested.
>
> Thanks.
>
> Now I l
ooking to commit, with some docs and minor code
changes as discussed.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
replication-lag-v7sr1.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pg
On 23 March 2017 at 15:05, Jon Nelson wrote:
> Attached please find a minor spelling error fix, changing "btis" to "bits".
Applied, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Se
his would be
> worthwhile, although I may be wrong.
What "new approach" are we discussing?
Is there a patch or design discussion?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-h
celeration for read-only case and small acceleration
> for read-write case.
> I'll run benchmark on 72-cores machine as well.
>
No need to wait for that.
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 24 March 2017 at 16:14, Robert Haas wrote:
> I suspect that is the fault of this patch. Please fix or revert.
Will revert then fix.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-
DB drop now.
Committed. Next!
--
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
d what
they get wrong, so we can be sure we are providing something people
actually want and/or expect. POLA needed. I don't want to be reading
various blogs about what those numpties on the Postgres project did in
v10. Thanks
--
Simon Riggshttp://www.2ndQuadrant.com/
Po
lesize.
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 list (pgsql-hackers@postgr
On 27 March 2017 at 09:03, Craig Ringer 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.2ndQuadrant.com/
PostgreSQL Developme
On 7 March 2017 at 23:31, Josh Berkus 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
>>> wrote:
>>>
>>>> - trigger_file
On 23 March 2017 at 13:16, Dave Page 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 & Services
--
Se
t 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/
PostgreS
On 23 March 2017 at 13:16, Dave Page 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 Support, Remote DBA,
oday. 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 & Services
--
Sent via pgsql-hac
he 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 cannot obtain.
--
Simon Riggs
On 28 March 2017 at 15:38, Andres Freund wrote:
> On 2017-03-28 15:32:49 +0100, Simon Riggs wrote:
>> On 28 March 2017 at 03:53, Craig Ringer wrote:
>> > On 28 March 2017 at 09:25, Andres Freund wrote:
>> >
>> >> If you actually need separate decoding of 2
On 29 March 2017 at 10:17, Craig Ringer wrote:
> On 29 March 2017 at 16:44, Craig Ringer wrote:
>
>> * Split oldestCatalogXmin tracking into separate patch
>
> Regarding this, Simon raised concerns about xlog volume here.
>
> It's pretty negligible.
>
> We on
On 30 March 2017 at 09:07, Craig Ringer 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 Riggshttp://www.2ndQuad
On 30 March 2017 at 15:27, Andres Freund wrote:
> On 2017-03-30 15:26:02 +0100, Simon Riggs wrote:
>> On 30 March 2017 at 09:07, Craig Ringer wrote:
>>
>> > Attached.
>>
>> * Cleaned up in 3 places
>> * Added code for faked up RunningTransactions in
ght be a bit longer as he's trying to do it in a hallway at
>> PGConf.US...
>
> Thanks Stephen.
>
> Here's an updated patch, and description of the changes. Simon,
> Stephen and Robert have looked at the description and are all happy
> with it \o/. Thank you to the
On 30 March 2017 at 18:29, Simon Riggs 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, Training & Services
--
S
erhead, this 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,
er 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, 24x7 Support, Remote DBA, Tra
>> 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.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Re
ine 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-hackers mailing list (
easing 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 changes to your subscrip
On 4 April 2017 at 22:47, Amit Kapila wrote:
> On Wed, Apr 5, 2017 at 3:36 AM, Simon Riggs wrote:
>> On 27 March 2017 at 15:36, Beena Emerson wrote:
>>
>>> 02-increase-max-wal-segsize.patch - Increases the wal-segsize and changes
>>> the internal representation
s 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 & Ser
rectly 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 mailing list (pgsql-hackers@postgresql.or
l-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 Riggshttp://www.2
on 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.postgresql.org/mailpref/pgsql-hackers
On 5 April 2017 at 18:48, Tom Lane wrote:
> Simon Riggs 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 not convinced that that change
> was a good idea,
actly
> 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, 24x7 Support, Remote
x27;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
tocol 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-hackers
On 6 April 2017 at 16:15, Álvaro Hernández Tortosa 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?
--
Simon Riggs
On 6 April 2017 at 17:41, David Rowley wrote:
> On 7 April 2017 at 00:47, Simon Riggs wrote:
>> On 5 April 2017 at 18:48, Tom Lane wrote:
>>> Simon Riggs writes:
>>>> Collect and use multi-column dependency stats
>>>
>>> The buildfarm is unhappy
ponse, 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 to work on the patch, if that's OK.
--
Si
(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 changes to your subscription:
http://ww
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.
--
Simon Riggs
gt;> 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 for N transactions to complete
--
On 13 April 2017 at 09:27, Amit Langote 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.
--
Simon Riggsh
aking 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 & Services
--
Sent via pgsql-hacke
s 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/
PostgreSQL Developme
On 14 April 2017 at 08:39, Amit Langote wrote:
> On 2017/04/14 16:25, Simon Riggs wrote:
>> On 14 April 2017 at 08:13, Amit Langote
>> wrote:
>>
>>> Attached patch gets rid of a "is has".
>>
>> Yes, its a typo, but doesn't add missing in
On 14 April 2017 at 14:02, Robert Haas wrote:
> On Fri, Apr 14, 2017 at 3:43 AM, Simon Riggs wrote:
>> Oh, just looks very different to what we discussed, so I presumed more
>> changes were coming.
>
> I waited quite a while for you to review Amit's patches on that
>
made part of the section.
>
> By the way, will you also be adding details on UNION ALL views (I remember
> you said you would along with BRIN)? Actually, my patch copied verbatim
> what older docs had about them that you said is too short a description.
It makes sense to descri
hat 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
>> transactions in the system.
>>
>> I wonder if we shou
On 15 April 2017 at 23:37, Jeff Janes wrote:
> After this commit, I get crash recovery failures when using prepared
> transactions.
>
> commit 728bd991c3c4389fb39c45dcb0fe57e4a1dccd71
> Author: Simon Riggs
> Date: Tue Apr 4 15:56:56 2017 -0400
>
> Speedup 2PC recove
omments 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 you pain?
--
Simon
ot;.
+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 like PG10 to be the version
>> 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 Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7
On 18 April 2017 at 06:57, Amit Langote wrote:
> On 2017/04/18 14:50, Amit Langote wrote:
>> Attached patch fixes the oversight that COMMENT ON COLUMN is not allowed
>> on partitioned tables columns.
>
> Forgot to mention that I added this to the open items list.
Pushed, tha
On 18 April 2017 at 09:51, Simon Riggs wrote:
> On 17 April 2017 at 16:33, Jeff Janes wrote:
>> On Sun, Apr 16, 2017 at 6:59 PM, Michael Paquier
>> wrote:
>>>
>>>
>>>
>>> Jeff, does this patch make the situation better? The fix is rather
>&
r 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.org/mailpref/pgsql-hackers
On 18 April 2017 at 13:12, Michael Paquier wrote:
> On Tue, Apr 18, 2017 at 7:54 PM, Simon Riggs wrote:
>> Yeh, this is better. Pushed.
>
> I have been outraced on this one, the error is obvious once you see it ;)
Didn't realise you were working on it, nothing competitive a
On 18 April 2017 at 09:25, Heikki Linnakangas 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 ">=password"?
&
sn'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, 24x7 Support, Re
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, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
On 23 June 2017 at 06:45, Thomas Munro 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.2ndQuadrant.com/
PostgreSQL Development
On 23 June 2017 at 08:21, Andres Freund 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 writes:
>> > > So rearranged code a little to keep it lean.
>> >
>> > Didn't
On 21 June 2017 at 15:18, Simon Riggs wrote:
> On 21 June 2017 at 16:15, Yugo Nagata wrote:
>> On Wed, 21 Jun 2017 19:08:35 +0530
>> Kuntal Ghosh wrote:
>>
>>> On Wed, Jun 21, 2017 at 6:05 PM, Yugo Nagata wrote:
>>> >
>>> > Attached is a pa
On 23 June 2017 at 08:18, Simon Riggs wrote:
> On 23 June 2017 at 06:45, Thomas Munro 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.
I've pushe
On 23 June 2017 at 08:23, Simon Riggs wrote:
> On 23 June 2017 at 08:21, Andres Freund 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 writes:
>>> > > So rearranged code
On 23 June 2017 at 19:25, Andres Freund wrote:
> On 2017-06-23 19:21:57 +0100, Simon Riggs wrote:
>> On 23 June 2017 at 08:23, Simon Riggs wrote:
>> > On 23 June 2017 at 08:21, Andres Freund wrote:
>> >> On 2017-06-07 10:17:31 -0700, Andres Freund wrote:
>> &
st 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 (pgsql-hackers@postgresq
50s
> (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
--
Simon Rig
to do with the parallel safety of the query.
Please give an example of something that would be unsafe? Is that
documented anywhere, README etc?
FOR x IN query LOOP .. END LOOP
seems like a case that would be just fine, since we're going to loop
thru every row or break early.
Surely NO SCROL
n 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/
Postgre
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 we have now for other things.
--
Simon Riggs
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 older versions:
> generate custom
n that commit, because the thinking behind the aforementioned commit
> (that the constraint is trivially validated because the newly created
> table contains no data) does not equally apply to the foreign tables case.
>
> Should we do something about that?
In what way does it not apply?
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-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 1 August 2017 at 08:37, Amit Langote wrote:
> On 2017/08/01 15:22, Simon Riggs wrote:
>> On 1 August 2017 at 07:16, Amit Langote
>> wrote:
>>> In f27a6b15e656 (9.6 & later), we decided to "Mark CHECK constraints
>>> declared NOT VALID va
the example in RFC 5802
> (SCRAM-SHA-1) section 5. But the analogous example in RFC 7677
> (SCRAM-SHA-256) section 3 uses a length of 16. Should we use that instead?
16 preferred, IMHO
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, R
m not surprised they don't work and have never been tested.
Your suggestion of "furthest" is already the default behaviour.
Why are you using 'now'? Why would you want to pick a randomly
selected end time?
recovery_target_time = 'allballs' sounds fun for recover
301 - 400 of 8523 matches
Mail list logo
