Re: [HACKERS] [COMMITTERS] pgsql: pgindent run for 9.4

robably the directory should be excluded from pgindent processing. While I haven't checked, I assume all other branches are affected. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To m

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

Kevin Grittner wrote: > each connection caused to be held in cache the last page at each > level of the index. Apologies for ambiguous terminology there. To be clear: the most recently accessed page at each level of the index. -- Kevin Grittner EDB: http://www.enterprisedb.com The Ente

Re: [HACKERS] Clock sweep not caching enough B-Tree leaf pages?

0.75, and there was nothing particularly magic about that multiplier other than it was pretty fast and worked better that 0.5 in my benchmarks.  I also don't remember what we used as the initial value on a page load. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Co

Re: [HACKERS] Auto-tuning work_mem and maintenance_work_mem

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

Re: [HACKERS] integrate pg_upgrade analyze_new_cluster.sh into vacuumdb

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

Re: [HACKERS] Ctrl+C from sh can shut down daemonized PostgreSQL cluster

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

[HACKERS] Ctrl+C from sh can shut down daemonized PostgreSQL cluster

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

Re: [HACKERS] A minor correction in comment in heaptuple.c

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 >>>

Re: [HACKERS] proposal: hide application_name from other users

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

Re: [HACKERS] Incorrectly reporting config errors

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

Re: [HACKERS] Incorrectly reporting config errors

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

Re: [HACKERS] Hard limit on WAL space used (because PANIC sucks)

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

Re: [HACKERS] change alter user to be a true alias for alter role

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

Re: [HACKERS] Race condition in b-tree page deletion

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

Re: [HACKERS] shared memory message queues

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

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

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

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

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

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

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

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

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

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

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

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

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

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

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

Re: [Lsf-pc] [HACKERS] Linux kernel impact on PostgreSQL performance

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

Re: [HACKERS] Disallow arrays with non-standard lower bounds

tion code simpler, easier to read, and less fragile.  I support overloading functions with simpler parameter lists for standard-conforming arrays; I don't support dropping support for whoever might be using non-conforming arrays.  A veriable lower bound is an extension to the standard, and e

Re: [HACKERS] Linux kernel impact on PostgreSQL performance

at DEADLINE or NOOP perform better than any alternatives for most database loads. Anyone with a job setting up Linux machines to be used for database servers should know to cover that.  As long as those two don't get broken, I'm good. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enter

Re: [HACKERS] Linux kernel impact on PostgreSQL performance

reasonable regimen for testing database performance on Linux > kernels. ... or perhaps you figure this is what would bring such issues to the community's attention before people are bitten in production environments? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise Postgre

Re: [HACKERS] Standalone synchronous master

raded mode in some way, or we > need pg_sync_rep_degraded(), or (ideally) both. +1 Since this new feature, where enabled, would cause synchronous replication to provide no guarantees beyond what asynchronous replication does[1], but would tend to cause people to have an *expectation* that they

[HACKERS] ECPG regression tests generating warnings

e is in the src/interfaces/ecpg/test/sql/ directory and was modified by the above-mentioned commit. -- 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

Re: [HACKERS] Disallow arrays with non-standard lower bounds

d limiting. That said, I think it would be nice to have better support for arrays defined with a single dimension and a low bound of 1, as the standard requires.  Functions which throw an error when passed a non-conforming parameter and can provide a simplified API as a result would probably get used

Re: [HACKERS] [PATCH] Negative Transition Aggregate Functions (WIP)

approximate numbers is misplaced. >> But NaN is an orthogonal problem I think. Agreed. -- 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

Re: [HACKERS] Standalone synchronous master

Andres Freund wrote: > On 2014-01-08 13:34:08 -0800, Kevin Grittner wrote: > >> On the other hand, we keep getting people saying they want the >> database to make the promise of synchronous replication, and >> tell applications that it has been successful even when it &g

Re: [HACKERS] Standalone synchronous master

return from a commit request means.  Sooner or later, Murphy's Law being what it is, if we do this someone will lose the primary and blame us because the synchronous replica is missing gobs of transactions that were successfully committed. -- Kevin Grittner EDB: http://www.enterprisedb.com The

Re: [HACKERS] How to reproduce serialization failure for a read only transaction.

Florian Pflug wrote: > On Jan7, 2014, at 20:11 , Kevin Grittner wrote: >> Yeah, neither of the provided examples rolled back the read only >> transaction itself; > > Actually, the fixed version [1] of my example does. > > [1] > http://www.postgresql.org/mess

Re: [HACKERS] Re: How to reproduce serialization failure for a read only transaction.

AK wrote: > So if I am reading the data and then commit, I should be always > fine, correct? If a serializable transaction successfully commits, that means that all data read within that transaction can be trusted. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise Post

Re: [HACKERS] Re: How to reproduce serialization failure for a read only transaction.

the simple write skew and get into more complex ways of breaking things.  With that tweak you can run all of those transactions if W1 skips the SELECT.  You can let W1 do the SELECT as long as you don't run R.  The problem is that the SELECT in W1 sees the work of W1 but not W2 and th

Re: [HACKERS] Re: How to reproduce serialization failure for a read only transaction.

(unlike strategies which rely on blocking, like S2PL) all transactions must be participating in the stricter isolation level for it to be reliable.  In fact, given the performance benefits of declaring transactions READ ONLY when possible, I have seen shops that make *that* a default, too, and ove

Re: [HACKERS] How to reproduce serialization failure for a read only transaction.

/wiki/SSI#Read_Only_Transactions -- 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

Re: [HACKERS] [PATCH] SQL assertions prototype

Kevin Grittner wrote: > For an example of how things can look OK in terms of enforced > constraints as of different moments in time, yet those moments in > time could be inconsistent, see this section: > > http://wiki.postgresql.org/wiki/SSI#Enforcing_Business_Rules_in_Trigg

Re: [HACKERS] [PATCH] SQL assertions prototype

ou can't ensure that a non-serializable transaction won't see a state which is inconsistent with a later database state according to *procedural* business rules. -- 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

Re: [HACKERS] [BUG FIX] Version number expressed in octal form by mistake

Tom Lane wrote: > Kevin Grittner writes: >> Tom Lane wrote: >>> So I'm inclined to propose that we set min/max to 0 and 99 >>> here. >> >> Something like the attached back-patched to 8.4? > > Works for me. Done. Thanks

Re: [HACKERS] [BUG FIX] Version number expressed in octal form by mistake

into the archive file.  And we don't have enough > information to be very sure about whether it will work, short of actually > trying it.  So why should the code arbitrarily refuse to try? > > So I'm inclined to propose that we set min/max to 0 and 99 here. Something like

Re: [HACKERS] truncating pg_multixact/members

would be deleted "soon enough" anyway.  Barring objection, deleting them at startup seems like a sane way to handle pg_upgrade issues when we do increase the filename size. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pg

Re: [HACKERS] [BUG FIX] Version number expressed in octal form by mistake

Kevin Grittner wrote: > Joel Jacobson wrote: > >> As reported by Andrey Karpov in his article >> http://www.viva64.com/en/b/0227/ >> the version number is expressed in octal form 070100 should be >> changed to 70100. >> >> Attached patch fixes the repor

Re: [HACKERS] [BUG FIX] Version number expressed in octal form by mistake

making it an octal literal it is taken as version 2.87.36.  Do we want to make the code match the docs, or make both match what the code appears to have been attempting? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list

Re: [HACKERS] [BUGFIX] Typos when using the memcmp() function.

Joel Jacobson wrote: > As reported by Andrey Karpov in his article > http://www.viva64.com/en/b/0227/ > a parenthesis has been misplaced. > > Attached patch fixes the problem. Applied to all supported branches.  Thanks! -- Kevin Grittner EDB: http://www.enterprisedb.com

Re: [HACKERS] [BUGFIX] Typos when using the memcmp() function.

Joel Jacobson wrote: > As reported by Andrey Karpov in his article > http://www.viva64.com/en/b/0227/ > a parenthesis has been misplaced. > > Attached patch fixes the problem. That sure looks like a bug to me.  It exists in all supported branches.  I can get this one. -- Kev

Re: [HACKERS] preserving forensic information when we freeze

et a spurious error message when there is a tuple freeze while the window is open, so the current changes are probably good news for those using this approach. Other than that and ctid (for similar reasons) I have not seen system columns used in applications or application frameworks. -- Kevin

Re: [HACKERS] clang's -Wmissing-variable-declarations shows some shoddy programming

Bruce Momjian wrote: > I have fixed the binary_upgrade_* variables defines, and Heikki has > fixed some other cases.  Can you rerun the test against git head and > post the updated output?  Thanks. I'm now seeing the attached. -- Kevin Grittner EDB: http://www.enterprisedb.com

Re: [HACKERS] [PATCH] SQL assertions prototype

done something which could affect the truth of the assertion. -- 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

Re: [HACKERS] [PATCH] SQL assertions prototype

Jim Nasby wrote: > On 12/18/13, 1:42 PM, Kevin Grittner wrote: >> Jim Nasby wrote: >> >>> This is another case where it would be very useful to restrict >>> what relations a transaction (or in this case, a substransaction) >>> can access. If we had

Re: [HACKERS] [PATCH] SQL assertions prototype

SSI could also optimize based on that, although there are probably about 10 other optimizations that would be bigger gains before getting to that. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)

Re: [HACKERS] [PATCH] SQL assertions prototype

ing a multi-table invariant using triggers: http://wiki.postgresql.org/wiki/SSI -- 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.o

Re: [HACKERS] [PATCH] SQL assertions prototype

hing which could affect the truth of an assertion? That seems like it would work, but I suspect that it would be worse for performance than SSI in many workloads, and better than SSI in other workloads.  Maybe a GUC to determine which strategy is used? -- Kevin Grittner EDB: http://www.enterprisedb.c

Re: [HACKERS] [PATCH] SQL assertions prototype

ice to have a way to prohibit overrides, but that's another issue. Otherwise it is hard to see how to make it work in a general way without a mutually exclusive lock mode on the table for the duration of any transaction which modifies the table. -- Kevin Grittner EDB: http://www.enterprisedb.c

Re: [HACKERS] pg_rewarm status

ld have used a prewarm utility is following an off-hours VACUUM FREEZE run.  Where this maintenance made sense the only downside I saw was a brief period in the mornings where the cache was not populated with the "hot" data, and performance was somewhat degraded until the cache settled in a

Re: [HACKERS] Race condition in b-tree page deletion

f just leaving it alone in stable branches.  Anyway, that would be a different patch. More on *this* patch in a day or two. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make c

Re: [HACKERS] Reference to parent query from ANY sublink

34.12..34.12 rows=200 width=12) ->  HashAggregate  (cost=32.12..34.12 rows=200 width=12)    Group Key: lower.f2    ->  Seq Scan on subselect_tbl lower  (cost=0.00..27.70 rows=1770 width=12) The additional information is so useful, I'm all for committing

Re: [HACKERS] Reference to parent query from ANY sublink

tly.) Yeah, I found myself wishing for an EXPLAIN option that would show that. > The cost of the HashAggregate is estimated higher, though, which > suggests that maybe it's distinct'ing on two columns where the > bogus plan only does one. FWIW, I noticed that the actual row coun

Re: [HACKERS] Reference to parent query from ANY sublink

Kevin Grittner wrote: > I applied it to master and ran the regression tests, and one of > the subselect tests failed. > > This query: > > SELECT '' AS six, f1 AS "Correlated Field", f3 AS "Second > Field" >   FROM SUBSELECT_TBL upper >   W

Re: [HACKERS] ANALYZE sampling is too good

s. So if one selected 11 > pages at random, you get about 10 pages of large rows and about one for > small rows! With 10 * 2 = 20 large rows, and 1 * 20 = 20 small rows. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing l

Re: [HACKERS] In-Memory Columnar Store

are orthogonal to work on incremental maintenance. I have no plans to work on either matview freshness or rewrite, as there seems to be several years worth of work to get incremental maintenance up to a level matching other products.  I welcome anyone else to take on those other projects. -- Kev

Re: [HACKERS] [RFC] Shouldn't we remove annoying FATAL messages from server log?

MauMau wrote: > From: "Kevin Grittner" > FATAL is used when the problem is severe enough that the process > or connection must end. It seems to me to be what should > consistently be used when a client connection or its process must > be terminated for a reason other t

Re: [HACKERS] Why the buildfarm is all pink

Kevin Grittner wrote: > Tom Lane wrote: > >> I haven't touched matview.sql here; that seems like a distinct >> issue. > > I'll fix that. Done. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-h

Re: [HACKERS] Why the buildfarm is all pink

Tom Lane wrote: > I haven't touched matview.sql here; that seems like a distinct issue. I'll fix that. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make ch

Re: [HACKERS] Reference to parent query from ANY sublink

later and try it, the rows show up.  It's not immediately apparent to me what's wrong. Will look again later, or maybe someone more familiar with the planner can spot the problem. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers

Re: [HACKERS] [RFC] Shouldn't we remove annoying FATAL messages from server log?

blem is severe enough that the process or connection must end.  It seems to me to be what should consistently be used when a client connection or its process must be terminated for a reason other than a client-side request to terminate. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterp

Re: [HACKERS] Reference to parent query from ANY sublink

Kevin Grittner wrote: > test=# SELECT * > FROM    tab1 a > LEFT JOIN > tab2 b > ON a.i = ANY ( > SELECT  k     > FROM    tab3 c > WHERE    k = a.i); >  i | j > ---+--- >  1 | 4 >  1 | 5 >  1 | 6 >  2 | >  3

Re: [HACKERS] Reference to parent query from ANY sublink

intend with the SEMI JOIN syntax.  PostgreSQL supports semi-joins; but that is an implementation detail for the EXISTS or IN syntax.  Could you clarify your intent? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (p

[HACKERS] pg_archivecleanup bug

least one WAL file.  Perhaps we want to back-patch the simple fix and do something fancier for 9.4? I would also add a few comment lines before committing this, if we decide to go with the simple approach -- this is for purposes of illustration; to facilitate discussion. Thoughts? -- Kevin Gri

Re: [HACKERS] Time-Delayed Standbys

the software do fsync because the sysadmin might not have turned off write-back buffering on drives without persistent storage. Either way, poor system management can defeat the feature.  Either way, I see no reason to withhold the feature from those who manage their systems in a sane fash

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

et.  My personal feeling is that it would be good if that were not a barrier to using pg_upgrade; but it would be OK as long as running it with the --check option *tells* you that the cluster can't be upgraded without turning that property off for all databases, and that the user under whi

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

back to 8.4. -- 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

Re: [HACKERS] select_common_type()'s behavior doesn't match the documentation

documentation has been rewritten more > recently.  It's a bit scary to be proposing to change behavior that's > been stable for eleven years, but ... > > Thoughts? The current behavior is bad enough to merit changing it.  Not for back-patch, of course. -- Kevin Grittner EDB: ht

Re: [HACKERS] MultiXact bugs

Kevin Grittner wrote: > In going over this, I found pre-existing bugs when a tuple was both > inserted and deleted by concurrent transactions, but fixing that is > too invasive to consider for Monday's minor release lockdown.  The > attached seems very safe to me, and protects

Re: [HACKERS] MultiXact bugs

the global cutoff that will cause wrong > hint bits to be set. Or am I missing something? I don't see where that parameter has anything to do with setting hint bits; it only seems to affect the return code for the caller. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise Post

Re: [HACKERS] MultiXact truncation, startup et al.

is reverted in there, too (no longer necessary.) Does this mean that when HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DELETE_IN_PROGRESS it is no longer possible for HeapTupleHeaderGetUpdateXid() to return InvalidTransactionId? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterp

Re: [HACKERS] MultiXact bugs

Andres Freund wrote: > On 2013-11-27 15:42:11 -0800, Kevin Grittner wrote: >> What back-patching will be needed for a fix?  It sounds like >> 9.3? > > Yep. In going over this, I found pre-existing bugs when a tuple was both inserted and deleted by concurrent transactions, b

Re: [HACKERS] MultiXact bugs

Andres Freund wrote: > On 2013-11-27 15:14:11 -0800, Kevin Grittner wrote: >> ... however, I have not been able to trigger that Assert even with >> gdb breakpoints at what I think are the right spots.  Any >> suggestions?  How far back is it true that the above >> Hea

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Bruce Momjian wrote: > On Wed, Nov 27, 2013 at 06:05:13AM -0800, Kevin Grittner wrote: >> Bruce Momjian wrote: >>> I am confused what we are patching.  Are we patching pg_dump, >>> pg_dumpall, or both? >> >> Just pg_dumpall.c. > > OK, there was a pg_

Re: [HACKERS] MultiXact bugs

ateXid(tuple->t_data) on the exact same tuple structure can return InvalidTransactionId?  Is there some other condition (besides a ROLLBACK of an UPDATE on the tuple being read) which needs to be met?  Is any particular timing necessary? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterp

Re: [HACKERS] Should we improve documentation on isolation levels?

AK wrote: > the documentation is not incorrect, it is just incomplete. Yeah, that's exactly how I saw it.  :-) Docs changed on master only.  Thanks for the report! -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mail

Re: [HACKERS] Should we improve documentation on isolation levels?

second SELECT starts." > > The reason: there could be other DML running between these two SELECTs. That's a fair point.  I'll commit something to the master branch. I don't think this rises to the level of a documentation bug that needs to be back-patched. -- Kevin Grittn

Re: [HACKERS] doPickSplit stack buffer overflow in XLogInsert?

ap with the next thing on the stack, allowing one or the other to get stepped on. (2)  That the CRC calculation might picking up uninitialized data which was not actually going to match what was used during recovery, leading to "end of recovery" on replay. If you are confident that nei

Re: [HACKERS] Platform-dependent(?) failure in timeout handling

Tom Lane wrote: > 3. Establish a coding rule that if you catch an error with > PG_TRY() and don't re-throw it, you have to unblock signals in > your PG_CATCH block. Could that be done in the PG_END_TRY macro? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise Post

Re: [HACKERS] doPickSplit stack buffer overflow in XLogInsert?

Andres Freund wrote: > On 2013-11-26 14:14:38 -0800, Kevin Grittner wrote: > >> I happened to build in a shell that was still set up for the clang >> address sanitizer, and got the attached report.  On a rerun it was >> repeatable.  XLogInsert() seems to read pa

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Bruce Momjian wrote: > On Tue, Nov 26, 2013 at 03:25:44PM -0800, Kevin Grittner wrote: >> Bruce Momjian wrote: >> >>> How are we handling breakage of pg_dump, not pg_dumpall? >> >> That was discussed.  Do you have something to add? > > I am confused what

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

rather I leave the whole thing to you, that's OK, too. -- 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

[HACKERS] doPickSplit stack buffer overflow in XLogInsert?

part of the code is unfamiliar to me. -- 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

Re: [HACKERS] PL/Python: domain over array support

air_domain AS integer[] CHECK (array_length(VALUE,1)=2 AND VALUE[1] < VALUE[2]);   CREATE FUNCTION test_type_conversion_array_domain(x ordered_pair_domain) RETURNS ordered_pair_domain AS $$   plpy.info(x, type(x)) ====== -- Kevin Gr

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Bruce Momjian wrote: > Kevin Grittner wrote: >> Bruce Momjian wrote: >> >>> I am not a fan of backpatching any of this. >> >> Here's my problem with that.  Here's setup to create what I >> don't think is all that weird a setup: >>

Re: [HACKERS] MultiXact bugs

hit the > problem (I presume there is no update/delete in these test cases, > but I didn't check).  I defer to Kevin on this issue. Right now if HeapTupleSatisfiesVacuum() returns HEAPTUPLE_DELETE_IN_PROGRESS we call HeapTupleHeaderGetUpdateXid(tuple->t_data) and Assert() that the res

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

ommand from the start of a compound statement. -- 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

Re: [HACKERS] [PATCH] SQL assertions prototype

David Fetter wrote: > On Mon, Nov 25, 2013 at 11:04:23AM -0800, Kevin Grittner wrote: >> As soon as we are out of this CF, I am planning to write code to >> capture deltas and fire functions to process them "eagerly" >> (within the creating transaction).  There h

Re: [HACKERS] [PATCH] SQL assertions prototype

" around the point that "after triggers" fire.  How close does that sound to what CREATE ASSERTION (as currently envisioned) would need?  How viable does it sound to turn an assertion expression into a matview which is empty if there are no violations? -- Kevin Grittner EDB: http:/

Re: [HACKERS] Regress tests to improve the function coverage of schemacmds and user and tablespace files

y to exercise such longer-running tests, but I suspect we soon will.  At any rate, this is a piece of information the committer will want, so you will be helping whoever that is if you can supply it. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via p

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

BLE SELECT 0 ALTER TABLE SELECT 0 ALTER TABLE SELECT 0 ALTER TABLE SELECT 0 ALTER TABLE ALTER TABLE CREATE INDEX CREATE INDEX CREATE INDEX CREATE INDEX SET REFRESH MATERIALIZED VIEW SET REFRESH MATERIALIZED VIEW REFRESH MATERIALIZED VIEW REFRESH MATERIALIZED VIEW REFRESH MATERIALIZED VIEW REFRESH MATER

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Andres Freund wrote: > On 2013-11-22 13:34:18 -0800, Kevin Grittner wrote: >> Oddly, it didn't complain about creating users within a read-only >> transaction.  That seems like a potential bug. > > There's lots of things that escape XactReadOnly. I've thought (

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

Bruce Momjian wrote: > On Fri, Nov 22, 2013 at 01:55:10PM -0800, Kevin Grittner wrote: > >> It does nothing about pg_upgrade, which is sort of a separate >> issue.  My inclination is that connections to the new cluster >> should set this and connections to the old should

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

ck? In the nearest analog in the SQL standard, the BEGIN/END block is called a compound statement, and like any other statement it is ended by a semicolon; the standard does not allow a semicolon after the BEGIN. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Com

Re: [HACKERS] [GENERAL] pg_upgrade ?deficiency

ump output with \i from a text file.  If we go this way, would we want options on pg_restore and/or psql to issue this set when reading in a file (or piped input)? -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-ha

<    3   4   5   6   7   8   9   10   11   12   >