On Wed, Jan 17, 2018 at 1:04 PM, Ashutosh Sharma wrote:
> Hi All,
>
> While working on exclusion constraints for one of our internal
> project, I noticed that there is no test-case for exclusion
> constraints in alter_table.sql file. However, for other constraints i
> could see lots of test-cases
On Sat, Jan 20, 2018 at 7:03 AM, Peter Geoghegan wrote:
> On Thu, Jan 18, 2018 at 5:53 PM, Peter Geoghegan wrote:
>
> Attached patch details:
>
> * The patch synchronizes processes used the approach just described.
> Note that this allowed me to remove several #include statements within
> tupleso
Robert Haas writes:
> Well, I'm a little stumped. When I do it the way you did it, it fails
> with the same error you got:
> contrib_regression=# EXPLAIN (VERBOSE, COSTS OFF)
> SELECT * FROM ft1, ft2, ft4, ft5 WHERE ft1.c1 = ft2.c1 AND ft1.c1 = ft4.c1
> AND ft1.c1 = ft5.c1 FOR UPDATE;
> ERRO
On Sat, Jan 20, 2018 at 10:20 AM, Peter Geoghegan wrote:
> On Fri, Jan 19, 2018 at 8:44 PM, Amit Kapila wrote:
>> Right, but I think using parallel_leader_participation, you can do it
>> reliably and probably write some regression tests which can complete
>> in a predictable time.
>
> Do what rel
I wrote:
> FWIW, I suspect that a solution
> that doesn't take into account a metric like coefficient of variation
> will have the wrong behavior sometimes, whether for highly uniform or
> highly non-uniform distributions.
By this I meant the coefficient of variation of the class size in the
sampl
On Fri, Jan 19, 2018 at 8:44 PM, Amit Kapila wrote:
> Right, but I think using parallel_leader_participation, you can do it
> reliably and probably write some regression tests which can complete
> in a predictable time.
Do what reliably? Guarantee that the leader will not participate as a
worker,
On Sat, Jan 20, 2018 at 8:33 AM, Peter Geoghegan wrote:
> On Fri, Jan 19, 2018 at 6:52 PM, Amit Kapila wrote:
>
>> BTW, is there any other way for "parallel create index" to force that
>> the work is done by workers? I am insisting on having something which
>> can test the code path in workers b
On Sun, Jan 7, 2018 at 11:26 PM, Masahiko Sawada wrote:
> On Fri, Jan 5, 2018 at 1:39 AM, Robert Haas wrote:
>> On Tue, Jan 2, 2018 at 1:09 AM, Mithun Cy wrote:
>>> So in case of N_RELEXTLOCK_ENTS = 1 we can see regression as high 25%. ?
>
> Thank you for the performance measurement!
>
>> So no
On Thu, Jan 18, 2018 at 8:53 PM, Robert Haas wrote:
> On Thu, Dec 21, 2017 at 9:13 AM, Amit Kapila wrote:
>> I am not against using the way specific to parallel context layer as
>> described by you above. However, I was trying to see if there is
>> some general purpose solution as the low-impac
On Fri, Jan 19, 2018 at 6:52 PM, Amit Kapila wrote:
> Or reverse is also possible which means the workers won't get chance
> to run the plan in which case we can use parallel_leader_participation
> = off to test workers behavior. As said before, I see only that as
> the reason to keep parallel_le
On Sat, Jan 20, 2018 at 2:57 AM, Thomas Munro
wrote:
> On Sat, Jan 20, 2018 at 6:32 AM, Robert Haas wrote:
>> On Fri, Jan 19, 2018 at 12:16 PM, Peter Geoghegan wrote:
>>> Clarity on what I should do about parallel_leader_participation in the
>>> next revision would be useful at this point. You s
On Fri, Jan 19, 2018 at 10:50 AM, Robert Haas wrote:
>> Hm. It did fail as advertised when I connected to the contrib_regression
>> database (after installcheck) and entered the query by hand; I
>> copied-and-pasted the result of that to show you. It's possible that it
>> would not have failed i
On Fri, Jan 19, 2018 at 5:19 PM, Tomas Vondra
wrote:
> Regarding the HOT issue - I have to admit I don't quite see why A2
> wouldn't be reachable through the index, but that's likely due to my
> limited knowledge of the HOT internals.
The index entries only point to the root tuple in the HOT chai
On 01/19/2018 08:33 PM, Robert Haas wrote:
> On Fri, Jan 19, 2018 at 2:16 PM, Tomas Vondra
> wrote:
>> I think an important piece of this puzzle is that we only really care
>> about catalog changes made in a transaction that aborts after doing some
>> additional changes, with that catalog tuple
> On 19 Jan 2018, at 19:43, Peter Eisentraut
> wrote:
> 0003-Move-EDH-support-to-common-files.patch
>
> To avoid copy-and-paste, and also because the EDH explanation doesn't
> really belong in a file header comment. Maybe the whole thing is known
> well enough nowadays that we can just remove
On 01/19/2018 03:34 PM, Tomas Vondra wrote:
> Attached is v5, fixing a silly bug in part 0006, causing segfault when
> creating a subscription.
>
Meh, there was a bug in the sgml docs ( vs. ),
causing another failure. Hopefully v6 will pass the CI build, it does
pass a build with the same paramet
On Fri, Jan 19, 2018 at 3:56 AM, Amit Langote
wrote:
> I rebased the patches, since they started conflicting with a recently
> committed patch [1].
I think that my latest commit has managed to break this pretty thoroughly.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
Peter Eisentraut wrote:
> On 1/19/18 14:07, David Steele wrote:
> > I have yet to add tests for pg_rewindwal and pg_upgrade. pg_rewindwal
> > doesn't *have* any tests as far as I can tell and pg_upgrade has tests
> > in a shell script -- it's not clear how I would extend it or reuse the
> > Perl c
On 1/19/18 14:07, David Steele wrote:
> I have yet to add tests for pg_rewindwal and pg_upgrade. pg_rewindwal
> doesn't *have* any tests as far as I can tell and pg_upgrade has tests
> in a shell script -- it's not clear how I would extend it or reuse the
> Perl code for perm testing.
>
> Does an
On Sat, Jan 20, 2018 at 6:32 AM, Robert Haas wrote:
> On Fri, Jan 19, 2018 at 12:16 PM, Peter Geoghegan wrote:
>> Clarity on what I should do about parallel_leader_participation in the
>> next revision would be useful at this point. You seem to either want
>> me to remove it from consideration en
Robert Haas writes:
> On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane wrote:
>> What do people think of just removing this DROP DATABASE restriction?
>> Arguably, superusers should know better than to drop template1 anyway.
>> Maybe we should replace it with a hard-wired check against dropping
>> templ
On Fri, Jan 19, 2018 at 2:54 PM, Tom Lane wrote:
> Hmm ... so there's a small problem with this idea of dropping and
> recreating template1:
>
> pg_restore: connecting to database for restore
> pg_restore: dropping DATABASE template1
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_r
On Fri, Jan 19, 2018 at 4:37 AM, Amit Khandekar wrote:
> Attached rebased patch.
Committed with a bunch of mostly-cosmetic revisions. I removed the
macro you added, which has a multiple evaluation hazard, and just put
that logic back into the function. I don't think it's likely to
matter for pe
On 1/17/18 23:52, Michael Paquier wrote:
> On Wed, Jan 17, 2018 at 05:23:25PM -0500, Peter Eisentraut wrote:
>> On 1/16/18 23:38, Michael Paquier wrote:
>>> + if (prop->objtype == OBJECT_TABLE)
>>> + /*
>>> +* If the property data says it's a table, dig a little deeper to
>>> get
>
Hmm ... so there's a small problem with this idea of dropping and
recreating template1:
pg_restore: connecting to database for restore
pg_restore: dropping DATABASE template1
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 3024; 1262 1 DATAB
On Fri, Jan 19, 2018 at 2:16 PM, Tomas Vondra
wrote:
> I think an important piece of this puzzle is that we only really care
> about catalog changes made in a transaction that aborts after doing some
> additional changes, with that catalog tuple in place. Because only then
> we actually need that
On 01/19/2018 06:54 PM, Robert Haas wrote:
> On Tue, Dec 26, 2017 at 9:21 AM, Nikhil Sontakke
> wrote:
>> The main issue here is that HeapTupleSatisfiesVacuum *assumes* that
>> rows belonging to an aborted transaction are not visible to anyone
>> else.
>
> One problem here is that if a transacti
Tom Lane wrote:
> Alvaro Herrera writes:
> > Local partitioned indexes
>
> Evidently you're not there yet. I'm suspicious that the continuing
> failures on dromedary may trace to its use of -DCOPY_PARSE_PLAN_TREES
> ... try looking for a missed field addition in copyfuncs.c.
I had already tried
On 1/19/18 3:08 AM, Michael Paquier wrote:
> On Wed, Jan 10, 2018 at 03:19:46PM -0300, Alvaro Herrera wrote:
>> David Steele wrote:
>>> On 1/8/18 8:58 PM, Peter Eisentraut wrote:
>>
Yeah, I didn't like this aspect when this patch was originally
submitted. We want to keep the code legible
On 01/19/2018 07:35 PM, Claudio Freire wrote:
>
>
> On Fri, Jan 19, 2018 at 2:22 PM, Tomas Vondra
> mailto:tomas.von...@2ndquadrant.com>> wrote:
>
>
>
> On 01/19/2018 06:13 PM, Claudio Freire wrote:
> >
> >
> > On Fri, Jan 19, 2018 at 2:07 PM, Konstantin Knizhnik
> > mail
On Wed, Jan 17, 2018 at 10:02 PM, Tom Lane wrote:
> Also, this isn't really a good argument against using uniform names
> for parameters that every implementation is certain to have, like
> ssl_key_file.
Even then, it's not that hard to imagine minor variations between what
different implementati
Comparing the existing {be,fe}-secure-openssl.c with the proposed
{be,fe}-secure-gnutls.c, and with half an eye on the previously proposed
Apple Secure Transport implementation, I have identified a few more
areas of refactoring that should be done in order to avoid excessive
copy-and-pasting in the
On Fri, Jan 19, 2018 at 2:22 PM, Tomas Vondra
wrote:
>
>
> On 01/19/2018 06:13 PM, Claudio Freire wrote:
> >
> >
> > On Fri, Jan 19, 2018 at 2:07 PM, Konstantin Knizhnik
> > mailto:k.knizh...@postgrespro.ru>> wrote:
> >
> >
> >
> >
> > Well, I haven't said it has to be single-threaded lik
On Tue, Dec 26, 2017 at 9:21 AM, Nikhil Sontakke
wrote:
> The main issue here is that HeapTupleSatisfiesVacuum *assumes* that
> rows belonging to an aborted transaction are not visible to anyone
> else.
One problem here is that if a transaction aborts, it might have done
so after inserting or upd
On Fri, Jan 19, 2018 at 12:16 PM, Peter Geoghegan wrote:
> On Fri, Jan 19, 2018 at 4:52 AM, Robert Haas wrote:
>>> Other than that, looks good to me. It's a simple patch with a clear purpose.
>>
>> Committed.
>
> Cool.
>
> Clarity on what I should do about parallel_leader_participation in the
> n
On 01/19/2018 06:19 PM, Konstantin Knizhnik wrote:
>
>
> On 19.01.2018 20:03, Claudio Freire wrote:
>>
>>
>> On Fri, Jan 19, 2018 at 1:53 PM, Konstantin Knizhnik
>> mailto:k.knizh...@postgrespro.ru>> wrote:
>>
>>
>>
>> On 19.01.2018 19:28, Pavel Stehule wrote:
>>>
>>>
>>> When I
On 01/19/2018 06:13 PM, Claudio Freire wrote:
>
>
> On Fri, Jan 19, 2018 at 2:07 PM, Konstantin Knizhnik
> mailto:k.knizh...@postgrespro.ru>> wrote:
>
>
>
>
> Well, I haven't said it has to be single-threaded like pgbouncer. I
> don't see why the bgworker could not use multi
On 01/19/2018 06:07 PM, Konstantin Knizhnik wrote:
>
> ...
>
3) Is there any sort of shrinking the pools? I mean, if the backend is
idle for certain period of time (or when we need backends for other
databases), does it get closed automatically?
>>> When client is disconnecte
On 19.01.2018 20:03, Claudio Freire wrote:
On Fri, Jan 19, 2018 at 1:53 PM, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
On 19.01.2018 19:28, Pavel Stehule wrote:
When I've been thinking about adding a built-in
connection pool, my
On Fri, Jan 19, 2018 at 4:52 AM, Robert Haas wrote:
>> Other than that, looks good to me. It's a simple patch with a clear purpose.
>
> Committed.
Cool.
Clarity on what I should do about parallel_leader_participation in the
next revision would be useful at this point. You seem to either want
me
On Fri, Jan 19, 2018 at 2:07 PM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
>
>> Well, I haven't said it has to be single-threaded like pgbouncer. I
>> don't see why the bgworker could not use multiple threads internally (of
>> course, it'd need to be not to mess the stuff that is
On 19.01.2018 20:01, Pavel Stehule wrote:
2018-01-19 17:53 GMT+01:00 Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>>:
On 19.01.2018 19:28, Pavel Stehule wrote:
When I've been thinking about adding a built-in
connection pool, my
rough plan
On Fri, Jan 19, 2018 at 2:06 PM, Tomas Vondra
wrote:
>
>
> On 01/19/2018 06:03 PM, Claudio Freire wrote:
> >
> >
> > On Fri, Jan 19, 2018 at 1:53 PM, Konstantin Knizhnik
> > mailto:k.knizh...@postgrespro.ru>> wrote:
> >
> >
> >
> > On 19.01.2018 19:28, Pavel Stehule wrote:
> >>
> >>
> >>
On 19.01.2018 19:59, Tomas Vondra wrote:
The problem can be much easily solved in case of using pthread version
of Postgres. In this case reassigning session to another executor
(thread) can be don much easily.
And there is no need to use unportable trick with passing fiel
descriptor to other
On 01/19/2018 06:03 PM, Claudio Freire wrote:
>
>
> On Fri, Jan 19, 2018 at 1:53 PM, Konstantin Knizhnik
> mailto:k.knizh...@postgrespro.ru>> wrote:
>
>
>
> On 19.01.2018 19:28, Pavel Stehule wrote:
>>
>>
>> When I've been thinking about adding a built-in connection
>>
On Fri, Jan 19, 2018 at 1:53 PM, Konstantin Knizhnik <
k.knizh...@postgrespro.ru> wrote:
>
>
> On 19.01.2018 19:28, Pavel Stehule wrote:
>
>
>
> When I've been thinking about adding a built-in connection pool, my
>>> rough plan was mostly "bgworker doing something like pgbouncer" (that
>>> is, lis
On 01/19/2018 05:53 PM, Konstantin Knizhnik wrote:
>
>
> On 19.01.2018 19:28, Pavel Stehule wrote:
>>
>>
>> When I've been thinking about adding a built-in connection
>> pool, my
>> rough plan was mostly "bgworker doing something like
>> pgbouncer" (that
>>
2018-01-19 17:53 GMT+01:00 Konstantin Knizhnik :
>
>
> On 19.01.2018 19:28, Pavel Stehule wrote:
>
>
>
> When I've been thinking about adding a built-in connection pool, my
>>> rough plan was mostly "bgworker doing something like pgbouncer" (that
>>> is, listening on a separate port and proxying e
On 01/19/2018 05:17 PM, Konstantin Knizhnik wrote:
>
>
> On 19.01.2018 18:53, Tomas Vondra wrote:
>>
>> ...
>>
>> The questions I'm asking myself are mostly these:
>>
>> 1) When assigning a backend, we first try to get one from a pool, which
>> happens right at the beginning of BackendStartup. If
On 19.01.2018 19:28, Pavel Stehule wrote:
When I've been thinking about adding a built-in connection
pool, my
rough plan was mostly "bgworker doing something like
pgbouncer" (that
is, listening on a separate port and proxying everything to
regul
On 19.01.2018 16:14, Antonin Houska wrote:
Konstantin Knizhnik wrote:
On 11.01.2018 12:34, Antonin Houska wrote:
Konstantin Knizhnik wrote:
I haven't thought that much about details, so just one comment: you shouldn't
need the conversion to text and back to binary form. utils/adt/rangetype
Ok great. Thanks Michael and Stephen for the explanations.
When I've been thinking about adding a built-in connection pool, my
>> rough plan was mostly "bgworker doing something like pgbouncer" (that
>> is, listening on a separate port and proxying everything to regular
>> backends). Obviously, that has pros and cons, and probably would not
>> work serve t
Hi,
On 01/19/2018 03:34 PM, Simon Riggs wrote:
> On 26 December 2017 at 14:21, Nikhil Sontakke wrote:
>
>> With logical decoding, there might arise a case that such a row, if it
>> belongs to a system catalog table or even a user catalog table
>> (https://git.postgresql.org/gitweb/?p=postgresql.
Robert Haas writes:
> On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote:
Well, we could say that the properties of template1 and postgres
are only restored if you use --clean.
>>> True. Would that be a POLA v
On 19.01.2018 18:53, Tomas Vondra wrote:
On 01/19/2018 10:52 AM, Konstantin Knizhnik wrote:
On 18.01.2018 18:02, Tomas Vondra wrote:
Hi Konstantin,
On 01/18/2018 03:48 PM, Konstantin Knizhnik wrote:
On 17.01.2018 19:09, Konstantin Knizhnik wrote:
Hi hackers,
...
I haven't looked at the
On 01/19/2018 10:52 AM, Konstantin Knizhnik wrote:
>
>
> On 18.01.2018 18:02, Tomas Vondra wrote:
>> Hi Konstantin,
>>
>> On 01/18/2018 03:48 PM, Konstantin Knizhnik wrote:
>>> On 17.01.2018 19:09, Konstantin Knizhnik wrote:
Hi hackers,
...
>> I haven't looked at the code yet, bu
On Fri, Jan 19, 2018 at 10:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 19, 2018 at 1:53 AM, Etsuro Fujita
>> wrote:
>>> I noticed that this test case added by the patch is not appropriate:
>>> because it doesn't inject extra Sort nodes into EPQ recheck plans, so it
>>> works well
Robert Haas writes:
> On Fri, Jan 19, 2018 at 1:53 AM, Etsuro Fujita
> wrote:
>> I noticed that this test case added by the patch is not appropriate:
>> because it doesn't inject extra Sort nodes into EPQ recheck plans, so it
>> works well without the fix. I modified this to inject a Sort into t
Hello everyone,
I would like to contribute to documentation review of the patches
discussed in thread
https://www.postgresql.org/message-id/flat/cy4pr17mb13207ed8310f847cf117eed0d8...@cy4pr17mb1320.namprd17.prod.outlook.com
(https://commitfest.postgresql.org/16/1403/). Unfortunately, I was not
=?iso-8859-1?Q?J=F6rg?= Westheide writes:
> When doing a "make check" on Mac OS X with SIP (aka rootless mode)
> enabled it will fail like this:
> ...
Yeah, well-known problem. AFAIK, all PG developers who use Macs just
disable SIP immediately.
> The problem is that the psql links to libpq whi
On 18.01.2018 18:00, Claudio Freire wrote:
On Thu, Jan 18, 2018 at 11:48 AM, Konstantin Knizhnik
mailto:k.knizh...@postgrespro.ru>> wrote:
Attached please find new version of the patch with few fixes.
And more results at NUMA system with 144 cores and 3Tb of RAM.
Read-only pg
On Fri, Jan 19, 2018 at 1:53 AM, Etsuro Fujita
wrote:
> I noticed that this test case added by the patch is not appropriate:
>
> +-- multi-way join involving multiple merge joins
> +EXPLAIN (VERBOSE, COSTS OFF)
> +SELECT * FROM ft1, ft2, ft4, ft5 WHERE ft1.c1 = ft2.c1 AND ft1.c1 = ft4.c1
> +AN
On Fri, Jan 19, 2018 at 9:54 AM, Jörg Westheide
wrote:
> When doing a "make check" on Mac OS X with SIP (aka rootless mode) enabled
> it will fail like this:
I don't know whether this fix is any good, but thanks for working on
the problem. It's a very annoying problem, and I'd love to see it
sol
On Fri, Jan 19, 2018 at 10:00 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote:
>>> Well, we could say that the properties of template1 and postgres
>>> are only restored if you use --clean.
>
>> True. Would that be a POLA violation, do you think?
>
>
Robert Haas writes:
> On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote:
>> Well, we could say that the properties of template1 and postgres
>> are only restored if you use --clean.
> True. Would that be a POLA violation, do you think?
It seems a bit non-orthogonal. Also, while your point that
Hi!
When doing a "make check" on Mac OS X with SIP (aka rootless mode)
enabled it will fail like this:
- >8 snip 8< -
rm -rf ./testtablespace
mkdir ./testtablespace
PATH="/Volumes/Home/arbeit/port25/postgresql-clean/tmp_install/usr/local/pgsql/bin:$PATH"
DYLD_LIBRARY_PATH="//tmp_insta
On Fri, Jan 19, 2018 at 9:45 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane wrote:
>>> If we did it like that, the rationale for an actual --set-db-properties
>>> switch would vanish, at least so far as pg_dumpall is concerned -- we
>>> could just make all
Robert Haas writes:
> On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane wrote:
>> If we did it like that, the rationale for an actual --set-db-properties
>> switch would vanish, at least so far as pg_dumpall is concerned -- we
>> could just make all that behavior an integral part of --create. And
>> thi
On Fri, Jan 19, 2018 at 4:56 AM, Yoshimi Ichiyanagi
wrote:
>>Was the only non-default configuration setting wal_sync_method? i.e.
>>synchronous_commit=on? No change to max_wal_size?
> No, I used the following parameter in postgresql.conf to prevent
> checkpoints from occurring while running the
On 26 December 2017 at 14:21, Nikhil Sontakke wrote:
> With logical decoding, there might arise a case that such a row, if it
> belongs to a system catalog table or even a user catalog table
> (https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=66abc2608c7c00fcd449e00a9e23f13f02e6
Attached is v5, fixing a silly bug in part 0006, causing segfault when
creating a subscription.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
0001-Introduce-logical_work_mem-to-limit-ReorderBuffer-v5.pa
Michael, all,
* Michael Paquier (michael.paqu...@gmail.com) wrote:
> On Thu, Jan 18, 2018 at 02:04:45PM +, Ryan Murphy wrote:
> > I had not tried this before with my unpatched build of postgres. (In
> > retrospect of course I should have). I expected my superuser to be
> > able to perform th
On Thu, Jan 18, 2018 at 6:35 PM, Tom Lane wrote:
> If we did it like that, the rationale for an actual --set-db-properties
> switch would vanish, at least so far as pg_dumpall is concerned -- we
> could just make all that behavior an integral part of --create. And
> this wouldn't need to be condi
Hi Jesper
Jesper Pedersen wrote:
> I get
>
> pg_restore: creating INDEX "pg_catalog.pg_authid_oid_index"
> pg_restore: [archiver (db)] Error while PROCESSING TOC:
> pg_restore: [archiver (db)] Error from TOC entry 5493; 1259 2677 INDEX
> pg_authid_oid_index jpedersen
> pg_restore: [archiver (db)
В письме от 18 января 2018 18:42:01 пользователь Tom Lane написал:
> >> This patch raises error if user tries o set or change toast.* option for
> >> a
> >> table that does not have a TOST relation.
> >
> > I think there is a problem with this idea, which is that the rules for
> > whether or not a
Hi Alvaro,
On 01/18/2018 04:43 PM, Alvaro Herrera wrote:
Here's a patch to add pg_dump tests. This verifies that the
CREATE INDEX on parent and partition appear, as well as ALTER INDEX ..
ATTACH PARTITION.
While doing this, I noticed a small bug: the ALTER INDEX would not be
dumped when only o
Hi Peter,
Il 18/01/18 17:30, Peter Eisentraut ha scritto:
> On 1/17/18 11:33, Petr Jelinek wrote:
>>> P.S: I'm struggling to understand why we have two possible values of
>>> session_replication_role settings that behave identically (origin and
>>> local). I'm unable to see any difference accordin
On 16 January 2018 at 20:24, Andrew Dunstan
wrote:
> Looks good. Marking ready for committer.
Few questions/points for the docs.
Docs say: "A new transaction is started automatically after a
transaction is ended using these commands"
Presumably this would have exactly the same isolation level a
On 6 December 2017 at 22:34, Merlin Moncure wrote:
> On Wed, Dec 6, 2017 at 8:41 AM, Peter Eisentraut
> wrote:
>> On 12/5/17 13:33, Robert Haas wrote:
>>> On Tue, Dec 5, 2017 at 1:25 PM, Peter Eisentraut
>>> wrote:
I think ROLLBACK in a cursor loop might not make sense, because the
cur
Konstantin Knizhnik wrote:
> On 11.01.2018 12:34, Antonin Houska wrote:
> > Konstantin Knizhnik wrote:
> > I haven't thought that much about details, so just one comment: you
> > shouldn't
> > need the conversion to text and back to binary form. utils/adt/rangetypes.c
> > contains constructor
On Thu, Jan 18, 2018 at 2:05 PM, Peter Geoghegan wrote:
> Review of your patch:
>
> * SerializedReindexState could use some comments. At least a one liner
> stating its basic purpose.
Added a comment.
> * The "System index reindexing support" comment block could do with a
> passing acknowledgeme
>> [1] Occasionally it will store a much longer MCV list, because no values
>> was
>> sampled exactly once, which triggers a different code path in which all
>> seen
>> values are put in the MCV and the histogram is NULL. This is not
>> reliable,
>> as whether the least-sample value is present in
Re: Peter Eisentraut 2018-01-17
> On 1/17/18 10:14, Christoph Berg wrote:
> > The difference is that when parsing version() (which is all my variant
> > is changing), people already have to deal with extra stuff at the end
> > (gcc version), while that would be new for "psql --version".
>
> For
Hi All,
Il 18/01/18 17:48, Simon Riggs ha scritto:
> On 17 January 2018 at 17:07, Petr Jelinek
> wrote:
>
>> Things I am less convinced about:
>>
>> The patch will cascade truncation on downstream if cascade was specified
>> on the upstream, that can potentially be dangerous and we either shoul
On 19 January 2017 at 09:37, Kyotaro HORIGUCHI
wrote:
>
> Though I haven't look closer to how a modification is splitted
> into WAL records. A tuple cannot be so long. As a simple test, I
> observed rechder->xl_tot_len at the end of XLogRecordAssemble
> inserting an about 400KB not-so-compressable
On 18 January 2018 at 17:14, Peter Eisentraut
wrote:
> On 12/29/17 07:01, Marco Nenciarini wrote:
>> The current behavior of session_replication_role = replica with TRUNCATE
>> is not the same of with the other commands.
>> It does not check FKs for INSERT/UPDATE/DELETE but it does for TRUNCATE,
>
On 2018/01/19 18:50, Amit Khandekar wrote:
> FYI ...
>
> For the pending update-partition-key patch, we would again require the
> rel variable for UPDATE. So in the rebased update-partition-key patch
> [1], 'rel' is assigned the root partitioned table. But this time, I
> have used the already open
On 19 January 2018 at 08:25, Simon Riggs wrote:
> On 17 January 2018 at 05:49, Jeff Davis wrote:
>> On Wed, Jan 10, 2018 at 7:49 AM, Simon Riggs wrote:
>>> Do we optimize for TIMESTAMP <@ RANGE as well?
>>
>> Not currently. It requires a little extra complexity because empty
>> ranges will match
Thank you for your reply.
Wed, 17 Jan 2018 15:29:11 -0500Robert Haas wrote :
>> Using pgbench which is a PostgreSQL general benchmark, the postgres server
>> to which the patches is applied is about 5% faster than original server.
>> And using my insert benchmark, it is up to 90% faster than ori
On 18.01.2018 18:02, Tomas Vondra wrote:
Hi Konstantin,
On 01/18/2018 03:48 PM, Konstantin Knizhnik wrote:
On 17.01.2018 19:09, Konstantin Knizhnik wrote:
Hi hackers,
...
I haven't looked at the code yet, but after reading your message I have
a simple question - gow iss this going to work
FYI ...
For the pending update-partition-key patch, we would again require the
rel variable for UPDATE. So in the rebased update-partition-key patch
[1], 'rel' is assigned the root partitioned table. But this time, I
have used the already opened node->rootResultRelInfo to get the root
partitioned
> I'm fine with the current shape. Thanks. Maybe the same
> discussion applies to polygons. (cf. poly_overlap)
It indeed does. I am incorporating.
> line_closept_point asserts line_interpt_line returns true but it
> is hazardous. It is safer if line_closept_point returns NaN if
> line_interpt
Thanks for taking a look.
On 2018/01/19 14:39, Michael Paquier wrote:
> On Thu, Jan 18, 2018 at 06:54:18PM +0900, Amit Langote wrote:
>> I think having pg_partition_root() and pg_partition_parent() will give
>> users enough to get useful views as follows:
>
> So... pg_partition_root() gives you a
On 19 January 2018 at 16:00, Kyotaro HORIGUCHI
wrote:
> And I'd like to ask David to check out his mail environment so
> that SPF record is available for his message.
Will investigate
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training
On Wed, Nov 29, 2017 at 7:48 AM, Michael Paquier
wrote:
> On Tue, Sep 5, 2017 at 11:51 AM, Andres Freund wrote:
> > On 2017-09-05 11:36:47 +0900, Michael Paquier wrote:
> >> On Thu, Aug 31, 2017 at 9:19 PM, Magnus Hagander
> wrote:
> >> > PFA an updated and rebased patch.
> >> >
> >> > Rebased.
On Fri, Jan 19, 2018 at 10:54:53AM +0900, Kyotaro HORIGUCHI wrote:
> On the other hand if one logical record must be read from single
> source, we need any means to deterrent wal-recycling on the
> primary side. Conducting that within the primary side is rejected
> by consensus.
There is this appr
On 2017/12/19 19:06, Amit Langote wrote:
> Hi.
>
> I have a patch that rearranges the code around partition tuple-routing,
> such that allocation of per-partition objects (ResultRelInfo,
> TupleConversionMap, etc.) is delayed until a given partition is actually
> inserted into (i.e., a tuple is ro
On Fri, Jan 19, 2018 at 3:39 PM, Simon Riggs wrote:
> On 19 January 2018 at 05:38, Masahiko Sawada wrote:
>> Hi,
>>
>> Attached patch for fixing a typo in slotfuncs.c
>>
>> s/possition/position/
>
> Fixed, thanks.
>
Thank you!
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORAT
Hello,
At Thu, 18 Jan 2018 16:01:01 +0100, Emre Hasegeli wrote in
> > 0001:
> >
> > - You removed the check of parallelity check of
> > line_interpt_line(old line_interpt_internal) but line_parallel
> > is not changed so the consistency between the two functions are
> > lost. It is better
1 - 100 of 104 matches
Mail list logo
