On 04.01.2012 07:58, Peter Geoghegan wrote:
As part of the ongoing effort to reduce wake-ups when idle/power
consumption, the attached patch modifies the background writer to
hibernate in ten second bursts once the bgwriter laps the clock sweep.
It's fairly well commented, so a description of how
"Kevin Grittner" wrote:
> if we define sum1 and sum2 as uint I don't see how we can get an
> overflow with 8k byes
I feel the need to amend that opinion.
While sum1 only needs to hold a maximum of (BLCKSZ * 255), which
would be adequate for a BLCKSZ up to 16 MB, sum2 needs to hold up to
a ma
As part of the ongoing effort to reduce wake-ups when idle/power
consumption, the attached patch modifies the background writer to
hibernate in ten second bursts once the bgwriter laps the clock sweep.
It's fairly well commented, so a description of how it works here
would probably be redundant. Th
Is this perhaps by design?
Oy, this doesn’t look good:
$ do LANGUAGE plperl $$ elog(NOTICE, $^V) $$;
ERROR: server conn crashed?
ERROR: server conn crashed?
The connection to the server was lost. Attempting reset: Succeeded.
(pgxn@localhost:5900) 06:44:42 [pgxn]
$
Best,
David
smime.p7s
Des
On Jan 3, 2012, at 7:34 PM, Robert Haas wrote:
> On Tue, Jan 3, 2012 at 7:11 PM, Tom Lane wrote:
>> Jim Nasby writes:
>>> Yeah, but the problem we run into is that with every backend trying to run
>>> the clock on it's own we end up with high contention again... it's just in
>>> a different pla
I assume you guys know where to go to get the complete sql:2011 spec:
http://www.iso.org/iso/search.htm?qt=9075&searchSubmit=Search&sort=rel&type=simple&published=true
But if time/money is an issue the following seems to be the best publicly
available description of the temporal features:
http:/
Robert Haas writes:
> On Tue, Jan 3, 2012 at 6:25 PM, Peter Eisentraut wrote:
>> [ reasons ]
> I agree with these reasons. We don't get charged $0.50 per GUC, so
> there's no particular reason to contort things to have fewer of them.
Well, there definitely is a distributed cost to each additio
Daniel Farina writes:
> And, even more interestingly,
> $ stat 16587.8 pg_internal.init
> File: `16587.8'
> Size: 98532 Blocks: 200IO Block: 4096 regular file
> Device: fe00h/65024d Inode: 1073741952 Links: 1
> Access: (0600/-rw---) Uid: ( 107/postgres) Gid: ( 115
Robert Haas writes:
> On Tue, Jan 3, 2012 at 7:39 PM, Peter Geoghegan wrote:
>> Yes, I know that these only appeared in GCC 4.6+ and as such are a
>> relatively recent phenomenon, but there has been some effort to
>> eliminate them, and if I could get a non-hacked -Werror build I'd feel
>> happy
On Tue, Dec 27, 2011 at 6:39 AM, Alexander Björnhagen
wrote:
> And so we get back to the three likelihoods in our two-node setup :
>
> 1.The master fails
> - Okay, promote the standby
>
> 2.The standby fails
> - Okay, the system still works but you no longer have data
> redundancy. Deal with it.
On 01/03/2012 09:00 PM, Robert Haas wrote:
Normally you can just go to buildfarm.postgresql.org
and see which machines are failing and at what stage, and the view the
stage logs to see the specific errors. It's not the best web
interface I've ever seen, but it's not *that* bad.
And if someon
On Tue, Dec 27, 2011 at 10:48 PM, YAMAMOTO Takashi
wrote:
> does it make sense to teach the planner (and the executor?) use an ordering op
> to optimize queries like the following?
>
> select * from t where a <-> 1000 < 10
Seems useful to me. I'm not sure how hard it is, though.
--
Robe
On 01/03/2012 08:40 PM, Robert Haas wrote:
On Tue, Jan 3, 2012 at 9:33 AM, Pavel Stehule wrote:
I'd suppose it interesting to add a table to pg_catalog containing this data.
- it is useless overhead
I tend to agree.
I am expecting so definition some constants in Perl, Python is simple
Pr
On Tue, Jan 3, 2012 at 6:25 PM, Peter Eisentraut wrote:
> On mån, 2012-01-02 at 23:42 -0500, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote:
>> >> Were you thinking one option pointing to a directory or one option per
>> >> file?
>>
>> >
On Tue, Jan 3, 2012 at 6:29 PM, Peter Eisentraut wrote:
> On mån, 2012-01-02 at 17:27 -0500, Andrew Dunstan wrote:
>>
>> On 01/02/2012 04:37 PM, Peter Eisentraut wrote:
>> > On mån, 2012-01-02 at 15:55 -0500, Andrew Dunstan wrote:
>> >> On 01/02/2012 03:12 PM, Peter Eisentraut wrote:
>> >>> pg_reg
On Tue, Jan 3, 2012 at 7:39 PM, Peter Geoghegan wrote:
> Yes, I know that these only appeared in GCC 4.6+ and as such are a
> relatively recent phenomenon, but there has been some effort to
> eliminate them, and if I could get a non-hacked -Werror build I'd feel
> happy enough about excluding them
On Fri, Dec 30, 2011 at 11:58 AM, Jeff Janes wrote:
> On 12/29/11, Ants Aasma wrote:
>> Unless I'm missing something, double-writes are needed for all writes,
>> not only the first page after a checkpoint. Consider this sequence of
>> events:
>>
>> 1. Checkpoint
>> 2. Double-write of page A (DW b
On Tue, Jan 3, 2012 at 9:33 AM, Pavel Stehule wrote:
>> I'd suppose it interesting to add a table to pg_catalog containing this data.
>
> - it is useless overhead
I tend to agree.
> I am expecting so definition some constants in Perl, Python is simple
Presumably one could instead write a script
On Mon, Jan 2, 2012 at 1:42 AM, chris r. wrote:
>>> I ported the entire schema to my test DB server and could not reproduce
>>> the error there. Note that probably recreating the view solves this
>>> issue. Given this, how should I proceed to create a test case? Any
>>> tutorial on this? (I'm not
On Tue, Jan 3, 2012 at 7:11 PM, Tom Lane wrote:
> Jim Nasby writes:
>> Yeah, but the problem we run into is that with every backend trying to run
>> the clock on it's own we end up with high contention again... it's just in a
>> different place than when we had a true LRU. The clock sweep might
On Tue, Jan 3, 2012 at 6:22 PM, Jim Nasby wrote:
> On Jan 3, 2012, at 11:15 AM, Robert Haas wrote:
>>> So you don't think a freelist is worth having, but you want a list of
>>> allocation targets.
>>> What is the practical difference?
>>
>> I think that our current freelist is practically useless,
I'm not sure if this is an XFS problem, or Postgres. There's enough
suspicious evidence that it's too hard to say.
Today, I get an interesting issue raised whereby a reasonably simple
query fails on a system that does take successful pg_dumps regularly.
To make a short story shorter, I end up wit
During the talk "How To Get Your PostgreSQL Patch Accepted" during
PgCon last year, I raised the idea of making a -Werror build option
easily available. I think it was Robert that pointed out that the
problem with that was that there is a warning due to an upstream Flex
bug that we can't do anythin
On Tue, Jan 03, 2012 at 06:43:52PM -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > Since I didn't actually tell you that I've made a context diff
> > for you, and it's attached. I'll let someone with more FBSD-fu than me
> > actually comment on it.
>
> I have no FBSD-fu whatever, but the qu
On Dec 28, 2011, at 3:31 AM, Simon Riggs wrote:
> On Wed, Dec 28, 2011 at 9:00 AM, Robert Haas wrote:
>
>> What I'm not too clear
>> about is whether a 16-bit checksum meets the needs of people who want
>> checksums.
>
> We need this now, hence the gymnastics to get it into this release.
>
> 1
Jim Nasby writes:
> Yeah, but the problem we run into is that with every backend trying to run
> the clock on it's own we end up with high contention again... it's just in a
> different place than when we had a true LRU. The clock sweep might be cheaper
> than the linked list was, but it's stil
On Jan 1, 2012, at 10:43 PM, Peter Eisentraut wrote:
> I figured the best and most flexible way to address this is to export
> acldefault() as an SQL function and replace
>
>aclexplode(proacl)
>
> with
>
>aclexplode(coalesce(proacl, acldefault('f', proowner)))
It would be nice to provid
On Jan 3, 2012, at 5:28 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
>>> This could well be related to the fact that DropRelFileNodeBuffers()
>>> does a scan of shared_buffers, which is an O(N) approach no matter the
>>> size of the index.
>
>> Couldn
Andrew Dunstan writes:
> Since I didn't actually tell you that I've made a context diff
> for you, and it's attached. I'll let someone with more FBSD-fu than me
> actually comment on it.
I have no FBSD-fu whatever, but the question this patch raises in my
mind is whether /boot/loader.conf exist
On 01/03/2012 06:29 PM, Peter Eisentraut wrote:
I think there is some room for improvement there:
- Why is the isolation test not part of check-world/installcheck-world?
The buildfarm does not use the -world targets, for several reasons,
including:
That was not my question. I run check-w
On 01/03/2012 06:15 PM, Brad Davis wrote:
On Tue, Jan 03, 2012 at 05:02:57PM -0500, Andrew Dunstan wrote:
On 01/03/2012 04:49 PM, Brad Davis wrote:
Hi,
I have a patch that improves the documentation for FreeBSD Kernel Tuning:
- Show a # prompt instead of $ to indicate a root shell is neede
On mån, 2012-01-02 at 17:27 -0500, Andrew Dunstan wrote:
>
> On 01/02/2012 04:37 PM, Peter Eisentraut wrote:
> > On mån, 2012-01-02 at 15:55 -0500, Andrew Dunstan wrote:
> >> On 01/02/2012 03:12 PM, Peter Eisentraut wrote:
> >>> pg_regress: Replace exit_nicely() with exit() plus atexit() hook
> >>
Jim Nasby writes:
> On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
>> This could well be related to the fact that DropRelFileNodeBuffers()
>> does a scan of shared_buffers, which is an O(N) approach no matter the
>> size of the index.
> Couldn't we just leave the buffers alone? Once an index is
On mån, 2012-01-02 at 23:42 -0500, Tom Lane wrote:
> Peter Eisentraut writes:
> > On mån, 2012-01-02 at 15:47 +0100, Magnus Hagander wrote:
> >> Were you thinking one option pointing to a directory or one option per
> >> file?
>
> > One option per file:
>
> That seems like serious overkill. Why
On Jan 3, 2012, at 11:15 AM, Robert Haas wrote:
>> So you don't think a freelist is worth having, but you want a list of
>> allocation targets.
>> What is the practical difference?
>
> I think that our current freelist is practically useless, because it
> is almost always empty, and the cases wher
On Tue, Jan 03, 2012 at 05:02:57PM -0500, Andrew Dunstan wrote:
>
>
> On 01/03/2012 04:49 PM, Brad Davis wrote:
> > Hi,
> >
> > I have a patch that improves the documentation for FreeBSD Kernel Tuning:
> >
> > - Show a # prompt instead of $ to indicate a root shell is needed
> > - Remove the -w f
On Jan 3, 2012, at 12:11 PM, Simon Riggs wrote:
> This could well be related to the fact that DropRelFileNodeBuffers()
> does a scan of shared_buffers, which is an O(N) approach no matter the
> size of the index.
>
> On top of that, taking what Robert Haas mentioned on another thread,
> Invalidate
On Jan 3, 2012, at 4:21 PM, Kevin Grittner wrote:
> (2) I'm not sure about doing this in three parts, to skip the
> checksum itself and the hole in the middle of the page. Is this
> because the hole might not have predictable data? Why would that
> matter, as long as it is read back the same?
I
On Mon, Jan 02, 2012 at 12:31:13PM +0100, Dimitri Fontaine wrote:
> Marko Kreen writes:
> > I tried to generalize a function that creates partitions
> > for a table and found out it's impossible to do it for grants.
> >
> > Basically, what I want is a child table that takes it's grants
> > from pa
Simon Riggs wrote:
> v2 of checksum patch, using a conditional copy if checksumming is
> enabled, so locking is removed.
>
> Thanks to Andres for thwacking me with the cluestick, though I
> have used a simple copy rather than a copy & calc.
>
> Tested using make installcheck with parameter on/
On Tue, Jan 3, 2012 at 4:17 PM, Tom Lane wrote:
>> For Itanium, I was able to find some fairly official-looking
>> documentation that said "this is how you should do it". It would be
>> nice to find something similar for PPC64, instead of testing every
>> machine and reinventing the wheel ourselv
On 01/03/2012 04:49 PM, Brad Davis wrote:
Hi,
I have a patch that improves the documentation for FreeBSD Kernel Tuning:
- Show a # prompt instead of $ to indicate a root shell is needed
- Remove the -w flag to sysctl since it is not needed anymore and just silently
ignored
- Encourage the us
Hi,
I have a patch that improves the documentation for FreeBSD Kernel Tuning:
- Show a # prompt instead of $ to indicate a root shell is needed
- Remove the -w flag to sysctl since it is not needed anymore and just silently
ignored
- Encourage the user to set the read-only sysctls in /boot/loade
Robert Haas writes:
> I'm unconvinced by these numbers. There is a measurable change but it
> is pretty small. The Itanium changes resulted in an enormous gain at
> higher concurrency levels.
Yeah, that was my problem with it also: I couldn't measure enough gain
to convince me it was a real eff
Excerpts from Simon Riggs's message of mar ene 03 17:57:56 -0300 2012:
>
> On Tue, Jan 3, 2012 at 6:14 PM, Alvaro Herrera
> wrote:
>
> > If there are many call sites, maybe it'd be a good idea to use a
> > semantic patcher tool such as Coccinelle instead of doing it one by one.
>
> Thanks for
On Tue, Jan 3, 2012 at 6:14 PM, Alvaro Herrera
wrote:
> If there are many call sites, maybe it'd be a good idea to use a
> semantic patcher tool such as Coccinelle instead of doing it one by one.
Thanks for the suggestion, regrettably I've already made those changes.
After examining the call si
On Tue, Jan 3, 2012 at 6:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 3, 2012 at 12:55 PM, Tom Lane wrote:
>>> Another point that requires some thought is that switching SnapshotNow
>>> to be MVCC-based will presumably result in a noticeable increase in each
>>> backend's rate of
On Wed, Jan 4, 2012 at 12:33 AM, Noah Misch wrote:
> On Wed, Jan 04, 2012 at 12:09:16AM +0400, Alexander Korotkov wrote:
> > Thanks for your great work on reviewing this patch. Now I'm trying to
> find
> > memory corruption bug. Unfortunately it doesn't appears on my system. Can
> > you check if
Robert Haas writes:
> On Tue, Jan 3, 2012 at 3:05 PM, Jeremy Harris wrote:
>> Also, heavy-contention locks should be placed in cache lines away from other
>> data (to avoid thrashing the data cache lines when processors are fighting
>> over the lock cache lines).
> Yep. This is possibly a probl
On Wed, Jan 04, 2012 at 12:09:16AM +0400, Alexander Korotkov wrote:
> Thanks for your great work on reviewing this patch. Now I'm trying to find
> memory corruption bug. Unfortunately it doesn't appears on my system. Can
> you check if this bug remains in attached version of patch. If so, please
>
On Tue, Jan 3, 2012 at 3:05 PM, Jeremy Harris wrote:
> On 2012-01-03 04:44, Robert Haas wrote:
>> On read-only workloads, you get spinlock contention, because everyone
>> who wants a snapshot has to take the LWLock mutex to increment the
>> shared lock count and again (just a moment later) to decr
Hi!
Thanks for your great work on reviewing this patch. Now I'm trying to find
memory corruption bug. Unfortunately it doesn't appears on my system. Can
you check if this bug remains in attached version of patch. If so, please
provide me information about system you're running (processor, OS etc.)
On 2012-01-03 04:44, Robert Haas wrote:
On read-only workloads, you get spinlock contention, because everyone
who wants a snapshot has to take the LWLock mutex to increment the
shared lock count and again (just a moment later) to decrement it.
Does the LWLock protect anything but the shared loc
Hello
2012/1/3 Robert Haas :
> On Tue, Jan 3, 2012 at 10:38 AM, Pavel Stehule
> wrote:
>> Hello
>>
>> 2012/1/3 Robert Haas :
>>> On Mon, Jan 2, 2012 at 12:01 PM, Pavel Stehule
>>> wrote:
here is updated patch
>>>
>>> I think the comments in parse_utilcmd.c probably need a bit of adjustmen
Robert Haas writes:
> On Tue, Jan 3, 2012 at 1:42 PM, Tom Lane wrote:
>> BTW, I wonder if this couldn't be ameliorated by establishing some
>> ground rules about how up-to-date a snapshot really needs to be.
>> Arguably, it should be okay for successive SnapshotNow scans to use the
>> same snapsh
On Tue, Jan 3, 2012 at 1:42 PM, Tom Lane wrote:
> I wrote:
>>> Another point that requires some thought is that switching SnapshotNow
>>> to be MVCC-based will presumably result in a noticeable increase in each
>>> backend's rate of wanting to acquire snapshots.
>
> BTW, I wonder if this couldn't
On 01/03/2012 01:55 PM, Tom Lane wrote:
Andrew Dunstan writes:
From time to time there are complaints because people mistakenly feed a
text format dump to pg_restore and get back a somewhat cryptic message
about the file not being a valid archive. It's been suggested that we
should have pg
On Tue, Jan 3, 2012 at 1:42 PM, Kevin Grittner
wrote:
> Robert Haas wrote:
>> Tom Lane wrote:
>>> Um ... you're supposing that only DDL uses SnapshotNow, which is
>>> wrong. I refer you to the parser, the planner, execution
>>> functions for arrays, records, enums, any sort of relcache
>>> relo
Andrew Dunstan writes:
> From time to time there are complaints because people mistakenly feed a
> text format dump to pg_restore and get back a somewhat cryptic message
> about the file not being a valid archive. It's been suggested that we
> should have pg_restore run the file through psql,
From time to time there are complaints because people mistakenly feed a
text format dump to pg_restore and get back a somewhat cryptic message
about the file not being a valid archive. It's been suggested that we
should have pg_restore run the file through psql, but that would involve
more work
I wrote:
>> Another point that requires some thought is that switching SnapshotNow
>> to be MVCC-based will presumably result in a noticeable increase in each
>> backend's rate of wanting to acquire snapshots.
BTW, I wonder if this couldn't be ameliorated by establishing some
ground rules about ho
Robert Haas wrote:
> Tom Lane wrote:
>> Um ... you're supposing that only DDL uses SnapshotNow, which is
>> wrong. I refer you to the parser, the planner, execution
>> functions for arrays, records, enums, any sort of relcache
>> reload, etc etc etc. Yes, some of that is masked by
>> backend-in
On Tue, Jan 3, 2012 at 1:24 PM, Tom Lane wrote:
> Um ... you're supposing that only DDL uses SnapshotNow, which is wrong.
> I refer you to the parser, the planner, execution functions for arrays,
> records, enums, any sort of relcache reload, etc etc etc. Yes, some
> of that is masked by backend-
Robert Haas writes:
> On Tue, Jan 3, 2012 at 12:55 PM, Tom Lane wrote:
>> Another point that requires some thought is that switching SnapshotNow
>> to be MVCC-based will presumably result in a noticeable increase in each
>> backend's rate of wanting to acquire snapshots. Hence, more contention
>
Excerpts from Robert Haas's message of mar ene 03 12:24:52 -0300 2012:
> I feel like the first thing we should be doing here is some
> benchmarking. If we change just the scans in dependency.c and then
> try the test case Tom suggested (dropping a schema containing a large
> number of functions)
On Tue, Jan 3, 2012 at 12:55 PM, Tom Lane wrote:
> Simon Riggs writes:
>> That was acceptable to *me*, so I didn't try measuring using just
>> SnapshotNow.
>
>> We can do a lot of tests but at the end its a human judgement. Is 100%
>> correct results from catalog accesses worth having when the r
On Fri, Sep 9, 2011 at 11:02 PM, Daniel Farina wrote:
> On Wed, Aug 24, 2011 at 1:04 PM, Daniel Farina wrote:
>> On Wed, Aug 24, 2011 at 12:38 PM, Tom Lane wrote:
>>> Assuming the issue really is the physical unlinks (which I agree I'd
>>> like to see some evidence for), I wonder whether the pro
Noah Misch writes:
> Regarding the other message, avoid composing a translated message from
> independently-translated parts.
Yes. I haven't looked at the patch, but I wonder whether it wouldn't be
better to dodge both of these problems by having the subroutine return a
success/failure result co
Simon Riggs writes:
> That was acceptable to *me*, so I didn't try measuring using just SnapshotNow.
> We can do a lot of tests but at the end its a human judgement. Is 100%
> correct results from catalog accesses worth having when the real world
> speed of it is not substantially very good? (Whe
On Sun, Jan 1, 2012 at 11:50 PM, Peter Eisentraut wrote:
> Currently, pg_dump sorts operators by name, but operators with the same
> name come out in random order. A few releases ago we adjusted this for
> functions, so that they are in increasing number of arguments order.
> I'd like to do this
On Tue, Jan 3, 2012 at 11:17 AM, Simon Riggs wrote:
> On Tue, Jan 3, 2012 at 3:24 PM, Robert Haas wrote:
>> I feel like the first thing we should be doing here is some
>> benchmarking. If we change just the scans in dependency.c and then
>> try the test case Tom suggested (dropping a schema cont
On Tue, Jan 3, 2012 at 10:56 AM, Simon Riggs wrote:
> On Tue, Jan 3, 2012 at 3:18 PM, Robert Haas wrote:
>>> The clock sweep is where all the time goes, in its current form.
>>
>> ...but I agree with this. In its current form, the clock sweep has to
>> acquire a spinlock for every buffer it touc
2011/12/23 Robert Haas :
> On Fri, Dec 23, 2011 at 5:56 AM, Kohei KaiGai wrote:
>> I'd like the regression test on select_view test being committed also
>> to detect unexpected changed in the future. How about it?
>
> Can you resend that as a separate patch? I remember there were some
> things I
On Tue, Dec 20, 2011 at 02:30:08PM +0100, Magnus Hagander wrote:
> That said - can someone who knows the translation stuff better than me
> comment on if this is actually going to be translatable, or if it
> violates too many translation rules?
> +pg_signal_backend(int pid, int sig, bool allow_sam
On Tue, Jan 3, 2012 at 3:24 PM, Robert Haas wrote:
> I feel like the first thing we should be doing here is some
> benchmarking. If we change just the scans in dependency.c and then
> try the test case Tom suggested (dropping a schema containing a large
> number of functions), we can compare the
On Tue, Jan 3, 2012 at 10:38 AM, Pavel Stehule wrote:
> Hello
>
> 2012/1/3 Robert Haas :
>> On Mon, Jan 2, 2012 at 12:01 PM, Pavel Stehule
>> wrote:
>>> here is updated patch
>>
>> I think the comments in parse_utilcmd.c probably need a bit of adjustment.
>
> I don't see it - there is only one c
On Tue, Jan 3, 2012 at 3:18 PM, Robert Haas wrote:
>> The clock sweep is where all the time goes, in its current form.
>
> ...but I agree with this. In its current form, the clock sweep has to
> acquire a spinlock for every buffer it touches. That's really
> expensive, and I think we need to ei
Hello
2012/1/3 Robert Haas :
> On Mon, Jan 2, 2012 at 12:01 PM, Pavel Stehule
> wrote:
>> here is updated patch
>
> I think the comments in parse_utilcmd.c probably need a bit of adjustment.
I don't see it - there is only one comment and it is adjusted with
"if" statement.
please, show it
Reg
On Sat, Dec 31, 2011 at 7:36 PM, Noah Misch wrote:
> Building on commit 8f9fe6edce358f7904e0db119416b4d1080a83aa, this adds
> protransform functions to the length coercions for numeric, varbit, timestamp,
> timestamptz, time, timetz and interval. This mostly serves to make more ALTER
> TABLE ALTE
On Mon, Jan 2, 2012 at 12:01 PM, Pavel Stehule wrote:
> here is updated patch
I think the comments in parse_utilcmd.c probably need a bit of adjustment.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hac
On Tue, Jan 3, 2012 at 5:47 AM, Simon Riggs wrote:
> On Tue, Jan 3, 2012 at 4:40 AM, Noah Misch wrote:
>> On Tue, Jan 03, 2012 at 01:18:41AM +, Simon Riggs wrote:
>>> Just for the record, yes we do run multiple catalog scans in some
>>> parts of the code.
>>>
>>> So I can see how we might tri
On Mon, Jan 2, 2012 at 2:53 PM, Simon Riggs wrote:
>> Get rid of the freelist? Once shared buffers are full, it's just about
>> useless anyway. But you'd need to think about the test cases that you
>> pay attention to, as there might be scenarios where it remains useful.
>
> Agree freelist is mo
2012/1/3 Christopher Browne :
> On Tue, Jan 3, 2012 at 5:55 AM, Samuel PHAN wrote:
>> I'm using PL/Python, and when getting the result object from a
>> plpy.execute(), I can access to the result.status().
>>
>> E.g.: the result.status() is 4. But to know what 4 corresponds to, I must
>> open the "
On Tue, Jan 3, 2012 at 5:55 AM, Samuel PHAN wrote:
> I'm using PL/Python, and when getting the result object from a
> plpy.execute(), I can access to the result.status().
>
> E.g.: the result.status() is 4. But to know what 4 corresponds to, I must
> open the "spi.h" file from the sources to see :
On 12/31/2011 06:10 PM, Brar Piening wrote:
Brar Piening wrote:
Andrew Dunstan wrote:
Can you narrow down exactly what in that commit broke VS 2010? Are
there any compiler warnings?
I was able to nail down the problem.
In the absence of reaction, to keep my promise, I'm sending the
attac
I'm using PL/Python, and when getting the result object from a
plpy.execute(), I can access to the result.status().
E.g.: the result.status() is 4. But to know what 4 corresponds to, I must
open the "spi.h" file from the sources to see :
#define SPI_OK_CONNECT 1
#define SPI_OK_FINISH 2
#define SP
Pavel Stehule wrote:
> here is new version of CHECK FUNCTION patch
I won't be able to review that one because I'll be in
California from Jan 6 to Jan 29.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.p
On Tue, Jan 3, 2012 at 4:40 AM, Noah Misch wrote:
> On Tue, Jan 03, 2012 at 01:18:41AM +, Simon Riggs wrote:
>> Just for the record, yes we do run multiple catalog scans in some
>> parts of the code.
>>
>> So I can see how we might trigger 4 nested scans, using cache
>> replacement while scann
88 matches
Mail list logo
