ing
these 30-some lines of code to every PL.
--
Kevin Grittner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
message-id/CAD=a8sbzwgd4u-tasjp0owtpileffhoz5o5ev0um6digqbv...@mail.gmail.com
Unless you can produce convincing proof to the contrary, your proposal
will be disqualified because of plagiarism.
--
Kevin Grittner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make cha
ered by this testing, which at high concurrency on a
16 core machine might hit a particular problem less often than once
per day.
I also remember that both Anssi Kääriäinen and Yamamoto Takahashi
did a lot of valuable testing of the patch and found problems that
we had missed. Perhaps they can
On Mon, Apr 3, 2017 at 7:16 PM, Thomas Munro
wrote:
> On Tue, Apr 4, 2017 at 3:41 AM, Kevin Grittner wrote:
>> On Mon, Apr 3, 2017 at 8:59 AM, Tom Lane wrote:
>>> Thomas Munro writes:
>>>> Or perhaps the code to inject trigger data transition tables into SPI
>
proposal is here:
https://summerofcode.withgoogle.com/serve/5874530240167936/
Also, I just entered a comment about an important question that I
think needs to be answered right up front.
--
Kevin Grittner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
Sorry, I didn't notice that this was going to a public list. That URL
is only available to people who signed up as mentors for PostgreSQL
GSoC participation this year. Does the link to the draft work for you?
--
Kevin Grittner
--
Sent via pgsql-hackers mailing list (pgsql-ha
code, but it's probably not worth
adding 4 hours to any tests, even if it only shows up with
CLOBBER_CACHE_ONLY. I assume the consensus is that I should revert
it?
--
Kevin Grittner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund wrote:
> I'd rather fix the issue, than remove the tests entirely. Seems quite
> possible to handle blocking on Safesnapshot in a similar manner as
> pg_blocking_pids?
I'll see what I can figure out.
--
Kevin Grittner
enough
I was planning on pushing this today.
--
Kevin Grittner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Apr 7, 2017 at 3:47 PM, Thomas Munro
wrote:
> On Sat, Apr 8, 2017 at 6:35 AM, Kevin Grittner wrote:
>> On Fri, Apr 7, 2017 at 12:52 PM, Andres Freund wrote:
>>
>>> I'd rather fix the issue, than remove the tests entirely. Seems quite
>>> possible t
On Mon, Feb 27, 2017 at 7:35 AM, Dagfinn Ilmari Mannsåker
wrote:
> Kevin Grittner writes:
>
>> It occurred to me that it would make sense to allow these settings
>> to be attached to a database or table (though *not* a role). I'll
>> look at that when I get back
t link to be following?
If you're starting from the blocked (read-only) transaction (which
you are), inLink is the one to follow.
Note: It would be better form to use the SxactIsDeferrableWaiting()
macro than repeat the bit-testing code directly in your function.
--
Kevin Grittner
--
Sen
its array
> argument directly; it could probably do that significantly faster than the
> general-purpose array && code. So we'd have to expend a bit of backend C
> code, but we'd have something that would be quite speedy and we could
> customize in future without fea
ove
rules are followed, nor can I see anything special it *could* do.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, Apr 10, 2017 at 1:17 PM, Tom Lane wrote:
> Kevin Grittner writes:
>> On Mon, Apr 10, 2017 at 9:28 AM, Tom Lane wrote:
>>> I notice that the safe-snapshot code path is not paying attention to
>>> parallel-query cases, unlike the lock code path. I'm not
rting with the list Craig included) as section headers, and
put links to useful reading below each?
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
e first try. For
examples, to help get a feel of why that is, see:
https://wiki.postgresql.org/wiki/SSI
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.pos
attempt
to do otherwise, or is there something to salvage that has worked at
some point? If we do get these working, don't they deserve at least
one regression test?
Will post again after I have a chance to review the FDW issue.
--
Kevin Grittner
VMware vCenter Server
https://www.vmwar
On Fri, Apr 28, 2017 at 2:42 PM, Tom Lane wrote:
> Kevin Grittner writes:
>> On Tue, Apr 25, 2017 at 6:17 PM, Thomas Munro
>> wrote:
>>> For views, aside from the question of transition tables, I noticed
>>> that statement triggers don't seem to fire at
On Fri, Apr 28, 2017 at 3:54 PM, Kevin Grittner wrote:
> Not firing a table's DML because it was fired off a view would be crazy,
should read:
Not firing a table's trigger because the trigger is on DML run from a
view's INSTEAD OF trigger would be crazy,
--
Kevin Gritt
h. I think best case is Friday.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Mon, May 1, 2017 at 11:53 AM, Robert Haas wrote:
> On Mon, May 1, 2017 at 12:10 PM, Kevin Grittner wrote:
>> On Mon, May 1, 2017 at 10:01 AM, Robert Haas wrote:
>>> It seems pretty clear to me that this is busted.
>>
>> I don't think you actually teste
lar odd behavior under
inheritance. I hope to post something Friday.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
ject names then seems odd, of course.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 3, 2017 at 4:37 PM, Tom Lane wrote:
> At this point I'm inclined to just delete the whole test.
ok
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscripti
. If your statement is ONLY on the a
given level in the hierarchy, the row triggers for only that level
would fire. If you don't use ONLY, a row trigger at that level
would fire for operations at that level or any child level, but with
a record format matching the level of the trigger.
No
combination of the function and the target
relation, rather than having one cache entry regardless of the
target table.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, May 16, 2017 at 4:50 PM, Thomas Munro
wrote:
> On Wed, May 17, 2017 at 9:20 AM, Kevin Grittner wrote:
>> On Wed, May 10, 2017 at 7:02 AM, Thomas Munro
>> wrote:
>>> On Wed, May 10, 2017 at 11:10 PM, Thomas Munro
>>> wrote:
>>>> 2. If y
e reflected in the
transition table. This needs to be fixed.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, May 31, 2017 at 1:44 AM, Noah Misch wrote:
> IMMEDIATE ATTENTION REQUIRED.
I should be able to complete review and testing by Friday. If there
are problems I might not take action until Monday; otherwise I
should be able to do so on Friday.
--
Kevin Grittner
VMware vCenter Ser
ccessful split
> operation. For that, we can insert a call for PredicateLockPageSplit() in
> gistplacetopage().
That all sounds good. When you code a patch, don't forget to add
tests to src/test/isolation.
Do you need any help getting a development/build/test environment
set up?
--
Kevin Gr
f its runtime waiting on
the corresponding kernel mutexes."
If you cannot duplicate their results, you might want to contact the
authors for more details on their testing methodology.
Note that the locking around access to the list is likely to be a
bigger problem than the actual walking a
(or some
portion of it larger than 10%) instead, I think we could adjust the
scope based on those results.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
id further
complicating things with CTE/transition table usage until we sort
out the basics of triggers firing from CTE DML in the first place.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
27;ll give it a few days for objections before reverting.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Jun 6, 2017 at 3:41 PM, Marko Tiikkaja wrote:
> On Tue, Jun 6, 2017 at 10:25 PM, Kevin Grittner wrote:
>> It took years to get an in-depth review, then I was asked
>> not to commit it because others were working on patches that would
>> conflict. That just doesn&#
zableConflictIn() ...etc)
When you have a patch for any AM, please post it to the list. Each
AM will be reviewed and considered for commit separately.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
ion, but still. Should we skip
> finishing split or should we add it to collision check too?
When a page is split, I think you need to call
PredicateLockPageSplit() before it gets to the point that an insert
to get to it.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Se
functions stand out:
10.86% PredicateLockTuple
3.51% CheckForSerializableConflictIn
In both cases, most of that seems to go to lightweight locking. Since
you said this is a CPU graph, that again suggests spinlock contention
issues.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
table for any rows affected by an update or delete. If we
have a single statement that combines INSERT and UPDATE behaviors,
it might make sense to have an "old" table for updates and a single
"new" table for both.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
7;ll try to keep to small enough issues that the
resources required to support what I do is not beyond what I can
deliver.
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
if the algorithm treats all
> tuples in the old table as deletes (even though in this case they
> result from updates) and all tuples in the new table as inserts (even
> though in this case *some* of them result from updates) anyway then I
> don't think it matters.
I don't th
atement -- well, it won't be
a problem for matview maintenance. The biggest hurt there would be
to *my* sense of aesthetics. ;-)
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to you
ndex Only Scan, but also on Bitmap Index Scan? And may be
> KNN version of scan too?
> I couldn't find such tests for B-tree, do we have them?
Off-hand, I don't know. It would be interesting to run regression tests with
code coverage and look at the index AMs.
https://www.postgre
transactions.
Essentially, the transaction should only count toward the TPS rate
when it eventually completes without a serialization failure.
Marina, did I understand you correctly?
--
Kevin Grittner
VMware vCenter Server
https://www.vmware.com/
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On Thu, Jun 15, 2017 at 4:18 PM, Alvaro Herrera
wrote:
> Kevin Grittner wrote:
> As far as I understand her proposal, it is exactly the opposite -- if a
> transaction fails, it is discarded. And this P.S. note is asking
> whether this is a good idea, or would we prefer
where in the stack trace, and that there was not any explicit
transaction started -- just a VACUUM command for the table, without
any BEGIN/COMMIT.
This is using source at commit 9faa6ae14f6098e4b55f0131f7ec2694a381fb87.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kevin Grittner wrote:
> If you run `make installcheck` against a cluster with
> default_transaction_isolation = 'repeatable read' you get one
> failure:
> + ERROR: brin_summarize_new_values() cannot run in a transaction that has
> already obtained a snapshot
> Th
Jeff Janes wrote:
> On Tue, Jul 21, 2015 at 3:10 PM, Kevin Grittner wrote:
>> Kevin Grittner wrote:
>>
>>> If you run `make installcheck` against a cluster with
>>> default_transaction_isolation = 'repeatable read' you get one
>>> failure:
&g
should I just do it?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=doc/src/sgml/config.sgml;h=b91d6c75d276e644583915485264b1787fb0c756;hb=master#l5561
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
solution would be to proceed straight to the kill() and only log
something if it was found by kill().
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Tom Lane wrote:
> Kevin Grittner writes:
>> I think a LOG entry when an autovacuum process is actually canceled
>> has value just in case it is happening on a particular table so
>> frequently that the table starts to bloat. I see no reason to log
>> anything if ther
Alvaro Herrera wrote:
> Kevin Grittner wrote:
>> If you run `make installcheck` against a cluster with
>> default_transaction_isolation = 'repeatable read' you get one
>> failure:
>
> I am tempted to say that we should just disallow to run vacuum on
&
Simon Riggs wrote:
> On 30 July 2015 at 22:24, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> Kevin Grittner wrote:
>>>> If you run `make installcheck` against a cluster with
>>>> default_transaction_isolation = 'repeatable read' you get o
the page range based on all non-dead
tuples? I understand that the range being scanned would need to be
locked, but we're OK with doing that for creation of other indexes.
(There is no mention of snapshots or locks in the BRIN README)
--
Kevin Grittner
EDB: http://www.enterprisedb.c
Alvaro Herrera wrote:
> Untested patch attached.
That fixes the installcheck failure on my machine.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
r the declarations and my wording might not
be ideal.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
brin-unused-declarations.diff
Description: invalid/octet-stream
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
l of 1 to 1U, but doesn't that just double
the threshold for failure? Wouldn't 1L (to match the definition of
lbuckets) be better?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
for finding and analyzing this and providing a patch!
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
> Kevin Grittner writes:
>> Kouhei Kaigai wrote:
>>> we may need a couple of overhaul around HashJoin to support large
>>> size of data, not only nbuckets around 0x8000.
>> Perhaps, but this is a clear bug, introduced to the 9.5 code, with
causing an assertion failure during 9.5
testing pending analysis and fixes for the other hazards. Getting
past the assertion failure might help identify some other bugs in
the area.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing
Merlin Moncure wrote:
> -* Forget the query stack and constrant-related state information. As
> +* Forget the query stack and constraint-related state information. As
Pushed. Thanks!
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
I find the TestLib.pm framework to be more friendly with the
attached tweak to SimpleTee.pm. It's not a big deal, so if anyone
objects I'll let it drop, and I don't think it merits anything
fancier.
Objections?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise Pos
hink
> one flush would be sufficient.
Isn't the loop over file handles written to? What would you flush
outside the loop?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To mak
rsion of this
time-based patch for several weeks, and is happy with the results
-- it is preventing bloat for them and not generating "snapshot too
old" errors at unexpected times.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
snapshot-to
sters running under the same OS
user, please provide more deails, like the specific version and
copy/paste of error messages and relevant log entries.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
| notices obtained from the database server, as well as output of
| various backslash commands that query the database (such as \d),
| but not error messages.
Are you seeing anything inconsistent with the documentation? If
so, what?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterpri
Kevin Grittner wrote:
> I find the TestLib.pm framework to be more friendly with the
> attached tweak to SimpleTee.pm.
Pushed.
Please ignore the typo in the commit message -- I was looking right
at the code saying "autoflush", but what came off my fingers (from
muscle memory?)
es forward, only there is a "jump"
forward at the shift). This would allow the tardy database to be
dedicated to catching up again.
Bottom line is that this very smooth behavior required two features
-- the ability for the application to control database affinity,
and the ability to shi
remembering right? And this came about because it added
20-some hours to a pg_upgrade run?
If there are no objections, I will push this as a bug fix back to
9.3, where the performance regression was introduced.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compan
t. I've seen various spins on solutions
described, from which I can infer various possible problems; but to
pick the best version of this as *the* solution I think we need a
clear statement of the problem itself.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
ry.org/projects/fsutil/
The license is BSD, so there should be no problem grabbing the source
and using as much (or as little) as you find helpful.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@post
r more than what you describe above. That would, IMO,
be a mistake.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I
discussed off-list -- the original patch duplicated a bit of code
that we agreed should be split into a static function and called
from both places, to protect against someone later changing one and
missing the other.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise Po
;t do that, I think we should prohibit RETURNING on DELETE
or UPDATE if there is RLS affecting the user's SELECTs.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
fore probably need
to also set the new field), and Jan's proposed patch only changes
one of them. If we do this, I think we need to change both places
that are affected, so ResourceOwnerCreate() in resowner.c would
need a line or two added.
--
Kevin Grittner
EDB: http://www.enterprisedb.co
to handle that, we could probably use it (and some of the
previously-discussed techniques might not be needed), but my
understanding is that there is currently no way to do so.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
nditional on the previous one and
each data page write would be conditional on the WAL record for the
last update to the page. But nobody seems to think that would
yield acceptable performance.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
successful. (Well, at least by default; they can
choose to set synchronous_commit to off for some or all
transactions.) If a write barrier to control this applied to
everything on the filesystem, performance would be horrible.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterpr
with the corresponding
I/O stalls. We approached that incrementally, and that's the point
where stalls stopped occurring. We did not adjust the OS
thresholds for writing dirty pages, although I know of others who
have had to do so.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The
normally of 8KB each.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I wrote:
> to avoid write gluts it must often be limited to 1GB to 1GB.
That should have been "1GB to 2GB."
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
a
connection pool to limit the number of database connections to
something near ((2 * core count) + effective spindle count), since
that's where I typically see best performance; but people don't
always do that.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Comp
some
"slack" space for writes?
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
7;m not seeing that one but I am now getting these:
setup.c: In function ‘test_shm_mq_setup’:
setup.c:65:25: warning: ‘outq’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
setup.c:66:24: warning: ‘inq’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
--
K
se the right timing to be sure of hitting
it. I'm still playing with that, but I figured I should post these
notes from reviewing the source code while I continue with that.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mail
Jov wrote:
> attach patch add the per database set for alter user
Please add to the open CommitFest so that the patch doesn't "fall
through the cracks":
https://commitfest.postgresql.org/action/commitfest_view/open
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Ent
had no space to
keep even a single segment, no? And how would that work with a
situation where the archive_command was failing, causing a build-up
WAL files? It just seems like too much mechanism and incomplete
coverage of the problem space.
--
Kevin Grittner
EDB: http://www.enterprisedb.co
ld be to not generate noise for interim states;
just report net changes. And don't say that a file "contains
errors" when we mean "those options are ignored on reload; they
will only take effect on restart".
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise Po
Tom Lane wrote:
> Kevin Grittner writes:
>> My preference would be to not generate noise for interim states;
>> just report net changes.
>
> Yeah. Is it worth explicitly detecting and dropping redundant assignments
> to the same variable? A naive check for that would b
n't a good reason- if my
> database isn't accepting connections, I probably don't care one
> bit how bloated a table is. Indeed, I care *more* that I'm out
> of connections and would want to know that ASAP.
+1
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterpr
Bruce Momjian wrote:
> On Tue, Jun 18, 2013 at 11:04:25AM -0700, Kevin Grittner wrote:
>> D'Arcy J.M. Cain
>>
>>> Although, the more I think about it, the more I think that the
>>> comment is both confusing and superfluous. The code itself is
>>>
seems reasonable, I can draft a patch to
implement that.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
they can start
multiple clusters from a single shell, and if they later use Ctrl+C
in that shell all of those instances are shut down.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
es without
serious impairment of performance.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
0.05 just to test
whether I was wandering near a tipping point for a bad choice from
this. I have never had 0.05 produce plans noticeably better or
worse than 0.03.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsq
uum changes in 9.2.3 put an end to some
debilitating problems with blocking and load related to overly
aggressive and eager autovacuum runs. Jan's fix addressed problems
with tables used for queues, as in slony and some JMS
implementations. Andres fixed a bug which caused wraparound
prev
new code has a cycle of quick detection of blocked
processes, incremental truncate and sleep, and retry up to 100
times before giving up. In 9.2.3 and 9.2.4 it *also* reschedules
quickly like the old aborted truncation; in 9.2.5 it will just try
again if it seems needed at the next normally scheduled
527891 (excluding connections establishing)
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Kevin Grittner wrote:
> Alvaro Herrera wrote:
>
>> Does the combination in $SUBJECT make sense?
>
> I don't think so; I don't know what it would mean.
Oh, I see -- it's part of the SELECT statement, causing a row-level
lock on each row as it is accessed.
>&
201 - 300 of 4000 matches
Mail list logo
