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
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
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
Fujii Masao wrote:
On Sun, Feb 7, 2010 at 1:02 AM, Bruce Momjian br...@momjian.us 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
On Mon, Jan 18, 2010 at 11:46 PM, Magnus Hagander mag...@hagander.net 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
On Mon, Feb 8, 2010 at 6:11 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com 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
2010/2/7 Josh Berkus j...@agliodbs.com:
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
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().
A general
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 only
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
2010/2/1 Michael Glaesemann michael.glaesem...@myyearbook.com:
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
Takahiro Itagaki escribió:
KaiGai Kohei kai...@kaigai.gr.jp 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
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 hot standby
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
Both
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, without
-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
you in
Alvaro Herrera alvhe...@commandprompt.com 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
Dimitri Fontaine wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
On Mon, Feb 8, 2010 at 10:25 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Dimitri Fontaine wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
Bruce Momjian wrote:
Guy Rouillier wrote:
On 1/6/2010 3:29 PM, Tom Lane wrote:
Guy Rouillierguyr-...@burntmail.com 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
Joachim Wieland wrote:
+ typedef struct AsyncQueueEntry
+ {
+ /*
+ * this record has the maximal length, but usually we limit it to
+ * AsyncQueueEntryEmptySize + strlen(payload).
+ */
+ Sizelength;
+ Oid dboid;
+
Alvaro Herrera alvhe...@commandprompt.com 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
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
On Thu, Feb 4, 2010 at 11:57 AM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 10:25 AM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Mon, Feb 8, 2010 at 11:47 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 10:25 AM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Eh? Previously we allowed code to go in with documentation to be
written after feature
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
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
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,
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 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 float.
Alvaro Herrera alvhe...@commandprompt.com 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
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
argument
On Sun, Feb 7, 2010 at 11:23 PM, Robert Haas robertmh...@gmail.com wrote:
On Sun, Feb 7, 2010 at 3:37 PM, Josh Berkus j...@agliodbs.com 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
On Fri, Feb 5, 2010 at 8:53 PM, Bruce Momjian br...@momjian.us 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
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
On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas robertmh...@gmail.com 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
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
Hitoshi Harada umi.tan...@gmail.com writes:
2010/1/23 Robert Haas robertmh...@gmail.com:
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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
* 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
On Monday 08 February 2010 19:34:01 Greg Stark wrote:
On Mon, Feb 8, 2010 at 4:53 AM, Robert Haas robertmh...@gmail.com 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
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 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
* 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. The
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 no idea
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
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,
On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
2010/2/8 Oleg Bartunov o...@sai.msu.su:
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
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 not
Robert Haas escribió:
On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi 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
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
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
[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
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
functions
On Mon, Feb 8, 2010 at 3:30 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Robert Haas escribió:
On Mon, Feb 8, 2010 at 1:01 PM, Marko Tiikkaja
marko.tiikk...@cs.helsinki.fi wrote:
Could we just write, e.g.
non-SELECT statements are not allowed within a cursor declaration?
Or we
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
effect,
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
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 etd...@gmail.com:
Hi,
We've come across this issue on 8.2.15 on a Windows
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
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 never
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 never
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 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)
Alvaro Herrera alvhe...@commandprompt.com 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
On Mon, Feb 8, 2010 at 10:34 PM, Bruce Momjian br...@momjian.us 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.
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
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 be
Andrew Dunstan and...@dunslane.net 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
On Mon, Feb 8, 2010 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us 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
Alvaro Herrera alvhe...@commandprompt.com 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
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
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)
Alvaro Herrera alvhe...@commandprompt.com 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
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.
However,
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;
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
On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
2010/1/23 Robert Haas robertmh...@gmail.com:
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
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. $
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
alvhe...@commandprompt.com 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
On Thu, Dec 3, 2009 at 7:19 AM, Simon Riggs si...@2ndquadrant.com 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
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 and...@dunslane.net wrote:
M Z wrote:
Hi,
I am trying to checkout code from different branches (such as 8.3, 8.4).
I found a few
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 (type error
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
Fujii Masao wrote:
On Mon, Feb 8, 2010 at 10:34 PM, Bruce Momjian br...@momjian.us 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 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:
On Mon, Feb 8, 2010 at 10:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Feb 8, 2010 at 3:05 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
It seems a bit strange to have all the rb_free_recursive support and not
use it anywhere ... and a
2010/2/8 Teodor Sigaev teo...@sigaev.ru:
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
On Mon, Feb 8, 2010 at 10:37 PM, Hitoshi Harada umi.tan...@gmail.com wrote:
2010/2/9 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
2010/1/23 Robert Haas robertmh...@gmail.com:
Would it make sense to pull some of the infrastructure bits out of
this patch and commit
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
(2010/02/08 22:23), Alvaro Herrera wrote:
Takahiro Itagaki escribió:
KaiGai Koheikai...@kaigai.gr.jp wrote:
default:both contents and metadata
--data-only:same
--schema-only: neither
However, it means only large object performs an exceptional object
On 2010-02-09 01:09 +0200, Tom Lane wrote:
Marko Tiikkaja marko.tiikk...@cs.helsinki.fi 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
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,
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
representation
97 matches
Mail list logo
