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
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 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
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
(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
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
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
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
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
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
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 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
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 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, 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.
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
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
"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 (
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
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
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
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
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
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
>> >>
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
"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
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
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
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
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
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
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
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 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
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
35 matches
Mail list logo
