Re: [HACKERS] Simplify ACL handling for large objects and removal of superuser() checks

ould be easier to identify all superusers, including those whose superuserishness derives from a known export, and (2) a syntax change for GRANT that would require an extra token, so that you'd have to write something like GRANT EXPLOITABLE lo_export TO trusted_user_foo so that you couldn't unknowingly grant a dangerous privilege. Or is there more to it than that? mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PATCH: multivariate histograms and MCV lists

ur patches need updating. Tom's commit 471d55859c11b40059aef7dd82f82b3a0dc338b1 changed src/bin/psql/describe.c, which breaks your 0001-multivariate-MCV-lists.patch.gz file. I reviewed the patch a few months ago, and as I recall, it looked good to me. I should review it again before approving it, thoug

Re: [HACKERS] Add some const decorations to prototypes

> On Oct 31, 2017, at 7:46 AM, Peter Eisentraut > wrote: > > Here is a patch that adds const decorations to many char * arguments in > functions. It should have no impact otherwise; there are very few code > changes caused by it. Some functions have a

Re: [HACKERS] proposal: schema variables

nly? mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

On 26/09/17 20:44, Mark Kirkwood wrote: $ pg_basebackup -D . WARNING:  could not read symbolic link "pg_tblspc/space1": Invalid argument pg_basebackup: directory "/data0/pgdata/11/pg_tblspc/space1" exists but is not empty pg_basebackup: removing contents of data

Re: [HACKERS] Bug with pg_basebackup and 'shared' tablespace

it with me like this (paraphrasing) 'So this pg_basebackup thing is a bit temperamental...'. I'm thinking we do not want to be giving users this impression. regards Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgre

Re: [HACKERS] md5 still listed as an option in pg_hba.conf.sample

> On Sep 26, 2017, at 10:36 AM, Bruce Momjian <br...@momjian.us> wrote: > > On Tue, Sep 26, 2017 at 10:23:55AM -0700, Mark Dilger wrote: >> The comment that I think needs updating is: >> >> # METHOD can be "trust", "reject", "md5",

[HACKERS] md5 still listed as an option in pg_hba.conf.sample

The comment that I think needs updating is: # METHOD can be "trust", "reject", "md5", "password", "scram-sha-256", # "gss", "sspi", "ident", "peer", "pam", "ldap", "radius" o

Re: [HACKERS] tablespaces inside $PGDATA considered harmful

g_tblspc/space1" exists but is not empty pg_basebackup: removing contents of data directory "." So pg_basebackup is completely broken by this construction - should we not prohibit the creation of tablespace directories under $PGDATA (or at least $PGDATA/pg_tblspc) at this point?

Re: [HACKERS] Renaming PG_GETARG functions (was Re: PG_GETARG_GISTENTRY?)

> On Sep 12, 2017, at 1:07 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > [ changing subject line to possibly draw more attention ] > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Apr 5, 2017, at 9:23 AM, Tom Lane <t...@sss.pgh.pa.us> wrote:

Re: [HACKERS] More flexible LDAP auth search filters?

I would end up deploying onto servers. This happens a lot in large organisations whereby getting group memberships updated in the main directory can take days/weeks whereas someone with root access to the server itself can hard-code an authentication list of users and/or groups in an LDAP filter

Re: [HACKERS] MAIN, Uncompressed?

tion . +1, have thought about this myself previouslythank you for bringing it up! regards Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

esults? > Best Regards, Mark Rofail

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Aug 10, 2017, at 11:20 AM, Robert Haas <robertmh...@gmail.com> wrote: > > On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >> I can understand this, but wonder if I could use something like >> >> FOR I TOTALLY PROMISE

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

it's a polymorphic function. > If so, we don't introduce additional restriction here... > You mean to remove the wrapper query ? > GROUP BY would also use default btree/hash opclass for element type. It > doesn't differ from DISTINCT from that point. > Then there's no going around this limitation, Best Regard, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

This is the query fired upon any UPDATE/DELETE for RI checks: SELECT 1 FROM ONLY x WHERE pkatt1 = $1 [AND ...] FOR KEY SHARE OF x in the case of foreign key arrays, it's wrapped in this query: SELECT 1 WHERE (SELECT count(DISTINCT y) FROM unnest($1) y) = (SELECT count(*) FROM () z)

Re: [HACKERS] More flexible LDAP auth search filters?

self. But if it's documented that's not a reason to reject the patch as I definitely see it as an improvement. As I mentioned previously in the thread, the main barrier preventing people from using LDAP is that the role cannot be generated from other attributes in the directory. In a lot of real-life

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Regards, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

of count(distinct x) *must not* vary > > depending on what indexes happen to be available. > > Err ... > > > I think what you meant to say is that the planner may only choose an > > optimization of this sort when the index's opclass matches the one > > DISTINCT will use, ie the default for the data type. I understand the problem. I am currently researching how to resolve it. Best Regards, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

These are limitations of the patch ordered by importance: ✗ presupposes that count(distinct y) has exactly the same notion of equality that the PK unique index has. In reality, count(distinct) will fall back to the default btree opclass for the array element type. - Supported actions: ✔ NO

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Fri, Jul 28, 2017 at 1:19 PM, Erik Rijkers wrote: > One small thing while building docs: > > $ cd doc/src/sgml && make html > osx -wall -wno-unused-param -wno-empty -wfully-tagged -D . -D . -x lower > postgres.sgml >postgres.xml.tmp > osx:ref/create_table.sgml:960:100:E:

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

er of the referencing array or the whole array. I think there's a lot of options the user might want to consider and it's hard to generalize to DELETE CASCADE. Maybe new grammar would be introduced here ?| Best Regards, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

Best Regards, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Thu, Jul 27, 2017 at 12:54 PM, Alexander Korotkov wrote: > > How many rows of FK table were referencing the PK table row you're > updating/deleting. > I wonder how may RI trigger work so fast if it has to do some job besides > index search with no results? > The problem

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

ntributor would likely find it extremely difficult to sort all of > the problems that would result from a change in this area. Best Regards, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

> > However, there is a bug that prevented me from testing the third scenario, > I assume there's an issue of incompatible types problem since the right > operand type is anyelement and the supporting procedures expect anyarray. > I am working on debugging it right now. > I have also solved the

Re: [HACKERS] autovacuum can't keep up, bloat just continues to rise

eletes) - as on modern HW a lot of churn can happen in 1 minute, and that just makes vacuum's job harder. regards Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Wed, Jul 19, 2017 at 10:08 PM, Alvaro Herrera wrote: > So let's step back a bit, > get a patch that works for the case where the types match on both sides > of the FK, then we review that patch; if all is well, we can discuss the > other problem as a stretch goal.

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

ause the type will be removed. But that is the same and no worse than what they would get if we just remove the abstime type in postgres 11 without any replacement. I'm not implementing any of this yet, as I expect further objections. Thoughts? mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

better by timestamptz (paraphrase), and so I said that improving storage efficiency was such a use. I maintain that position. The abstime type is a good and useful type, and we will lose that use when we discard it. Those who feel otherwise might like to also argue for dropping float4 because float

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Wed, Jul 19, 2017 at 7:28 PM, Robert Haas wrote: > Why do we have to solve that limitation? Since the regress test labled element_foreing_key fails now that I made the RI queries utilise @(anyarray, anyelement), that means it's not functioning as it is meant to be.

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

id actually enhances the performance of the RI checks. How can I go about this? Best Regards, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

ations of int4[] @>> int8, int4[] @>> int4, int4[] @>> int2, int4[] @>> numeric. So I think implementing operators is the way to go. Best Regards, Mark Rofail.

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 18, 2017, at 9:13 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > >> >> On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> >>> >>> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us>

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 2:34 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > >> >> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> Mark Dilger <hornschnor...@gmail.com> writes: >>>> On Jul 17, 2017, at 12:54

Re: [HACKERS] More flexible LDAP auth search filters?

On 17/07/17 18:08, Magnus Hagander wrote: > On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland > <mark.cave-ayl...@ilande.co.uk <mailto:mark.cave-ayl...@ilande.co.uk>> > wrote: > Great to hear from you! It has definitely been a while... > > Indeed. You should

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Tue, 18 Jul 2017 at 7:43 pm, Alexander Korotkov wrote: > separate operators for int4[] @>> int8, int4[] @>> int4, int4[] @>> int2, > int4[] @>> numeric. > My only comment on the separate operators is its high maintenance. Any new datatype introduced a corresponding

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Tue, 18 Jul 2017 at 7:43 pm, Alexander Korotkov <aekorot...@gmail.com> wrote: > On T upue, Jul 18, 2017 at 2:24 AM, Mark Rofail <markm.rof...@gmail.com> > wrote: > >> On Wed, Jul 12, 2017 at 12:53 AM, Alvaro Herrera < >> alvhe...@2ndquadrant.com> wrot

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Well, if you or somebody is willing to do the legwo

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Wed, Jul 12, 2017 at 12:53 AM, Alvaro Herrera wrote: > > We have one opclass for each type combination -- int4 to int2, int4 to > int4, int4 to int8, etc. You just need to add the new strategy to all > the opclasses. I tried this approach by manually declaring

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> On Jul 17, 2017, at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Now, this should mostly work conveniently, except t

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 3:12 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> Well, if you or somebody is willing to do the legwo

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 2:14 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >>> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >> On Jul 15, 2017, at 3:00 PM, Tom Lane <t...

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

> On Jul 17, 2017, at 12:54 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > >> On Jul 15, 2017, at 3:00 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> >> The types abstime, reltime, and tinterval need to go away, or be >> reimplemented, some

Re: [HACKERS] Something for the TODO list: deprecating abstime and friends

ee and politely refuse to merge in your change which removes them. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] More flexible LDAP auth search filters?

ddress was entered. In terms of matching multiple users, all LDAP authentication routines I've seen will fail if more than one DN matches the search filter, so this nicely handles the cases where either the custom filter is incorrect or more than one entry is accidentally matched in the directory.

Re: [HACKERS] More flexible LDAP auth search filters?

as been mandatory for v3 and is implemented on AD). And yes, while better authentication mechanisms do exist, I find that all too often most software packages claim LDAP support rather than Kerberos, and even then it is often limited to LDAP simple binds without ldaps support. ATB, Ma

Re: [HACKERS] More flexible LDAP auth search filters?

r disabled or misconfigured sending plaintext passwords over the wire regardless, so it's generally easiest to firewall ldap port 389 at the edge of the trusted VLAN so that only ldaps port 636 connections make it out onto the untrusted network hosting the local AD/OpenLDAP server. ATB, Mark.

Re: [HACKERS] More flexible LDAP auth search filters?

l the other use-cases. As an example, I don't know if anyone would actually do this with PostgreSQL but I've been asked on multiple occasions to configure software so that users should be allowed to log in with either their email address or username which is easily done with a custom LDAP filter like "(|(mail=%u)(uid=%u))". ATB, Mark. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] New partitioning - some feedback

think a new modifier would be too rushed at this stage, but there's no reason to throw out the progress on \d vs \dt. +1 And similarly, there seemed to be a reasonably clear push to label the 'partitions' as such. regards Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgres

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Wed, Jul 12, 2017 at 2:30 PM, Mark Rofail <markm.rof...@gmail.com> wrote: > On Wed, Jul 12, 2017 at 12:53 AM, Alvaro Herrera <alvhe...@2ndquadrant.com > > wrote: >> >> We have one opclass for each type combination -- int4 to int2, int4 to >> int4, int4

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

ion ? I think another solution would be external casting BTW now that we've gone through this a little further, it's starting to > look like a mistake to me to use the same @> operator for (anyarray, > anyelement) than we use for (anyarray, anyarray). I agree. Changed to @>> Best Regards, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

here are the modifications to ri_triggers.c On Wed, Jul 12, 2017 at 12:26 AM, Mark Rofail <markm.rof...@gmail.com> wrote: > > *What I did * > >- now the RI checks utilise the @>(anyarray, anyelement) > > Best Regards, > Mark Rofail > diff --git a/src/back

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

see if the RI constraint > would be violated: SELECT 1 FROM ONLY fktable x WHERE $1 = ANY (fkcol) FOR SHARE OF x;. or is there anything remaining ? Best Regards, Mark Rofail

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

On Sun, Jul 9, 2017 at 2:38 AM, Alexander Korotkov wrote: > Could you, please, specify idea of what you're implementing in more > detail? > Ultimatley we would like an indexed scan instead of a sequential scan, so I thought we needed to index the FK array columns first.

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

the CREATE INDEX query. For example: CREATE INDEX ON fktable USING gin (fkcolumn array_ops) Where does the strategy number fit? - The patch is attached here, is the approach I took to creating an index programmatically, correct? Best Regard, Mark Rofail diff --git a/src/backend

Re: [HACKERS] New partitioning - some feedback

On 07/07/17 19:54, Michael Banck wrote: On Fri, Jul 07, 2017 at 07:40:55PM +1200, Mark Kirkwood wrote: On 07/07/17 13:29, Amit Langote wrote: Someone complained about this awhile back [1]. And then it came up again [2], where Noah appeared to take a stance that partitions should be visible

Re: [HACKERS] Revisiting NAMEDATALEN

y one of many other options, causes some of the test output to change. Even configure's options, such as --with-blocksize, cannot be changed from the default value without potentially breaking the regression tests. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.o

Re: [HACKERS] New partitioning - some feedback

partition tables *must* be shown in \d output, then I'd be happy if they were identified as such rather than just 'table' (e.g 'partition table'). regards Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mail

[HACKERS] New partitioning - some feedback

| t date_fact_20170601 | r | t date_fact_2017060100 | r | t date_fact_201707 | r | t date_fact_rest | r | t (7 rows) ...so it looks to be possible to hide the partitions from the main display and/or mark them as such. Now I realize that making this comment now

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

ex a table? [1] https://www.postgresql.org/message-id/28389.1351094795%40sss.pgh.pa.us Best Regards, Mark Rofail diff --git a/src/backend/utils/adt/ri_triggers.c b/src/backend/utils/adt/ri_triggers.c index 3a25ba52f3..0045f64c9e 100644 --- a/src/backend/utils/adt/ri_triggers.c +++ b/src/backend/u

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jul 5, 2017, at 5:30 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >> >>> On Jul 3, 2017, at 10:25 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>>

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

till have problems when exceptions beyond my control get thrown inside the loop? And if exception handling is a problem in the loop, are exceptions somehow not a problem in other parallel queries? Obviously I mean that syntax above in jest, but the question is in ernest. Thanks, mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jun 29, 2017, at 8:55 PM, Mark Dilger <hornschnor...@gmail.com> wrote: > > > Changing myfunc to create a temporary table, to execute the sql to populate > that temporary table, and to then loop through the temporary table's rows > fixes the problem. For the real-w

Re: [HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

> On Jun 29, 2017, at 9:14 PM, Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger <hornschnor...@gmail.com> wrote: >> Hackers, >> >> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does n

[HACKERS] Request more documentation for incompatibility of parallelism and plpgsql exec_run_select

this belongs in section 15.3.4 or 42.5.4. mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

to do it in the arraycontainselem and pass it as a parameter to the underlying function array_contains_elem. I'm proposing to introduce a new struct like ArrayType, but ElementType along all with brand new MACROs to make dealing with anyelement easier in any polymorphic context. Best Regards, Mark Rofai

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

rrays.out) - wokred on the new GIN strategy, I don't think it would vary much from GinContainsStrategy. *What I plan to do:* - I need to start working on the Referential Integrity code but I don't where to start Best Regards, Mark Rofail diff --git a/src/backend/access/gin/ginarrayproc.c b/sr

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

such a check? Best Regards, Mark Rofail diff --git a/src/backend/access/gin/ginarrayproc.c b/src/backend/access/gin/ginarrayproc.c index cc7435e030..214aac8fba 100644 --- a/src/backend/access/gin/ginarrayproc.c +++ b/src/backend/access/gin/ginarrayproc.c @@ -24,6 +24,7 @@ #define GinContainsStrategy 2

Re: [HACKERS] logical replication: \dRp+ and "for all tables"

hoping we'd get some more votes in this thread, but it seems like we've only got three, and by my count two of them are for just printing "all tables". I'd certainly prefer to see 'all tables' - in addition to being more compact, it also reflects more correctly how the publication was def

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

On 06/06/17 10:12, Gavin Flower wrote: On 06/06/17 09:41, Mark Kirkwood wrote: On 05/06/17 09:30, Tom Lane wrote: I've been thinking about the behavior discussed in https://www.postgresql.org/message-id/flat/20170522132017.29944.48391%40wrigleys.postgresql.org and it seems to me

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

• After finding the arraycontains function, I implemented arraycontainselem that corresponds to the operator @<(anyarray, anyelem) ◦ Please read the attached patch file to view my progress. • In addition to src/backend/utils/adt/arrayfuncs.c where I implemented arraycontainselem.

Re: [HACKERS] Make ANALYZE more selective about what is a "most common value"?

ans specializing in statistics - so can get their thoughts on this issue if you feel it would be worthwhile. Cheers Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] logical replication - still unstable after all these months

On 05/06/17 13:08, Mark Kirkwood wrote: On 05/06/17 00:04, Erik Rijkers wrote: On 2017-05-31 16:20, Erik Rijkers wrote: On 2017-05-31 11:16, Petr Jelinek wrote: [...] Thanks to Mark's offer I was able to study the issue as it happened and found the cause of this. [0001-Improve-handover

Re: [HACKERS] logical replication - still unstable after all these months

-between-sync-and-apply-worker-v2.patch] No errors after (several days of) running variants of this. (2500x 1 minute runs; 12x 1-hour runs) Same here, no errors with the v2 patch applied (approx 2 days - all 1 minute runs) regards Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 2:19 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2017-06-04 14:16:14 -0700, Mark Dilger wrote: >> Sorry, I was not clear. What I meant to get at was that if you remove from >> the >> executor all support for SRFs inside cas

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 12:35 PM, Andres Freund <and...@anarazel.de> wrote: > > Hi Mark, > > On 2017-06-04 11:55:03 -0700, Mark Dilger wrote: >>> Yea, I'm not a big fan of the either the pre v10 or the v10 behaviour of >>> SRFs inside coalesce/case.

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

> On Jun 4, 2017, at 11:55 AM, Mark Dilger <hornschnor...@gmail.com> wrote: > > SELECT x, CASE WHEN y THEN SUM(generate_series(1,z)) ELSE 5 END > FROM table_with_columns_x_and_y; Sorry, this table is supposed to be the same as the previous one, table_with_col

Re: [HACKERS] PostgreSQL 10 changes in exclusion constraints - did something change? CASE WHEN behavior oddity

y is false. That could be changed with an aggregate function such as: SELECT x, CASE WHEN y THEN SUM(generate_series(1,z)) ELSE 5 END FROM table_with_columns_x_and_y; Which to me gives one output row per table row regardless of whether y is true. Thanks, and my apologies if I am m

Re: [HACKERS] logical replication - still unstable after all these months

On 03/06/17 11:10, Petr Jelinek wrote: On 02/06/17 22:29, Petr Jelinek wrote: On 02/06/17 08:55, Mark Kirkwood wrote: On 02/06/17 17:11, Erik Rijkers wrote: On 2017-06-02 00:46, Mark Kirkwood wrote: On 31/05/17 21:16, Petr Jelinek wrote: I'm seeing a new failure with the patch applied

Re: [HACKERS] pg_class.relpartbound definition overly brittle

gt; own rationale. Maybe you'd like to complain that every one of those > rationales is wrongheaded but I do not think you will get far. > > I think the best advice for Mark is to look at pg_get_expr() output and > see if that matches. Yes, I'm already doing that based on the discussion so f

Re: [HACKERS] logical replication - still unstable after all these months

On 02/06/17 17:11, Erik Rijkers wrote: On 2017-06-02 00:46, Mark Kirkwood wrote: On 31/05/17 21:16, Petr Jelinek wrote: I'm seeing a new failure with the patch applied - this time the history table has missing rows. Petr, I'll put back your access :-) Is this error during 1-minute runs

Re: [HACKERS] logical replication - still unstable after all these months

On 31/05/17 21:16, Petr Jelinek wrote: On 29/05/17 23:06, Mark Kirkwood wrote: On 29/05/17 23:14, Petr Jelinek wrote: On 29/05/17 03:33, Jeff Janes wrote: What would you want to look at? Would saving the WAL from the master be helpful? Useful info is, logs from provider (mainly

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On Jun 1, 2017, at 6:31 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Mark Dilger <hornschnor...@gmail.com> writes: >> When you guys commit changes that impact partitioning, I notice, and change >> my code to match. But in this case, it seemed to me

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 6:32 PM, Amit Langote <langote_amit...@lab.ntt.co.jp> > wrote: > > On 2017/06/01 4:50, Robert Haas wrote: >> On Wed, May 31, 2017 at 3:40 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >>> recent changes have introduced t

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 4:00 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Mark Dilger wrote: > >>>> >>>>

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 3:42 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2017-05-31 15:38:58 -0700, Mark Dilger wrote: >>> Normal users aren't going to make sense of node trees in the first >>> place. You should use pg_get_expr for it: >>&

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 3:17 PM, Andres Freund <and...@anarazel.de> wrote: > > On 2017-05-31 15:06:06 -0700, Mark Dilger wrote: >> That's cold comfort, given that most users will be looking at the pg_class >> table and not writing C code that compares Node objects. I w

Re: [HACKERS] pg_class.relpartbound definition overly brittle

> On May 31, 2017, at 2:49 PM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > > Mark Dilger wrote: >> Hackers, >> >> recent changes have introduced the :location field to the partboundspec >> in pg_catalog.pg_class. This means that if two identica

[HACKERS] pg_class.relpartbound definition overly brittle

fields for those two tables could show up as different. Can we perhaps remove the :location field here? If not, could somebody please defend why this belongs in the catalog entries for the table? Sorry if I am missing something obvious... Thanks, Mark Dilger -- Sent via pgsql-hackers mailing

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

> On May 31, 2017, at 7:58 AM, Bruce Momjian <br...@momjian.us> wrote: > > On Wed, May 31, 2017 at 07:53:22AM -0700, Mark Dilger wrote: >>> Just to clarify, the TEMPORARY clause would allow the tablespace to >>> start up empty, while normal tablespaces can't do

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

> On May 31, 2017, at 6:04 AM, Bruce Momjian <br...@momjian.us> wrote: > > On Wed, May 31, 2017 at 07:53:53AM -0400, Robert Haas wrote: >> On Tue, May 30, 2017 at 6:50 PM, Mark Dilger <hornschnor...@gmail.com> wrote: >>>> On May 29, 2017, at 11:53 AM,

Re: [HACKERS] Use of non-restart-safe storage by temp_tablespaces

ject wanted to extend the grammar and behavior in this direction, maybe temp_tablespaces would work that way? I'm not so familiar with what the temp_tablespaces GUC is for -- only ever implemented what I described above. Mark Dilger -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql

[HACKERS] syscache entries out of order

pedantry. Patch attached. Mark Dilger syscache.patch.0 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

Re: [HACKERS] GSoC 2017: Foreign Key Arrays

ed in the source code Best Regards, Mark Rofail

Re: [HACKERS] logical replication - still unstable after all these months

for the table(s) that are out of sync. I have a run that aborted with failure (accounts table md5 mismatch). Petr - would you like to have access to the machine ? If so send me you public key and I'll set it up. Cheers Mark -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] logical replication - still unstable after all these months

On 29/05/17 13:33, Jeff Janes wrote: On Sun, May 28, 2017 at 3:17 PM, Mark Kirkwood <mark.kirkw...@catalyst.net.nz <mailto:mark.kirkw...@catalyst.net.nz>> wrote: On 28/05/17 19:01, Mark Kirkwood wrote: So running in cloud land now...so for no errors -

Re: [HACKERS] logical replication - still unstable after all these months

On 29/05/17 16:26, Erik Rijkers wrote: On 2017-05-29 00:17, Mark Kirkwood wrote: On 28/05/17 19:01, Mark Kirkwood wrote: So running in cloud land now...so for no errors - will update. The framework ran 600 tests last night, and I see 3 'NOK' results, i.e 3 failed test runs (all scale 25

Re: [HACKERS] logical replication - still unstable after all these months

On 28/05/17 19:01, Mark Kirkwood wrote: So running in cloud land now...so for no errors - will update. The framework ran 600 tests last night, and I see 3 'NOK' results, i.e 3 failed test runs (all scale 25 and 8 pgbench clients). Given the way the test decides on failure (gets tired

Re: [HACKERS] logical replication - still unstable after all these months

for scripts on Ubuntu), added ports and databases as reqd and fixed the need to mess too much with PATH (see attached diff). So running in cloud land now...so for no errors - will update. regards Mark diff -Naur test.orig/config.sh test/config.sh --- test.orig/config.sh 1970-01-01 12:00

  1   2   3   4   5   6   7   8   9   10   >