ey get right and 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
t;
> This one's ready to go. Working on drop slots on 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
On 24 March 2017 at 16:14, Robert Haas <robertmh...@gmail.com> 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 &
ave pretty much acceleration 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 Develop
ocalized fix for this 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
--
On 23 March 2017 at 15:05, Jon Nelson <jnel...@jamponi.net> wrote:
> Attached please find a minor spelling error fix, changing "btis" to "bits".
Applied, thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Re
th 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 (pgsql-hackers@postg
On 23 March 2017 at 06:42, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 23 March 2017 at 01:02, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
>
>> Thanks! Please find attached v7, which includes a note we can point
>> at when someone asks why it doesn
seems easier to add that 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 y
s me think it would 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/
Post
me because with the addition of
> PROC_IN_LOGICAL_DECODING flag "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 Rigg
andby
> patch, with 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 Devel
nt this 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 mailin
uess what would 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.
an AELs, but its
> parent xact does. 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 bul
On 20 March 2017 at 08:31, David Rowley <david.row...@2ndquadrant.com> wrote:
> On 18 March 2017 at 21:59, Simon Riggs <si...@2ndquadrant.com> wrote:
>> As Amit says, I don't see the gain from adding that to each xact state.
>>
>> I'd suggest refactor
On 22 March 2017 at 11:03, Thomas Munro <thomas.mu...@enterprisedb.com> 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.
--
On 21 March 2017 at 17:32, David Steele <da...@pgmasters.net> wrote:
> Hi Thomas,
>
> On 3/15/17 8:38 PM, Simon Riggs wrote:
>>
>> On 16 March 2017 at 08:02, Thomas Munro <thomas.mu...@enterprisedb.com>
>> wrote:
>>
>>> I agree that th
ood to me also. Does what we need it to do.
I was a little 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 vi
On 21 March 2017 at 16:33, Robert Haas <robertmh...@gmail.com> wrote:
> On Tue, Mar 21, 2017 at 12:19 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 16 March 2017 at 10:03, Amit Langote <langote_amit...@lab.ntt.co.jp>
>> wrote:
>>> On 2017/03/1
rows)
>
> Maybe that 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
he longer Logical Decoding on Standby will 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-h
t case there would never be an abort until after
decoding.
So I suggest we have a pre-prepare callback to ensure that the plugin
can decide whether to decode or not. We can pass information to the
plugin such as whether we have issued DDL in that xact or not. The
plugin can then decide how it wishes t
t cause failure because in read_local_xlog_page() we
say that we are reading from history when
state->currTLI != ThisTimeLineID explicitly rather than use
sendTimeLineIsHistoric
So it looks like we could do with a few extra comments
If you correct these I'll commit it tomorrow.
--
Simon Riggs
On 13 March 2017 at 10:56, Craig Ringer <cr...@2ndquadrant.com> wrote:
> On 7 March 2017 at 21:08, Simon Riggs <simon.ri...@2ndquadrant.com> wrote:
>
>> Patch 4 committed. Few others need rebase.
>
> Since this patch series
Patch 1 fails since feature has already
signed to avoid
cache spoiling by large scans.
--
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:/
sn't get any uglier than it already is.
--
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 16 March 2017 at 19:08, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Thu, Mar 16, 2017 at 6:01 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 8 March 2017 at 10:02, David Rowley <david.row...@2ndquadrant.com> wrote:
>>> On 8 March 2017 at 01:13
nId(), so that we assign the lock to the
subxid rather than the top xid. That could increase lock traffic, but
less likely. It also solves the problem of early release when AELs
held by subxids.
(2) looks safe enough, so patch attached.
--
Simon Riggshttp://www.2ndQuadrant.com/
Post
"what is the most recent lag
measurement" and "how long until we are caught up" as possible
intrepretations of these values. Thanks.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent vi
On 8 March 2017 at 10:02, David Rowley <david.row...@2ndquadrant.com> wrote:
> On 8 March 2017 at 01:13, Simon Riggs <si...@2ndquadrant.com> wrote:
>> Don't understand this. I'm talking about setting a flag on
>> commit/abort WAL records, like the attached.
>
&g
On 14 March 2017 at 07:39, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> Hi,
>
> Please see separate replies to Simon and Craig below.
>
> On Sun, Mar 5, 2017 at 8:38 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 1 March 2017 at 10:47, Thomas Mun
On 14 March 2017 at 07:39, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
>
> On Mon, Mar 6, 2017 at 3:22 AM, Craig Ringer <cr...@2ndquadrant.com> wrote:
>> On 5 March 2017 at 15:31, Simon Riggs <si...@2ndquadrant.com> wrote:
>>> What we want from this
Patch 4 committed. Few others need rebase.
--
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
;trial
commits" as a way of seeing if the build farm likes things. If they
do, we can push to the main repo.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql
need more info and
research to work out how to do that, so we can only do it this way at
present.
Other than that the patch looks fairly straightforward, so adding a
few tests will be all we need here.
Plus function docs. I'm on the hook to write brin docs anyway, so no
more needed here.
ansaction IDs seems impractical.
Don't understand this. I'm talking about setting a flag on
commit/abort WAL records, like the attached.
We just need to track info so we can set the flag at EOXact and we're done.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 2
e perf
> report for StandbyReleaseLocks().
Didn't look at the code closely, but if the common case COMMITs don't
scan the list that would be most of the problem solved. If we did need
a hash table, we should just use a normal hash table?
--
Simon Riggshttp://www.2n
would be annoying to have some files in one mode,
some in another.
--
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
HAS PARTITIONS should be in upper case.
"has partitions" is not part of the DDL, whereas "FOR VALUES FROM (0)
TO (100)" is. So ISTM sensible to differentiate between DDL and
non-ddl using upper and lower case.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL De
On 6 March 2017 at 04:00, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> On Mon, Mar 6, 2017 at 8:35 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 6 March 2017 at 00:51, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote:
>>> On 2017/03/05 16:
On 6 March 2017 at 00:51, Amit Langote <langote_amit...@lab.ntt.co.jp> wrote:
> On 2017/03/05 16:20, Simon Riggs wrote:
>> I notice also that
>> \d+
>> does not show which partitions have subpartitions.
>
> Do you mean showing just whether a partition is it
nt objects too.
>
> I think that's what this patch fixes. Do you see this behaviour after
> applying the patch?
It does seems as if I've made a mistake there. The patch passes.
Thanks for checking.
I will apply tomorrow if no further comments.
--
Simon Riggshttp://www.2ndQuadr
fully
applied then it should not continue to show 14 secs for the next 2
hours.
IMHO the lag time should drop to zero in a reasonable time and stay at
zero for those 2 hours because there is no current lag.
If we want to show historical lag data, I'm supportive of the idea,
but we must report an
On 1 March 2017 at 10:47, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> On Fri, Feb 24, 2017 at 9:05 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 21 February 2017 at 21:38, Thomas Munro
>> <thomas.mu...@enterprisedb.com> wrote:
>>> Ho
On 27 February 2017 at 02:38, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
> On 2017/02/26 5:30, Simon Riggs wrote:
>> On 23 February 2017 at 16:33, Simon Riggs <si...@2ndquadrant.com> wrote:
>>
>>> I'll be happy to review
>>
>> Patch lo
On 28 February 2017 at 17:49, Simon Riggs <si...@2ndquadrant.com> wrote:
> I've edited the stated reason for the patch on the CF app, so its
> clearer as to why this might be acceptable.
Robins,
I'm looking to commit the patch version I posted, so I would like your
comments
On 1 March 2017 at 04:50, Ashutosh Sharma <ashu.coe...@gmail.com> wrote:
> On Tue, Feb 28, 2017 at 11:44 PM, Simon Riggs <si...@2ndquadrant.com>
> wrote:
>
>> On 28 February 2017 at 11:34, Ashutosh Sharma <ashu.coe...@gmail.com>
>> wrote:
>>
3 28416 2.131330194
> 128 28455 28618 0.5728342998
> 180 26739 26879 0.5235797898
> 196 27820 27963 0.5140186916
> 256 28763 28969 0.7161978931
>
> Also, Excel sheet (results-readwrite-300-SF.xlsx) containing the results
> for all the 3 runs is attached.
>
--
Simon Ri
On 28 February 2017 at 13:30, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Simon Riggs <si...@2ndquadrant.com> writes:
>> On 28 February 2017 at 13:05, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Um ... isn't there a transaction boundary there anyway?
>
>> Y
e removes any mention of specific vendors or approaches.
I've edited the stated reason for the patch on the CF app, so its
clearer as to why this might be acceptable.
--
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
fore
>> entering the second phase. This allows the global xmin to advance,
>
> Um ... isn't there a transaction boundary there anyway?
Yes, the patch releases the snapshot early, so it does not hold it
once the build scan has completed. This allows the sort and build
phases to occur wi
In CREATE INDEX CONCURRENTLY it seems possible to release the index
build snapshot early, so we can reset our xmin before we complete the
sort and write the main part of the index.
Patch to implement this attached.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development
On 28 February 2017 at 08:14, Amit Langote
<langote_amit...@lab.ntt.co.jp> wrote:
> OK. So, I will start writing the patch with above general skeleton and
> hopefully post it within this week and you can improve it as fit.
Will do, thanks.
--
Simon Riggs
llow some
responsiveness from us. Thanks Michael, Magnus.
--
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 subsc
the section
on BRIN indexes, all of which would have their own independent sets of
caveats.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To ma
On 23 February 2017 at 16:33, Simon Riggs <si...@2ndquadrant.com> wrote:
> I'll be happy to review
Patch looks OK so far, but fails on a partition that has partitions,
probably because of the way we test relkind in the call to
StoreCatalogInheritance1().
Please add a test for that
o nothing..
Sorry, that is just an error of implementation, not intention. I had
it on my list to keep, at your request.
New version coming up.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsq
%2BTgmoYe5eDhjRodo3uOtVFGiDWwO2zGUp_mDHeSxuEqq-jS_A%40mail.gmail.com
Earlier patch, dropped from 9.6
https://www.postgresql.org/message-id/CANP8%2Bj%2B0fuq2MWKvUsQTJFt8EF_z-Tyn-Q61J2A%2BVT2Uzuf-Rg%40mail.gmail.com
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training
so I've
added those also.
I've also added checks to prevent it running with other mutually
exclusive options.
Reworded doc changes also.
Tested, but no tests added for this.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training &
On 12 January 2017 at 13:34, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 1/11/17 5:27 AM, Simon Riggs wrote:
>> The main area of "design doubt" remains the implementation of the
>> recovery_target parameter set. Are we happy with the user in
at. We could have an explicit option to allow
that. This appears to be the only way we could avoid silent errors for
foreign table partitions.
--
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
r.
>
Would you be able to test my patch also please?
--
Simon Riggshttp://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 16 February 2017 at 05:24, Seki, Eiji <seki.e...@jp.fujitsu.com> wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> Please persuade us with measurements that allowing this impact on
>> ANALYZE would really improve performance at least in your case, and
ee if
you deploy this same "You don't get to show up.." argument against Tom
or Noah when they point out holes in late reviews, though we already
both know you won't. I see you using that yourself, objecting
frequently against patches large and small if they do not meet your
exactin
On 21 February 2017 at 21:38, Thomas Munro
<thomas.mu...@enterprisedb.com> wrote:
> On Tue, Feb 21, 2017 at 6:21 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> And happier again, leading me to move to the next stage of review,
>> focusing on the behaviour emerging f
On 23 February 2017 at 17:27, Peter Geoghegan <p...@bowt.ie> wrote:
> On Thu, Feb 23, 2017 at 8:08 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> What claims are you talking about? Which things have been exaggerated,
>> and by whom?
>
> * The specious argument
On 23 February 2017 at 06:40, Ashutosh Bapat
<ashutosh.ba...@enterprisedb.com> wrote:
> I think this is ready for committer.
Thanks for writing and reviewing this. I'll be happy to review and
commit. Please add to CF.
--
Simon Riggshttp://www.2ndQuadrant.com/
P
d 4 seem achievable in this release,
potentially in restricted form. I think we should probably avoid
trying to UPDATE rows from one partition to another in this release,
since that seems likely to be buggy and seems like would only be
needed in relatively few cases.
Let me know if I can help with t
claims are you talking about? Which things have been exaggerated,
and by whom?
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To m
On 17 February 2017 at 07:45, Thomas Munro
<thomas.mu...@enterprisedb.com> wrote:
> On Fri, Feb 17, 2017 at 12:45 AM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> Feeling happier about this for now at least.
>
> Thanks!
And happier again, leading me to move to the nex
than "table", for clarity. 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.org/mailpref/pgsql-hackers
On 20 February 2017 at 10:27, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Feb 20, 2017 at 3:01 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 20 February 2017 at 09:15, Amit Kapila <amit.kapil...@gmail.com> wrote:
>>> On Mon, Feb 20, 2017 a
eems worth testing to me.
Hopefully someone can recheck. Thanks in advance.
--
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
On 20 February 2017 at 16:53, Robert Haas <robertmh...@gmail.com> wrote:
> On Mon, Feb 20, 2017 at 6:02 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>> On 15 February 2017 at 19:15, Andres Freund <and...@anarazel.de> wrote:
>>
>>> I think I pr
setXmin() pointlessly at end of xact, so
patch attached to remove that call, plus some comments to explain
that. This reduces the cause.
Also, another patch to reduce the calls to SnapshotResetXmin() using a
simple heuristic to reduce the effects.
--
Simon Riggshttp://www.2ndQua
On 20 February 2017 at 09:15, Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Mon, Feb 20, 2017 at 7:26 AM, Masahiko Sawada <sawada.m...@gmail.com>
> wrote:
>> On Fri, Feb 17, 2017 at 3:41 AM, Robert Haas <robertmh...@gmail.com> wrote:
>>> On Thu, F
oblems at once, but this was already a really big
> patch, and IMHO quite a good one.
Please explain these personal comments against me.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent vi
On 16 February 2017 at 11:32, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 10 February 2017 at 06:19, Amit Langote
> <langote_amit...@lab.ntt.co.jp> wrote:
>
>> the "right thing" here being that the
>> command's code either throws an error or warnin
T
> (city_id) DO NOTHING;
> ERROR: ON CONFLICT clause is not supported with partitioned tables
>
> Why do we have such a restriction? And what would it take to remove it?
Partitioned tables don't yet support a global unique constraint that
would be required for support of ON C
it might do.
e.g. We need to document what replay_lag represents. Does it include
write_lag and flush_lag, or is it the time since the flush_lag. i.e.
do I add all 3 together to get the full lag, or would that cause me to
double count?
How sensitive is this? Does the lag spike quickly and t
es. We have the opportunity to change things here and we
should do so.
(It also seems like wasted effort to try to remove the overhead caused
by a parent table for partitioning. Why introduce a special case to
save a few bytes? Premature optimization, surely?)
--
Simon Riggshttp:/
es, not just recently vacuumed rows.
--
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
created automatically for me
in the first place. I might just understand that running ATTACH TABLE
might change that viewpoint.
I'm pretty sure DROP TABLE and CREATE INDEX are fairly basic
expectations from users about how tables should work, partitioned or
otherwise.
It leaves me asking
pact on
ANALYZE would really improve performance at least in your case, and
also examine the effect of this on the accuracy and usefulness of the
gathered statistics.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Serv
On 14 February 2017 at 11:48, Thomas Munro
<thomas.mu...@enterprisedb.com> wrote:
> Here is a new version with the buffer on the sender side as requested.
Thanks, I will definitely review in good time to get this in PG10
--
Simon Riggshttp://www.2ndQuadrant.com/
P
ontrols this output for the vac-non-autovac case.
If my idea would not log manual ANALYZE, well, we can add that in
easily. There is no reason to block the patch for such a minor foible.
This is a short patch to address a specific minor issue, not a blue
sky redesign of logging.
If someone else want
umentation at every step, otherwise it won't be able to receive
full and fair review. So please make sure each new patch contains docs
changes for that patch.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
of those and they are all about as easy as one
another, though the last one will be a bigger patch, so a) might be
simpler.
The following patch implements (1), but not yet (2) to allow debate.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA
We've added xmin info to pg_stat_activity and pg_stat_replication, but
VACUUM doesn't yet report which xmin value it used when it ran.
Small patch to add this info to VACUUM output.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA
y don't understand
Any issues with that?
--
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
sert *any* data before a
> partition (to be precise, a leaf partition) is created.
Where is all of this documented? All I see at the moment is old docs.
--
Simon Riggshttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
On 2 February 2017 at 18:48, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 2/2/17 8:32 AM, Simon Riggs wrote:
>> I think we should remove the "replication" false database concept in
>> pg_hba.conf altogether and allow any valid pg_hba rule to inv
ility from connecting as normal users, if the are marked as
NOLOGIN.
--
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 subscri
On 30 January 2017 at 16:34, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 1/30/17 9:04 AM, Simon Riggs wrote:
>> all I want in this release is
>> super-ownership.
>
> What exactly is super-ownership, and what problems does it solve?
The problem i
On 30 January 2017 at 16:43, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Simon Riggs <si...@2ndquadrant.com> writes:
>> Agreed. Let me reiterate: all I want in this release is
>> super-ownership.
>
> While I'm not entirely convinced whether super-ownership is a goo
be able to make it more flexible later. I'm much more
> concerned that we'll end up painting ourselves into a corner that's
> difficult to get out of as privileges are, generally speaking, not
> something we can really whack around from release to release. They're
> extremely
On 27 January 2017 at 22:48, Peter Eisentraut
<peter.eisentr...@2ndquadrant.com> wrote:
> On 1/26/17 1:25 PM, Simon Riggs wrote:
>> That should include the ability to dump all objects, yet without any
>> security details. And it should allow someone to setup logical
On 27 January 2017 at 14:09, Dave Page <dp...@pgadmin.org> wrote:
> On Fri, Jan 27, 2017 at 1:18 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
>
>> If the monitoring tool requires superuser then that is a problem, so
>> it would be helpful if it didn't do tha
en we can put those specific things
into the server and we can all be happy. Again, a detailed list would
help here.
Does the latest version of pgadmin provide access to log files? I
can't see much that really needs Adminpack anymore, though I've not
done a thorough analysis at all.
--
Simon Rig
201 - 300 of 8408 matches
Mail list logo
