On 2015/12/02 1:53, Robert Haas wrote:
On Fri, Nov 27, 2015 at 1:33 AM, Etsuro Fujita
wrote: Plan *plan =
&node->scan.plan;
@@ -3755,7 +3763,7 @@ make_foreignscan(List *qptlist,
/* cost will be filled in by create_foreignscan_plan */
plan->targetlist = qptlist;
On 2015/12/02 14:54, Kouhei Kaigai wrote:
On 2015/12/02 1:41, Robert Haas wrote:
On Thu, Nov 26, 2015 at 7:59 AM, Etsuro Fujita
wrote:
The attached patch adds: Path *fdw_outerpath field to ForeignPath node.
FDW driver can set arbitrary but one path-node here.
After that, this path-node shall b
Michael Paquier wrote:
> So, looking at this thread, here is the current status:
> - Tom Lane: -1
> - Michael Paquier: -1
> - Peter Geoghegan: +1?
> - Peter Eisentraut: +1
> - the author: surely +1.
> Any other opinions? Feel free to correct this list if needed, and then
> let's try to mov
On Wed, Dec 2, 2015 at 12:06 PM, Michael Paquier
wrote:
>
> On Sun, Nov 22, 2015 at 3:25 PM, Amit Kapila
wrote:
> > On Fri, Nov 20, 2015 at 11:34 PM, Robert Haas
wrote:
> >>
> >> On Thu, Nov 19, 2015 at 11:59 PM, Amit Kapila
> >> wrote:
> >> > Isn't it better to destroy the memory for readers a
> On Thu, Nov 26, 2015 at 5:27 AM, Kouhei Kaigai wrote:
> > I'm now implementing. The above design perfectly works on ForeignScan.
> > On the other hands, I'd like to have deeper consideration for CustomScan.
> >
> > My recent patch adds LibraryName and SymbolName on CustomScanMethods
> > to looku
On Tue, Dec 1, 2015 at 9:55 PM, Bruce Momjian wrote:
> On Tue, Dec 1, 2015 at 06:40:09PM -0300, Alvaro Herrera wrote:
>> Bruce Momjian wrote:
>>
>> > Do we still have licensing issues if we ship Postgres and OpenSSL
>> > together?
>>
>> See
>> https://www.postgresql.org/message-id/20150801151410.
Currently find_inheritance_children() is smart enough to skip a child
table that it finds has been dropped concurrently after it gets a lock on
the same. It does so by looking up the child relid in syscache. It seems
it should also check if the table is still in the list of children of the
parent.
On 2015-12-02 08:52:20 +, Kouhei Kaigai wrote:
> diff --git a/src/backend/nodes/copyfuncs.c b/src/backend/nodes/copyfuncs.c
> index 26264cb..c4bb76e 100644
> --- a/src/backend/nodes/copyfuncs.c
> +++ b/src/backend/nodes/copyfuncs.c
> @@ -635,8 +635,12 @@ _copyWorkTableScan(const WorkTableScan *
On Tue, Dec 1, 2015 at 7:00 PM, Tom Lane wrote:
> "Shulgin, Oleksandr" writes:
> > This post summarizes a few weeks of research of ANALYZE statistics
> > distribution on one of our bigger production databases with some
> real-world
> > data and proposes a patch to rectify some of the oddities ob
On 2015/12/02 1:54, Robert Haas wrote:
On Fri, Nov 27, 2015 at 1:25 AM, Kouhei Kaigai wrote:
Sorry, I don't understand this. In my understanding, fdw_recheck_quals
can be defined for a foreign join, regardless of the join type,
Yes, "can be defined", but will not be workable if either side
Hi,
I can't really do huge review considering I wrote half of the code, but
I have couple of things I noticed.
First, I wonder if it would be useful to mention somewhere, even if it's
only here in the mailing list how can the protocol be extended in
non-breaking way in future for transaction
On Mon, Nov 30, 2015 at 8:43 PM, Tom Lane wrote:
> * Finish multixact truncation rework
>
> We're not seriously going to push something this large into 9.5 at this
> point, are we?
I don't know all the details here, so my apologies if any of this is
incorrect/stupid/misinformed.
Given all the qu
On 2015-12-02 12:14:42 +0100, Joel Jacobson wrote:
> On Mon, Nov 30, 2015 at 8:43 PM, Tom Lane wrote:
> > * Finish multixact truncation rework
> >
> > We're not seriously going to push something this large into 9.5 at this
> > point, are we?
>
> I don't know all the details here, so my apologies
On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote:
> The significant changes are in 9.5.
Will multixact truncations be WAL logged in 9.5?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hack
On 2015-12-02 12:25:37 +0100, Joel Jacobson wrote:
> On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote:
> > The significant changes are in 9.5.
>
> Will multixact truncations be WAL logged in 9.5?
Yes.
C.f. the release notes:
* Rework truncation of the multixact commit log to be properly WAL
On Wed, Dec 2, 2015 at 12:36 PM, Andres Freund wrote:
>
> On 2015-12-02 12:25:37 +0100, Joel Jacobson wrote:
> > On Wed, Dec 2, 2015 at 12:19 PM, Andres Freund wrote:
> > > The significant changes are in 9.5.
> >
> > Will multixact truncations be WAL logged in 9.5?
>
> Yes.
>
> C.f. the release n
Thanks Ashutosh.
Re-reviewed and Re-verified the patch, pg_sort_all_pd_v5.patch
looks good to me.
On Fri, Nov 27, 2015 at 3:02 PM, Ashutosh Bapat <
ashutosh.ba...@enterprisedb.com> wrote:
> Thanks Rushabh for your review and comments.
>
> On Thu, Nov 26, 2015 at 5:39 PM, Rushabh Lathia
> wrote
On Wed, Dec 2, 2015 at 5:45 PM, Amit Kapila wrote:
> I am fine with it. I think the further optimizations can be done
> separately.
Done.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/p
On Wed, Dec 2, 2015 at 08:53:07AM +, Dave Page wrote:
> On Tue, Dec 1, 2015 at 9:55 PM, Bruce Momjian wrote:
> > On Tue, Dec 1, 2015 at 06:40:09PM -0300, Alvaro Herrera wrote:
> >> Bruce Momjian wrote:
> >>
> >> > Do we still have licensing issues if we ship Postgres and OpenSSL
> >> > toget
On Wed, Dec 2, 2015 at 1:06 PM, Bruce Momjian wrote:
> On Wed, Dec 2, 2015 at 08:53:07AM +, Dave Page wrote:
>> On Tue, Dec 1, 2015 at 9:55 PM, Bruce Momjian wrote:
>> > On Tue, Dec 1, 2015 at 06:40:09PM -0300, Alvaro Herrera wrote:
>> >> Bruce Momjian wrote:
>> >>
>> >> > Do we still have
On Mon, Nov 30, 2015 at 4:55 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
>> Well, it's December nearly, and we don't seem to be making much progress
>> towards pushing out 9.5.0. I see the following items on
>> https://wiki.postgresql.org/wiki/PostgreSQL_9.5_Open_Items
>>
>>
On Fri, Nov 27, 2015 at 9:28 PM, Peter Geoghegan wrote:
> It looks like commit 3bd909b22 did not place GatherPath within
> print_path(), preventing complete information for Gather paths from
> appearing when OPTIMIZER_DEBUG is in use.
Thanks, committed. Sorry I missed that.
--
Robert Haas
Ente
On Wed, Dec 2, 2015 at 7:45 AM, Kyotaro HORIGUCHI <
horiguchi.kyot...@lab.ntt.co.jp> wrote:
>
> Thank you for picking this up.
>
> At Tue, 1 Dec 2015 20:33:02 +0530, Amit Kapila
wrote in
> > On Mon, Nov 30, 2015 at 6:17 PM, Kyotaro HORIGUCHI <
> > horiguchi.kyot...@lab.ntt.co.jp> wrote:
> > > ===
On Tue, Dec 01, 2015 at 05:07:15PM -0500, Robert Haas wrote:
> I think it's weird to back a commit out only to put a bunch of very similar
> stuff back in.
I agree with that. If the original patches and their replacements shared 95%
of diff lines in common, we wouldn't be having this conversation
On Fri, Nov 27, 2015 at 2:32 AM, Amit Kapila wrote:
> Okay, as discussed I have handled the case of sub-transactions without
> additional shmem in the attached patch. Apart from that, I have tried
> to apply this optimization for Prepared transactions as well, but as
> the dummy proc used for suc
On 2015-12-02 09:57:19 -0500, Noah Misch wrote:
> On Tue, Dec 01, 2015 at 05:07:15PM -0500, Robert Haas wrote:
> > I think it's weird to back a commit out only to put a bunch of very similar
> > stuff back in.
>
> I agree with that. If the original patches and their replacements shared 95%
> of di
I just noticed that parse_psql_options() ignores the result of setQFout(),
meaning that if the argument of a -o command line option is bogus, we'll
ignore the switch entirely after printing an error report. For example
$ psql -o /dev/foo -c 'select 1'
/dev/foo: Permission denied
?column?
--
On 12/02/2015 05:27 AM, Robert Haas wrote:
On Mon, Nov 30, 2015 at 4:55 PM, Stephen Frost wrote:
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Well, it's December nearly, and we don't seem to be making much progress
towards pushing out 9.5.0. I see the following items on
https://wiki.postgresql.org/
On 2015-12-02 08:25:13 -0800, Joshua D. Drake wrote:
> A feature does not exist without documentation.
Uh, you do realize there's actually documentation about RLS? The issues
mentioned here are some small adjustments, not entirely new docs.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On 12/02/2015 08:39 AM, Andres Freund wrote:
On 2015-12-02 08:25:13 -0800, Joshua D. Drake wrote:
A feature does not exist without documentation.
Uh, you do realize there's actually documentation about RLS? The issues
mentioned here are some small adjustments, not entirely new docs.
No I did
I wrote:
> I just noticed that parse_psql_options() ignores the result of setQFout(),
> meaning that if the argument of a -o command line option is bogus, we'll
> ignore the switch entirely after printing an error report.
There's more silliness in the same area. \o with an invalid target spec
is
On Fri, Nov 27, 2015 at 8:54 PM, Tatsuo Ishii wrote:
> I explain why the manual editing is necessary.
>
> One of the most famous problems with Unicode is "wave dash"
> (U+301C). According the Unicode consortium's Unicode/SJIS map, it
> corresponds to 0x8160 of Shift_JIS. Unfortunately this was a m
On Sun, Nov 29, 2015 at 4:02 PM, Peter Geoghegan wrote:
> The C collation is treated exactly the same as other collations when
> considering whether the generation of abbreviated keys for text should
> continue. This doesn't make much sense. With text, the big cost that
> we are concerned about go
Robert Haas writes:
> On Fri, Nov 27, 2015 at 8:54 PM, Tatsuo Ishii wrote:
>> In short, there are number of reasons we cannot simply import the
>> consortium's mapping regarding SJIS (and EUC_JP).
> I haven't seen a response to this point, but it seems important.
I'll defer to Tatsuo-san concer
On Mon, Nov 30, 2015 at 11:20 AM, Konstantin Knizhnik
wrote:
> We have implemented ACID multimaster based on logical replication and our
> DTM (distributed transaction manager) plugin.
> Good news is that it works and no inconsistency is detected.
> But unfortunately it is very very slow...
>
> At
On Sat, Nov 28, 2015 at 7:05 PM, Peter Geoghegan wrote:
> On Sat, Nov 28, 2015 at 2:04 PM, Jeff Janes wrote:
>> For me very large sorts (100,000,000 ints) with work_mem below 4MB do
>> better with unpatched than with your patch series, by about 5%. Not a
>> big deal, but also if it is easy to ke
On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote:
> I just noticed that parse_psql_options() ignores the result of setQFout(),
> meaning that if the argument of a -o command line option is bogus, we'll
> ignore the switch entirely after printing an error report. For example
>
> $ psql -o /dev/foo
On 11/15/15 7:37 PM, Peter Eisentraut wrote:
On 11/15/15 3:20 PM, Jim Nasby wrote:
As to the argument about displaying a check or an X, why should that
capability only exist for boolean types? For example, why not allow psql
to convert a numeric value into a bar of varying sizes? I've frequently
On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote:
> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote:
> > I just noticed that parse_psql_options() ignores the result of
> setQFout(),
> > meaning that if the argument of a -o command line option is bogus, we'll
> > ignore the switch entirely afte
"David G. Johnston" writes:
> On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote:
>> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote:
>>> This seems surprising to me: any other program in the world would do
>>> exit(1) after discovering that it couldn't write where it had been
>>> told to. Shou
On Wed, Dec 2, 2015 at 1:24 PM, Tom Lane wrote:
> "David G. Johnston" writes:
>> On Wed, Dec 2, 2015 at 11:04 AM, Robert Haas wrote:
>>> On Wed, Dec 2, 2015 at 11:07 AM, Tom Lane wrote:
This seems surprising to me: any other program in the world would do
exit(1) after discovering that
On Mon, Nov 30, 2015 at 9:10 PM, Vinayak wrote:
> Thanks for the v7.
> Please check the comment below.
> -Table name in the vacuum progress
>
> + snprintf(progress_message[0], PROGRESS_MESSAGE_LENGTH, "%s.%s",
> schemaname,relname);
Uh, I hope that line doesn't appear in the patch. We're scarcel
On Tue, Dec 1, 2015 at 2:25 AM, Kyotaro HORIGUCHI
wrote:
> Yeah, it is actually restricted in that length. But if we allow
> the buffer to store whole the qualified names, it will need 64 *
> 2 + 1 +1 = 130 bytes * 10 1300 bytes for each beentry... It might
> be acceptable by others, but I don't t
Vinayak wrote:
> In the vacuum progress, column table_name is showing first 30 characters of
> table name.
> postgres=# create table test_vacuum_progress_in_postgresql(c1 int,c2 text);
> postgres=# select * from pg_stat_vacuum_progress ;
> -[ RECORD 1 ]---+--
> pid
Hi
Today I have problem with regress tests on my laptop.
I did fresh clone of git
Is it working elsewhere?
Regards
Pavel
regression.diffs
Description: Binary data
regression.out
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Pavel Stehule wrote:
> Hi
>
> Today I have problem with regress tests on my laptop.
Maybe this is because of the libxml version?
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailin
Hi all,
I have a question about postgres_fdw optimizations/pushdown:
I have the following code running on 9.5beta2 (same format as
previous/related message for consistency)
CREATE EXTENSION postgres_fdw;
CREATE SERVER loop foreign data wrapper postgres_fdw
OPTIONS (port '5432', dbname 'testdb
On Wed, Dec 2, 2015 at 10:03 AM, Robert Haas wrote:
>> I'm not very concerned about a regression that is only seen when
>> work_mem is set below the (very conservative) postgresql.conf default
>> value of 4MB when sorting 100 million integers.
>
> Perhaps surprisingly, I tend to agree. I'm cautio
2015-12-02 20:08 GMT+01:00 Alvaro Herrera :
> Pavel Stehule wrote:
> > Hi
> >
> > Today I have problem with regress tests on my laptop.
>
> Maybe this is because of the libxml version?
100%, same issue is with 9.4.5
After downgrade to 2.9.2 (from 2.9.3) this issue was out
So it is looking like
Noah Misch wrote:
> On Tue, Dec 01, 2015 at 08:11:21PM -0300, Alvaro Herrera wrote:
> > Finally, I ran perltidy on all the files, which strangely changed stuff
> > that I didn't expect it to change. I wonder if this is related to the
> > perltidy version.
>
> The last pgindent run (commit 807b9e0
On Tue, Dec 1, 2015 at 8:46 AM, YUriy Zhuravlev
wrote:
> On Tuesday 01 December 2015 08:38:21 you wrote:
>> it (zero
>> based indexing support) doesn't meet the standard of necessity for
>> adding to the core API and as stated it's much to magical.
>
> We do not touch the arrays, we simply create
Thank you for reply.
On 12/02/2015 08:30 PM, Robert Haas wrote:
Logical decoding only begins decoding a transaction once the
transaction is complete. So I would guess that the sequence of
operations here is something like this - correct me if I'm wrong:
1. Do the transaction.
2. PREPARE.
3. R
Hi
2015-11-17 1:49 GMT+01:00 Marko Tiikkaja :
> On 9/11/15 12:25 PM, Pavel Stehule wrote:
>
>> new update of parse_ident function patch
>>
>
> Nice! I've certainly wanted something like this a number of times.
>
> Some comments about the v2 of the patch:
>
>- The patch doesn't apply anymore,
On 12/01/2015 11:20 AM, Tom Lane wrote:
> Notice that the dashed lines go all the way to the right margin of my
> 80-column terminal window, even though the data requires no more than
> 22 columns. While this doesn't look so awful as-is, when I'm working
> in a very wide window it starts to look a
Hello Hackers,
I recently analyzed an incident where a major lag in synchronous replication
blocked a number of synchronous backends. I found myself looking at backends
that, according to pg_stat_activity, were neither waiting nor idle but yet they
didn't finish their work.
As it turns out, the
On Wed, Dec 2, 2015 at 12:39 AM, Michael Paquier
wrote:
> On Mon, Nov 9, 2015 at 8:07 AM, Steve Singer wrote:
>> In snapmgr.c
>>
>>
>> + * XXX: If we can trust a read of an int64 value to be atomic, we can skip
>> the
>> + * spinlock here.
>> + */
>> +int64
>> +GetOldSnapshotThresholdTimestamp(
Sorry, I initially responded only to Josh. Forwarding to list:
On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus wrote:
> On 12/01/2015 11:20 AM, Tom Lane wrote:
>> Notice that the dashed lines go all the way to the right margin of my
>> 80-column terminal window, even though the data requires no m
On Tue, Dec 1, 2015 at 7:21 AM, Amit Kapila wrote:
> Above and changes in add_path() makes planner not to select parallel path
> for seq scan where earlier it was possible. I think you want to change the
> costing of parallel plans based on rows selected instead of total_cost,
> but there seems to
Michael Paquier wrote:
> Well, Alvaro has whispered me a more elegant method by using TestLib()
> to only import a portion of the routines and avoid the redefinition
> errors. Hence, patch 0001 attached creates equivalents of command_*
> for PostgresNode and tests use it without setting PGPORT. Pa
Pavel Stehule writes:
> Today I have problem with regress tests on my laptop.
Looks like
https://bugzilla.redhat.com/show_bug.cgi?id=1286692
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
h
On 9/15/15 11:49 PM, Pavel Stehule wrote:
1. processing user input with little bit more comfort - the user doesn't
need to separate schema and table
This is especially useful if you're doing anything that needs to
dynamically work with different objects. I'd say about 80% of the time
I'm doin
Jeff Janes writes:
> On Wed, Dec 2, 2015 at 12:37 PM, Josh Berkus wrote:
>> If you're fixing the dashed-line code, is there a way to say that we
>> never have more than a reasonable number of dashes (ideally, the width
>> of the terminal) no matter how wide the data is? Having 4000 dashes
>> bec
On Mon, Nov 30, 2015 at 11:00 PM, David Rowley
wrote:
> There are in fact also two queries in TPC-H (Q10 and Q18) which are written
> to include all of the non-aggregated column in the GROUP BY list. During a
> recent test I witnessed a 50% gain in performance in Q10 by removing the
> unneeded col
On 02/12/2015 20:25, cevian wrote:
> Hi all,
>
Hello,
> I have a question about postgres_fdw optimizations/pushdown:
>
> I have the following code running on 9.5beta2 (same format as
> previous/related message for consistency)
> CREATE EXTENSION postgres_fdw;
> CREATE SERVER loop foreign data
On 3 December 2015 at 04:22, Julian Schauder
wrote:
> I suggest adding a new state to pg_stat_activity.state for backends that
> are
>
waiting for their synchronous commit to be flushed on the remote host.
>
>
Excellent idea. Anything that improves management and visibility into what
the system
On Thu, Dec 3, 2015 at 5:48 AM, Kevin Grittner wrote:
>> There has been a review but no replies for more than 1 month. Returned
>> with feedback?
>
> I do intend to post another version of the patch to tweak the
> calculations again, after I can get a patch in to expand the
> testing capabilities t
On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote:
> On 11/15/15 7:37 PM, Peter Eisentraut wrote:
>>
>> On 11/15/15 3:20 PM, Jim Nasby wrote:
>>>
>>> As to the argument about displaying a check or an X, why should that
>>> capability only exist for boolean types? For example, why not allow psql
>>>
On 3 December 2015 at 04:22, Julian Schauder
wrote:
>
> I suggest adding a new state to pg_stat_activity.state for backends that
> are
> waiting for their synchronous commit to be flushed on the remote host.
> I chose 'waiting for synchronous replication' for now.
>
>
I've added this to the next
On Tue, Dec 1, 2015 at 7:53 AM, Anastasia Lubennikova
wrote:
> If we don't need c4 as an index scankey, we don't need any btree opclass on
> it.
> But we still want to have it in covering index for queries like
>
> SELECT c4 FROM tbl WHERE c1=1000; // uses the IndexOnlyScan
> SELECT * FROM tbl WHE
On 1 December 2015 at 00:20, Konstantin Knizhnik
wrote:
> We have implemented ACID multimaster based on logical replication and our
DTM (distributed transaction manager) plugin.
What are you using for an output plugin and for replay?
I'd really like to collaborate using pglogical_output if at a
Hello,
At Thu, 3 Dec 2015 09:24:35 +0900, Michael Paquier
wrote in
> On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote:
> > On 11/15/15 7:37 PM, Peter Eisentraut wrote:
> > I was more thinking it would be nice to be able to temporarily
> > over-ride/wrap what an output function is doing. AFAIK t
On 3 December 2015 at 04:18, Konstantin Knizhnik
wrote:
> The problem is that transactions are delivered to replica through single
> channel: logical replication slot.
> And while such transaction is waiting acknowledgement from arbiter, it is
> blocking replication channel preventing other (par
On 3 December 2015 at 01:30, Robert Haas wrote:
> 1. Do the transaction.
> 2. PREPARE.
> 3. Replay the transaction.
>
As Konstantin noted they aren't using Pg's 2PC. They actually couldn't if
they wanted to because logical decoding does not support decoding an xact
at PREPARE TRANSACTION time,
On 11/30/15 11:00 PM, David Rowley wrote:
> It seems that there's no shortage of relational databases in existence
> today which don't support this. These databases would require the GROUP
> BY clause to include the p.description column too.
Well, actually, we implemented this because other datab
On 12/2/15 7:00 PM, Craig Ringer wrote:
> I notice that you don't set the 'waiting' flag. 'waiting' is presently
> documented as:
>
>True if this backend is currently waiting on a lock
>
> ... but I'm inclined to just widen its definition and set it here, since
> we most certainly are wa
On Thu, Dec 3, 2015 at 10:09 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
> At Thu, 3 Dec 2015 09:24:35 +0900, Michael Paquier
> wrote in
>
>> On Thu, Dec 3, 2015 at 3:10 AM, Jim Nasby wrote:
>> > On 11/15/15 7:37 PM, Peter Eisentraut wrote:
>> > I was more thinking it would be nice to be able to
On Mon, Nov 30, 2015 at 04:29:43PM +0900, KAWAMICHI Ryoji wrote:
>
>
> Robert Haas wrote:
> >
> > - If we're sequential scanning a small table, let's say less than 1/4
> > of shared_buffers, which is the point where synchronized scans kick
> > in, then assume the data is coming from shared_buff
On 3 December 2015 at 14:28, Peter Eisentraut wrote:
> On 11/30/15 11:00 PM, David Rowley wrote:
> > It seems that there's no shortage of relational databases in existence
> > today which don't support this. These databases would require the GROUP
> > BY clause to include the p.description column
On Wed, Dec 2, 2015 at 9:30 AM, Kyotaro HORIGUCHI
wrote:
> Hello,
>
>> You're right, it's not necessary.
>> Attached latest v29 patch which removes the mention in pg_upgrade
>> documentation.
>
> The changes looks to be correct but I haven't tested.
> And I have some additional random comments.
>
Michael Paquier writes:
> On Thu, Dec 3, 2015 at 8:38 AM, Tom Lane wrote:
>> Test Summary Report
>> ---
>> t/001_initdb.pl (Wstat: 6400 Tests: 8 Failed: 0)
>> Non-zero exit status: 25
>> Parse errors: Bad plan. You planned 14 tests but ran 8.
>> Files=1, Tests=8, 0 wallclock secs
On 3 December 2015 at 09:32, Peter Eisentraut wrote:
> On 12/2/15 7:00 PM, Craig Ringer wrote:
> > I notice that you don't set the 'waiting' flag. 'waiting' is presently
> > documented as:
> >
> >True if this backend is currently waiting on a lock
> >
> > ... but I'm inclined to just wid
On 12/02/2015 05:24 PM, Tom Lane wrote:
> Don't think I agree. Suppose that you have a wider-than-screen table
> and you use a pager to scroll left and right in that. If we shorten the
> dashed lines, then once you scroll to the right of wherever they stop,
> you lose that visual cue separating t
On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote:
> BTW, not the fault of this patch in particular, but this example points
> up the complaint I've had right along about how opaque TAP test failures
> are. How did you dig down to see that error message?
Well, it showed up on my terminal...
> Is
Michael Paquier writes:
> On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote:
>> BTW, not the fault of this patch in particular, but this example points
>> up the complaint I've had right along about how opaque TAP test failures
>> are. How did you dig down to see that error message?
> Well, it sh
On Wed, Dec 02, 2015 at 10:36:56PM -0500, Josh Berkus wrote:
> On 12/02/2015 05:24 PM, Tom Lane wrote:
> > Don't think I agree. Suppose that you have a wider-than-screen table
> > and you use a pager to scroll left and right in that. If we shorten the
> > dashed lines, then once you scroll to the
On Wed, Nov 25, 2015 at 7:18 PM, Pavel Stehule wrote:
>
>
> 2015-11-25 8:05 GMT+01:00 Haribabu Kommi :
>>
>>
>> Thanks. Here I attached the poc patch that returns authentication method
>> of the
>> first matched hba entry in pg_hba.conf with the given input values.
>> Currently these
>> functions
Amit Langote writes:
> Currently find_inheritance_children() is smart enough to skip a child
> table that it finds has been dropped concurrently after it gets a lock on
> the same. It does so by looking up the child relid in syscache. It seems
> it should also check if the table is still in the li
On Thu, Dec 3, 2015 at 12:50 PM, Tom Lane wrote:
> Michael Paquier writes:
>> On Thu, Dec 3, 2015 at 12:19 PM, Tom Lane wrote:
>>> BTW, not the fault of this patch in particular, but this example points
>>> up the complaint I've had right along about how opaque TAP test failures
>>> are. How di
Hello, sorry for the cloberred CC list.
# I restored it manually from upthread..
At Wed, 2 Dec 2015 13:42:01 -0500, Robert Haas wrote in
> On Tue, Dec 1, 2015 at 2:25 AM, Kyotaro HORIGUCHI
> wrote:
> > Yeah, it is actually restricted in that length. But if we allow
> > the buffer to store who
2015-12-02 23:00 GMT+01:00 Tom Lane :
> Pavel Stehule writes:
> > Today I have problem with regress tests on my laptop.
>
> Looks like
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1286692
sure
Pavel
>
>
> regards, tom lane
>
Hello,
At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera
wrote in <20151202184820.GL2763@alvherre.pgsql>
> Vinayak wrote:
>
> > In the vacuum progress, column table_name is showing first 30 characters of
> > table name.
> > postgres=# create table test_vacuum_progress_in_postgresql(c1 int,c2 te
2015-12-03 5:00 GMT+01:00 Haribabu Kommi :
> On Wed, Nov 25, 2015 at 7:18 PM, Pavel Stehule
> wrote:
> >
> >
> > 2015-11-25 8:05 GMT+01:00 Haribabu Kommi :
> >>
> >>
> >> Thanks. Here I attached the poc patch that returns authentication method
> >> of the
> >> first matched hba entry in pg_hba.co
On 27 July 2015 at 04:58, Heikki Linnakangas wrote:
>
> This patch seems sane to me, as far as it goes. However, there's no
> planner or executor code to use the aggregate combining for anything. I'm
> not a big fan of dead code, I'd really like to see something to use this.
>
I've attached an u
On 20 October 2015 at 23:23, David Rowley
wrote:
> On 13 October 2015 at 20:57, Haribabu Kommi
> wrote:
>
>> On Tue, Oct 13, 2015 at 5:53 PM, David Rowley
>> wrote:
>> > On 13 October 2015 at 17:09, Haribabu Kommi
>> > wrote:
>> >>
>> >> On Tue, Oct 13, 2015 at 12:14 PM, Robert Haas
>> >> wro
On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote:
> At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera
> wrote
>>
>> Actually, do we really need to have the table name as a string at all
>> here? Why not just report the table OID? Surely whoever wants to check
>> the progress can connect to the data
Hello, the attched is an example implement of output filter
dynamic loading feature of psql.
At Thu, 3 Dec 2015 10:41:11 +0900, Michael Paquier
wrote in
> > How about plugins on psql side? Calling hooked function in
> > printQuery could do that on psql. Impact on psql itself is
> > minimized. (
On Tue, Dec 1, 2015 at 2:17 AM, Pavel Stehule wrote:
> here is complete patch - regress tests for all supported Python branches
I had a look at what changed in v10 since my last reviewed version and
indeed most of it is straightforward: renames from SPIError to Error.
The patch also changes plpy.
On Thu, Dec 3, 2015 at 12:55 AM, cevian wrote:
> Hi all,
>
> I have a question about postgres_fdw optimizations/pushdown:
>
> I have the following code running on 9.5beta2 (same format as
> previous/related message for consistency)
> CREATE EXTENSION postgres_fdw;
> CREATE SERVER loop foreign dat
On Thu, Dec 3, 2015 at 4:18 PM, David Rowley
wrote:
>
> Hi,
>
> I just wanted to cross post here to mark that I've posted an updated patch
> for combining aggregate states:
> http://www.postgresql.org/message-id/CAKJS1f9wfPKSYt8CG=t271xbymzjrzwqbjeixiqrf-olh_u...@mail.gmail.com
>
> I also wanted t
Hello,
At Thu, 3 Dec 2015 14:18:50 +0900, Amit Langote
wrote in <565fd0ba.5020...@lab.ntt.co.jp>
> On 2015/12/03 13:47, Kyotaro HORIGUCHI wrote:
> > At Wed, 2 Dec 2015 15:48:20 -0300, Alvaro Herrera
> > wrote
> >>
> >> Actually, do we really need to have the table name as a string at all
> >>
1 - 100 of 113 matches
Mail list logo
