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 in XLogWalRcvFlush() by issue_xlog_fsy
Peter Eisentraut writes:
> 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 release notes RSN so that I can edit them?
> I don't have any r
On Mon, Jan 18, 2010 at 2:19 PM, Fujii Masao wrote:
> When I configured a cascaded standby (i.e, made the additional
> standby server connect to the standby), I got the following
> errors, and a cascaded standby didn't start replication.
>
> ERROR: timeline 0 of the primary does not match recove
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 FATAL message, emit a COMMER
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 me --- although
ideally everyo
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?
==
conifer=# CREATE TABLE xpath_test (id integer NOT NULL, t xml);
Bruce Momjian writes:
> I assumed people would want to do listen/notify on the slave only, or is
> there no good use for that? I don't see passing notify information from
> the master to the slave as useful.
You apparently haven't been reading the thread where we were discussing
the listen/notif
Takahiro Itagaki wrote:
>
> Bruce Momjian wrote:
>
> > Summary: ALTER TABLE SET NOT NULL on a parent table is passed to the
> > child, while ALTER TABLE ADD PRIMARY KEY is not, particularly the NOT
> > NULL part of the PRIMARY KEY specification.
> >
> > That does seem like something that shoul
James William Pye wrote:
> Need a special case for the infinities as well?
>
> postgres=# create table foo (d date);
> postgres=# INSERT INTO foo VALUES ('infinity');
> postgres=# COPY foo TO '/Users/jwp/foo.copy' WITH BINARY;
> postgres=# COPY foo FROM '/Users/jwp/foo.copy' WITH BINARY;
> ERRO
Tom Lane wrote:
> Greg Smith writes:
> > What's the actual reason for the restriction then?
>
> Well, NOTIFY doesn't seem very sensible for a read-only slave to
> execute: it can't change the database state so there's nothing for
> it to notify about. Ideally we should allow slave sessions to LI
Greg Smith writes:
> What's the actual reason for the restriction then?
Well, NOTIFY doesn't seem very sensible for a read-only slave to
execute: it can't change the database state so there's nothing for
it to notify about. Ideally we should allow slave sessions to LISTEN
to notify events that w
I wrote:
> If you're lost about the point here, it's this: an ArrayExpr can
> represent the result of an array assignment. For example, given
> UPDATE foo SET a[42] = x, what is generated is an ArrayExpr
> with refexpr = a, refupperindexpr = 42, refassgnexpr = x.
> On execution that generates the
Greg Smith wrote:
> Bruce Momjian wrote:
> > Oops, I did cleanup on the HS docs all day today in response to a doc
> > patch that was posted in December. How extensive are your changes?
> >
>
> Not very--wording improvements, typos, some technical clarification
> after quizzing Simon on inter
I wrote:
> Andrew Dunstan writes:
>> I am getting regression failures on the rowtypes, transactions and
>> arrays tests. Diff file is attached. I'm going to look into it, but if
>> anyone has a good idea what's going on please speak up ASAP.
> And as for the transactions-test failures, a stack
Bruce Momjian wrote:
Oops, I did cleanup on the HS docs all day today in response to a doc
patch that was posted in December. How extensive are your changes?
Not very--wording improvements, typos, some technical clarification
after quizzing Simon on internals that were described in a fuzzy
Greg Smith wrote:
> Tom Lane wrote:
> > Bruce Momjian writes:
> >
> >> Our documentation says listen/notify will return an error if executed on
> >> the hot standby server:
> >>
> >>o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables
> >>
> >> With the listen/n
Greg Smith wrote:
Tom Lane wrote:
The explanation is wrong, but it's still disallowed.
What's the actual reason for the restriction then? I did a whole
proofreading round on the HS documentation the other day and am
working on a patch to clean up everything I found, can add better
notes a
Tom Lane wrote:
Bruce Momjian writes:
Our documentation says listen/notify will return an error if executed on
the hot standby server:
o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables
With the listen/notify system now implemented in memory, is this still
tr
Tom Lane wrote:
I wrote:
Robert Haas writes:
* Fix large object support in pg_dump. I think this is just waiting
for a second opinion on whether the approach is correct. I've been
meaning to look at it, but haven't gotten enough round tuits; maybe
someone else would like to take a
The attached patch is modified to be applied to the latest tree,
and it increments the version number of the archive file.
kai...@saba pg_dump]$ ./pg_dump -Ft postgres > ~/hoge.tar
[kai...@saba pg_dump]$ /usr/bin/pg_restore --version
pg_restore (PostgreSQL) 8.4.2
[kai...@saba pg_dump]$ /u
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 in XLogWalRcvFlush() by issue_xlog_fsync(),
> issue_xlog_fsync()
I wrote:
> Robert Haas writes:
>> * Fix large object support in pg_dump. I think this is just waiting
>> for a second opinion on whether the approach is correct. I've been
>> meaning to look at it, but haven't gotten enough round tuits; maybe
>> someone else would like to take a look? This is a
LinkedIn
I'd like to add you to my professional network on LinkedIn.
- Michael Clemmons
Confirm that you know Michael Clemmons
https://www.linkedin.com/e/isd/1082803003/uR15HoO8/
--
(c) 2010, LinkedIn Corporation
Tom Lane wrote:
> Bruce Momjian writes:
> > Our documentation says listen/notify will return an error if executed on
> > the hot standby server:
>
> > o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables
>
> > With the listen/notify system now implemented in memory, is thi
Faouzi Semlali wrote:
> Hi
>
> First of all, my apologies if this is not where the email should directed to.
> Please ignore if that's the case or redirect me to the apporiate person.
>
> Our product support INFORMIX for the moment and I have been assigned to look
> into migrating it to an Open
Bruce Momjian writes:
> Our documentation says listen/notify will return an error if executed on
> the hot standby server:
> o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables
> With the listen/notify system now implemented in memory, is this still
> true?
The explana
Hi
First of all, my apologies if this is not where the email should directed to.
Please ignore if that's the case or redirect me to the apporiate person.
Our product support INFORMIX for the moment and I have been assigned to look
into migrating it to an Open Source Database. My team's choice n
(2010/02/18 4:54), Tom Lane wrote:
> I've been looking at the proposed patch for pg_dump with large objects,
> and I'm afraid it breaks things even worse than they're broken in HEAD.
>
> Currently, when pg_restore is processing a BLOBS item, it emits
> lo_create() followed by lo_write() calls, and
Michael Meskes wrote:
On Tue, Feb 16, 2010 at 09:44:26AM +1000, Rob Newton wrote:
Is there some way of building with Pg v8.0 ECPG lib and running on a
system with Pg v8.4 ECPG lib? or vice versa? and is libecpg_compat
intended for that purpose?
You can link the static library in so you're i
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 release notes RSN so that I can edit them?
>
> I
Our documentation says listen/notify will return an error if executed on
the hot standby server:
o LISTEN, UNLISTEN, NOTIFY since they currently write to system tables
With the listen/notify system now implemented in memory, is this still
true?
--
Bruce Momjian http://momjia
Boszormenyi Zoltan wrote:
Rob Newton írta:
Is there some way of building with Pg v8.0 ECPG lib and running on a
system with Pg v8.4 ECPG lib? or vice versa? and is libecpg_compat
intended for that purpose?
You can build the src/interfaces/libpq and src/interfaces/e
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 release notes RSN so that I can edit them?
I don't have any release notes yet. Feel free to p
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 release notes RSN so that I can edit them?
--Josh Berkus
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
Peter Eisentraut wrote:
> FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released
> Friday'ish.
No much time for a translation update I guess ...
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgs
FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released
Friday'ish.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
[snip]
Probably the only way we can make this design work is to bump the
archive version number so that older pg_restores will fail. (Whereupon
there is no need to rename the entry type BTW.) This is slightly
annoying but it's not like we've not done it multiple times before.
On Feb 17, 2010, at 10:04 AM, Greg Sabino Mullane wrote:
> while (my $notify = $dbh->pg_notifies) {
> my ($name, $pid, $payload) = @$notify;
> print qq{I received notice "$name" from PID $pid, payload was "$payload"\n};
>
> }
>
> Not sure what you mean by adapting interfaces t
Fujii Masao wrote:
> On Wed, Feb 17, 2010 at 6:00 PM, Fujii Masao wrote:
>> On Wed, Feb 17, 2010 at 4:07 PM, Fujii Masao wrote:
>>> On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander
>>> wrote:
In that case, O_DIRECT would be counterproductive, no? It maps to
FILE_FLAG_NOI_BUFFERING, wh
Robert Haas writes:
> According to
> http://www.postgresql.org/docs/current/interactive/plpgsql-porting.html
> there are no default parameters in PostgreSQL, but according to
> http://www.postgresql.org/docs/current/interactive/sql-createfunction.html
> there are.
> It looks like this was fixed
I've been looking at the proposed patch for pg_dump with large objects,
and I'm afraid it breaks things even worse than they're broken in HEAD.
Currently, when pg_restore is processing a BLOBS item, it emits
lo_create() followed by lo_write() calls, and conditionally precedes
that by lo_unlink() i
According to
http://www.postgresql.org/docs/current/interactive/plpgsql-porting.html
there are no default parameters in PostgreSQL, but according to
http://www.postgresql.org/docs/current/interactive/sql-createfunction.html
there are.
It looks like this was fixed in CVS HEAD at some point (maybe
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 never be used again.
>
> Potentially. Patches welcome!
GitHub. ;-
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> With the new listen/notify implementation we can send a payload along
> with the notification. This has been in the protocol already since
> years and there is no change needed for libpq. However we need to
> adapt the various interfaces to al
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 to have
> the correct value either way.
FWIW
Takahiro Itagaki writes:
> I'd like to apply the patch to HEAD and previous releases because
> the issue seems to be a bug in the core. Any comments or objections?
The proposed patch seems quite ugly to me; not only the messy coding,
but the fact that it might return either the segment containing
Peter Eisentraut writes:
> On ons, 2010-02-17 at 11:05 -0500, Tom Lane wrote:
>> Since oldcontext is only set in the one place, it really shouldn't
>> require "volatile" decoration, but maybe it does.
> It is my understanding that local automatic variables may be clobbered
> by [sig]longjmp unles
On ons, 2010-02-17 at 11:05 -0500, Tom Lane wrote:
> All of the MemoryContextSwitchTo calls in plpython seem to be in
> patterns like this:
>
> MemoryContext oldcontext;
>
> oldcontext = CurrentMemoryContext;
> PG_TRY();
> {
> ... do something ...
> }
> PG_CATCH();
Zdenek Kotala writes:
> I revived codlin_month and it falls during PL/Python test:
> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=codlin_moth&dt=2010-02-16%2015:09:05
All of the MemoryContextSwitchTo calls in plpython seem to be in
patterns like this:
MemoryContext oldcontext;
oldc
Joachim Wieland writes:
> While I can see a lot of improvements over my version, I think the
> logic in asyncQueueProcessPageEntries() needs to be reordered:
Hmmm ... I was intending to cover the case of a failure in
TransactionIdDidCommit too, but I can see it will take a bit more
thought.
Tim Bunce wrote:
Did this ever get turned into a formal bug report with a number?
No, and nobody seemed to care much about the poroblem :-( Maybe I will
get a chance to do something about it during the next few weeks,
although I am currently busier than a one legged man in a butt-kicking
Did this ever get turned into a formal bug report with a number?
Tim.
On Thu, Jan 14, 2010 at 07:39:09PM -0500, Andrew Dunstan wrote:
>
> Tim Bunce just showed me the following oddity:
>
>andrew=# SET SESSION plperl.use_strict = on;
>SET
>andrew=# SHOW plperl.use_strict;
> plper
On Tue, Feb 16, 2010 at 02:13:30PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:06 PM, Tim Bunce wrote:
>
> >>> For varadic functions, separate plans are created and cached for each
> >>> distinct
> >>> number of arguments the function is called with.
> >>
> >> Why?
> >
> > It keeps t
On Wed, Feb 17, 2010 at 6:39 AM, Tom Lane wrote:
>> * Faster CREATE DATABASE by delaying fsync. This is really two
>> patches now, one of which is apparently to be backpatched.
>
> This one (both parts) seems to have crashed and burned on unexpected
> portability issues :-(. Do we have any expec
On Tue, Feb 16, 2010 at 05:22:27PM -0500, Robert Haas wrote:
> > It's certainly been an interesting introduction to PostgreSQL
> > development!
>
> Hopefully we haven't scared you off - your work is definitely very
> much appreciated (and I at least hope to see you back for 9.1)!
Thanks Robert. T
On Wednesday 17 February 2010 07:39:16 Tom Lane wrote:
> Robert Haas writes:
> > * Fix large object support in pg_dump. I think this is just waiting
> > for a second opinion on whether the approach is correct. I've been
> > meaning to look at it, but haven't gotten enough round tuits; maybe
> >
On Tue, Feb 16, 2010 at 02:25:00PM -0800, David E. Wheeler wrote:
> On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote:
>
> > p.s. One quick heads-up: David Wheeler has reported a possible issue
> > with Safe 2.21. I hope to investigate that tomorrow.
>
> Actually it's 2.22. 2.21 is already dead.
Oops
Boszormenyi Zoltan írta:
> Michael Meskes írta:
>
>> On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote:
>>
>>
>>> I was trying to stress the *beta* status. Maybe someone into NetBSD might
>>> be
>>> interested in reporting this as a bug. At least it behaves different to al
On Wed, Feb 17, 2010 at 6:00 PM, Fujii Masao wrote:
> On Wed, Feb 17, 2010 at 4:07 PM, Fujii Masao wrote:
>> On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander wrote:
>>> In that case, O_DIRECT would be counterproductive, no? It maps to
>>> FILE_FLAG_NOI_BUFFERING, which makes sure it doesn't go i
On Tue, Feb 16, 2010 at 11:41 PM, Tom Lane wrote:
> Joachim Wieland writes:
>> [ listen/notify patch ]
>
> I found a number of implementation problems having to do with wraparound
> behavior and error recovery. I think they're all fixed, but any
> remaining bugs are probably my fault not yours.
I revived codlin_month and it falls during PL/Python test:
http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=codlin_moth&dt=2010-02-16%2015:09:05
TRAP: BadArgument("!(((context) != 0 && (Node*)((context)))->type)
== T_AllocSetContext", File: "mcxt.c", Line: 641)
feaf5005 _lwp_kill
Michael Meskes írta:
> On Tue, Feb 16, 2010 at 10:28:00PM +0100, Michael Meskes wrote:
>
>> I was trying to stress the *beta* status. Maybe someone into NetBSD might be
>> interested in reporting this as a bug. At least it behaves different to all
>> other archs we have.
>>
>
> Hmm, it se
On Wed, Feb 17, 2010 at 4:07 PM, Fujii Masao wrote:
> On Wed, Feb 17, 2010 at 3:03 PM, Magnus Hagander wrote:
>> In that case, O_DIRECT would be counterproductive, no? It maps to
>> FILE_FLAG_NOI_BUFFERING, which makes sure it doesn't go into the
>> cache. So the read in the startup proc is actua
I'd like to apply the patch to HEAD and previous releases because
the issue seems to be a bug in the core. Any comments or objections?
Some users actually use STOP WAL LOCATION in their backup script,
and they've countered the bug with 1/256 probability in recent days.
Fujii Masao wrote:
> On
This one is for the maintainers of the various postgresql interfaces:
With the new listen/notify implementation we can send a payload along
with the notification. This has been in the protocol already since
years and there is no change needed for libpq. However we need to
adapt the various interfa
Bruce Momjian wrote:
> Summary: ALTER TABLE SET NOT NULL on a parent table is passed to the
> child, while ALTER TABLE ADD PRIMARY KEY is not, particularly the NOT
> NULL part of the PRIMARY KEY specification.
>
> That does seem like something that should be fixed.
Yeah, the issue is in our T
66 matches
Mail list logo
