Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

Hi, On Sat, Jul 20, 2013 at 6:28 PM, Greg Smith wrote: > On 7/20/13 4:48 AM, didier wrote: > >> >> That is the theory. In practice write caches are so large now, there is > almost no pressure forcing writes to happen until the fsync calls show up. > It's easily possible to enter the checkpoint

Re: [HACKERS] Improvement of checkpoint IO scheduler for stable transaction responses

On Sat, Jul 20, 2013 at 6:28 PM, Greg Smith wrote: > On 7/20/13 4:48 AM, didier wrote: > >> With your tests did you try to write the hot buffers first? ie buffers >> with a high refcount, either by sorting them on refcount or at least >> sweeping the buffer list in reverse? >> > > I never tried

Re: [HACKERS] [PATCH] pgbench --throttle (submission 7 - with lag measurement)

Greg, > Yes, I already took at look at it briefly. The updates move in the > right direction, but I can edit them usefully before commit. I'll > have that done by tomorrow and send out a new version. I'm hopeful > that v18 will finally be the one that everyone likes. Have you done it? -- Tatsu

Re: [HACKERS] Proposal: template-ify (binary) extensions

On 07/21/2013 10:30 PM, Markus Wanner wrote: >> but I will admit having a hard time swallowing >> the threat model we're talking about… > An attacker having access to a libpq connection with superuser rights > cannot currently run arbitrary native code. He can try a DOS by > exhausting system resou

Re: [HACKERS] REINDEX checking of index constraints

On 07/21/2013 11:30 AM, Josh Berkus wrote: > Noah, > >> Attached patch just restores the old behavior. Would it be worth preserving >> the ability to fix an index consistency problem with a REINDEX independent >> from related heap consistency problems such as duplicate keys? > > I would love to

Re: [HACKERS] Proposal: template-ify (binary) extensions

Salut Dimitri, On 07/20/2013 01:23 AM, Dimitri Fontaine wrote: > Markus Wanner writes: >>> - per-installation (not even per-cluster) DSO availability >>> >>> If you install PostGIS 1.5 on a system, then it's just impossible to >>> bring another cluster (of the same PostgreSQL major vers

Re: [HACKERS] REINDEX checking of index constraints

On 07/21/2013 11:30 AM, Josh Berkus wrote: > Noah, > >> Attached patch just restores the old behavior. Would it be worth preserving >> the ability to fix an index consistency problem with a REINDEX independent >> from related heap consistency problems such as duplicate keys? > > I would love to

Re: [HACKERS] REINDEX checking of index constraints

Noah, > Attached patch just restores the old behavior. Would it be worth preserving > the ability to fix an index consistency problem with a REINDEX independent > from related heap consistency problems such as duplicate keys? I would love to have two versions of REINDEX, one which validated and

[HACKERS] REINDEX checking of index constraints

Historically, REINDEX would always revalidate any uniqueness enforced by the index. An EDB customer reported that this is not happening, and indeed I broke it way back in commit 8ceb24568054232696dddc1166a8563bc78c900a. Specifically, REINDEX TABLE and REINDEX DATABASE no longer revalidate constrai

Re: [HACKERS] Preventing tuple-table leakage in plpgsql

Noah Misch writes: > On Fri, Jul 19, 2013 at 07:34:14PM -0400, Tom Lane wrote: >> However, we can use your idea when running inside a subtransaction, >> while still attaching the tuple table to the procedure's own procCxt >> when no subtransaction is involved. The attached draft patch does it >>

Re: [HACKERS] InvokeObjectPostAlterHook() vs. CommandCounterIncrement()

On Sun, Jul 21, 2013 at 11:44:51AM +0300, Ants Aasma wrote: > On Jul 21, 2013 4:06 AM, "Noah Misch" wrote: > > If these hooks will need to apply to a larger operation, I > > think that mandates a different means to reliably expose the before/after > > object states. > > I haven't checked the code

Re: [HACKERS] Preventing tuple-table leakage in plpgsql

On Fri, Jul 19, 2013 at 07:34:14PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Fri, Jul 05, 2013 at 02:47:06PM -0400, Tom Lane wrote: > >> So I'm inclined to propose that SPI itself should offer some mechanism > >> for cleaning up tuple tables at subtransaction abort. We could just > >> ha

Re: [HACKERS] Preventing tuple-table leakage in plpgsql

Noah Misch writes: > On Thu, Jul 11, 2013 at 09:14:38PM -0400, Chad Wagner wrote: >> Should SPI_connect be called again after the subtransaction is created? And >> SPI_finish before the subtransaction is committed or aborted? > Hmm. An SPI_push()+SPI_connect() every time PL/pgSQL starts a subtr

Re: [HACKERS] Preventing tuple-table leakage in plpgsql

On Thu, Jul 11, 2013 at 09:14:38PM -0400, Chad Wagner wrote: > It looks like to me when AtEOSubXact_SPI is called the > _SPI_current->connectSubId is always 1 (since it is only set when > SPI_connect is called, which is only once for plpgsql), but the > CurrentSubTransactionId is incremented each t

[HACKERS] Auto explain target tables

hi, list, again. the next proposal into auto explain. one would be happy if could set list of target tables and indexes. sometimes it is very hard to detect who is using your indexes. but turn total logging on under thousands transactions per seconds is not seems like nice idea couse size of re

[HACKERS] Wal sync odirect

hi, list. there are my proposal. i would like to tell about odirect in wal sync in wal_level is higher than minimal. i think in my case when wal traffic is up to 1gb per 2-3 minutes but discs hardware with 2gb bbu cache (or maybe ssd under wal) - there would be better if wall traffic could not h

Re: [HACKERS] InvokeObjectPostAlterHook() vs. CommandCounterIncrement()

On Jul 21, 2013 4:06 AM, "Noah Misch" wrote: > If these hooks will need to apply to a larger operation, I > think that mandates a different means to reliably expose the before/after > object states. I haven't checked the code to see how it would fit the API, but what about taking a snapshot befor