On Thursday 18 February 2010 06:17:06 Fujii Masao wrote:
[2460]: LOG: could not receive data from client: No connection could be
made because the target machine actively refused it. [2460]: FATAL:
invalid standby closing message type 4
[2460]: LOG: could not send data to client: No
On 17/02/10 18:30, David E. Wheeler wrote:
On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
Umm, perhaps F-funcname(@args), or PG-funcname(@args), or ... ?
Anyone got any better suggestions?
PG is good. Or maybe DB?
It's a module whose only use is embedded in a DB called PG - not sure
those
Dne 17.02.10 18:39, Peter Eisentraut napsal(a):
On ons, 2010-02-17 at 11:26 -0500, Tom Lane wrote:
But the behavior gcc appears to exhibit is that it won't warn about
variables that are only assigned once before the PG_TRY is entered,
and that seems reasonable to me since such a variable ought
On Wed, Feb 17, 2010 at 10:30:03AM -0800, David E. Wheeler wrote:
On Feb 17, 2010, at 4:28 AM, Tim Bunce wrote:
Yes, but if it's a variadic function, I suspect that it won't often be
called with the same number of args. So you'd potentially end up
caching a lot of extra stuff that would
2010/2/18 Tom Lane t...@sss.pgh.pa.us:
In connection with the recent discussion of changing SearchSysCache call
format, Robert espoused the view that right now is the time when there
are a minimal number of outstanding patches that would suffer merge
problems from an invasive change. That
Fujii Masao wrote:
Hi,
When the replication connection is closed unexpectedly, walsender might emit
the following unfit messages. IOW, the loss of the connection might be wrongly
regarded as an arrival of invalid message by the walsender. This looks messy.
We should get rid of that unfit
2010/2/18 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Fujii Masao wrote:
Hi,
When the replication connection is closed unexpectedly, walsender might emit
the following unfit messages. IOW, the loss of the connection might be
wrongly
regarded as an arrival of invalid message by
2010/2/18 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Fujii Masao wrote:
On Thu, Feb 18, 2010 at 5:28 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
If I'm reading the patch correctly, when wal_sync_method is 'open_sync',
walreceiver nevertheless opens the WAL
Magnus Hagander wrote:
2010/2/18 Tom Lane t...@sss.pgh.pa.us:
Which leads me to the thought that rather than postponing running
pgindent until late beta, maybe we should run it *now*, and get the
bulk of its work done for the new code in 9.0. Then people would have
a solid base to patch
Magnus Hagander wrote:
O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we are, which is the case here, it
should be really bad for performance, since we actually have to do a
physical read.
Incidentally, that should also apply to general
Magnus Hagander wrote:
This cannot possibly be correct:
+ if (errno == EAGAIN || EWOULDBLOCK || errno == EINTR)
The middle argument is missing the errno== part.
Ahh, rats. Yeah it clearly is. Thanks.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
2010/2/18 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Magnus Hagander wrote:
There are of course people out
there with patches *already* that will have problems with this, but
they'll have the problem eventually anyway. The only real stopper
there is if someone (Simon would be the
Magnus Hagander wrote:
2010/2/18 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
It's worth noting that any patches that bit-rot because of pgindent run
can be fixed with the following procedure:
1. check out the source tree just before pgindent.
2. Apply patch
3. Run pgindent
4.
On Thu, Feb 18, 2010 at 7:05 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
This cannot possibly be correct:
+ if (errno == EAGAIN || EWOULDBLOCK || errno == EINTR)
The middle argument is missing the errno== part.
Ahh, rats.
Tim Bunce tim.bu...@pobox.com writes:
I like F-funcname or FN-funcname myself.
Thanks. I quite like FN.
Anybody else want to express an opinion on the color if this bikeshed
before I repaint it?
I wouldn't have, but since you ask... What about reusing the internal
name, you seem to be
On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we are, which is the case here, it
should be really bad for performance,
Fujii Masao wrote:
* The received byte is stored in *c. Returns 1 if a byte was read, 0 if
! * if no data was available, or EOF if trouble.
Typo. 'if' is repeated.
+ ereport(COMMERROR,
+
2010/2/18 Fujii Masao masao.fu...@gmail.com:
On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we are, which is the case
On Fri, Feb 12, 2010 at 2:29 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
So the only major feature we're missing is the ability to clean up old
files.
I found another missing feature in new file-based log shipping (i.e.,
standby_mode is enabled and 'cp' is used as
On Feb 17, 2010, at 11:34 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Which leads me to the thought that rather than postponing running
pgindent until late beta, maybe we should run it *now*, and get the
bulk of its work done for the new code in 9.0. Then people would have
a solid base to patch
Simon Riggs wrote:
Introduce WAL records to log reuse of btree pages, allowing conflict
resolution during Hot Standby. Page reuse interlock requested by Tom.
Analysis and patch by me.
There's still a theoretical possibility for this to happen:
1. A page is marked as deleted by VACUUM, setting
Magnus Hagander wrote:
2010/2/18 Fujii Masao masao.fu...@gmail.com:
On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Magnus Hagander wrote:
O_DIRECT helps us when we're not going to read the file again, because
we don't waste cache on it. If we
M Z escribió:
Hi Alvaro,
I followed your instruction but put the patch on 8.4.2 as I found it
crashes. It looks like the server still crash in the same way. Can you and
anyone give me some ideas how to fix this bug?
See src/backend/utils/adt/xml.c. Note the comment at the top:
/*
* Notes
Magnus Hagander wrote:
Doesn't that require that all pgindent runs produce the same output?
Which they generally don't due to different sets of typedefs and
stuff? It's a solvable problem of course, but not quite as simple as
you make it sound :-)
The typedef file emitted by the buildfarm is
Tom Lane wrote:
Which leads me to the thought that rather than postponing running
pgindent until late beta, maybe we should run it *now*, and get the
bulk of its work done for the new code in 9.0. Then people would have
a solid base to patch against, rather than having to expect a major
merge
Andrew Dunstan wrote:
Tom Lane wrote:
Which leads me to the thought that rather than postponing running
pgindent until late beta, maybe we should run it *now*, and get the
bulk of its work done for the new code in 9.0. Then people would have
a solid base to patch against, rather than
Alvaro Herrera wrote:
Magnus Hagander wrote:
Doesn't that require that all pgindent runs produce the same output?
Which they generally don't due to different sets of typedefs and
stuff? It's a solvable problem of course, but not quite as simple as
you make it sound :-)
The typedef
On Tue, 16 Feb 2010 15:22:00 +0100, Greg Stark gsst...@mit.edu wrote:
There's a second problem though. We don't actually know how long any
given query is going to take to plan or execute. We could just
remember how long it took to plan and execute last time or how long it
took to plan last time
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes:
Magnus Hagander wrote:
Doesn't that require that all pgindent runs produce the same output?
True. So everyone will have to send their patches to Bruce for bit-rot
fixing ;-)
I think Bruce ought to publish the specific typedef
Andrew Dunstan wrote:
Alvaro Herrera wrote:
Magnus Hagander wrote:
Doesn't that require that all pgindent runs produce the same output?
Which they generally don't due to different sets of typedefs and
stuff? It's a solvable problem of course, but not quite as simple as
you make it
Pierre C li...@peufeu.com writes:
Problem with prepared statements is they're a chore to use in web apps,
especially PHP, since after grabbing a connection from the pool, you don't
know if it has prepared plans in it or not.
Have you met preprepare yet?
I'm reading through the Wiki docs, and one thing isn't clear:
3. Set up connections and authentication so that the standby server can
successfully connect to the pseudo replication database of the primary.
I've searched Google, to see if its mentioned anywhere else, but nadda ...
can't
Alvaro Herrera alvhe...@commandprompt.com writes:
Then if you look at xpath.c in contrib/xml2 you notice that it's doing
exactly the thing that the core module says it's unreliable: using
palloc and friends in xmlMemSetup. So to fix the bug what's needed is
that the xmlMemSetup call in
Tom Lane t...@sss.pgh.pa.us writes:
FWIW, the core xml code seems to have been pretty stable since we gave
up on trying to redirect libxml's memory allocations to palloc.
So what you basically need to do to xpath.c is something like this:
On Thu, 18 Feb 2010 16:09:42 +0100, Dimitri Fontaine
dfonta...@hi-media.com wrote:
Pierre C li...@peufeu.com writes:
Problem with prepared statements is they're a chore to use in web apps,
especially PHP, since after grabbing a connection from the pool, you
don't
know if it has prepared
Pierre C li...@peufeu.com writes:
On Thu, 18 Feb 2010 16:09:42 +0100, Dimitri Fontaine
dfonta...@hi-media.com wrote:
http://preprepare.projects.postgresql.org/README.html
http://packages.debian.org/source/sid/preprepare
Hey, this thing is nice.
Thanks :)
How hard would it be to put a
On Thu, 2010-02-18 at 14:23 +0200, Heikki Linnakangas wrote:
Simon Riggs wrote:
Introduce WAL records to log reuse of btree pages, allowing conflict
resolution during Hot Standby. Page reuse interlock requested by Tom.
Analysis and patch by me.
There's still a theoretical possibility for
On Feb 18, 2010, at 1:35 AM, Tim Bunce wrote:
http://github.com/timbunce/posgtresql-plperl-call
Thanks, forked.
Thanks. I quite like FN.
Anybody else want to express an opinion on the color if this bikeshed
before I repaint it?
I like PG because it lets you know that you're calling a
On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
Joachim Wieland j...@mcknight.de writes:
We could probably fake this on the Hot Standby in the following way:
We introduce a commit record for every notifying transaction and write
it into the queue itself. So right before writing
On 2/18/10 9:58 AM, Simon Riggs wrote:
I thought a bit more about this and don't really understand why we need
an xid at all. When we discussed this before the role of a NOTIFY was to
remind us to refresh a cache, not as a way of delivering a transactional
payload. If the cache refresh use
On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
Joachim Wieland j...@mcknight.de writes:
We could probably fake this on the Hot Standby in the following way:
We introduce a commit record for every notifying
Merlin Moncure mmonc...@gmail.com writes:
On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs si...@2ndquadrant.com wrote:
I thought a bit more about this and don't really understand why we need
an xid at all. When we discussed this before the role of a NOTIFY was to
remind us to refresh a cache,
Simon Riggs si...@2ndquadrant.com writes:
On Thu, 2010-02-18 at 14:23 +0200, Heikki Linnakangas wrote:
A straightforward way to fix that is to WAL-log the real xid in the
XLOG_BTREE_DELETE_PAGE records, instead of resetting it to
FrozenTransactionId.
An even simpler way would be to reset the
What about catching the error in the application and INSERT'ing into the
current preprepare.relation table? The aim would be to do that in dev or
in pre-prod environments, then copy the table content in production.
Yep, but it's a bit awkward and time-consuming, and not quite suited to
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Is the payload decoded to utf8 when pg_enable_utf8 is true?
No - there's a note in the code to look into that at some point. So
stick to ASCII for the moment. I'm sure the great DBD::Pg utf-8
overhaul (where we get rid of the pg_enable_utf8
When accidentally running pg_dump from an 8.4.2 instance into a 9.0devel (cvs
as of 2010.02.17)
slave as below, this causes a PANIC. The slave can be restarted.
localhost:55432 = 8.4.2 instance (ssh tunnel)
/tmp:7575 = a 9.0devel standby
time pg_dump -h localhost -p 55432 -t public.tab_jobs
Folks,
While hacking on PL/Parrot, I ran across an issue where when trying to
load PL/pgsql, it's done unconditionally and fails. How do we fix
pg_regress to be a little more subtle about this?
Cheers,
David.
--
David Fetter da...@fetter.org http://fetter.org/
Phone: +1 415 235 3778 AIM:
On Feb 18, 2010, at 1:01 PM, Greg Sabino Mullane wrote:
Is the payload decoded to utf8 when pg_enable_utf8 is true?
No - there's a note in the code to look into that at some point. So
stick to ASCII for the moment. I'm sure the great DBD::Pg utf-8
overhaul (where we get rid of the
Erik Rijkers wrote:
And to be clear: I realize that one cannot expect a pg_dump at a slave to
work:
Hmm, why not?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-hackers mailing list
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
No - there's a note in the code to look into that at some point. So
stick to ASCII for the moment. I'm sure the great DBD::Pg utf-8
overhaul (where we get rid of the pg_enable_utf8 hack) will encompass
payloads as well.
Is that
On Thu, February 18, 2010 23:08, Alvaro Herrera wrote:
Erik Rijkers wrote:
And to be clear: I realize that one cannot expect a pg_dump at a slave to
work:
Hmm, why not?
Because the slave is readonly.
My case was:
pg_dump $pg8.4.2 | psql $slave
I ran this by accident.
I suppose I
On Thursday 18 February 2010 22:25:35 Erik Rijkers wrote:
When accidentally running pg_dump from an 8.4.2 instance into a 9.0devel
(cvs as of 2010.02.17) slave as below, this causes a PANIC. The slave can
be restarted.
localhost:55432 = 8.4.2 instance (ssh tunnel)
/tmp:7575 = a 9.0devel
Andrew Dunstan and...@dunslane.net writes:
With the following settings
custom_variable_classes = 'auto_explain'
auto_explain.log_min_duration = 0
auto_explain.log_format = 'xml'
auto_explain.log_analyze = on
auto_explain.log_verbose = on
shared_preload_libraries =
David Fetter da...@fetter.org writes:
While hacking on PL/Parrot, I ran across an issue where when trying to
load PL/pgsql, it's done unconditionally and fails. How do we fix
pg_regress to be a little more subtle about this?
Why exactly would we want it to not fail? Regression tests are not
Zdenek Kotala zdenek.kot...@sun.com writes:
Dne 17.02.10 18:39, Peter Eisentraut napsal(a):
FWIW, this is a Sun Studio build that is complaining here.
Yes It is SS12. I add volatile keyword and problem disappears.
OK, I've applied that change in CVS. Please change codlin_moth back to
the
On Feb 18, 2010, at 3:27 PM, Tom Lane wrote:
While hacking on PL/Parrot, I ran across an issue where when trying to
load PL/pgsql, it's done unconditionally and fails. How do we fix
pg_regress to be a little more subtle about this?
Why exactly would we want it to not fail? Regression
On ons, 2010-02-17 at 15:59 -0800, Josh Berkus wrote:
On 2/17/10 3:05 PM, Peter Eisentraut wrote:
On ons, 2010-02-17 at 14:58 -0800, Josh Berkus wrote:
On 2/17/10 2:08 PM, Peter Eisentraut wrote:
FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released
Friday'ish.
Can you get me
Peter Eisentraut wrote:
On ons, 2009-12-30 at 12:55 -0500, Greg Smith wrote:
Basically, configure failed on their OpenBSD system because thread
safety is on but the libxml2 wasn't compiled with threaded support:
http://xmlsoft.org/threads.html
Disabling either feature (no
On Thu, Feb 18, 2010 at 06:27:30PM -0500, Tom Lane wrote:
David Fetter da...@fetter.org writes:
While hacking on PL/Parrot, I ran across an issue where when
trying to load PL/pgsql, it's done unconditionally and fails. How
do we fix pg_regress to be a little more subtle about this?
Why
David Fetter escreveu:
OK, I know it's late, but having PL/pgsql on by default has caused an
unforeseen need: --require-language.
Why? IMHO pg_regress should be used with the same postgres version it was
built with. So any tests that use --load-language=plpgsql should be fixed.
Besides we
On Feb 18, 2010, at 2:19 PM, Pierre C wrote:
What about catching the error in the application and INSERT'ing
into the
current preprepare.relation table? The aim would be to do that in
dev or
in pre-prod environments, then copy the table content in production.
Yep, but it's a bit
On Fri, Feb 19, 2010 at 12:26:29AM -0200, Euler Taveira de Oliveira wrote:
David Fetter escreveu:
OK, I know it's late, but having PL/pgsql on by default has caused
an unforeseen need: --require-language.
Why? IMHO pg_regress should be used with the same postgres version
it was built
Robert Haas wrote:
On Sat, Dec 19, 2009 at 11:01 PM, Robert Haas robertmh...@gmail.com wrote:
On Sat, Dec 19, 2009 at 4:46 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I believe the
On Fri, Feb 19, 2010 at 12:25 AM, Marc G. Fournier scra...@hub.org wrote:
I'm reading through the Wiki docs, and one thing isn't clear:
3. Set up connections and authentication so that the standby server can
successfully connect to the pseudo replication database of the primary.
I've
Fujii Masao wrote:
On Fri, Feb 19, 2010 at 12:25 AM, Marc G. Fournier scra...@hub.org wrote:
I'm reading through the Wiki docs, and one thing isn't clear:
3. Set up connections and authentication so that the standby server can
successfully connect to the pseudo replication database of the
On Fri, Feb 19, 2010 at 12:47 PM, Bruce Momjian br...@momjian.us wrote:
FYI, I have modified the SGML docs to call it a replication
pseudo-database.
Thanks! I also changed the expression on wiki so.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software
My only thought would be to change 'pseudo' to 'virtual' ... my initial
read, I was looking for a system database like template1/template0 being
created ...
Thx ...
On Fri, 19 Feb 2010, Fujii Masao wrote:
On Fri, Feb 19, 2010 at 12:25 AM, Marc G. Fournier scra...@hub.org wrote:
I'm
David Fetter da...@fetter.org wrote:
Any external projects will fail on this if they're attempting to
support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
suggested that we special-case PL/pgsql for 9.0 and greater, as it's
in template0, where those tests are based.
+1 for the
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
David Fetter da...@fetter.org wrote:
support both pre-9.0 and post-9.0 PostgreSQLs. David Wheeler has
suggested that we special-case PL/pgsql for 9.0 and greater, as it's
in template0, where those tests are based.
+1 for the CREATE
Bruce Momjian wrote:
I have a TODO on fixing some of the typedef finding. But I can generate
an up to date version of the list Bruce last used in a day or two, and
then get this better whacked into shape for another run at the more
traditional time.
I am ready to run pgindent
Andres Freund wrote:
Trivial patch attached.
Thanks, committed.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Feb 18, 2010, at 8:38 PM, Tom Lane wrote:
The regression test in the core is targeting only its version,
but some external projects have version-independent tests.
I think it's more like are under the fond illusion that their tests are
version-independent. Are we going to back out the
72 matches
Mail list logo
