On Sat, Jan 28, 2012 at 05:30, Tom Lane wrote:
> Thom Brown writes:
>> I'm using latest git master (latest entry
>> 0816fad6eebddb8f1f0e21635e46625815d690b9) and I'm getting an error
>> when trying to create a large data set with pgbench:
>
>> LOG: could not stat file "base/pgsql_tmp/pgsql_tmp80
On Sat, Jan 28, 2012 at 09:57, Magnus Hagander wrote:
> On Sat, Jan 28, 2012 at 05:30, Tom Lane wrote:
>> Thom Brown writes:
>>> I'm using latest git master (latest entry
>>> 0816fad6eebddb8f1f0e21635e46625815d690b9) and I'm getting an error
>>> when trying to create a large data set with pgbenc
On 28 January 2012 09:04, Magnus Hagander wrote:
> On Sat, Jan 28, 2012 at 09:57, Magnus Hagander wrote:
>> On Sat, Jan 28, 2012 at 05:30, Tom Lane wrote:
>>> Thom Brown writes:
I'm using latest git master (latest entry
0816fad6eebddb8f1f0e21635e46625815d690b9) and I'm getting an erro
Ok, thanks.
Att,
Fred
2012/1/24 Robert Haas
> On Tue, Jan 24, 2012 at 11:25 AM, Tom Lane wrote:
> > Robert Haas writes:
> >> I doubt it. Almost nothing in the backend is thread-safe. You can't
> >> acquire a heavyweight lock, a lightweight lock, or a spinlock. You
> >> can't do anything th
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scales wrote:
> The advantage of putting the checksum calculation in smgrwrite() (or
> mdwrite()) is that it catches a bunch of page writes that don't go through
> the buffer pool (see calls to smgrwrite() in nbtree.c, nbtsort.c, spginsert.c)
I'll have anot
On Fri, Jan 27, 2012 at 10:05 PM, Jeff Janes wrote:
> On Sat, Jan 21, 2012 at 7:31 AM, Simon Riggs wrote:
>>
>> Yes, it was. Sorry about that. New version attached, retesting while
>> you read this.
>
> In my hands I could never get this patch to do anything. The new
> cache was never used.
>
>
On Thu, Jan 26, 2012 at 5:27 AM, Fujii Masao wrote:
> One thing I would like to ask is that why you think walreceiver is more
> appropriate for writing XLOG_END_OF_RECOVERY record than startup
> process. I was thinking the opposite, because if we do so, we might be
> able to skip the end-of-recov
On Fri, Jan 13, 2012 at 10:48:56AM +0100, Pierre C wrote:
> Maybe an extra column in pg_proc would do (but then, the proargtypes
> and friends would describe only the sql-callable version) ?
> Or an extra table ? pg_cproc ?
> Or an in-memory hash : hashtable[ fmgr-callable function ] => C version
>
On 01/27/2012 11:52 PM, Noah Misch wrote:
Is a platform-independent fsync be available at initdb time?
Not sure.
It's a macro on Windows that calls _commit(fd), so it should be portable
enough.
I'm curious what problem we're actually solving here, though. I've run
the buildfarm countles
On Sat, 2012-01-28 at 10:31 -0500, Andrew Dunstan wrote:
> I'm curious what problem we're actually solving here, though. I've run
> the buildfarm countless thousands of times on different VMs, and five of
> my seven current animals run in VMs, and I don't think I've ever seen a
> failure ascriba
Andrew Dunstan writes:
> I'm curious what problem we're actually solving here, though. I've run
> the buildfarm countless thousands of times on different VMs, and five of
> my seven current animals run in VMs, and I don't think I've ever seen a
> failure ascribable to inadequately synced files
On Sat, Jan 28, 2012 at 7:31 AM, Andrew Dunstan wrote:
>
>
> On 01/27/2012 11:52 PM, Noah Misch wrote:
>>>
>>> Is a platform-independent fsync be available at initdb time?
>>
>> Not sure.
>>
>
> It's a macro on Windows that calls _commit(fd), so it should be portable
> enough.
>
> I'm curious what
On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
> Andrew Dunstan writes:
> > I'm curious what problem we're actually solving here, though. I've run
> > the buildfarm countless thousands of times on different VMs, and five of
> > my seven current animals run in VMs, and I don't think I've ever
2012/1/26 Robert Haas :
> On Thu, Jan 26, 2012 at 7:27 AM, Kohei KaiGai wrote:
>> It seems to me reasonable design.
>> The attached patch is rebased one according to your perform-deletion patch.
>
> That looks pretty sensible. But I don't think this is true any more:
>
> + Please note that it
On Sat, Jan 28, 2012 at 10:18 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> I'm curious what problem we're actually solving here, though. I've run
>> the buildfarm countless thousands of times on different VMs, and five of
>> my seven current animals run in VMs, and I don't think I've ever seen
On 01/28/2012 01:46 PM, Jeff Davis wrote:
On Sat, 2012-01-28 at 13:18 -0500, Tom Lane wrote:
Andrew Dunstan writes:
I'm curious what problem we're actually solving here, though. I've run
the buildfarm countless thousands of times on different VMs, and five of
my seven current animals run in
I suggest you work on more general approach, see
http://www.sai.msu.su/~megera/wiki/2009-08-12 for example.
btw, I don't like you changed ts_rank_cd arguments.
Oleg
On Fri, 27 Jan 2012, karave...@mail.bg wrote:
Hello,
I have developed a variation of cover density ranking functions that count
create user foouser;
create tablespace temptblspc location '/tmp/tmptblspc';
alter user foouser set temp_tablespaces='temptblspc';
Run pg_dumpall. It will produce a dump like:
...
CREATE ROLE foouser;
ALTER ROLE foouser WITH NOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB
LOGIN NOREPLICATION;
ALTE
2012/1/26 Robert Haas :
> On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai wrote:
>> 2012/1/26 Robert Haas :
>>> I'm wondering if a function would be a better fit than a GUC. I don't
>>> think you can really restrict the ability to revert a GUC change -
>>> i.e. if someone does a SET and then a RESE
On Fri, Jan 27, 2012 at 1:45 PM, Jeff Janes wrote:
> On Thu, Jan 12, 2012 at 4:31 AM, Simon Riggs wrote:
>
>> The following patch adds a pgbench option -I to load data using
>> INSERTs, so that we can begin benchmark testing with rows that have
>> large numbers of distinct un-hinted transaction i
On 28.01.2012 15:49, Simon Riggs wrote:
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scales wrote:
Also, I missed this before: don't you want to add the checksum calculation
(PageSetVerificationInfo) to mdextend() (or preferably smgrextend()) as well?
Otherwise, you won't be checksumming a bunch o
On Jan 27, 2012, at 2:19 AM, Cédric Villemain wrote:
>> Also --exclude-extension?
>
> It might be the default.
> We need something to dump the content of
> pg_catalog.pg_extension_script (or whatever table is going to contain
> SQL code), per extension or all.
I think dim said --no-extensions wo
I thought it'd be a good idea to put in some basic test cases for the
EvalPlanQual code using the isolationtester infrastructure. While
fooling with it, I soon ran into this restriction:
if (p->nsteps != nallsteps)
{
fprintf(stderr, "invalid
Le 28 janvier 2012 21:46, David E. Wheeler a écrit :
> On Jan 27, 2012, at 2:19 AM, Cédric Villemain wrote:
>
>>> Also --exclude-extension?
>>
>> It might be the default.
>> We need something to dump the content of
>> pg_catalog.pg_extension_script (or whatever table is going to contain
>> SQL cod
On Thu, Jan 12, 2012 at 4:49 AM, Simon Riggs wrote:
> On Thu, Jan 5, 2012 at 6:26 PM, Simon Riggs wrote:
>
>> Patch to remove clog contention caused by dirty clog LRU.
>
> v2, minor changes, updated for recent commits
This no longer applies to file src/backend/postmaster/bgwriter.c, due
to the l
On Thu, Jan 26, 2012 at 08:23:34AM -0500, Robert Haas wrote:
> On Thu, Jan 26, 2012 at 6:55 AM, Noah Misch wrote:
> > On Wed, Jan 25, 2012 at 11:53:10PM -0500, Tom Lane wrote:
> >> Not only is that code spectacularly unreadable, but has nobody noticed
> >> that this commit broke the buildfarm?
> >
Excerpts from Tom Lane's message of sáb ene 28 18:08:36 -0300 2012:
> I thought it'd be a good idea to put in some basic test cases for the
> EvalPlanQual code using the isolationtester infrastructure. While
> fooling with it, I soon ran into this restriction:
>
> if (p->nsteps != nallst
When you try to use the NEW variable in a statement-level trigger, you get
ERROR: record "new" is not assigned yet
DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
which is not too friendly, given that people sometimes forget to specify
FOR EACH at all, get the defaul
Noah Misch writes:
> On Thu, Jan 26, 2012 at 08:23:34AM -0500, Robert Haas wrote:
>> I'm just going to remove the test. This is not very future-proof and
> [ objections ]
FWIW, I concur with Robert's choice here. This test method is ugly and
fragile, and I'm not even thinking about the questio
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> When you try to use the NEW variable in a statement-level trigger, you get
> ERROR: record "new" is not assigned yet
> DETAIL: The tuple structure of a not-yet-assigned record is indeterminate.
> I'm not that familiar with PL/pgSQL code, so I'm not sur
On Fri, Jan 27, 2012 at 5:35 AM, Heikki Linnakangas
wrote:
> On 26.01.2012 04:10, Robert Haas wrote:
>
>>
>> I think you should break this off into a new function,
>> LWLockWaitUntilFree(), rather than treating it as a new LWLockMode.
>> Also, instead of adding lwWaitOnly, I would suggest that we
Heikki Linnakangas writes:
> Barring objections, I'll write a patch to relax the checking on
> default_text_search_config and temp_tablespaces to match search_path.
This seems like something that's going to come back again and again.
What do you think of changing things so that ALTER ROLE/DATABA
- Цитат от Oleg Bartunov (o...@sai.msu.su), на 28.01.2012 в 21:04 -
> I suggest you work on more general approach, see
> http://www.sai.msu.su/~megera/wiki/2009-08-12 for example.
>
> btw, I don't like you changed ts_rank_cd arguments.
Hello Oleg,
Thanks for the feedback.
Is it O
Given a freshly created table (not vacuumed), and a query that uses an
index-only scan, for example:
CREATE TABLE foo(a int PRIMARY KEY);
INSERT INTO foo SELECT * FROM generate_series(1,100);
ANALYSE foo;
EXPLAIN ANALYSE SELECT count(*) FROM foo WHERE a <= 1;
34 matches
Mail list logo
