>If the date is passed in binary format, it will pass it to int4recv() --
>but because the date is 4 bytes, and int4recv is defined for any 4-byte
>input, it won't cause an error; it will produce a wrong result. In other
>words, the binary representation for a date _is_ a valid binary
>representati
In this version of the patch, there is a compiler warning:
async.c: In function ‘AtPrepare_Notify’:
async.c:593: warning: unused variable ‘p’
and also two trivial merge conflicts: an OID conflict for the functions
you added, and a trivial code conflict.
On Sun, 2010-02-07 at 17:32 +0100, Joa
On 2010-02-09 01:09 +0200, Tom Lane wrote:
> Marko Tiikkaja writes:
>> I traced this down to heapam.c, which has this:
>> ...
>> This doesn't exactly work anymore since we modify the snapshot after
>> calling ExecInitScan().
>
> So don't do that. The executor is generally entitled to assume that
(2010/02/08 22:23), Alvaro Herrera wrote:
Takahiro Itagaki escribió:
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 o
The only sane things to check out apart from HEAD are normally the
STABLE branches. For release m.n those are always called RELm_n_STABLE.
You can also get the tag set for a specific release. Those are called
RELm_n_o for m.n.o releases.
If you look at the output for "cvs log configure.in" y
On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada wrote:
> 2010/2/9 Tom Lane :
>> Hitoshi Harada writes:
>>> 2010/1/23 Robert Haas :
Would it make sense to pull some of the infrastructure bits out of
this patch and commit those bits separately, so as to reduce the size
of the main pa
2010/2/8 Teodor Sigaev :
>> I think that the code in ginInsertRecordBA() is needlessly complex.
>> As far as I can see, nNodesOnCurrentLevel is always exactly one more
>> than nNodesOnPreviousLevel, and I think step is also basically
>> redundant with both of these although the relationship is a li
On Mon, Feb 8, 2010 at 10:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
>> wrote:
>>> It seems a bit strange to have all the rb_free_recursive support and not
>>> use it anywhere ... and a freefunc callback even, whose only caller
>>> seems to set
On Mon, 2010-02-08 at 20:50 +0100, Florian Weimer wrote:
> I saw your note that you have to specify the types for date values
> etc. Is this really desirable or even necessary? Can't you specify
> the type as unknown (OID 705, I believe)?
I believe the problem that Andrew is describing is that:
Fujii Masao wrote:
> On Mon, Feb 8, 2010 at 10:34 PM, Bruce Momjian wrote:
> > Ahh, good point. ?I had not considered the table would change. ?What I
> > did was to mark "Slaves accept read-only queries" as "Hot only".
>
> Can the "warm standby" still reside in v9.0? If not, the mark of
> "Hot on
For example, how can I list all the branches for postgresql 8.3 (and 8.4)?
Now I can checkout code using:
cvs -z3 -d :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot
co -P pgsql
But I don't know when version it is, and I want get code from some
postgresql 8.3 and 8.4 branches but
On Tue, 2010-02-09 at 13:56 +1100, Andrew McNamara wrote:
> >For a given type, the input function may be more likely to catch an
> >input error than the recv function; or the reverse. Either way, it is
> >very type-specific, and the only difference is the whether the input is
> >misinterpreted (typ
Hi Andrew,
Could you please give a little more detail how I can find different CVS
branches?
Thanks,
M Z
On Mon, Feb 8, 2010 at 10:38 PM, Andrew Dunstan wrote:
>
>
> M Z wrote:
>
>> Hi,
>>
>> I am trying to checkout code from different branches (such as 8.3, 8.4).
>>
>> I found a few ways to
On Thu, Dec 3, 2009 at 7:19 AM, Simon Riggs wrote:
>
> The answer is nobody got round to enhancing this yet and well considered
> proposals and subsequent patches would be welcome.
>
what is a well considered proposal in this area? the transition
function cost should be applied to every row cost
Robert Haas writes:
> On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
> wrote:
>> It seems a bit strange to have all the rb_free_recursive support and not
>> use it anywhere ... and a freefunc callback even, whose only caller
>> seems to set as null currently. Hmm, even in the knngist patch the
>
M Z wrote:
Hi,
I am trying to checkout code from different branches (such as 8.3, 8.4).
I found a few ways to checkout code from CVS:
1. webCVS: http://anoncvs.postgresql.org/cvsweb.cgi/
2. cvs -z3 -d
:pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot co
-P pgsql
3. $ rsy
2010/2/9 Tom Lane :
> Hitoshi Harada writes:
>> 2010/1/23 Robert Haas :
>>> Would it make sense to pull some of the infrastructure bits out of
>>> this patch and commit those bits separately, so as to reduce the size
>>> of the main patch? In particular, the AggGetMemoryContext() stuff
>>> looks
On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
wrote:
> It seems a bit strange to have all the rb_free_recursive support and not
> use it anywhere ... and a freefunc callback even, whose only caller
> seems to set as null currently. Hmm, even in the knngist patch the
> rb_freefunc stuff is unused
Hi,
I am trying to checkout code from different branches (such as 8.3, 8.4).
I found a few ways to checkout code from CVS:
1. webCVS: http://anoncvs.postgresql.org/cvsweb.cgi/
2. cvs -z3 -d :pserver:anoncvs:passw...@anoncvs.postgresql.org:/projects/cvsroot
co -P pgsql
3. $ rsync --progress -avz
>For a given type, the input function may be more likely to catch an
>input error than the recv function; or the reverse. Either way, it is
>very type-specific, and the only difference is the whether the input is
>misinterpreted (type error not caught; bad) or an error is thrown (type
>error caught
On Tue, 2010-02-09 at 12:51 +1100, Andrew McNamara wrote:
> Now, with the text format parameters, the parser usually does the right
> thing, since text formats have plenty of hints for us humans.
The parser doesn't care whether it's text format or binary format when
determining the type.
> Howeve
Alvaro Herrera writes:
> Tom Lane wrote:
>> Maybe we should do
>> something about this. There wasn't any obvious solution before,
>> but now that we have the nontransactional smgr-level sinval messages
>> being sent on drops and truncates, it seems like tying rd_targblock
>> clearing to those wou
>On Tue, 2010-02-09 at 10:46 +1100, Andrew McNamara wrote:
>> The problem is deeper than that - when query parameters use the binary
>> option, the server has no way to decode the binary parameter without an
>> appropriate type OID.
>
>Postgres does not attempt to decode anything (text or binary fo
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> Actually, after thinking about this some more, I realize that this code
> >> has got a significantly bigger problem than just whether it will respond
> >> to CANCEL promptly.
>
> > Err, that problem was exactly why I added the inte
Alvaro Herrera writes:
> Tom Lane wrote:
>> Actually, after thinking about this some more, I realize that this code
>> has got a significantly bigger problem than just whether it will respond
>> to CANCEL promptly.
> Err, that problem was exactly why I added the interrupt holdoff in
> there, so i
On Mon, Feb 8, 2010 at 5:20 PM, Tom Lane wrote:
>> Our Solaris *moth members seem to have stopped building. Have we lost them?
>
> They're not *all* dead, but it sure looks like Oracle scaled that lab
> way back the moment they owned it. I'm surprised any of them are still
> alive :-(
We still h
Andrew Dunstan writes:
> Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a
> recent RADIUS support fix. Looks like we might need to include win32.h
> in there.
That was discussed already. I assume Magnus is going to address it
as soon as he gets back from FOSDEM.
> MSVC
Tom Lane wrote:
> Actually, after thinking about this some more, I realize that this code
> has got a significantly bigger problem than just whether it will respond
> to CANCEL promptly. If we truncate the table, and then get an error
> sometime before commit, the relcache inval message will not
It looks like some recent patches have broken a couple of things on the
buildfarm.
Mingw builds are missing in6addr_any in backend/libpq/auth.c, added by a
recent RADIUS support fix. Looks like we might need to include win32.h
in there.
MSVC builds are broken from a missing _isnan function
On Mon, Feb 8, 2010 at 10:34 PM, Bruce Momjian wrote:
> Ahh, good point. I had not considered the table would change. What I
> did was to mark "Slaves accept read-only queries" as "Hot only".
Can the "warm standby" still reside in v9.0? If not, the mark of
"Hot only" seems odd for me.
> I did
Alvaro Herrera writes:
> Tom Lane wrote:
>> The point would be to not disable interrupts till after doing the FSM
>> vacuuming. Ignoring CANCEL for longer than we must is bad.
> Oh, I see. I guess the answer is that it depends on what happens if you
> interrupt after vacuuming the FSM. I have
On Tue, 2010-02-09 at 10:46 +1100, Andrew McNamara wrote:
> The problem is deeper than that - when query parameters use the binary
> option, the server has no way to decode the binary parameter without an
> appropriate type OID.
Postgres does not attempt to decode anything (text or binary format)
On Mon, 2010-02-08 at 09:14 +0100, Massa, Harald Armin wrote:
> And we should not forget to look for the reasons for the incubation of
> that many pure-Python drivers:
All very good points. That's why the doc I wrote:
http://wiki.postgresql.org/wiki/Driver_development
is specifically targeted at
>On Tue, 2010-02-09 at 09:15 +1100, Andrew McNamara wrote:
>> I can't see how this would work with binary query parameters - the server
>> will see a blob of binary data and have no way to know what it represents.
>
>Unknown is unknown, whether in binary or text format. As far as I know,
>PostgreSQ
On Tue, 2010-02-09 at 09:15 +1100, Andrew McNamara wrote:
> I can't see how this would work with binary query parameters - the server
> will see a blob of binary data and have no way to know what it represents.
Unknown is unknown, whether in binary or text format. As far as I know,
PostgreSQL neve
Marko Tiikkaja writes:
> I traced this down to heapam.c, which has this:
> ...
> This doesn't exactly work anymore since we modify the snapshot after
> calling ExecInitScan().
So don't do that. The executor is generally entitled to assume that
parameters given to ExecutorStart are correct. In p
Tom Lane wrote:
> Alvaro Herrera writes:
> > What's the point of not following Oracle here, since this is solely an
> > Oracle compatibility function?
>
> Changing FM's behavior like that will break approximately every user
> of to_char() ...
I would love to know why we are finding out about thi
IIRC, we've had zero reports on whether the patch worked at all on 8.2
in an environment where the problem actually existed. So yes, some
testing and feedback would be much apprecaited.
//Magnus
2010/2/8 Etienne Dube :
> Hi,
>
> We've come across this issue on 8.2.15 on a Windows Server 2008 inst
Hi,
We've come across this issue on 8.2.15 on a Windows Server 2008
instance. I noticed the patch hasn't been applied to the 8.2 branch yet.
Any chances that this will be part of an eventual 8.2.16 release? Do you
need more testing and feedback before commiting the patch?
Thanks,
Etienne Du
>> http://code.google.com/p/ocpgdb/
>
>I saw your note that you have to specify the types for date values
>etc. Is this really desirable or even necessary? Can't you specify
>the type as unknown (OID 705, I believe)?
>
>At work, we recently used to typelessness of Perl's DBD::Pg with great
>e
On Mon, Feb 8, 2010 at 3:30 PM, Alvaro Herrera
wrote:
> Robert Haas escribió:
>> On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
>> wrote:
>> >> Could we just write, e.g.
>> >> "non-SELECT statements are not allowed within a cursor declaration?"
>> >> Or we could say "INSERT, UPDATE, and DELETE st
I wrote:
> I started looking at this patch. I believe that we should commit the
> AggGetMemoryContext API function --- *not* the window context
> management changes that you included here, but only the API abstraction
> --- to be sure that that gets into 9.0 so that third-party aggregate
> functi
[Sigh. This email, unlike the previous, actually includes the patch.]
On Mon, Feb 08, 2010 at 01:44:16PM +, Tim Bunce wrote:
>
> > I'll continue reviewing the patch, but these things at least need fixing.
Here's an updated patch. The only changes relative to the previous
version are in the d
On Mon, Feb 08, 2010 at 01:44:16PM +, Tim Bunce wrote:
>
> > I'll continue reviewing the patch, but these things at least need fixing.
Here's an updated patch. The only changes relative to the previous
version are in the docs, as I outlined in the previous message.
I'll add it to the commitf
On Mon, 2010-02-08 at 20:29 +0100, Florian Weimer wrote:
> I'm contemplating to create a new language binding for libpq (or, to
> be more precise, turn an existing language binding into something that
> can be published). I've been agonizing a bit over how to create a
> bridge between the host lan
Robert Haas escribió:
> On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
> wrote:
> >> Could we just write, e.g.
> >> "non-SELECT statements are not allowed within a cursor declaration?"
> >> Or we could say "INSERT, UPDATE, and DELETE statements are not allowed
> >> within a cursor declaration", bu
Robert Haas escribió:
> Yeah, I don't feel good about "INSERT, UPDATE, and DELETE" because in
> most of the relevant contexts the list might get longer if in the
> future we allow things like EXPLAIN and COPY within CTEs. I think
> "Non-SELECT statement" is reasonably clear, though; people might
2010/2/8 Oleg Bartunov :
> List of holidays by country
> http://en.wikipedia.org/wiki/List_of_holidays_by_country
>
> I'm not sure how it's valid, though. In Russia, for example,
> russian goverment decreed holidays 1-10 January, 2010. I think next time we
> should consider december-january as a ha
On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
wrote:
>> Could we just write, e.g.
>> "non-SELECT statements are not allowed within a cursor declaration?"
>> Or we could say "INSERT, UPDATE, and DELETE statements are not allowed
>> within a cursor declaration", but I'm thinking we may want to allo
List of holidays by country
http://en.wikipedia.org/wiki/List_of_holidays_by_country
I'm not sure how it's valid, though. In Russia, for example,
russian goverment decreed holidays 1-10 January, 2010. I think next time we
should consider december-january as a half.
Oleg
On Sun, 7 Feb 2010, Rober
It seems a bit strange to have all the rb_free_recursive support and not
use it anywhere ... and a freefunc callback even, whose only caller
seems to set as null currently. Hmm, even in the knngist patch the
rb_freefunc stuff is unused. How do we now that it works?
(What, for example, if we wer
Alvaro Herrera wrote:
> Tom Lane wrote:
>> The point would be to not disable interrupts till after doing the FSM
>> vacuuming. Ignoring CANCEL for longer than we must is bad.
>
> Oh, I see. I guess the answer is that it depends on what happens if you
> interrupt after vacuuming the FSM. I have
* Andrew McNamara:
>>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
On 2/8/10 11:17 AM, Tom Lane wrote:
> Given the lack of time remaining in this CF, I'm tempted to propose
> ripping out the RANGE support and just trying to get ROWS committed.
> That should be substantially less controversial from a semantic
> standpoint, and it still seems like a considerable imp
Hi,
While playing around with another issue with the patch, I came across
the following:
=> create table foo(a int);
CREATE TABLE
=> with t as (insert into foo values(0)) select * from foo;
a
---
(0 rows)
I traced this down to heapam.c, which has this:
/*
* return null immediately if relation
On Monday 08 February 2010 19:34:01 Greg Stark wrote:
> On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas wrote:
> > On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
> >
> >> Yeah, it seems there are two patches here -- one is the addition of
> >> fsync_fname() and the other is the fsync_prepare stuff.
* Jeff Davis:
> I have written up a set of guidelines for driver development based on
> what I learned working on ruby-pg:
>
> http://wiki.postgresql.org/wiki/Driver_development
Interesting, thanks.
I'm contemplating to create a new language binding for libpq (or, to
be more precise, turn an exi
Tom Lane wrote:
> Alvaro Herrera writes:
> > Tom Lane wrote:
> >> I see that lazy_vacuum_rel() truncates the heap before it does vacuuming
> >> of the free space map. Once upon a time this wouldn't have mattered,
> >> but now it means that cancel interrupts are likely to be ignored for
> >> the d
Hitoshi Harada writes:
> 2010/1/23 Robert Haas :
>> Would it make sense to pull some of the infrastructure bits out of
>> this patch and commit those bits separately, so as to reduce the size
>> of the main patch? In particular, the AggGetMemoryContext() stuff
>> looks like a good candidate for t
On Mon, 8 Feb 2010, Josh Berkus wrote:
On 2/8/10 7:31 AM, Robert Haas wrote:
Eh? Previously we allowed code to go in with documentation to be
written after feature freeze. Is this no longer acceptable?
My $0.0201115:
Depends on the feature, I'd say. If it's sufficiently obvious to test
th
On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas wrote:
> On Sun, Feb 7, 2010 at 10:09 PM, Alvaro Herrera
>> Yeah, it seems there are two patches here -- one is the addition of
>> fsync_fname() and the other is the fsync_prepare stuff.
Sorry, I'm just catching up on my mail from FOSDEM this past weeke
That looks pretty good. I confess I don't fully understand why it
works. If we're inserting a bunch of equal-key entries, why does it
matter what order we insert them in? Is there some code in here
(where?) that breaks ties on the basis of where they are in the input
data?
Entries to insert i
On Fri, Feb 5, 2010 at 8:53 PM, Bruce Momjian wrote:
> Do you want a C comment to document this problem?
Well I would rather a better heuristic :)
We really need some statistics nerds in this group who can pipe up
when these kinds of issues come up. There must be a good way to
estimate the proba
On Sun, Feb 7, 2010 at 11:23 PM, Robert Haas wrote:
> 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
On 2010-02-08 18:42 +0200, Robert Haas wrote:
> On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
>> Here's an updated patch. Only changes from the previous patch are
>> fixing the above issue and a regression test for it.
>
> - I'm not sure that canSetTag is the right name for the additional
> arg
Alvaro Herrera writes:
> Tom Lane wrote:
>> I see that lazy_vacuum_rel() truncates the heap before it does vacuuming
>> of the free space map. Once upon a time this wouldn't have mattered,
>> but now it means that cancel interrupts are likely to be ignored for
>> the duration of FreeSpaceMapVacuu
On Feb 8, 2010, at 9:34 AM, Josh Berkus wrote:
>>> Eh? Previously we allowed code to go in with documentation to be
>>> written after feature freeze. Is this no longer acceptable?
>
> My $0.0201115:
I think you need to use a NUMERIC type there, as some calculation has lost
precision in the fl
Tom Lane wrote:
> I see that lazy_vacuum_rel() truncates the heap before it does vacuuming
> of the free space map. Once upon a time this wouldn't have mattered,
> but now it means that cancel interrupts are likely to be ignored for
> the duration of FreeSpaceMapVacuum(). Is that really necessary
On 2/8/10 7:31 AM, Robert Haas wrote:
>> Eh? Previously we allowed code to go in with documentation to be
>> written after feature freeze. Is this no longer acceptable?
My $0.0201115:
Depends on the feature, I'd say. If it's sufficiently obvious to test
the feature without full documentation,
I see that lazy_vacuum_rel() truncates the heap before it does vacuuming
of the free space map. Once upon a time this wouldn't have mattered,
but now it means that cancel interrupts are likely to be ignored for
the duration of FreeSpaceMapVacuum(). Is that really necessary?
Would it be okay to sw
On Feb 8, 2010, at 5:15 AM, Magnus Hagander wrote:
> The text is about 180Kb. PostgreSQL takes ~40 seconds without the
> patch, ~36 seconds with it, to extract the match from it. Perl takes
> 0.016 seconds.
Obviously we need to support Perl regular expressions in core. Not PCRE, but
Perl. ;-P
B
On Mon, Feb 8, 2010 at 11:47 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> On Mon, Feb 8, 2010 at 10:25 AM, Alvaro Herrera
>> wrote:
>>> Eh? Previously we allowed code to go in with documentation to be
>>> written after feature freeze. Is this no longer acceptable?
>>
>> I don't think w
Robert Haas writes:
> On Mon, Feb 8, 2010 at 10:25 AM, Alvaro Herrera
> wrote:
>> Eh? Previously we allowed code to go in with documentation to be
>> written after feature freeze. Is this no longer acceptable?
>
> I don't think we usually allow that for minor features. For big
> things, it's p
On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
wrote:
> On 2010-02-04 18:04 UTC+2, I wrote:
>> While working on the docs, I noticed one problem with the patch itself:
>> it doesn't handle multi-statement DO INSTEAD rules correctly. I'm going
>> to submit a fix for that later.
>
> Here's an updat
Hi,
I was looking at the code for bitmap index:
http://archives.postgresql.org/pgsql-hackers/2008-10/msg01691.php
and I couldn't understand why during "bmbuild" (the ambuild call for
bitmap indexes) the code checks for not-ordered ItemPointerData(s).
In which cases the ItemPointerData(s) given
Alvaro Herrera writes:
> What's the point of not following Oracle here, since this is solely an
> Oracle compatibility function?
Changing FM's behavior like that will break approximately every user
of to_char() ...
regards, tom lane
--
Sent via pgsql-hackers mailing lis
Joachim Wieland wrote:
> + typedef struct AsyncQueueEntry
> + {
> + /*
> + * this record has the maximal length, but usually we limit it to
> + * AsyncQueueEntryEmptySize + strlen(payload).
> + */
> + Sizelength;
> + Oid db
Bruce Momjian wrote:
> Guy Rouillier wrote:
> > On 1/6/2010 3:29 PM, Tom Lane wrote:
> > > Guy Rouillier writes:
> > >> Oracle states clearly in the SQL Reference manual:
> > >
> > >> "A modifier can appear in a format model more than once. In such a case,
> > >> each subsequent occurrence toggles
On Mon, Feb 8, 2010 at 10:25 AM, Alvaro Herrera
wrote:
> 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
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 documentation is required to get
Alvaro Herrera writes:
> I just noticed that this patch
>> Create a "relation mapping" infrastructure to support changing the
>> relfilenodes
>> of shared or nailed system catalogs. This has two key benefits:
> creates a new function pg_relation_filenode() that only uses the
> syscache to fetc
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> I have written up a set of guidelines for driver development
> based on what I learned working on ruby-pg:
>
> http://wiki.postgresql.org/wiki/Driver_development
...
> I would appreciate comments by anyone (Greg Sabino Mullane: I included
> y
I just noticed that this patch
> Create a "relation mapping" infrastructure to support changing the
> relfilenodes
> of shared or nailed system catalogs. This has two key benefits:
creates a new function pg_relation_filenode() that only uses the
syscache to fetch the relation's filenode, witho
On Sun, Feb 07, 2010 at 08:25:33PM -0500, Andrew Dunstan wrote:
> 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
Markus Wanner wrote:
> 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 ho
Takahiro Itagaki escribió:
>
> 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 comment even if
2010/2/1 Michael Glaesemann :
>
> On Jan 31, 2010, at 22:14 , Tom Lane wrote:
>
>> The Tcl folk accepted that patch, so I went ahead and applied it to
>> our code. It would still be a good idea for us to do any testing we
>> can on it, though.
>
> I applied the patch and ran both the test query I
Tom Lane wrote:
> 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
> t
Greg,
> The point isn't so much "standardizing". Having a low performance Python
> driver turns into a PostgreSQL PR issue.
I totally agree.
>And if you're writing a database driver with performance as a goal, native
Python is simply not >an option.
yes. Additionally: performance is not the
Robert Haas írta:
> ...
> OK, please change it.
>
New patch is attached with the discussed changes.
>>> Someone who knows the overall structure of the code better than I do
>>> will have to comment on whether there are any code paths to worry
>>> about that do not go through PortalRun().
>>>
>
2010/2/7 Josh Berkus :
>> 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
On Mon, Feb 8, 2010 at 6:11 PM, Heikki Linnakangas
wrote:
> I removed that.
Thanks!
> It only makes a difference if you stop archive recovery, remove
> recovery.conf, and start up again, causing the server to do normal crash
> recovery. That's a "don't do that" scenario, but it seems better to n
On Mon, Jan 18, 2010 at 11:46 PM, Magnus Hagander wrote:
>>> From what I can tell, this indicates that pq_getbyte_if_available() is
>>> not working - because it's supposed to never block, right?
>>
>> Right, it's not supposed to block.
>>
>>> This could be because the win32 socket emulation layer
Fujii Masao wrote:
> 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 pr
Hi there,
Greg Smith ha scritto:
Looks like the first action item is to talk with the Psycopg people
about their license.
Oh: and I'm going to take care of this. License changes can be a
very sensitive topic and I'm told that discussion probably needs to
happy in Italian too; I can arrange
Massa, Harald Armin wrote:
I agree that there are some performance-challenges with pure-Python
drivers.
And we should not forget to look for the reasons for the incubation of
that many pure-Python drivers:
a) Python is no longer one-language, one-implementation. There are (at
least) cPython (th
>The pg8000 / bpgsql seem to be toy projects, and anyway you dont
>want to use pure-Python drivers in high-performance environments.
I agree that there are some performance-challenges with pure-Python drivers.
And we should not forget to look for the reasons for the incubation of that
many pure-P
97 matches
Mail list logo
