In the following scenario, we can see orphan comments.
session.1 session.2
----
1: CREATE TYPE my_typ
AS (a int, b text);
2: BEGIN;
3: COMMENT ON TYPE my_typ
IS
better
description than copypaste from FormIndexDatum.
Regards,
---
Takahiro Itagaki
NTT Open Source Software Center
sorted_cluster-20100706.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
I reviewed
your patch. It seems to be in good shape, and worked as
expected. I
suppressed a compiler warning in the patch and cleaned up
whitespaces in it.
Patch attached.
Thanks for the review!
I saw that you also changed the writing:
LogicalTapeWrite(state-tapeset, tapenum,
tuple,
2010/7/6 KaiGai Kohei kai...@ak.jp.nec.com:
In the following scenario, we can see orphan comments.
Yeah. I think the reason we haven't seen any complaints about this
before is that the worst-case scenario is that a comment for a dropped
database object eventually becomes associated with a new
On Mon, Jul 5, 2010 at 3:26 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Jul 5, 2010 at 2:08 PM, Tom Lane t...@sss.pgh.pa.us wrote:
At one time I was hoping to get rid of explicit entries in pg_attribute
for system columns, which would negate this
On Fri, Jun 25, 2010 at 1:56 PM, Josh Berkus j...@agliodbs.com wrote:
Shouldn't this be backpatched, or was this a new bug in 9.0?
We've always output bytes. I'd have noticed the discrepancy myself if I'd
read the actual docs ;-)
KB would be more useful. And I don't think people have
Robert Haas robertmh...@gmail.com writes:
2010/7/6 KaiGai Kohei kai...@ak.jp.nec.com:
In the following scenario, we can see orphan comments.
Yeah. I think the reason we haven't seen any complaints about this
before is that the worst-case scenario is that a comment for a dropped
database
Robert Haas robertmh...@gmail.com writes:
log_temp_files was introduced in 8.3, so we'll need to backpatch this
to 8.3, not just 8.4. Greg Smith tells me Simon has been busy with
other things, so I'm going to pick this up. Barring objections, I'm
going to revert Simon's patch and change the
Robert Haas wrote:
On Fri, Jun 25, 2010 at 1:56 PM, Josh Berkus j...@agliodbs.com wrote:
Shouldn't this be backpatched, or was this a new bug in 9.0?
We've always output bytes. I'd have noticed the discrepancy myself if I'd
read the actual docs ;-)
KB would be more useful. And I
On Tue, Jul 6, 2010 at 10:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
log_temp_files was introduced in 8.3, so we'll need to backpatch this
to 8.3, not just 8.4. Greg Smith tells me Simon has been busy with
other things, so I'm going to pick this up.
Robert Haas wrote:
It doesn't seem very palatable to have multiple handwritten integer
parsers floating around the code base either. Maybe we should try to
standardize something and ship it in src/port, or somesuch
I was considering at one point making two trips through strtol, each
allowed
On Tue, Jul 6, 2010 at 11:01 AM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
It doesn't seem very palatable to have multiple handwritten integer
parsers floating around the code base either. Maybe we should try to
standardize something and ship it in src/port, or somesuch
I
Robert Haas wrote:
I think my least favorite option is changing the behavior only in
HEAD. I think the reasonable options are:
1. Change the behavior in HEAD, 8.4, and 8.3, per previous discussion.
If we do this, we should do what I proposed in my previous email.
2. Change the comments
On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian br...@momjian.us wrote:
Robert Haas wrote:
I think my least favorite option is changing the behavior only in
HEAD. I think the reasonable options are:
1. Change the behavior in HEAD, 8.4, and 8.3, per previous discussion.
If we do this, we
Robert Haas robertmh...@gmail.com writes:
The reason I think it's OK to change the behavior in the back-branches
is that (a) the only thing it affects is logging, so it shouldn't
really break anything, and (b) apparently nobody has noticed that
the interpretation of the GUC is off by three
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian br...@momjian.us wrote:
Anything backpatched risks causing instability, and might discourage
people from performing minor upgrades. Minor fixes are rarely worth the
risk of causing instability in
On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 6, 2010 at 11:03 AM, Bruce Momjian br...@momjian.us wrote:
Anything backpatched risks causing instability, and might discourage
people from performing minor upgrades.
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Changing the unit setting would also be a behavioral change. I think
what Bruce is suggesting is that this is simply not worth worrying about
in the back branches.
It seems pretty
On Tue, Jul 6, 2010 at 11:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
without any field complaints,
I refer you to Simon's original commit message: Bug found during
recent performance tuning for PostgreSQL user.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres
2010/2/10 Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp
Tom Lane t...@sss.pgh.pa.us wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
We have an optimization to bulkload date in pg_restore, but the code
only works in parallel restore (--jobs = 2). Why don't we do the
Hello all.
While I'm very excited about enabling keepalives in libpq, I want to
know how can I use this functionality in my application?
Let's imagine that I connect to a server with keepalives option, other
options (keepalives_idle, keepalives_interval, keepalives_count) are
used either. Then
On Thu, Jun 17, 2010 at 9:34 PM, Takahiro Itagaki
itagaki.takah...@oss.ntt.co.jp wrote:
Jaime Casanova ja...@2ndquadrant.com wrote:
This one, doesn't apply to head anymore... please update
Thank you for reviewing my patch!
I attached an updated patch set for partitioning syntax.
I've taken
On Tue, Jul 6, 2010 at 11:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 6, 2010 at 11:10 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Changing the unit setting would also be a behavioral change. I think
what Bruce is suggesting is that this is
On mån, 2010-07-05 at 11:01 -0400, Tom Lane wrote:
Peter was suggesting that if we *stopped* using RTLD_GLOBAL then it
might be possible to use plpython2 and plpython3 concurrently in one
backend. After looking at the archives I'm not convinced that's
workable --- it sounds like not using
Robert Haas wrote:
On Mon, Jul 5, 2010 at 3:14 PM, Andrew Dunstan and...@dunslane.net wrote:
Andrew Dunstan wrote:
Marc G. Fournier wrote:
- Someone (presumably Bruce) needs to run pgindent. ?Any reason to
wait any longer on that?
The typedefs list on the buildfarm needs to be
Robert Haas wrote:
OK, so I talked to Bruce about this and I guess I've been persuaded
that we should just apply the patch I sent upthread to HEAD and leave
the back-branches broken, for fear of creating an incompatibility.
The only thing that might be appropriate to backport is the docs
Excerpts from Robert Haas's message of mar jul 06 10:08:21 -0400 2010:
Treating OID as a user-defined column seems reasonable, and probably
not even that messy if we put some appropriate macros in place. I'm
guessing the messy part would be finding all the places that expect to
be consulting
On Tue, Jul 6, 2010 at 3:40 PM, Greg Smith g...@2ndquadrant.com wrote:
Robert Haas wrote:
OK, so I talked to Bruce about this and I guess I've been persuaded
that we should just apply the patch I sent upthread to HEAD and leave
the back-branches broken, for fear of creating an
On Tue, Jul 6, 2010 at 2:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of mar jul 06 10:08:21 -0400 2010:
Treating OID as a user-defined column seems reasonable, and probably
not even that messy if we put some appropriate macros in place. I'm
Robert Haas wrote:
On Tue, Jul 6, 2010 at 2:49 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
I'm intending to work on logical column identifiers for 9.1. Perhaps I
could try to have a look at this, too, while at it.
I have a strong suspicion that's going to be a, ahem,
On Fri, Jul 2, 2010 at 5:44 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 29, 2010 at 10:53 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Tue, Jun 29, 2010 at 11:28 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Jun 29, 2010 at 12:42 AM, Tom Lane t...@sss.pgh.pa.us wrote:
On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan and...@dunslane.net wrote:
I have a strong suspicion that's going to be a, ahem, challenging
project. But it would be great to have. Getting rid of the system
column entries from pg_attribute is probably easy by comparison.
It will be a bit
Robert Haas robertmh...@gmail.com writes:
On Tue, Jul 6, 2010 at 5:18 PM, Andrew Dunstan and...@dunslane.net wrote:
Why wouldn't it be feasible?
Just because it might be too much to do all at once.
My thought is that the hardest part of this is going to be making sure
that every column index
I grow weary of mopping up after pgindent, as in
http://archives.postgresql.org/pgsql-committers/2010-07/msg00069.php
The problem evidently is that pgindent hasn't heard of wide character
constants. No doubt the best fix would be to teach it about them;
but given that we seem to have next to no
Robert Haas wrote:
Bruce felt it wasn't worth putting that amount of work into backbranch docs
that nobody's likely to read
anyway, but I suppose that view could be overruled if there's a strong
consensus.
I was never arguing in favor of touching anything in the back branches;
if you
pet...@postgresql.org (Peter Eisentraut) writes:
Log Message:
---
Add note that using PL/Python 2 and 3 in the same session will probably crash
Crash? I can see people regarding that as a security problem. Maybe we
need to do something more pro-active to prevent such conflicts?
On tis, 2010-07-06 at 17:49 -0400, Tom Lane wrote:
pet...@postgresql.org (Peter Eisentraut) writes:
Log Message:
---
Add note that using PL/Python 2 and 3 in the same session will probably
crash
Crash? I can see people regarding that as a security problem. Maybe we
need to
Tom Lane wrote:
I grow weary of mopping up after pgindent, as in
http://archives.postgresql.org/pgsql-committers/2010-07/msg00069.php
The problem evidently is that pgindent hasn't heard of wide character
constants. No doubt the best fix would be to teach it about them;
but given that we seem
On Tue, 2010-07-06 at 17:49 -0400, Tom Lane wrote:
pet...@postgresql.org (Peter Eisentraut) writes:
Log Message:
---
Add note that using PL/Python 2 and 3 in the same session will probably
crash
Crash? I can see people regarding that as a security problem. Maybe we
need to
Peter Eisentraut pete...@gmx.net writes:
On tis, 2010-07-06 at 17:49 -0400, Tom Lane wrote:
Crash? I can see people regarding that as a security problem. Maybe we
need to do something more pro-active to prevent such conflicts?
I don't see how. Loading any module that uses the same symbols
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
I'm dubious that it's worth the trouble. I suggest that it might be
best to replace these usages of L'\0' by plain scalar 0. Does anyone
think that wouldn't work or is too grotty?
or maybe 0x, which I gather from
On Tue, Jul 6, 2010 at 5:49 PM, Greg Smith g...@2ndquadrant.com wrote:
I was never arguing in favor of touching anything in the back branches; if
you recall I didn't even voice an opinion here until I got concerned about
too many changes happening in them. I think a proper fix in 9.0 combined
On Fri, Jun 11, 2010 at 9:14 AM, Fujii Masao masao.fu...@gmail.com wrote:
In 9.0, walsender reads WAL always from the disk and sends it to the standby.
That is, we cannot send WAL until it has been written (and flushed) to the
disk.
This degrades the performance of synchronous replication
(2010/07/06 23:33), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
2010/7/6 KaiGai Koheikai...@ak.jp.nec.com:
In the following scenario, we can see orphan comments.
Yeah. I think the reason we haven't seen any complaints about this
before is that the worst-case scenario is that
2010/7/6 KaiGai Kohei kai...@ak.jp.nec.com:
(2010/07/06 23:33), Tom Lane wrote:
Robert Haasrobertmh...@gmail.com writes:
2010/7/6 KaiGai Koheikai...@ak.jp.nec.com:
In the following scenario, we can see orphan comments.
Yeah. I think the reason we haven't seen any complaints about this
Robert Haas robertmh...@gmail.com writes:
Obviously not. We don't need to acquire an AccessExclusiveLock to
comment on an object - just something that will CONFLICT WITH an
AccessExclusiveLock. So, use the same locking rules, perhaps, but
take a much weaker lock, like AccessShareLock.
Well,
On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Obviously not. We don't need to acquire an AccessExclusiveLock to
comment on an object - just something that will CONFLICT WITH an
AccessExclusiveLock. So, use the same locking
Excerpts from Robert Haas's message of mar jul 06 22:31:40 -0400 2010:
On Tue, Jul 6, 2010 at 10:18 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Obviously not. We don't need to acquire an AccessExclusiveLock to
comment on an object - just something that
Tom Lane t...@sss.pgh.pa.us wrote:
I'm dubious that it's worth the trouble. I suggest that it might be
best to replace these usages of L'\0' by plain scalar 0.
I'd tend to go with just 0,
which is a reasonably common substitute for non-wide '\0' ...
I think all of the following codes
Hi All,
Every identifier is downcase truncated by function
downcase_truncate_identifier()
before using it.
But since the function downcase_truncate_identifier() is not
multibyte-charecter aware,
it is not able to downcase some of special charecters in identifier like
my_SchemÄ.
If schema is
50 matches
Mail list logo
