I wonder if the following error detail text could say more than it does
currently for the following rather artificial example case:
CREATE TABLE p1(a char(3));
CREATE TABLE p2(a char(2));
CREATE TABLE c(d int) INHERITS (p1, p2);
NOTICE: merging multiple inherited definitions of column "a"
ERROR:
Hello,
At Thu, 24 Dec 2015 18:31:42 -0500, Corey Huinker
wrote in
> On Wed, Dec 23, 2015 at 3:08 PM, Jim Nasby wrote:
>
> > On 12/23/15 12:15 PM, Corey Huinker wrote:
> >
> >> That's fair. I'm still at a loss for how to show that the fetch size was
> >> respected by the remote server, suggest
Hello,
At Thu, 24 Dec 2015 07:40:19 +0100 (CET), Fabien COELHO
wrote in
>
> Hello Michaël,
>
> >> If I read you correctly, I should cut it out into a new file and
> >> include it. Is it correct?
> >
> > Not really, I meant to see if it would be possible to include this set
> > of routines dir
On Mon, Dec 21, 2015 at 4:53 PM, David Rowley
wrote:
> On 22 December 2015 at 01:30, Robert Haas wrote:
>> Can we use Tom's expanded-object stuff instead of introducing
>> aggserialfn and aggdeserialfn? In other words, if you have a
>> aggtranstype = INTERNAL, then what we do is:
>>
>> 1. Create
On Wed, Dec 23, 2015 at 1:16 AM, Amit Kapila wrote:
> On Tue, Dec 22, 2015 at 10:43 PM, Robert Haas wrote:
>>
>> On Mon, Dec 21, 2015 at 1:27 AM, Amit Kapila
>> wrote:
>> > On Fri, Dec 18, 2015 at 9:58 PM, Robert Haas
>> > wrote:
>> >>
>> >> On Fri, Dec 18, 2015 at 1:16 AM, Amit Kapila
>> >> w
On 2015/12/25 0:44, Tom Lane wrote:
> Amit Langote writes:
>> Attached fixes the following comment typo (copy-pasto):
>> -Oid toast_oid; /* for restore toast frozen xid */
>> +Oid toast_oid; /* for restore toast table oid */
>
> That comment needs more help than
On Wed, Dec 23, 2015 at 3:08 PM, Jim Nasby wrote:
> On 12/23/15 12:15 PM, Corey Huinker wrote:
>
>> That's fair. I'm still at a loss for how to show that the fetch size was
>> respected by the remote server, suggestions welcome!
>>
>
> A combination of repeat() and generate_series()?
>
> I'm gues
On Fri, Dec 25, 2015 at 8:50 AM, Masahiko Sawada wrote:
> On Wed, Dec 23, 2015 at 8:45 AM, Thomas Munro
> wrote:
>> On Wed, Dec 23, 2015 at 3:50 PM, Thomas Munro
>> wrote:
>>> If you got rid of SyncRepGetSyncStandbysOnePriority as suggested
>>> above, then this function could be renamed to SyncR
Chapman Flack writes:
> I probably just need to learn the right coding pattern for this.
> What is it?
You can't just ignore a thrown error like that. What you'd have to do
to make this coding pattern work is to set up a subtransaction, and either
commit it in the success path or roll it back up
> The patch is attached.
Now, it is actually attached.
brin-correlation-v2.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 25/12/15 01:45, Michael Paquier wrote:
[...]
And the CF is no closed. Here is the final score:
Committed: 30.
Moved to next CF: 42.
Rejected: 9.
Returned with Feedback: 22.
Total: 103.
Regards,
You didn't say how may regards...
[More seriously]
Many thanks to you, and the other Postgres de
On Wed, Dec 23, 2015 at 9:40 PM, Jeff Janes wrote:
> On Wed, Sep 23, 2015 at 11:33 PM, Jeff Janes wrote:
>>
>> On further thought, neither do I. The attached patch inverts
>> ResolveRecoveryConflictWithLock to be called back from the lmgr code so that
>> is it like ResolveRecoveryConflictWithBuf
Hi all,
ALTER ROLE SET/RESET can set/reset only one GUC parameter per one SQL today.
So when we need to set/reset multiple GUC parameter to user, it would
be burdensome work.
I'd like propose feature makes ALTER ROLE SET/RESET can set/reset
multiple options like ALTER TABLE.
ALTER USER is as well
On Wed, Dec 23, 2015 at 8:45 AM, Thomas Munro
wrote:
> On Wed, Dec 23, 2015 at 3:50 PM, Thomas Munro
> wrote:
>> On Fri, Dec 18, 2015 at 7:38 AM, Masahiko Sawada
>> wrote:
>> [000-_multi_sync_replication_v3.patch]
>>
>> Hi Masahiko,
>>
>> I haven't tested this version of the patch but I have so
On Thu, Dec 24, 2015 at 6:18 PM, Tom Lane wrote:
> Michael Paquier writes:
> > And the CF is no closed. Here is the final score:
> > Committed: 30.
> > Moved to next CF: 42.
> > Rejected: 9.
> > Returned with Feedback: 22.
> > Total: 103.
>
> Many thanks to Michael for doing the CF management wo
Hi, Christophe!
On Thu, Dec 24, 2015 at 6:28 PM, Fornaroli Christophe
wrote:
> This code uses this upper bound for the similarity: ntrue / (nkeys -
> ntrue). But if there is ntrue trigrams in common, we know that the indexed
> string is at least ntrue trigrams long. We can then use a more aggres
I probably just need to learn the right coding pattern for this.
What is it?
What I want this code to do:
a) If there is a table 'mytable', set theSavedStuff to a pstrdup'd in
TopMemoryContext copy of column s from one row if present.
b) In case of an error because there is no table 'mytable
On 12/24/2015 04:18 PM, Tom Lane wrote:
Michael Paquier writes:
And the CF is no closed. Here is the final score:
Committed: 30.
Moved to next CF: 42.
Rejected: 9.
Returned with Feedback: 22.
Total: 103.
Many thanks to Michael for doing the CF management work this time!
+1
--
Tomas Vondr
On 12/24/2015 02:51 PM, Simon Riggs wrote:
On 17 December 2015 at 16:00, Tomas Vondra mailto:tomas.von...@2ndquadrant.com>> wrote:
On 12/17/2015 11:44 AM, Simon Riggs wrote:
My understanding is that the bloom filter would be ineffective
in any of
these cases
> Somebody wrote to me a few days ago that the BRIN cost estimation is
> rather poor. One immediately obvious issue which I think is easily
> fixed is the correlation estimate, which is currently hardcoded to 1.
>
> Since a BRIN scan always entails a scan of the relation in physical
> order, it's
Hi,
I think that we can improve the gin index scan performance for similarity
search defined in the pg_trgm extension. The similarity function is (for
the default case where DIVUNION is defined in the code):
count / (len1 + len2 - count) >= trgm_limit
where
len1 is the number of unique
There should be a way to do separate read/write security barriers for
updatable views. I'll start by addressing the problem, state some potential
solutions with the current software, and finally end with 2 proposals to
solve the problem in the best way possible.
## Problem
I want the user to see m
Amit Langote writes:
> Attached fixes the following comment typo (copy-pasto):
> -Oid toast_oid; /* for restore toast frozen xid */
> +Oid toast_oid; /* for restore toast table oid */
That comment needs more help than just that ;-). Done, thanks.
Michael Paquier writes:
> I just bumped into the following typo that has been introduced by e50cda7:
Pushed, thanks.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/
Michael Paquier writes:
> And the CF is no closed. Here is the final score:
> Committed: 30.
> Moved to next CF: 42.
> Rejected: 9.
> Returned with Feedback: 22.
> Total: 103.
Many thanks to Michael for doing the CF management work this time!
regards, tom lane
--
Sent
> There's still the problem that it won't work across a major version
> upgrade that makes any change whatsoever to the rowtype of pg_statistic.
I'm sorry if my previous explanation was poor, this time I am going to be
detailed.
Suppose you want to upgrade from 9.4 to 9.6. In that case you would
On 17 December 2015 at 16:00, Tomas Vondra
wrote:
> On 12/17/2015 11:44 AM, Simon Riggs wrote:
>
>>
>> My understanding is that the bloom filter would be ineffective in any of
>> these cases
>> * Hash table is too small
>>
>
> Yes, although it depends what you mean by "too small".
>
> Essentially
On Thu, Dec 24, 2015 at 12:09 PM, Michael Paquier
wrote:
> On Tue, Dec 22, 2015 at 10:45 PM, Michael Paquier
> wrote:
>> On Tue, Dec 22, 2015 at 4:04 PM, Michael Paquier
>> wrote:
>>> OK, if those don't get addressed soon, they will be moved to the next
>>> CF with the same status.
>>
>> After a
On Thu, Dec 24, 2015 at 7:03 PM, Ashutosh Bapat
wrote:
> On Thu, Dec 24, 2015 at 8:32 AM, Michael Paquier
>> Ashutosh, others, this thread has been stalling for more than 1 month
>> and a half. There is a new patch that still applies (be careful of
>> whitespaces btw), but no reviews came in. So
On Wed, 23 Dec 2015 16:36:23 -0800
Paul Jungwirth wrote:
> On 12/23/2015 08:10 AM, Ildus Kurbangaliev wrote:
> > There is a more improved version of the patch. Main idea is to
> > present uuid as two uint64 values, and make comparisons and penalty
> > calculation based on these values. This appro
On Tue, 15 Dec 2015 13:56:30 -0500
Robert Haas wrote:
> On Sun, Dec 13, 2015 at 6:35 AM, and...@anarazel.de
> wrote:
> > On 2015-12-12 21:15:52 -0500, Robert Haas wrote:
> >> On Sat, Dec 12, 2015 at 1:17 PM, and...@anarazel.de
> >> wrote:
> >> > Here's two patches doing that. The first is a
Hello, Tomas.
Great idea!
Did you consider to cache bloom filter or at least part(s) of it
somehow? I think this way we could gain some more TPS. This of course
assuming that creating a bloom filter is really a bottleneck here,
which would be nice be investigated first.
Best regards,
Aleksander
On Thu, Dec 24, 2015 at 8:32 AM, Michael Paquier
wrote:
> On Mon, Nov 9, 2015 at 8:55 PM, Ashutosh Bapat
> wrote:
> >
> >
> > On Sat, Nov 7, 2015 at 12:07 AM, Robert Haas
> wrote:
> >>
> >> On Wed, Aug 12, 2015 at 6:25 AM, Ashutosh Bapat
> >> wrote:
> >> > The previous patch would not compile
Attached fixes the following comment typo (copy-pasto):
-Oid toast_oid; /* for restore toast frozen xid */
+Oid toast_oid; /* for restore toast table oid */
Thanks,
Amit
diff --git a/src/bin/pg_dump/pg_dump.h b/src/bin/pg_dump/pg_dump.h
index 3c64a82..9c63abd 100
Oops, wrong patches - here are correct ones.diff --git a/src/backend/utils/resowner/resowner.c b/src/backend/utils/resowner/resowner.c
index 0e7acbf..3330c8d 100644
--- a/src/backend/utils/resowner/resowner.c
+++ b/src/backend/utils/resowner/resowner.c
@@ -29,6 +29,156 @@
#include "utils/snapmgr.h
On Thu, Dec 24, 2015 at 2:14 AM, Craig Ringer wrote:
> On 22 December 2015 at 23:48, Alex Ignatov wrote:
>
>>
>> I think that you can debug crash dump since windbg exists.
>
>
> Nobody in their right mind uses windbg though. Visual Studio is really where
> it's at and the Express versions make it
I believe I fixed all flaws mentioned so far (see attachment).
Also I did a new benchmark to make sure that new patch makes PostgreSQL
work faster and doesn't cause performance degradation in some cases.
"usual pgbench" row corresponds to `pgbench -j 8 -c 8 -T 30 pgbench`
performed on a 4-core P
37 matches
Mail list logo
