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 o
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
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 whene
Takahiro Itagaki writes:
> David Fetter 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 LANGUAGE IF NOT EXISTS behavior.
> The re
David Fetter 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 CREATE LANGUA
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 wrote:
I'm reading through the W
On Fri, Feb 19, 2010 at 12:47 PM, Bruce Momjian 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 Center
--
Se
Fujii Masao wrote:
> On Fri, Feb 19, 2010 at 12:25 AM, Marc G. Fournier 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 prima
On Fri, Feb 19, 2010 at 12:25 AM, Marc G. Fournier 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 searched Google
Robert Haas wrote:
> On Sat, Dec 19, 2009 at 11:01 PM, Robert Haas wrote:
> > On Sat, Dec 19, 2009 at 4:46 PM, Tom Lane wrote:
> >> Robert Haas writes:
> >>> On Sat, Dec 19, 2009 at 3:01 PM, Tom Lane wrote:
> I believe the correct approach is probably to treat values that need to
> be
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 b
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 awkward
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 co
On Thu, Feb 18, 2010 at 06:27:30PM -0500, Tom Lane wrote:
> David Fetter 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
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 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.
> >>
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? Regressi
Zdenek Kotala 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 higher optimization s
David Fetter 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
about papering
Andrew Dunstan 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 = 'auto_explain'
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.0d
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 suppo
-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
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 (pgsql-hac
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 pg
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 http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: d
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 -
-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
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
ORM-g
Simon Riggs 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 value to late
Merlin Moncure writes:
> On Thu, Feb 18, 2010 at 12:58 PM, 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 transa
On Thu, Feb 18, 2010 at 12:58 PM, Simon Riggs wrote:
> On Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
>> Joachim Wieland 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 int
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 Mon, 2010-02-15 at 15:00 -0500, Tom Lane wrote:
> Joachim Wieland 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 anything else, w
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 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 possibi
"Pierre C" writes:
> On Thu, 18 Feb 2010 16:09:42 +0100, Dimitri Fontaine
> 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 hook in pg so that, instead
On Thu, 18 Feb 2010 16:09:42 +0100, Dimitri Fontaine
wrote:
"Pierre C" 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 pre
Tom Lane 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:
> http://archives.postgresql.org/pgsql-committers/2009-05/msg00229.php
Alvaro Herrera 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 contrib is removed altogether
Tom Lane wrote:
> Heikki Linnakangas 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 li
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 con
"Pierre C" 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?
http://preprepare.projects.postgresql.org/README.
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
>
Heikki Linnakangas 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 list he uses for
each run (maybe c
On Tue, 16 Feb 2010 15:22:00 +0100, Greg Stark 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 and the average
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 f
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, r
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
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
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:
/*
* N
Magnus Hagander wrote:
> 2010/2/18 Fujii Masao :
>> On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
>> 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
shoul
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, setti
On Feb 17, 2010, at 11:34 PM, 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 t
On Fri, Feb 12, 2010 at 2:29 AM, Heikki Linnakangas
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 restore_command).
After the trigger file
2010/2/18 Fujii Masao :
> On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
> 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,
> + (errcode_for_sock
On Thu, Feb 18, 2010 at 7:04 PM, Heikki Linnakangas
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, since we actually have to do a
Tim Bunce 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 emulating th
On Thu, Feb 18, 2010 at 7:05 PM, Heikki Linnakangas
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. Yeah it clearly is. Thanks
Magnus Hagander wrote:
> 2010/2/18 Heikki Linnakangas :
>> 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. Diff against source t
2010/2/18 Heikki Linnakangas :
> 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 most likelyi I guess?) has
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
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 ge
Magnus Hagander wrote:
> 2010/2/18 Tom Lane :
>> 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, rathe
2010/2/18 Heikki Linnakangas :
> Fujii Masao wrote:
>> On Thu, Feb 18, 2010 at 5:28 AM, Heikki Linnakangas
>> wrote:
>>> If I'm reading the patch correctly, when wal_sync_method is 'open_sync',
>>> walreceiver nevertheless opens the WAL file without the O_DIRECT flag.
>>> When it later flushes it
2010/2/18 Heikki Linnakangas :
> 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 loo
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 unf
2010/2/18 Tom Lane :
> 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 seems correct to m
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 th
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 t
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
thos
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:
73 matches
Mail list logo
