On 2010-08-31 12:07 AM +0300, I wrote:
I looked at fixing this..
The previous patch had a bug in fmgr_sql() our regression tests didn't
catch. Fixed version attached.
Regards,
Marko Tiikkaja
*** a/src/backend/catalog/pg_proc.c
--- b/src/backend/catalog/pg_proc.c
***
*** 832,838
Hi,
I looked at fixing this inconsistency by making all query list snapshot
handling work like EXPLAIN ANALYZE's code does. The only reason I went
this way was that implementing wCTEs on top of this behaviour is a lot
easier.
There were three places that needed fixing. The SPI and portal l
2010/8/30 Pei He :
> Hi,
> I am hacking postgresql 8.2.5. a) and b) do not work for me.
>
> The situation is that I made a join operator, and a scan operator.
> And, The join operator requires the scan operator as the inner. So, I
> need to have the full control of the join plan.
>
> I am not ready
Hi,
I am hacking postgresql 8.2.5. a) and b) do not work for me.
The situation is that I made a join operator, and a scan operator.
And, The join operator requires the scan operator as the inner. So, I
need to have the full control of the join plan.
I am not ready to provide the optimization supp
I forgot to mention that I am using postgresql 8.2.5.
Thanks
--
Pei
On Mon, Aug 30, 2010 at 1:34 PM, Pei He wrote:
> Hi,
> I have developed a new operators, and I want to do some tests on it.
> I do not want the optimizer to choose the plan for me, and I need to
> construct a plan as exact as I
2010/8/30 Tom Lane :
> Pavel Stehule writes:
>> I found a PostgreSQL 8.3 server (Linux) used for large OLAP where the
>> data directory is bloating. There are more than one hundred thousand
>> files - 8KB or 0KB long. The filenames are not transformable to names
>> via oid2name. Does somebody know
Hi,
I have developed a new operators, and I want to do some tests on it.
I do not want the optimizer to choose the plan for me, and I need to
construct a plan as exact as I want.
Can anyone provide me a way to achieve that?
Thanks
--
Pei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
Pavel Stehule writes:
> I found a PostgreSQL 8.3 server (Linux) used for large OLAP where the
> data directory is bloating. There are more than one hundred thousand
> files - 8KB or 0KB long. The filenames are not transformable to names
> via oid2name. Does somebody know about similar bug?
1. 8.3
I wrote:
> I guess that something isn't properly setting up rnode.backend in
> recovery processing, but didn't find it yet.
CreateFakeRelcacheEntry is the culprit ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
"Kevin Grittner" writes:
> LOG: database system was interrupted; last known up at 2010-08-30
> 09:13:23 CDT
> LOG: database system was not properly shut down; automatic recovery in
> progress
> LOG: consistent recovery state reached at 0/5C5D04
> LOG: redo starts at 0/5C5D04
> TRAP: FailedAsse
Hello
I found a PostgreSQL 8.3 server (Linux) used for large OLAP where the
data directory is bloating. There are more than one hundred thousand
files - 8KB or 0KB long. The filenames are not transformable to names
via oid2name. Does somebody know about similar bug?
Regards
Pavel Stehule
--
Se
2010/8/30 Alvaro Herrera :
> Excerpts from Pavel Stehule's message of lun ago 30 07:51:55 -0400 2010:
>> 2010/8/30 Itagaki Takahiro :
>> > On Mon, Aug 30, 2010 at 7:58 PM, Pavel Stehule
>> > wrote:
>> >> propsals:
>> >> * "format" function - uses same formatting as PL/pgSQL RAISE statement
>> >>
Hi,
On 08/30/2010 04:52 PM, Tom Lane wrote:
Let me just point out that awhile back we got a *measurable* performance
boost by eliminating a single indirect fetch from the buffer addressing
code path.
I'll take a look a that, thanks.
So I don't have any faith in untested assertions
Neither
Joe Conway writes:
> I'm seeing it on a checkout from CVS head. Basically do
Oh, OK, I misread Kevin to say this would happen during make
installcheck itself. So the lack of buildfarm reports is not relevant.
Will get some caffeine in me and then take a look.
regards, t
On 08/30/2010 08:16 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Checking out HEAD from the git repository I see an assertion
>> failure.
>
> The buildfarm isn't reporting any such thing. Could you get a CVS
> checkout and diff it against the git results?
I'm seeing it on a checkout from C
Excerpts from Pavel Stehule's message of lun ago 30 07:51:55 -0400 2010:
> 2010/8/30 Itagaki Takahiro :
> > On Mon, Aug 30, 2010 at 7:58 PM, Pavel Stehule
> > wrote:
> >> propsals:
> >> * "format" function - uses same formatting as PL/pgSQL RAISE statement
> >> * "sprintf" function
> >>
> >> Now
Tom Lane wrote:
> Could you get a CVS checkout and diff it against the git results?
Will do.
-Kevin
--
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" writes:
> Checking out HEAD from the git repository I see an assertion
> failure.
The buildfarm isn't reporting any such thing. Could you get a CVS
checkout and diff it against the git results?
regards, tom lane
--
Sent via pgsql-hackers mailing list (
Markus Wanner writes:
> AFAICT we currently have three fixed size blocks to manage shared
> buffers: the buffer blocks themselves, the buffer descriptors, the
> strategy status (for the freelist) and the buffer lookup table.
> It's not obvious to me how these data structures should perform bett
Checking out HEAD from the git repository I see an assertion
failure. Steps to reproduce:
make distclean
./configure --prefix=/usr/local/pgsql-serializable \
--enable-debug --enable-depend --enable-cassert
make check
sudo make install
cd contrib/
make
sudo make install
cd ../
rm -fr /var/pgsql
On Mon, 2010-08-30 at 13:34 +0100, Greg Stark wrote:
> On Mon, Aug 30, 2010 at 10:18 AM, Simon Riggs wrote:
> > cost_hashjoin() has some treatment of what occurs when numbatches > 1
> > but that additional cost is not proportional to numbatches.
>
> Because that's not how our hash batching works.
On Mon, Aug 30, 2010 at 10:18 AM, Simon Riggs wrote:
> cost_hashjoin() has some treatment of what occurs when numbatches > 1
> but that additional cost is not proportional to numbatches.
Because that's not how our hash batching works. We generate two temp
files for each batch, one for the outer a
On Mon, Aug 30, 2010 at 6:18 PM, Simon Riggs wrote:
> On Mon, 2010-08-30 at 09:59 +0300, Heikki Linnakangas wrote:
>
>> However, is it safe to use GetOldestXMin() during recovery? Or to put it
>> other way, is GetOldestXMin() functioning correctly during hot standby?
>> It only scans through the P
On Tue, Aug 10, 2010 at 5:58 AM, Heikki Linnakangas
wrote:
> On 05/08/10 17:14, Fujii Masao wrote:
>>
>> I'm thinking to make users register and unregister each standbys via SQL
>> functions like register_standby() and unregister_standby():
>
> The register/unregister facility should be accessible
2010/8/30 Itagaki Takahiro :
> On Mon, Aug 30, 2010 at 7:58 PM, Pavel Stehule
> wrote:
>> propsals:
>> * "format" function - uses same formatting as PL/pgSQL RAISE statement
>> * "sprintf" function
>>
>> Now I propose a compromise - "format" function with only three tags:
>> %s .. some string
>>
On Mon, Aug 30, 2010 at 7:58 PM, Pavel Stehule wrote:
> propsals:
> * "format" function - uses same formatting as PL/pgSQL RAISE statement
> * "sprintf" function
>
> Now I propose a compromise - "format" function with only three tags:
> %s .. some string
> %i .. SQL identifier
> %l .. string lit
Hello
I am returning back to string functions. For me, the most important
function isn't commited still. There was discussion about "format" or
"sprintf" fuction. So I'll do a small resume.
goal: to get function that helps with formatting a message texts and
helps with building a SQL commands (us
cost_hashjoin() has some treatment of what occurs when numbatches > 1
but that additional cost is not proportional to numbatches.
The associated comment talks about "an extra time", making it sound like
we think numbatches would only ever be 2 (or 1).
Can someone explain the current code, or is
On Sun, 2010-05-23 at 16:21 -0400, Jan Wieck wrote:
> In some systems (data warehousing, replication), the order of commits is
> important, since that is the order in which changes have become visible.
> This information could theoretically be extracted from the WAL, but
> scanning the entire WAL
On Mon, 2010-08-30 at 09:59 +0300, Heikki Linnakangas wrote:
> However, is it safe to use GetOldestXMin() during recovery? Or to put it
> other way, is GetOldestXMin() functioning correctly during hot standby?
> It only scans through the ProcArray, but not the known-assigned xids
> array. That
(Sorry, need to disable Ctrl-Return, which quite often sends mails
earlier than I really want.. continuing my mail)
On 08/27/2010 10:46 PM, Robert Haas wrote:
Yeah, probably. I think designing something that works efficiently
over a network is a somewhat different problem than designing
someth
Hi,
On 08/27/2010 10:46 PM, Robert Haas wrote:
What other subsystems are you imagining servicing with a dynamic
allocator? If there were a big demand for this functionality, we
probably would have been forced to implement it already, but that's
not the case. We've already discussed the fact th
On sön, 2010-08-29 at 23:14 -0400, Tom Lane wrote:
> > And what about 9.1alpha1?
>
> Peter muttered something about doing that this week.
The major blocker is preparing the release notes. If someone has time
for that ...
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
On Mon, 2010-08-30 at 09:59 +0300, Heikki Linnakangas wrote:
> On 27/08/10 20:17, Fujii Masao wrote:
> > Yes. StartupXLOG calls that before bgwriter is invoked. That is, we can
> > ensure that StartupSUBTRANS has always been done before bgwriter
> > performs a restartpoint.
>
> Hmm, the comment in
On 27/08/10 20:17, Fujii Masao wrote:
Yes. StartupXLOG calls that before bgwriter is invoked. That is, we can
ensure that StartupSUBTRANS has always been done before bgwriter
performs a restartpoint.
Hmm, the comment in CreateCheckpoint() isn't totally accurate either:
* Truncate pg_subtrans
35 matches
Mail list logo