Hi,
Several couple weeks ago, I posted a mail to pgsql-doc.
http://www.postgresql.org/message-id/53992ff8.2060...@po.ntts.co.jp
In this thread, I concluded that it's better to
round up the value which is less than its unit.
Current behavior (rounding down) has undesirable setting risk,
because
Le mercredi 9 juillet 2014 21:30:05 Tom Lane a écrit :
Michael Paquier michael.paqu...@gmail.com writes:
I guess that this implementation is enough as a first shot, particularly
regarding the complexity that default expression import would bring up for
postgres_fdw (point raised during the
This patch is modified the comment.
Each comment is coping as follows.
Could you update the status of this patch from Waiting on Author to
Needs Review when you post the revised version of the patch?
Thank you for pointing out.
From now on, I will update status when I post the patch.
+
2014-07-10 7:32 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
On Wed, Jul 9, 2014 at 9:44 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Barring any objection, I will commit this patch except tab-completion
part.
Committed.
Thank you very much
It can be a second discussion, but I
Hi Fujita-san,
Sorry for leaving this thread for long time.
2014-06-24 16:30 GMT+09:00 Etsuro Fujita fujita.ets...@lab.ntt.co.jp:
(2014/06/23 18:35), Ashutosh Bapat wrote:
Hi,
Selecting tableoid on parent causes an error, ERROR: cannot extract
system attribute from virtual tuple. The
On 7/10/14 5:44 AM, Amit Kapila wrote:
Basically, I wanted to say that apart from modified columns, we just
need to pass table OID. If I am reading correctly, the same is
mentioned by Heikki as well.
Yes, Heikki was talking about that approach. I was more interested in
the significantly
Hello, The new patch looks good for me.
The usage of this is a bit irregular as a (extension) module but
it is the nature of this 'contrib'. The rearranged page type
detection logic seems neater and keeps to work as intended. This
logic will be changed after the new page type detection scheme
Thank you for taking a look on this patch.
I took a quick look at this patch, more or less because nobody else did.
Duing last CF, I proposed to match long pathkeys against index columns
during creating index paths. This worked fine but also it is difficult
to make sure that all
Hello,
Anyway, I think that making -n option display all the values that -f
option
changes would be useful. But since that's not a bugfix, we should apply it
only in HEAD.
Agreed.
Is this a TODO item?
It's not that. The 'bug' was my wrong guess and I've found that
it is done
Le 9 juil. 2014 20:36, David G Johnston david.g.johns...@gmail.com a
écrit :
csrajmohan wrote
EXPLAIN (format XML) command in PostgreSQL9.3.4 gives the plan chosen
by
the optimizer in XML format. In my program, I have to extract certain
data
about optimizer plan from this XML output. I
Hi,
Found few more bugs in new code:
A:
This got bad:
jeevan@ubuntu:~/pg_master$ ./install/bin/psql postgres
psql (9.5devel)
Type help for help.
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[1]=# \set PROMPT2 '%/[%l]%R%# '
postgres[1]=# select
postgres[2]-# *
postgres[3]-# from
postgres[4]-#
Hello
here is a proposed patch - autocomplete for known psql variable content
Regards
Pavel
2014-07-10 9:50 GMT+02:00 Pavel Stehule pavel.steh...@gmail.com:
2014-07-10 7:32 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
On Wed, Jul 9, 2014 at 9:44 PM, Pavel Stehule
On 07/02/2014 05:08 AM, Torsten Zuehlsdorff wrote:
Hello,
i've tried to setup a FreeBSD 10 machine as buildfarm-member. But it's
an IPv6 only machine and there is no IPv6 for the homepage.
Can anyone add support for IPv6 to it?
I'm looking into this.
cheers
andrew
--
Sent via
On Thu, Jul 10, 2014 at 8:35 PM, Jeevan Chalke
jeevan.cha...@enterprisedb.com wrote:
Hi,
Found few more bugs in new code:
A:
This got bad:
jeevan@ubuntu:~/pg_master$ ./install/bin/psql postgres
psql (9.5devel)
Type help for help.
postgres=# \set PROMPT1 '%/[%l]%R%# '
postgres[1]=#
Hi,
At 1047 line of receivelog.c:CopyStreamPoll(), we set NULL to
timeoutptr variable.
if the value of timeoutprt is set NULL then the process will wait
until can read socket using by select() function as following.
if (timeout_ms 0)
timeoutptr = NULL;
else
{
Hello,
I've finished reviewing the code. I already marked this patch as waiting on
author. I'll be waiting for the revised patch, then proceed to running the
program when the patch seems reasonable.
(12)
Like worker_spi, save and restore errno in signal handlers.
(13)
Remove the
I wrote:
Michael Paquier michael.paqu...@gmail.com writes:
I guess that this implementation is enough as a first shot, particularly
regarding the complexity that default expression import would bring up for
postgres_fdw (point raised during the review, but not really discussed
afterwards).
Ronan Dunklau ronan.dunk...@dalibo.com writes:
Similarly to what we do for the schema, we should also check that the server
in the parsed statement is the one we are importing from.
Hm. The FDW would really have to go out of its way to put the wrong thing
there, so is this worth the trouble?
On Wed, Jul 9, 2014 at 12:09 PM, Bruce Momjian br...@momjian.us wrote:
To me, that sounds vastly more complicated and error-prone than
forcing the TOAST tables to be added in a second pass as Andres
suggested.
But I just work here.
Agreed. I am now thinking we could harness the code that
On Mon, Jul 7, 2014 at 8:35 AM, Sergey Muraviov
sergey.k.murav...@gmail.com wrote:
So what's wrong with the patch?
And what should I change in it for 9.5?
Possibly nothing. The concern was tha it's modifying the output in
cases where the output is not \expanded and/or not wrapped. Now I've
On Wed, Jul 9, 2014 at 2:13 AM, Stephen Frost sfr...@snowman.net wrote:
Robert,
* Robert Haas (robertmh...@gmail.com) wrote:
If you're going to have predicates be table-level and access grants be
table-level, then what's the value in having policies? You could just
do:
ALTER TABLE
In contrib/test_shm_mq/test.c, the 9.4 pgindent run
(0a7832005792fa6dad171f9cadb8d587fe0dd800) did this:
-PG_MODULE_MAGIC;
-PG_FUNCTION_INFO_V1(test_shm_mq);
+PG_MODULE_MAGIC; PG_FUNCTION_INFO_V1(test_shm_mq);
PG_FUNCTION_INFO_V1(test_shm_mq_pipelined);
This is obviously not an improvement. Is
On Wed, Jul 9, 2014 at 6:16 PM, Alvaro Herrera alvhe...@2ndquadrant.com wrote:
Another thing I noticed is that version 8 of the patch blindly believed
the pages_per_range declared in catalogs. This meant that if somebody
did alter index foo set pages_per_range=123 the index would
immediately
On Thu, Jul 10, 2014 at 12:02:50PM -0400, Robert Haas wrote:
In contrib/test_shm_mq/test.c, the 9.4 pgindent run
(0a7832005792fa6dad171f9cadb8d587fe0dd800) did this:
-PG_MODULE_MAGIC;
-PG_FUNCTION_INFO_V1(test_shm_mq);
+PG_MODULE_MAGIC; PG_FUNCTION_INFO_V1(test_shm_mq);
I wrote:
So I propose we invent a couple more import options, say
import_default and import_collate, and make the postgres_fdw
code do the obvious thing with them. import_default should
probably default to false, but I'm about halfway tempted to
say that import_collate should default to true
Claudio Freire wrote:
On Wed, Jul 9, 2014 at 6:16 PM, Alvaro Herrera alvhe...@2ndquadrant.com
wrote:
Another thing I noticed is that version 8 of the patch blindly believed
the pages_per_range declared in catalogs. This meant that if somebody
did alter index foo set pages_per_range=123
It seems psql is missing autocomplete entries for LC_COLLATE and
LC_CTYPE for the CREATE DATABASE command. Attached patch adds that.
I doubt this is important enough to backpatch - thoughts?
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
diff --git
On 9.7.2014 16:07, Robert Haas wrote:
On Tue, Jul 8, 2014 at 5:16 PM, Tomas Vondra t...@fuzzy.cz wrote:
Thinking about this a bit more, do we really need to build the hash
table on the first pass? Why not to do this:
(1) batching
- read the tuples, stuff them into a simple list
-
On Fri, Jun 27, 2014 at 4:10 AM, Dilip kumar dilip.ku...@huawei.com wrote:
On 27 June 2014 02:57, Jeff Wrote,
Based on that, I find most importantly that it doesn't seem to
correctly vacuum tables which have upper case letters in the name,
because it does not quote the table names when they
On Thu, Jul 10, 2014 at 10:46:30AM -0400, Robert Haas wrote:
Agreed. I am now thinking we could harness the code that already exists
to optionally add a TOAST table as part of ALTER TABLE ADD COLUMN. We
would just need an entry point to call it from pg_upgrade, either via an
SQL command
On 07/10/2014 12:20 PM, Alvaro Herrera wrote:
So I guess the only thing left is to issue a NOTICE when said alter
takes place (I don't see that on the patch, but maybe it's there?)
That's not in the patch. I don't think we have an appropriate place to
emit such a notice.
What do you mean by
On 2014-07-10 16:33:40 -0400, Bruce Momjian wrote:
On Thu, Jul 10, 2014 at 10:46:30AM -0400, Robert Haas wrote:
Agreed. I am now thinking we could harness the code that already exists
to optionally add a TOAST table as part of ALTER TABLE ADD COLUMN. We
would just need an entry point
On Thu, Jul 10, 2014 at 3:50 PM, Josh Berkus j...@agliodbs.com wrote:
On 07/10/2014 12:20 PM, Alvaro Herrera wrote:
So I guess the only thing left is to issue a NOTICE when said alter
takes place (I don't see that on the patch, but maybe it's there?)
That's not in the patch. I don't think we
Josh Berkus wrote:
On 07/10/2014 12:20 PM, Alvaro Herrera wrote:
So I guess the only thing left is to issue a NOTICE when said alter
takes place (I don't see that on the patch, but maybe it's there?)
That's not in the patch. I don't think we have an appropriate place to
emit such a
Heikki Linnakangas wrote:
Attached is a new patch. It now keeps the current pg_clog unchanged,
but adds a new pg_csnlog besides it. pg_csnlog is more similar to
pg_subtrans than pg_clog: it's not WAL-logged, is reset at startup,
and segments older than GlobalXmin can be truncated.
This
On 07/10/2014 02:30 PM, Jaime Casanova wrote:
How is this different from ALTER TABLE foo SET (FILLFACTOR=80); or
from ALTER TABLE foo ALTER bar SET STORAGE EXTERNAL; ?
we don't get a notice for these cases either
Good idea. We should also emit notices for those. Well, maybe not for
On 07/10/2014 09:32 PM, Magnus Hagander wrote:
It seems psql is missing autocomplete entries for LC_COLLATE and
LC_CTYPE for the CREATE DATABASE command. Attached patch adds that.
I doubt this is important enough to backpatch - thoughts?
It won't apply to current head, but otherwise I see no
On Thu, Jul 10, 2014 at 11:11:19PM +0200, Andres Freund wrote:
On 2014-07-10 16:33:40 -0400, Bruce Momjian wrote:
On Thu, Jul 10, 2014 at 10:46:30AM -0400, Robert Haas wrote:
Agreed. I am now thinking we could harness the code that already exists
to optionally add a TOAST table as part
On Thu, Jul 10, 2014 at 2:30 PM, Jaime Casanova ja...@2ndquadrant.com
wrote:
On Thu, Jul 10, 2014 at 3:50 PM, Josh Berkus j...@agliodbs.com wrote:
On 07/10/2014 12:20 PM, Alvaro Herrera wrote:
So I guess the only thing left is to issue a NOTICE when said alter
takes place (I don't see
On Thu, Jul 10, 2014 at 10:29 PM, Alvaro Herrera
alvhe...@2ndquadrant.com wrote:
What I think should happen is that if the value is changed, the index
sholud be rebuilt right there.
I disagree. It would be a non-orthogonal interface if ALTER TABLE
sometimes causes the index to be rebuilt and
On Thu, Jul 10, 2014 at 06:17:14PM -0400, Bruce Momjian wrote:
Well, we are going to need to call internal C functions, often bypassing
their typical call sites and the assumption about locking, etc. Perhaps
this could be done from a plpgsql function. We could add and drop a
dummy column to
On Thu, Jul 10, 2014 at 08:32:01PM +0100, Magnus Hagander wrote:
It seems psql is missing autocomplete entries for LC_COLLATE and
LC_CTYPE for the CREATE DATABASE command. Attached patch adds that.
I doubt this is important enough to backpatch - thoughts?
I don't see how it could hurt to fix
On Fri, Jul 11, 2014 at 4:06 AM, Tom Lane t...@sss.pgh.pa.us wrote:
I wrote:
So I propose we invent a couple more import options, say
import_default and import_collate, and make the postgres_fdw
code do the obvious thing with them. import_default should
probably default to false, but
David Rowley dgrowle...@gmail.com writes:
Attached is the updated version of the patch.
I spent some time fooling with this patch, cleaning up the join-alias
issue as well as more-cosmetic things. However, while testing it
I realized that the whole thing is based on a false premise: to equate
a
I wrote:
We could no doubt fix this by also insisting that the left-side vars
be provably not null, but that's going to make the patch even slower
and even less often applicable. I'm feeling discouraged about whether
this is worth doing in this form.
Hm ... actually, there might be a better
hi, all
NOTE: fedora 17 x86_64, 7.2.2 can not be compiled in the env, I choose
8.4.0 because I think old version is easier to understand than newer
version!
I want to study pg's external sort (in tuplesort.c )through 8.4.0's source
code, and use ddd to do it, according to usingddd-postgres
On Fri, Jul 11, 2014 at 10:50 AM, 土卜皿 pengcz.n...@gmail.com wrote:
NOTE: fedora 17 x86_64, 7.2.2 can not be compiled in the env, I choose 8.4.0
because I think old version is easier to understand than newer version!
Are you aware that Postgres 7.2 has been released in 2002? It is EOL
hi,
thanks a lot!
2014-07-11 10:10 GMT+08:00 Michael Paquier michael.paqu...@gmail.com:
On Fri, Jul 11, 2014 at 10:50 AM, 土卜皿 pengcz.n...@gmail.com wrote:
NOTE: fedora 17 x86_64, 7.2.2 can not be compiled in the env, I choose
8.4.0
because I think old version is easier to understand
=?UTF-8?B?5Zyf5Y2c55q/?= pengcz.n...@gmail.com writes:
I am sorry, maybe I should make my question clearer, I only want to know,
in 8.4.0 or newer version,
whether I can debug posgres in the bare backend mode (in usingddd-postgres
http://www-inst.eecs.berkeley.edu/~cs186/fa04/usingddd.pdf,
hi, tom
thank you very much! this is what I wanted!
Dillon
2014-07-11 10:59 GMT+08:00 Tom Lane t...@sss.pgh.pa.us:
=?UTF-8?B?5Zyf5Y2c55q/?= pengcz.n...@gmail.com writes:
I am sorry, maybe I should make my question clearer, I only want to know,
in 8.4.0 or newer version,
whether I can
On Thu, Jul 10, 2014 at 06:38:26PM -0400, Bruce Momjian wrote:
On Thu, Jul 10, 2014 at 06:17:14PM -0400, Bruce Momjian wrote:
Well, we are going to need to call internal C functions, often bypassing
their typical call sites and the assumption about locking, etc. Perhaps
this could be done
Attached is a small patch to $SUBJECT.
In master, only single-byte characters are allowed as an escape. Of
course, with the patch it must still be a single character, but it may
be multi-byte.
Regards,
Jeff Davis
*** a/src/backend/utils/adt/regexp.c
--- b/src/backend/utils/adt/regexp.c
Bruce Momjian wrote:
On Thu, Jul 10, 2014 at 06:38:26PM -0400, Bruce Momjian wrote:
I have thought some more on this. I thought I would need to open
pg_class in C and do complex backend stuff, but I now realize I can do
it from libpq, and just call ALTER TABLE and I think that always
On Fri, Jul 11, 2014 at 12:49 PM, Jeff Davis pg...@j-davis.com wrote:
Attached is a small patch to $SUBJECT.
In master, only single-byte characters are allowed as an escape. Of
course, with the patch it must still be a single character, but it may
be multi-byte.
+1
Probably you know that,
54 matches
Mail list logo
