On Monday 08 February 2010 05:53:23 Robert Haas wrote:
> On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
>
> wrote:
> > Andres Freund escribió:
> >> I personally think the fsync on the directory should be added to the
> >> stable branches - other opinions?
> >> If wanted I can prepare patches for
On Mon, 2010-02-08 at 12:25 +1100, Andrew McNamara wrote:
> For now, ocpgdb has no Python 3 support (I don't foresee any real
> problems, however).
Encoding issues are the big one. There are a couple gotchas, and I
provided the details here:
http://wiki.postgresql.org/wiki/Driver_development#Text
(2010/02/05 13:53), Takahiro Itagaki wrote:
>
> KaiGai Kohei wrote:
>
>>> default:both contents and metadata
>>> --data-only:same
>>> --schema-only: neither
>>
>> However, it means only large object performs an exceptional object class
>> that dumps its owner, acl and co
On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
wrote:
> Andres Freund escribió:
>> I personally think the fsync on the directory should be added to the stable
>> branches - other opinions?
>> If wanted I can prepare patches for that.
>
> Yeah, it seems there are two patches here -- one is the add
2010/2/7 Oleg Bartunov :
> I understand your complaints. I think, the real problem is that some of us
> live in the part of word with long holidays in December, while we in Russia
> have very long holidays in January. So, about a month we couldn't
> synchronize developers and reviewers. I'm not su
On Sun, Feb 7, 2010 at 3:37 PM, Josh Berkus wrote:
>> As between the two, I get the feeling that there is more interest in
>> writeable CTEs. But that impression might be wrong, since it's an
>> unscientific recollection of discussions on -hackers; which are
>> themselves not representative of an
On Sun, Feb 7, 2010 at 12:46 PM, Boszormenyi Zoltan wrote:
>> 1. Looks like you've falsified the last comment block in PortalRunMulti().
> You mean the "fake something up" part? Will fix the comment.
Yes.
>> 2. I don't like the duplication of code in PortalRun() between the
>> first and second b
On Sun, Feb 7, 2010 at 4:54 PM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> On Sun, Feb 7, 2010 at 4:03 PM, Dimitri Fontaine
>> wrote:
>>> In case I'm not clear, what I'm saying is that I think we can consider
>>> the writable CTE patch ready for commit even though we still have to
>>> dec
Andres Freund escribió:
> I personally think the fsync on the directory should be added to the stable
> branches - other opinions?
> If wanted I can prepare patches for that.
Yeah, it seems there are two patches here -- one is the addition of
fsync_fname() and the other is the fsync_prepare stuf
I wrote:
> And there's another problem: _bt_pagedel is designed to recurse
> in certain improbable cases, but I think this is flat out wrong
> when doing WAL replay --- if the original process did recurse
> then it will have emitted a WAL record for each deleted page,
> meaning replay would try to
Whilst looking around for stuff that could be deleted thanks to removing
old-style VACUUM FULL, I came across some code in btree that seems
rather seriously buggy. For reasons explained in nbtree/README, we
can't physically recycle a "deleted" btree index page until all
transactions open at the ti
On Sunday 07 February 2010 19:27:02 Andres Freund wrote:
> On Sunday 07 February 2010 19:23:10 Robert Haas wrote:
> > On Sun, Feb 7, 2010 at 11:24 AM, Tom Lane wrote:
> > > Greg Smith writes:
> > >> This is turning into yet another one of those situations where
> > >> something simple and useful
>I added you into the list at http://wiki.postgresql.org/wiki/Python
Thanks.
>Can you check what I put in there, confirm Windows compatibility, and
>comment on Python 3.X support?
I haven't tried it under Windows and I haven't had any feedback either
way from Windows users.
For now, ocpgdb ha
Tim Bunce wrote:
This is the third update to the fourth of the patches to be split out
from the former 'plperl feature patch 1'.
Changes in this patch:
- Added plperl.on_plperl_init and plperl.on_plperlu_init GUCs
Both are PGC_SUSET
SPI functions are not available when the code is run.
On Sun, Feb 7, 2010 at 1:02 AM, Bruce Momjian wrote:
>> src/backend/access/transam/xlog.c
>> > else
>> > {
>> > XLogRecPtr InvalidXLogRecPtr = {0, 0};
>> > ControlFile->minRecoveryPoint = InvalidXLogRecPtr;
>> > }
>>
>> In my original patch, the above is for the problem discussed in
>
Andrew McNamara wrote:
I got sick of the constant stream of escaping bugs impacting on psycopg
and pyPgSQL, and wrote my own DB-API driver, using the more modern
libpq/binary/protocol 3 APIs where ever possible. The result is BSD
licensed:
http://code.google.com/p/ocpgdb/
I added you int
>Any other suggestions before I turn the above into a roadmap page on the
>wiki?
I got sick of the constant stream of escaping bugs impacting on psycopg
and pyPgSQL, and wrote my own DB-API driver, using the more modern
libpq/binary/protocol 3 APIs where ever possible. The result is BSD
licensed:
On Sun, 7 Feb 2010, Robert Haas wrote:
On Sun, Feb 7, 2010 at 1:38 AM, Josh Berkus wrote:
I think it might be time to revisit this issue. SR is in, and we have
a week left in the CF, and we have all of the above patches plus 5
small ones left to deal with. rbtree is close to being committabl
Thanks Tom, for the explanation.
Gokul.
On Sun, Feb 7, 2010 at 10:14 PM, Tom Lane wrote:
> Gokulakannan Somasundaram writes:
> >Is there any reason why we have given lesser precedence for postfix
> > operator compared to multiplication/division? Usually postfix operators
> have
> > more pr
Robert Haas writes:
> On Sun, Feb 7, 2010 at 4:03 PM, Dimitri Fontaine
> wrote:
>> In case I'm not clear, what I'm saying is that I think we can consider
>> the writable CTE patch ready for commit even though we still have to
>> decide what its impacts on documentation should be.
>
> Whether a p
On Sun, Feb 7, 2010 at 4:03 PM, Dimitri Fontaine wrote:
> Marko Tiikkaja writes:
>> The documentation has definitely improved from the last time Robert
>> looked at it, but I fear it still needs some more work. I'm willing to
>> do that work, but I need something concrete.
>
> It seems to me doc
On Feb 7, 2010, at 12:35 PM, Josh Berkus wrote:
>> I've always thought this feature was misnamed and nothing has happened
>> to change my mind, but it's not clear whether I'm in the majority.
>
> I'm afraid force of habit is more powerful than correctness on this one.
> It's going to be HS/SR whe
Marko Tiikkaja writes:
> The documentation has definitely improved from the last time Robert
> looked at it, but I fear it still needs some more work. I'm willing to
> do that work, but I need something concrete.
It seems to me documentation is required to get into the source tree
before beta, a
On 2010-02-07 22:37 +0200, Josh Berkus wrote:
> Robert,
>> I have not looked at the window functions patch at all, and I haven't
>> looked at the latest version of writeable CTEs, either. I will try to
>> spend some time on it in the next couple of days. My feeling about
>> the last version is th
Hi Simon, Hi all,
if (!logged && (wait_s > 0 || wait_us > 50))
{
const char *oldactivitymsg;
int len;
oldactivitymsg = get_ps_display(&len);
snprintf(waitactivitymsg, sizeof(waitactivitymsg),
"waiting for max_standb
Robert,
> As between the two, I get the feeling that there is more interest in
> writeable CTEs. But that impression might be wrong, since it's an
> unscientific recollection of discussions on -hackers; which are
> themselves not representative of anything.
Writeable CTE is definitely the bigger
> I've always thought this feature was misnamed and nothing has happened
> to change my mind, but it's not clear whether I'm in the majority.
I'm afraid force of habit is more powerful than correctness on this one.
It's going to be HS/SR whether that's perfectly correct or not.
--Josh Berkus
Josh Berkus wrote:
Anyway, I don't yet have a full diagnosis on the transaction control
issue or I'd already have posted it to psycopg -- it may be a toxic
interaction between Django and Psycopg2 rather than psycopg2 alone. I'd
not have brought it up except for this discussion.
I'm going to
Robert,
I understand your complaints. I think, the real problem is that some of us
live in the part of word with long holidays in December, while we in Russia
have very long holidays in January. So, about a month we couldn't synchronize
developers and reviewers. I'm not sure if we took this in
Greg Smith wrote:
Here's a full TODO page that includes everything mentioned here as
best I could summarize it:
http://wiki.postgresql.org/wiki/Python_PostgreSQL_Driver_TODO
Looks like the first action item is to talk with the Psycopg people
about their license.
Oh: and I'm going to take
>> I'm not a Python user myself, but I have trouble understanding how you
>> can describe bugs in one of the Python drivers as off-topic to the
>> Python driver situation.
>
> I thought the topic was "Confusion over Python drivers"?
>
> The only bug there was likely app one, or at least its n
On Feb 7, 2010, at 1:30 PM, Tom Lane wrote:
David Christensen writes:
On Feb 7, 2010, at 11:04 AM, Tom Lane wrote:
pg_relation_filepath(regclass) returns text
which would expose the output of relpath(), ie, the $PGDATA-relative
path name of the relation.
Should this return multiple values
David Christensen writes:
> On Feb 7, 2010, at 11:04 AM, Tom Lane wrote:
>> pg_relation_filepath(regclass) returns text
>> which would expose the output of relpath(), ie, the $PGDATA-relative
>> path name of the relation.
> Should this return multiple values (text[] or SETOF text) for tables
>
2010/2/7 Oleg Bartunov :
> On Sun, 7 Feb 2010, Robert Haas wrote:
>
>> On Sun, Feb 7, 2010 at 1:38 AM, Josh Berkus wrote:
I think it might be time to revisit this issue. SR is in, and we have
a week left in the CF, and we have all of the above patches plus 5
small ones left to
On Feb 7, 2010, at 11:04 AM, Tom Lane wrote:
In connection with the relation-mapping patch I proposed a function
pg_relation_filenode(regclass) returns oid
which client code would need to use instead of looking at
pg_class.relfilenode, if it wants to get a number that will be
meaningful
On Sunday 07 February 2010 19:23:10 Robert Haas wrote:
> On Sun, Feb 7, 2010 at 11:24 AM, Tom Lane wrote:
> > Greg Smith writes:
> >> This is turning into yet another one of those situations where something
> >> simple and useful is being killed by trying to generalize it way more
> >> than it ne
On Sun, Feb 7, 2010 at 11:24 AM, Tom Lane wrote:
> Greg Smith writes:
>> This is turning into yet another one of those situations where something
>> simple and useful is being killed by trying to generalize it way more
>> than it needs to be, given its current goals and its lack of external
>> in
Robert Haas írta:
> On Tue, Feb 2, 2010 at 4:03 AM, Boszormenyi Zoltan wrote:
>
>> Thanks for testing it, with the attached patch your test case also
>> returns SELECT N.
>>
>
> Thoughts:
>
> 1. Looks like you've falsified the last comment block in PortalRunMulti().
>
You mean the "fak
Simon Riggs writes:
> On Sat, 2010-02-06 at 13:04 -0500, Tom Lane wrote:
>> We might still want to consider toast-ifying pg_class if anyone ever
>> complains about not having room for wide relacl values; but CLUSTER
>> shouldn't be a forcing function for such decisions.
> What failure do you get
In connection with the relation-mapping patch I proposed a function
pg_relation_filenode(regclass) returns oid
which client code would need to use instead of looking at
pg_class.relfilenode, if it wants to get a number that will be
meaningful for mapped system catalogs. I still think we ne
On Sat, 2010-02-06 at 13:04 -0500, Tom Lane wrote:
> I wrote:
> > Still fooling with VACUUM FULL on catalogs ... I find that a sanity
> > check I put in is barfing on "VACUUM FULL pg_class", because the
> > transient table is built with a toast table, whereas pg_class hasn't got
> > one. It seems
On Sat, 2010-02-06 at 17:32 +0100, Andres Freund wrote:
> >
> > So it seems at least the behavior is quite different from what the
> > docs stats. Am I missing something here?
> Its a small bug/typo in standby.c:ResolveRecoveryConflictWithDatabase
>
> The line:
> CancelDBBackends(db
Gokulakannan Somasundaram writes:
>Is there any reason why we have given lesser precedence for postfix
> operator compared to multiplication/division? Usually postfix operators have
> more precedence than the binary operations. Is this some kind of work around
> to provide user-defined operato
Greg Smith writes:
> This is turning into yet another one of those situations where something
> simple and useful is being killed by trying to generalize it way more
> than it needs to be, given its current goals and its lack of external
> interfaces. There's no catversion bump or API breakage
On Sat Feb 6 01:20 AM, Tom Lane wrote:
> "Jonathan Bond-Caron" writes:
> > I think part of my problem is I haven't really understood what 'Then
> > make sure you have the right alignment' means.
>
> > My approach currently is:
>
> > After reading HeapTupleHeaderData (23 bytes), I advance anothe
On Sun, Feb 7, 2010 at 4:41 AM, Markus Wanner wrote:
> Bruce Momjian wrote:
>> Do we want to call the feature "hot standby"? Is a read-only standby a
>> "standby" or a "slave"?
>
> I think hot standby is pretty much the term, now.
See here for the previous iteration of this discussion:
http://a
On Sun, Feb 7, 2010 at 1:38 AM, Josh Berkus wrote:
>> I think it might be time to revisit this issue. SR is in, and we have
>> a week left in the CF, and we have all of the above patches plus 5
>> small ones left to deal with. rbtree is close to being committable, I
>> think; knngist has not bee
On Sun, Feb 7, 2010 at 2:05 AM, Tom Lane wrote:
> Given that we have a week still to go in the CF, I feel fairly
> confident of still getting the window frame patch in on time
> (assuming that there are indeed no major problems with it).
> I have not let go of it for that reason, and also because
On Sat, Feb 06, 2010 at 10:38:00PM -0800, Josh Berkus wrote:
>
> Add on_trusted_init and on_untrusted_init to plperl
> Package namespace and Safe init cleanup for plperl
Alex Hunsaker has marked the latest version of both of those
as Ready for Committer.
Tim.
--
Sent via pgsql-hackers mailing
Hi,
Is there any reason why we have given lesser precedence for postfix
operator compared to multiplication/division? Usually postfix operators have
more precedence than the binary operations. Is this some kind of work around
to provide user-defined operators? Can someone help me understand this
On 7 February 2010 10:49, Heikki Linnakangas
wrote:
> Thom Brown wrote:
>> On 7 February 2010 10:20, Thom Brown wrote:
>>> The post about the dev docs needing more hot standby mentions prompted
>>> me to have a look at how streaming replication is documented. Ignore
>>> this if this has already
Marko,
> I thought the topic was "Confusion over Python drivers"?
>
> The only bug there was likely app one, or at least its not widespread
> so off-topic. Rest are more like non-essential cool features,
> so again off-topic.
>
Those lack of "non-essential cool features" is right on topic - b
Thom Brown wrote:
> On 7 February 2010 10:20, Thom Brown wrote:
>> The post about the dev docs needing more hot standby mentions prompted
>> me to have a look at how streaming replication is documented. Ignore
>> this if this has already been discussed (I couldn't find any posts),
>> but I couldn
On 7 February 2010 10:20, Thom Brown wrote:
> The post about the dev docs needing more hot standby mentions prompted
> me to have a look at how streaming replication is documented. Ignore
> this if this has already been discussed (I couldn't find any posts),
> but I couldn't find any mention of s
The post about the dev docs needing more hot standby mentions prompted
me to have a look at how streaming replication is documented. Ignore
this if this has already been discussed (I couldn't find any posts),
but I couldn't find any mention of streaming replication except in the
write ahead log co
On 2/7/10, Robert Haas wrote:
> On Sat, Feb 6, 2010 at 7:48 PM, Marko Kreen wrote:
> > This is long-term todo item for psycopg, seems offtopic
> > to the "driver situation".
>
> [...]
>
> > This is routine bug in either app or psycopg, we have no reason
> > to touch it. The guy should report
Marko Kreen wrote:
I think we should concentrate on the PR problem and technical issues
related to that, keep the other low-level and non-user-visible
issues out. Or at least separate. (PsycopgTodo wiki page?)
That's just a matter of prioritizing the issues. Put the big ones at
the top,
Bruce,
Bruce Momjian wrote:
Ah, I now realize it only mentions "warm" standby, not "hot", so I just
updated the documentation to reflect that; you can see it here:
Maybe the table below also needs an update, because unlike "Warm Standby
using PITR", a hot standby accepts read-only queries an
Robert Haas wrote:
Well it seems that what we're trying to implement is more like
it_would_be_nice_if_you_would_start_syncing_this_file_range_but_its_ok_if_you_dont(),
so maybe that would work.
Anyway, is there something that we can agree on and get committed here
for 9.0, or should we postpone
59 matches
Mail list logo
