On Thu, Aug 18, 2011 at 03:23, Greg Smith wrote:
> 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 restricte
> > * 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_control
On Tue, Aug 16, 2011 at 7:25 PM, Tom Lane wrote:
> Jeevan Chalke 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 throws an error 'cursor "mycursor" already
2011/8/5 Jun Ishiduka :
> * 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_
On Thu, Aug 18, 2011 at 12:09 AM, Robert Haas 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 its latest value
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 informa
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 Wed, Aug 17, 2011 at 5:33 PM, Dave Page 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 Development, 2
=?UTF-8?B?TWFyY2luIE1hxYRr?= 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
command string in any
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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).
Applied with one
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
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 unexpectedl
On Wed, Aug 17, 2011 at 10:06, Andrew Dunstan 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 adds so
Dave Byrne 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 (pgsql-hackers@po
Robert Haas writes:
> On Wed, Aug 17, 2011 at 1:10 PM, Tom Lane 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 previously seen.
>> Can anyone think
Peter Eisentraut 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.
> The issu
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;
> print(os.path.join(f(p
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..
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
l
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
> 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.
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= 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 tricky than I
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 grav
On Wed, Aug 17, 2011 at 1:10 PM, Tom Lane 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 previously seen.
>
Peter Eisentraut 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 Debian i
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 saf
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
Thom Brown writes:
> On 17 August 2011 16:56, Jan UrbaÅski 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 some attention in case
On Wed, Aug 17, 2011 at 5:16 PM, Thom Brown wrote:
> On 17 August 2011 16:56, Jan Urbański wrote:
>>
>> On 17/08/11 17:50, Thom Brown wrote:
>> > On 17 August 2011 16:47, Jan Urbański wrote:
>> >
>> >> On 17/08/11 15:00, Dave Page wrote:
>> >>> The current plan (or, the last one I recall) is to
On Wed, Aug 17, 2011 at 05:12:49PM +0100, Thom Brown wrote:
> On 17 August 2011 17:02, David Fetter wrote:
>
> > On Wed, Aug 17, 2011 at 04:40:26PM +0100, Thom Brown wrote:
> > > On 17 August 2011 06:13, David Fetter wrote:
> > >
> > > > On Tue, Aug 16, 2011 at 10:17:21PM -0400, Bruce Momjian wr
On 17 August 2011 16:56, Jan Urbański wrote:
> On 17/08/11 17:50, Thom Brown wrote:
> > On 17 August 2011 16:47, Jan Urbański 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.
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
--
Sent
On 17/08/11 17:50, Thom Brown wrote:
> On 17 August 2011 16:47, Jan Urbański 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, bu
On Wed, Aug 17, 2011 at 4:47 PM, Jan Urbański 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 include
On 17 August 2011 16:47, Jan Urbański 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 include fixes
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 u
On Wed, Aug 17, 2011 at 9:53 AM, Fujii Masao wrote:
> On Wed, Aug 17, 2011 at 9:40 PM, Robert Haas wrote:
>> On Wed, Aug 17, 2011 at 6:19 AM, Fujii Masao wrote:
>>> The straightforward approach to address the problem you raised is to log
>>> the change of full_page_writes on the master. Since su
Heikki Linnakangas 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 a theoretical possibility of this
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: http://www
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 sep
Dave Page 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 think we can
On Wed, Aug 17, 2011 at 9:40 PM, Robert Haas wrote:
> On Wed, Aug 17, 2011 at 6:19 AM, Fujii Masao 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 also
>> replicated to the standby, the
2011/8/17 Devrim GÜNDÜZ :
> 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 thought we
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, R
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
Hi,
I am trying to build PostgreSQL 9.1beta3 using the ActiveState Python 3.2.
It did not compile successfully.
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'.
2. 'plpython' is
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
On Wed, Aug 17, 2011 at 6:19 AM, Fujii Masao wrote:
> 2011/8/17 Jun Ishiduka :
>>> 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 blocks. I am not familiar with where in th
On Wed, Aug 17, 2011 at 1:39 AM, senthilnathan
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
EnterpriseDB: http://
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 SecondDoc
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 minin
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 SecondDocu
2011/8/17 Jun Ishiduka :
>> 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 blocks. I am not familiar with where in the code
>> this actually happens but will this cause issues
On 16/08/11 19:12, Jan Urbański wrote:
> On 16/08/11 19:07, Jean-Baptiste Quenot wrote:
>> Dear Jan,
>>
>> Sorry I typed the wrong git commands. With latest plpython from
>> branch master I got the same gdb backtrace as reported before. I
>> managed to wrap up a testcase that fails 100% of times
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 (pgsql-h
On Wed, Aug 17, 2011 at 5:49 PM, Heikki Linnakangas
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 deal, the check is simply
> skipped i
On Wed, Aug 17, 2011 at 04:44, Fujii Masao wrote:
> On Wed, Aug 17, 2011 at 12:00 AM, Magnus Hagander wrote:
>> Adjust total size in pg_basebackup progress report when reality changes
>>
>> When streaming including WAL, the size estimate will always be incorrect,
>> since we don't know how much W
> Is there any way to tell from the WAL segments if they contain the full
> page data? If so could you verify this on the second slave when it is
> brought up? Or can you track this on the first slave and produce an
> error in either pg_start_backup or pg_stop_backup()
Sure.
I will make a patch w
On 16.08.2011 04:10, Fujii Masao wrote:
On Thu, Aug 11, 2011 at 1:34 AM, Heikki Linnakangas
wrote:
Hmm, that's not possible for the 'tar' output, but would work for 'dir'
output. Another similar idea would be to withhold the control file in memory
until the end of backup, and append it to 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 PostgreSQ
On Tue, Aug 16, 2011 at 10:17 PM, Tom Lane 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 lock strength of so
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 go
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
hi
63 matches
Mail list logo
