On 17.08.2011 00:17, Tom Lane wrote:
I'm looking into the idea I mentioned earlier:
All is not entirely lost, however: there's still some possible
performance benefit to be gained here, if we go to the scheme of
identifying victim catcache entries by hashvalue only. Currently,
each
On tis, 2011-08-16 at 20:35 -0400, Tom Lane wrote:
In fact, now that I think about it, setting the transaction snapshot
from a utility statement would be functionally useful because then you
could take locks beforehand.
Another issue is that in some client interfaces, BEGIN and COMMIT are
On Tue, Aug 16, 2011 at 11:15 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
On 16.08.2011 22:10, Heikki Linnakangas wrote:
Here's an version of the patch with a bunch of minor changes:
And here it really is, this time with an attachment...
Thanks a lot. I'm going to
On Tue, Aug 16, 2011 at 10:17 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Any objections to that plan?
None at all, but some questions.
This overhaul of the cache mechanism has been extensive, so you're now
very well placed to answer related questions.
As you know, I've been trying to reduce the
Thanks for your reply.,
@ Robert.,
What issue we may face if you take a backups(includes data dir + wal files)
at standby without LVM snapshot?
-Senthil
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Backup-s-from-standby-tp4688344p4706899.html
Sent from the
On Wed, Aug 17, 2011 at 5:49 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Hmm, this behaves slightly differently, if you first try to start the
restored server without recovery.conf, stop recovery, and restart it after
adding recovery.conf. But I guess that's not a big
On 17.08.2011 12:26, Fujii Masao wrote:
So, in master, we should change pg_controldata.c and pg_resetxlog.c for
new pg_control field backupEndRequired?
Ah, good catch! Fixed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list
hello …
i have just fallen over a nasty problem (maybe missing feature) with PL/Pythonu
…
consider:
-- add a document to the corpus
CREATE OR REPLACE FUNCTION textprocess.add_to_corpus(lang text, t text) RETURNS
float4 AS $$
from SecondCorpus import SecondCorpus
from
On 17/08/11 14:09, PostgreSQL - Hans-Jürgen Schönig wrote:
CREATE OR REPLACE FUNCTION textprocess.add_to_corpus(lang text, t text)
RETURNS float4 AS $$
from SecondCorpus import SecondCorpus
from SecondDocument import SecondDocument
i am doing some intense text mining
On 17/08/11 14:19, Jan Urbański wrote:
On 17/08/11 14:09, PostgreSQL - Hans-Jürgen Schönig wrote:
CREATE OR REPLACE FUNCTION textprocess.add_to_corpus(lang text, t text)
RETURNS float4 AS $$
from SecondCorpus import SecondCorpus
from SecondDocument import SecondDocument
i
On Wed, Aug 17, 2011 at 1:39 AM, senthilnathan
senthilnatha...@gmail.com wrote:
Thanks for your reply.,
@ Robert.,
What issue we may face if you take a backups(includes data dir + wal files)
at standby without LVM snapshot?
The backup might be corrupted in arbitrary ways.
--
Robert Haas
On Wed, Aug 17, 2011 at 6:19 AM, Fujii Masao masao.fu...@gmail.com wrote:
2011/8/17 Jun Ishiduka ishizuka@po.ntts.co.jp:
I see in xlog.h XLR_BKP_REMOVABLE, the comment above it says that this
flag is used to indicate that the archiver can compress the full page
blocks to non-full page
On Aug 17, 2011, at 2:19 PM, Jan Urbański wrote:
On 17/08/11 14:09, PostgreSQL - Hans-Jürgen Schönig wrote:
CREATE OR REPLACE FUNCTION textprocess.add_to_corpus(lang text, t text)
RETURNS float4 AS $$
from SecondCorpus import SecondCorpus
from SecondDocument import
The current plan (or, the last one I recall) is to push another 9.1
release tomorrow, for Monday release. Are we going with beta4 or rc1?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
On Wed, 2011-08-17 at 14:00 +0100, Dave Page wrote:
Are we going with beta4 or rc1?
RC1:
http://archives.postgresql.org/message-id/19869.1312298...@sss.pgh.pa.us
Regards,
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant,
2011/8/17 Devrim GÜNDÜZ dev...@gunduz.org:
On Wed, 2011-08-17 at 14:00 +0100, Dave Page wrote:
Are we going with beta4 or rc1?
RC1:
http://archives.postgresql.org/message-id/19869.1312298...@sss.pgh.pa.us
In Tom's final email to the -core thread he mentions I see now that he
did say RC1. I
On Wed, Aug 17, 2011 at 9:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 17, 2011 at 6:19 AM, Fujii Masao masao.fu...@gmail.com wrote:
The straightforward approach to address the problem you raised is to log
the change of full_page_writes on the master. Since such a WAL record is
Dave Page dp...@pgadmin.org writes:
Are we going with beta4 or rc1?
In Tom's final email to the -core thread he mentions I see now that he
did say RC1. I thought we were voting on the date though (not that I
have a problem with it being RC1).
Well, if this one's not ready to be an RC then I
On 17/08/11 11:40, Jan Urbański wrote:
On 16/08/11 19:12, Jan Urbański wrote:
On 16/08/11 19:07, Jean-Baptiste Quenot wrote:
[plpython is buggy]
I'll have a patch ready soon.
Here are two patches that fix two separate bugs that you found
simultaneously. Because they're actually separate
Hello, Dave.
You wrote:
DP The current plan (or, the last one I recall) is to push another 9.1
DP release tomorrow, for Monday release. Are we going with beta4 or rc1?
+1 for RC1
DP --
DP Dave Page
DP Blog: http://pgsnake.blogspot.com
DP Twitter: @pgsnake
DP EnterpriseDB UK:
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
A callback might be using the tuple ID in a way that fails if VACUUM
FULL moves the tuple, so I think we *have* to change it. (as you did
already)
Yeah, I thought about that too. As things stand in 9.0 and 9.1, there's
at least
On Wed, Aug 17, 2011 at 9:53 AM, Fujii Masao masao.fu...@gmail.com wrote:
On Wed, Aug 17, 2011 at 9:40 PM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Aug 17, 2011 at 6:19 AM, Fujii Masao masao.fu...@gmail.com wrote:
The straightforward approach to address the problem you raised is to log
On 17/08/11 15:00, Dave Page wrote:
The current plan (or, the last one I recall) is to push another 9.1
release tomorrow, for Monday release. Are we going with beta4 or rc1?
Sorry to butt in, but it would probably be good to include fixes for the
two segfault plpython bugs[1] before wrapping up
On 17 August 2011 16:47, Jan Urbański wulc...@wulczer.org wrote:
On 17/08/11 15:00, Dave Page wrote:
The current plan (or, the last one I recall) is to push another 9.1
release tomorrow, for Monday release. Are we going with beta4 or rc1?
Sorry to butt in, but it would probably be good to
On Wed, Aug 17, 2011 at 4:47 PM, Jan Urbański wulc...@wulczer.org wrote:
On 17/08/11 15:00, Dave Page wrote:
The current plan (or, the last one I recall) is to push another 9.1
release tomorrow, for Monday release. Are we going with beta4 or rc1?
Sorry to butt in, but it would probably be
On 17/08/11 17:50, Thom Brown wrote:
On 17 August 2011 16:47, Jan Urbański wulc...@wulczer.org wrote:
On 17/08/11 15:00, Dave Page wrote:
The current plan (or, the last one I recall) is to push another 9.1
release tomorrow, for Monday release. Are we going with beta4 or rc1?
Sorry to butt
On 08/12/2011 09:17 PM, Alex Hunsaker wrote:
[empty arrays returned are not handled correctly]
Anyway, the attached patch fixes it for me. That is when we don't have
an array state, just return an empty array. (Also adds some
additional comments)
Applied, thanks.
cheers
andrew
--
On 17 August 2011 16:56, Jan Urbański wulc...@wulczer.org wrote:
On 17/08/11 17:50, Thom Brown wrote:
On 17 August 2011 16:47, Jan Urbański wulc...@wulczer.org wrote:
On 17/08/11 15:00, Dave Page wrote:
The current plan (or, the last one I recall) is to push another 9.1
release
On Wed, Aug 17, 2011 at 05:12:49PM +0100, Thom Brown wrote:
On 17 August 2011 17:02, David Fetter da...@fetter.org wrote:
On Wed, Aug 17, 2011 at 04:40:26PM +0100, Thom Brown wrote:
On 17 August 2011 06:13, David Fetter da...@fetter.org wrote:
On Tue, Aug 16, 2011 at 10:17:21PM
On Wed, Aug 17, 2011 at 5:16 PM, Thom Brown t...@linux.com wrote:
On 17 August 2011 16:56, Jan Urbański wulc...@wulczer.org wrote:
On 17/08/11 17:50, Thom Brown wrote:
On 17 August 2011 16:47, Jan Urbański wulc...@wulczer.org wrote:
On 17/08/11 15:00, Dave Page wrote:
The current plan
Thom Brown t...@linux.com writes:
On 17 August 2011 16:56, Jan UrbaÅski wulc...@wulczer.org wrote:
On 17/08/11 17:50, Thom Brown wrote:
It's not listed as a beta-blocker yet. I take it that it should?
Oh, in the wiki? I don't know, it is a segfault-causing bug, but all I
wanted was to draw
On ons, 2011-08-17 at 18:28 +0530, Ashesh Vashi wrote:
I am trying to build PostgreSQL 9.1beta3 using the ActiveState Python 3.2.
It did not compile successfully.
Note that building against Python 3.2 works at least on Debian, so this
is not a universal problem. It appears to have to do with
BTW, while we're thinking about this ...
The plpython patch Jan just submitted reminds me that several of the PLs
detect whether they have obsolete cached data by noting whether the
tuple's xmin *and* TID are the same as previously seen.
Unlike depending on TID alone, I think this is probably
Peter Eisentraut pete...@gmx.net writes:
On ons, 2011-08-17 at 18:28 +0530, Ashesh Vashi wrote:
When I tried to figure out the exact reason for the failure, I found that:
1. 'python_configdir' variable is hardcoded, instead it should use the
configuration 'LIBPL'.
That looks reasonable. My
On Wed, Aug 17, 2011 at 1:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
BTW, while we're thinking about this ...
The plpython patch Jan just submitted reminds me that several of the PLs
detect whether they have obsolete cached data by noting whether the
tuple's xmin *and* TID are the same as
On 08/17/2011 09:42 AM, Tom Lane wrote:
I think you're imagining a lot more structure than actually exists in
this project ;-). Anybody can edit that page, and there's no necessary
consequence of something being written there. It's just notes to help
us keep track of issues, not something
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
On 16/08/11 19:07, Jean-Baptiste Quenot wrote:
[plpython is buggy]
Here are two patches that fix two separate bugs that you found
simultaneously. Because they're actually separate issues, it turned out
fixing them was a bit more
On tis, 2011-08-16 at 16:17 +0200, Magnus Hagander wrote:
Well, I got this on a win64 build. It's *supposed* to have ipv6. I
wonder if it breaks on windows just because there is no ipv6 address
on the machine...
It would mean that getaddrinfo() of ::1 failed. That seems weird.
A
On Aug 17, 2011, at 9:06 AM, Andrew Dunstan wrote:
[empty arrays returned are not handled correctly]
Anyway, the attached patch fixes it for me. That is when we don't have
an array state, just return an empty array. (Also adds some
additional comments)
Applied, thanks.
Awesome, thanks!
Excerpts from David Fetter's message of mié ago 17 12:31:14 -0400 2011:
By the way, the wiki is now tracking bugs. We have a bug tracker, and
it's that.
Yeah, but only during each release's last mile. Also consider that
any bug found to exist on older releases is not normally added to the
On ons, 2011-08-17 at 13:12 -0400, charles.mcdev...@emc.com wrote:
On tis, 2011-08-16 at 16:17 +0200, Magnus Hagander wrote:
Well, I got this on a win64 build. It's *supposed* to have ipv6. I
wonder if it breaks on windows just because there is no ipv6 address
on the machine...
It
On ons, 2011-08-17 at 13:20 -0400, Tom Lane wrote:
FWIW, all three python installations I have handy (2.7 on Fedora 14, 2.7
on OS X Lion, 2.5 on HPUX) produce the same result from either of
python -c from distutils.sysconfig import get_python_lib as f; import os;
Peter Eisentraut pete...@gmx.net writes:
On ons, 2011-08-17 at 13:20 -0400, Tom Lane wrote:
It's not immediately apparent to me why we should think that
get_python_lib is less trustworthy than LIBPL; but if someone
can make that case, I don't have any objection to this part of
the patch.
Robert Haas robertmh...@gmail.com writes:
On Wed, Aug 17, 2011 at 1:10 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The plpython patch Jan just submitted reminds me that several of the PLs
detect whether they have obsolete cached data by noting whether the
tuple's xmin *and* TID are the same as
Dave Byrne dby...@mdb.com writes:
I can confirm that the bug in pg_upgrade has been fixed with Bruce's patch
in commit 2411fbdac448045a23eebf4f0dbfd5790ebad720
Thanks, I marked it resolved on the wiki page.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Wed, Aug 17, 2011 at 10:06, Andrew Dunstan and...@dunslane.net wrote:
On 08/12/2011 09:17 PM, Alex Hunsaker wrote:
[empty arrays returned are not handled correctly]
Anyway, the attached patch fixes it for me. That is when we don't have
an array state, just return an empty array. (Also
Hello
I tried reporting the following bug via web form, it somerhow got lost
(it is not in pgsql-bugs archives, it was #6157 I believe). Anyway,
here it is:
psql -c 'release q; prepare q(int) as select 1'
FATAL: ReleaseSavepoint: unexpected state STARTED
server closed the connection
Attached is a patch that tracks and displays the accumulated cost when
autovacuum is running. Code by Noah Misch and myself. I hope this idea
will bring a formal process to vacuum tuning, which is currently too
hard to do. I was about to add without... to that, but I then
realized it needs
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org writes:
Here are two patches that fix two separate bugs that you found
simultaneously. Because they're actually separate issues, it turned out
fixing them was a bit more tricky than I expected (fixing one was
unmasking the other one etc).
=?UTF-8?B?TWFyY2luIE1hxYRr?= marcin.m...@gmail.com writes:
psql -c 'release q; prepare q(int) as select 1'
FATAL: ReleaseSavepoint: unexpected state STARTED
Can't get terribly excited about that, seeing that the statement is
surely going to draw an error and abort processing the rest of the
On Wed, Aug 17, 2011 at 5:33 PM, Dave Page dp...@pgadmin.org wrote:
That doesn't mean other things can't or shouldn't be fixed - just that
they won't necessarily cause adjustment of the schedule to accomodate
them.
+1
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL
Em 17-08-2011 18:04, Greg Smith escreveu:
Attached is a patch that tracks and displays the accumulated cost when
autovacuum is running. Code by Noah Misch and myself. I hope this idea
will bring a formal process to vacuum tuning, which is currently too
hard to do. I was about to add without...
On 08/17/2011 07:42 PM, Euler Taveira de Oliveira wrote:
I don't like exposing this information only on title processes. It
would be difficult for client apps (for example, PGAdmin) to track
this kind of information and it is restricted to local access. I'm not
objecting to display this
On Thu, Aug 18, 2011 at 12:09 AM, Robert Haas robertmh...@gmail.com wrote:
Ugh, you're right. But then you might have problems if the state
changes again before all backends have picked up the previous change.
Right.
What I've thought about before is making one backend (say, bgwriter)
store
2011/8/5 Jun Ishiduka ishizuka@po.ntts.co.jp:
* Procedure
1. Call pg_start_backup('x') on the standby.
2. Take a backup of the data dir.
3. Call pg_stop_backup() on the standby.
4. Copy the control file on the standby to the backup.
5. Check whether the control file is status during hot
On Tue, Aug 16, 2011 at 7:25 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jeevan Chalke jeevan.cha...@enterprisedb.com writes:
1. I have two functions func1 and func2.
2. func1 calls func2
3. Both has cursor with same name, say mycursor
4. Somehow I forgot closing it
5. executing func1
* Procedure
1. Call pg_start_backup('x') on the standby.
2. Take a backup of the data dir.
3. Call pg_stop_backup() on the standby.
4. Copy the control file on the standby to the backup.
5. Check whether the control file is status during hot standby with
pg_controldata.
? - If
57 matches
Mail list logo
