On 9 October 2017 at 15:37, Konstantin Knizhnik
wrote:
> Thank you for explanations.
>
> On 08.10.2017 16:00, Craig Ringer wrote:
>>
>> I think it'd be helpful if you provided reproduction instructions,
>> test programs, etc, making it very clear when things are / aren't
>> related to your changes
On 10/09/2017 03:26 PM, Amit Kapila wrote:
I have reverted the check
in the attached patch.
I have applied this patch against PG HEAD and run sqlsmith and analyzed
results . didn't find any specific failures against this patch.
--
regards,tushar
EnterpriseDB https://www.enterprisedb.com/
Th
On Fri, Oct 6, 2017 at 2:43 AM, Robert Haas wrote:
> On Fri, Sep 15, 2017 at 2:22 AM, Haribabu Kommi
> wrote:
> > Thanks for the review.
>
> I committed this patch with some cosmetic changes. I think the fact
> that several people have asked for this indicates that, even without
> making some o
Tom Lane wrote:
> Joe Conway writes:
> > I have been annoyed at least twice now by the lack of pg_regress command
> > line help output for the "--bindir=" option. In passing I noted
> > that there was no output for "--help" or "--version" options either.
>
> > Any objections to the attached?
>
>
On 11 October 2017 at 11:44, Jeremy Schneider wrote:
> On Sun, Oct 1, 2017 at 8:10 AM, Tom Lane wrote:
>>
>> configure --with-extra-version=whateveryouwant
>
> I see that this build option has been around since 9.4; is anyone
> using it to mark patched production builds? EnterpriseDB or
> 2ndQua
Andres Freund wrote:
> Hi,
>
> On 2017-10-03 13:58:37 -0400, Robert Haas wrote:
> > On Tue, Oct 3, 2017 at 12:23 PM, Andres Freund wrote:
> > > Makes sense?
> >
> > Yes.
>
> Here's an updated version of this patchset.
Maybe it'd be a good idea to push 0001 with some user of restrict ahead
of t
Hi,
Attached is a patch to enable views to be locked.
PostgreSQL has supported automatically updatable views since 9.3, so we can
udpate simply defined views like regular tables. However, currently,
table-level locks on views are not supported. We can not execute LOCK TABLE
for views, while we c
On 10 October 2017 at 23:50, Stephen Frost wrote:
> Yeah, it sounds interesting, but I was just chatting w/ David about it
> and we were thinking about how checkpoints are really rather often done,
> so you end up with quite a few of these lists being out there.
>
> Now, if the lists were always k
Hi Thomas,
I was testing this feature with v20 patch, and I got a crash while doing
large joins with small work_mem, and lots of workers as below.
-- Machine Configuration: (d1.xlarge) CUPs : 8 , RAM : 16GB , SIze : 640GB
-- postgres.conf setting as below:
work_mem = *64kB*
max_parallel_workers
On 9 October 2017 at 16:03, Amit Kapila wrote:
> On Fri, Oct 6, 2017 at 12:03 PM, Amit Khandekar
> wrote:
>> On 6 October 2017 at 08:49, Amit Kapila wrote:
>>>
>>> Okay, but why not cheapest partial path?
>>
>> I gave some thought on this point. Overall I feel it does not matter
>> which partia
On Tue, Oct 10, 2017 at 9:14 PM, Andres Freund wrote:
> I'm actually inclined not to, and keep this as a undocumented debugging
> option. Limiting the use of this option to people willing to read the
> code seems like a good idea to me.
-1. I use the documentation to find things, even though I a
On Mon, Oct 9, 2017 at 2:05 AM, Ashutosh Bapat
wrote:
> On Sat, Oct 7, 2017 at 1:04 AM, Robert Haas wrote:
>> Committed. I hope that makes things less red rather than more,
>> because I'm going to be AFK for a few hours anyway.
>
> Here's the last patch, dealing with the dummy relations, rebased
On Fri, Oct 6, 2017 at 3:36 PM, Nico Williams wrote:
>> If global temporary tables should be effective, then you have not have
>> modify system catalogue after creating. But lot of processes requires it -
>> ANALYZE, query planning.
>
> But the nice thing about them is that you need only create th
On Sat, Oct 7, 2017 at 7:26 AM, Simon Riggs wrote:
> PredicateLockTuple() specifically avoids adding an SIRead lock if the
> tuple already has a write lock on it, so surely it must also be
> correct to skip the SIRead lock if we are just about to update the
> row?
I wonder if there's a race condi
Alvaro Herrera writes:
> Tom Lane wrote:
>> Also, why is the patch apparently changing whitespace in all the help
>> lines? Seems like that will create a lot of make-work for translators.
> I think we don't have translations for pg_regress.
Good point --- objection withdrawn.
FYI, I've added my patch to the commitfest.
https://commitfest.postgresql.org/15/1319/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Oct 6, 2017 at 10:19 PM, Tom Lane wrote:
>> 9. Unneeded Self JOIN
>
>> Can't remember discussions of this.
>
> I can't get very excited about that one either.
My memories of being a PostgreSQL user rather than a developer are
getting a bit distant by now, but I definitely remember hitting
On 11 October 2017 at 15:33, Robert Haas wrote:
> On Sat, Oct 7, 2017 at 7:26 AM, Simon Riggs wrote:
>> PredicateLockTuple() specifically avoids adding an SIRead lock if the
>> tuple already has a write lock on it, so surely it must also be
>> correct to skip the SIRead lock if we are just about
On Mon, Oct 9, 2017 at 5:56 AM, Amit Kapila wrote:
> How about always returning false for PARAM_EXTERN?
Yeah, I think that's what we should do. Let's do that first as a
separate patch, which we might even want to back-patch, then return to
this.
--
Robert Haas
EnterpriseDB: http://www.enterpri
On 2017-10-11 10:53:56 +0200, Alvaro Herrera wrote:
> Andres Freund wrote:
> > Hi,
> >
> > On 2017-10-03 13:58:37 -0400, Robert Haas wrote:
> > > On Tue, Oct 3, 2017 at 12:23 PM, Andres Freund wrote:
> > > > Makes sense?
> > >
> > > Yes.
> >
> > Here's an updated version of this patchset.
>
>
Andres Freund wrote:
> On 2017-10-11 10:53:56 +0200, Alvaro Herrera wrote:
> > I wonder if it'd be a good idea to nag external users about pq_sendint
> > usage (is a #warning possible?).
>
> Think we'd need some separate infrastructure, i.e. for gcc ending up
> with __attribute__((deprecated)). I
On Wed, Oct 11, 2017 at 11:51 AM, Simon Riggs wrote:
> I'm inclined to believe Robert's hypothesis that there is some race
> condition there.
>
> The question is whether that still constitutes a serializability
> problem since we haven't done anything with the data, just passed it
> upwards to be
Andres Freund writes:
> On 2017-10-11 11:58:58 -0400, Tom Lane wrote:
>> I agree the PITA factor of the current approach keeps increasing.
>> It sounds a bit silly to build libpgport three ways, but maybe
>> we should just do that.
> We already kinda are, just by copying things around ;)
Yeah.
Hi,
On 2017-10-09 10:37:01 +0300, Konstantin Knizhnik wrote:
> So we have implement sharding - splitting data between several remote tables
> using pg_pathman and postgres_fdw.
> It means that insert or update of parent table cause insert or update of
> some derived partitions which is forwarded
On Tue, Oct 10, 2017 at 6:00 AM, Ashutosh Bapat
wrote:
> This looks good to me. I think it should be a separate, yet very small patch.
+1.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
On 11.10.2017 10:07, Craig Ringer wrote:
On 9 October 2017 at 15:37, Konstantin Knizhnik
wrote:
Thank you for explanations.
On 08.10.2017 16:00, Craig Ringer wrote:
I think it'd be helpful if you provided reproduction instructions,
test programs, etc, making it very clear when things are /
On Tue, Oct 10, 2017 at 11:22 AM, Alvaro Herrera
wrote:
> Hmm ... yeah, ATTACH and DETACH sound acceptable to me. On DETACH, the
> abstract index should be marked indisvalid=false unless a substitute
> index already exists; and on ATTACH when indisvalid=false we verify that
> all local indexes ex
Hi,
On 2017-10-11 18:05:32 +0200, Alvaro Herrera wrote:
> Well, my concern is to ensure that extension authors take advantage of
> the optimized implementation. If we never let them know that we've
> rewritten things, most are not going to realize they can make their
> extensions faster with a ve
On Wed, Oct 11, 2017 at 2:47 PM, Andres Freund wrote:
>> If do nothing, it's unlikely we'd ever get rid of the compat function.
>
> I think that's ok.
Yeah. I mean, it seems similar to what happened with heap_formtuple:
the last in-tree users of that function went away in 8.4 (902d1cb35)
but we
On Mon, Oct 9, 2017 at 10:59 PM, Masahiko Sawada wrote:
> Attached a patch for $subject. ISTM these are mistakes of copy-and-paste.
Committed, but isn't the code itself wrong as well in the DELETE case?
/* BEFORE ROW DELETE Triggers */
if (resultRelInfo->ri_TrigDesc &&
resultRelI
On Mon, Oct 9, 2017 at 10:22 AM, Alexander Korotkov
wrote:
> For me, it's crucial point that pluggable storages should be able to have
> different MVCC implementation, and correspondingly have full control over
> its interactions with indexes.
> Thus, it would be good if we would get consensus on
On Wed, Oct 11, 2017 at 1:19 AM, Craig Ringer wrote:
> We started using it for BDR, but unfortunately too much software
> explodes spectacularly when you use it, due to simplistic/buggy
> version parsing.
Since 10.0 will break most of that software anyway, maybe this is a
good time to revisit the
On Wed, Oct 11, 2017 at 1:08 PM, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 10:22 AM, Alexander Korotkov
> wrote:
>> For me, it's crucial point that pluggable storages should be able to have
>> different MVCC implementation, and correspondingly have full control over
>> its interactions with ind
Laurenz Albe writes:
> grant.sgml says that
>the default privileges granted to PUBLIC are as follows: CONNECT and
>CREATE TEMP TABLE for databases; EXECUTE privilege for functions;
>and USAGE privilege for languages.
> But types also have the USAGE privilege for PUBLIC by default:
Yu
Hi,
On 2017-09-20 20:27:05 -0700, Lukas Fittl wrote:
> As per the bug report at
> https://www.postgresql.org/message-id/20170921010956.17345.61461%40wrigleys.postgresql.org
> it seems that the query cancellation holdoff logic in ProcessInterrupts is
> a bit overly aggressive in keeping other inter
> On 09/21/2017 09:41 PM, Andres Freund wrote:
> > On 2017-09-21 09:30:31 -0400, Tom Lane wrote:
> >> Andrew Dunstan writes:
> >>> The speed of memset is hardly going to be the dominating factor in a
> >>> 'CREATE DATABASE' command, so we could certainly afford to change to
> >>> plain memset call
On 2017-10-11 08:54:10 -0700, Andres Freund wrote:
> On 2017-10-11 10:53:56 +0200, Alvaro Herrera wrote:
> > Maybe it'd be a good idea to push 0001 with some user of restrict ahead
> > of the rest, just to see how older msvc reacts.
>
> Can do. Not quite sure which older user yet, but I'm sure I c
Andres Freund writes:
> Andrew Dunstan writes:
>> I presume if you can make that assertion you already have something
>> along those lines?
> Not really. I just replaced memset with MemSetAligned in a bunch of
> places in the code and looked at profiles.
Well, it's not that much work to try it
On Wed, Oct 11, 2017 at 2:11 PM Andres Freund wrote:
> I've pushed this. Thanks for the report & fix!
>
Excellent, thanks!
Best,
Lukas
--
Lukas Fittl
On 10/11/17 04:19, Craig Ringer wrote:
> On 11 October 2017 at 11:44, Jeremy Schneider
> wrote:
>> On Sun, Oct 1, 2017 at 8:10 AM, Tom Lane wrote:
>>>
>>> configure --with-extra-version=whateveryouwant
>>
>> I see that this build option has been around since 9.4; is anyone
>> using it to mark pa
On Thu, Oct 12, 2017 at 5:02 AM, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 10:59 PM, Masahiko Sawada
> wrote:
>> Attached a patch for $subject. ISTM these are mistakes of copy-and-paste.
>
> Committed, but isn't the code itself wrong as well in the DELETE case?
>
> /* BEFORE ROW DELETE Tri
It seems to me that having ACL_OBJECT_* symbols alongside OBJECT_*
symbols is not useful and leads to duplication. Digging around in the
past suggests that we used to have a lot of these command-specific
symbols but got rid of them over time, except that the ACL stuff was
never touched. The attac
On Wed, Oct 11, 2017 at 10:28 PM, Robert Haas wrote:
> On Tue, Oct 10, 2017 at 9:14 PM, Andres Freund wrote:
>> I'm actually inclined not to, and keep this as a undocumented debugging
>> option. Limiting the use of this option to people willing to read the
>> code seems like a good idea to me.
>
> Hi,
>
> Attached is a patch to enable views to be locked.
Nice.
> PostgreSQL has supported automatically updatable views since 9.3, so we can
> udpate simply defined views like regular tables. However, currently,
> table-level locks on views are not supported. We can not execute LOCK TABLE
>
On Wed, Oct 4, 2017 at 9:00 PM, Michael Paquier
wrote:
> v4 looks correct to me. Testing it through (pgbench and some custom
> queries) I have not spotted issues. If the final decision is to use
> 64-bit query IDs, then this patch could be pushed.
Cool. Committed, thanks for the review.
--
Rob
On Thu, Oct 12, 2017 at 9:05 AM, Robert Haas wrote:
> On Wed, Oct 4, 2017 at 9:00 PM, Michael Paquier
> wrote:
>> v4 looks correct to me. Testing it through (pgbench and some custom
>> queries) I have not spotted issues. If the final decision is to use
>> 64-bit query IDs, then this patch could b
On Tue, Oct 10, 2017 at 7:07 AM, amul sul wrote:
> How about the attached patch(0003)?
> Also, the dim variable is renamed to natts.
I'm not sure I believe this comment:
+/*
+ * We arrange the partitions in the ascending order of their modulus
+ * and remainders. Also ev
On 12 October 2017 at 00:57, Konstantin Knizhnik
wrote:
> The reason of such behavior is obvious: wal sender has to decode huge
> transaction generate by insert although it has no relation to this
> publication.
It does. Though I wouldn't expect anywhere near the kind of drop you
report, and hav
On 12 October 2017 at 06:46, Peter Eisentraut
wrote:
> I've been using
>
> --with-extra-version=+git`date +%Y%m%d`"~"`git rev-parse --short HEAD`
>
> for my local builds for some time, and I've not experienced any such
> problems.
Interesting.
I've seen issues with a number of tools. The one I
On 2017/09/30 1:53, Robert Haas wrote:
> On Thu, Sep 28, 2017 at 1:54 AM, Amit Langote
> wrote:
>> I looked into how satisfies_hash_partition() works and came up with an
>> idea that I think will make constraint exclusion work. What if we emitted
>> the hash partition constraint in the following
On Wed, Oct 11, 2017 at 7:47 PM, Robert Haas wrote:
> On Mon, Oct 9, 2017 at 2:05 AM, Ashutosh Bapat
> wrote:
>> On Sat, Oct 7, 2017 at 1:04 AM, Robert Haas wrote:
>>> Committed. I hope that makes things less red rather than more,
>>> because I'm going to be AFK for a few hours anyway.
>>
>> He
Craig Ringer writes:
> On 12 October 2017 at 06:46, Peter Eisentraut
> wrote:
>> I've been using
>> --with-extra-version=+git`date +%Y%m%d`"~"`git rev-parse --short HEAD`
>> for my local builds for some time, and I've not experienced any such
>> problems.
> I've seen issues with a number of tool
Hi hackers,
I don't use Windows myself, but I'd rather avoid submitting patches
that fail to build, build with horrible warnings or blow up on that
fine operating system. I think it would be neat to be able to have
experimental branches of PostgreSQL built and tested on Windows
automatically just
>> test=# CREATE VIEW v3 AS SELECT count(*) FROM v1;
>> CREATE VIEW
>> test=# BEGIN;
>> BEGIN
>> test=# LOCK TABLE v3;
>> ERROR: cannot lock view "v3"
>> DETAIL: Views that return aggregate functions are not automatically
>> updatable.
>
> It would be nice if the message would be something like
On Fri, Oct 6, 2017 at 9:21 PM, Dilip Kumar wrote:
> On Fri, Oct 6, 2017 at 7:24 PM, Dilip Kumar wrote:
>> On Fri, Oct 6, 2017 at 6:08 PM, Alexander Kuzmenkov
>> wrote:
>>>
Analysis: The estimated value of the lossy_pages is way higher than
its actual value and reason is that the total
On 2017-10-11 17:13:20 -0700, Andres Freund wrote:
> Hi,
>
> On 2017-10-11 23:11:15 +, Andres Freund wrote:
> > Add configure infrastructure to detect support for C99's restrict.
> >
> > Will be used in later commits improving performance for a few key
> > routines where information about ali
On 2017-10-11 21:59:53 -0700, Andres Freund wrote:
> That fixed that problem I think. But unfortunately since then another
> problem has been reported by some other animals, all with older msvc
> versions afaict (thrips - vs 2012, bowerbird - vs 2012).
Correction, thrips is vs 2010, not 2012.
--
On Thu, Oct 12, 2017 at 7:55 AM, Peter Eisentraut
wrote:
> It seems to me that having ACL_OBJECT_* symbols alongside OBJECT_*
> symbols is not useful and leads to duplication. Digging around in the
> past suggests that we used to have a lot of these command-specific
> symbols but got rid of them
58 matches
Mail list logo
