does anything but effectively make them into
> superusers who aren't explicitly identified as superusers.
Just to help understand your concern, and not to propose actual features,
would it help if there were
(1) a function, perhaps pg_catalog.pg_exploiters(), which would return all
roles
ing.
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, though.
mark
--
Sent via pgs
> 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 strtol()-like behavior
> where they take
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
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
raphrasing) '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.postgresql.org/mailpref/pgsql-hackers
> On Sep 26, 2017, at 10:36 AM, Bruce Momjian 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", "password",
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
t;/data0/pgdata/11/pg_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_tbls
> On Sep 12, 2017, at 1:07 PM, Tom Lane wrote:
>
> [ changing subject line to possibly draw more attention ]
>
> Mark Dilger writes:
>>> On Apr 5, 2017, at 9:23 AM, Tom Lane wrote:
>>> In short, if you are supposed to write
>>> FOO *val = PG_
pam_authz_search - this is exactly the type of 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 authe
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
I have a concern that after supporting UPDATE/DELETE CASCADE, the
performance would drop.
On Thu, Jul 27, 2017 at 12:54 PM, Alexander Korotkov
wrote:
>
> I wonder how may RI trigger work so fast if it has to do some job besides
> index search with no results?
>
Best Regards,
Mark Rofail
> On Aug 10, 2017, at 11:20 AM, Robert Haas wrote:
>
> On Wed, Jul 5, 2017 at 12:14 AM, Mark Dilger wrote:
>> I can understand this, but wonder if I could use something like
>>
>> FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
>> ...
>> E
ction.
> 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
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)
Th
e 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 cases I see, that
would be enough to discount Postg
the experience to answer that
Best Regards,
Mark Rofail
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
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 ACTIO
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: document type does no
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
g/message-id/28617.1351095...@sss.pgh.pa.us
[2]
https://www.postgresql.org/message-id/CAJvoCutcMEYNFYK8Hdiui-M2y0ZGg%3DBe17fHgQ%3D8nHexZ6ft7w%40mail.gmail.com
[3]
https://www.postgresql.org/message-id/CAJvoCuuoGo5zJTpmPm90doYTUWoeUc%2BONXK2%2BH_vxsi%2BZi09bQ%40mail.gmail.com
Best Regards,
Mark Rofail
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 here is that the only to
extremely difficult to sort all of
> the problems that would result from a change in this area.
Best Regards,
Mark Rofail
>
> 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 bu
r inserts + deletes) - 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
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.
Agreed. This should be a fu
d. 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
er 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 float8
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.
ally enhances the
performance of the RI checks. How can I go about this?
Best Regards,
Mark Rofail
t4[] @>> int8,
int4[] @>> int4, int4[] @>> int2, int4[] @>> numeric.
So I think implementing operators is the way to go.
Best Regards,
Mark Rofail.
> On Jul 18, 2017, at 9:13 PM, Mark Dilger wrote:
>
>>
>> On Jul 17, 2017, at 2:34 PM, Mark Dilger wrote:
>>
>>>
>>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>>>
>>> Mark Dilger writes:
>>>>> On Jul 17, 2017,
> On Jul 17, 2017, at 2:34 PM, Mark Dilger wrote:
>
>>
>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>>> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote:
>>> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote:
>
On 17/07/17 18:08, Magnus Hagander wrote:
> On Mon, Jul 17, 2017 at 6:47 PM, Mark Cave-Ayland
> mailto:mark.cave-ayl...@ilande.co.uk>>
> wrote:
> Great to hear from you! It has definitely been a while...
>
> Indeed. You should spend more time on these lists :P
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 operator should be create
On Tue, 18 Jul 2017 at 7:43 pm, Alexander Korotkov
wrote:
> On T upue, Jul 18, 2017 at 2:24 AM, Mark Rofail
> wrote:
>
>> On Wed, Jul 12, 2017 at 12:53 AM, Alvaro Herrera <
>> alvhe...@2ndquadrant.com> wrote:
>>>
>>> We have one opclass for e
> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>>> Well, if you or somebody is willing to do the legwork, I'd be on board
>>> with a plan that says that every 68 years we redefine
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 the operator multiple of time
> On Jul 17, 2017, at 3:56 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote:
>>> Now, this should mostly work conveniently, except that we have
>>> +/-infinity (NOEND_ABSTIME/NOSTART_ABSTIME) to deal with ... It mig
> On Jul 17, 2017, at 3:12 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>>> Well, if you or somebody is willing to do the legwork, I'd be on board
>>> with a plan that says that every 68 years we redefine
> On Jul 17, 2017, at 2:14 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote:
>> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote:
>>>> The types abstime, reltime, and tinterval need to go away, or be
>>>&g
> On Jul 17, 2017, at 12:54 PM, Mark Dilger wrote:
>
>
>> On Jul 15, 2017, at 3:00 PM, Tom Lane wrote:
>>
>> The types abstime, reltime, and tinterval need to go away, or be
>> reimplemented, sometime well before 2038 when they will overflow.
>> It&#x
tree
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
ardless of whether a uid or email
address 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 i
GSSAPI, and even DIGEST-MD5 has 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 wit
ttls either 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.
ttribute for the default search filter of the form
"(attribute=username)" which defaults to uid for UNIX-type systems and
sAMAccountName for AD. However there is always the ability to specify a
custom filter where the user is substituted via e.g. %u to cover all the
other use-cases.
As
t beta3 before a September final
release.
I 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
--
Se
On Wed, Jul 12, 2017 at 2:30 PM, Mark Rofail wrote:
> 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
>>
lution 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
here are the modifications to ri_triggers.c
On Wed, Jul 12, 2017 at 12:26 AM, Mark Rofail
wrote:
>
> *What I did *
>
>- now the RI checks utilise the @>(anyarray, anyelement)
>
> Best Regards,
> Mark Rofail
>
diff --git a/src/backend/utils/adt/ri_trigger
traint
> 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
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.
Strategy) within 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
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
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
hese
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:
| r | t
date_fact_201706 | r | 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
y in C index 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
> On Jul 5, 2017, at 5:30 AM, Amit Kapila wrote:
>
> On Wed, Jul 5, 2017 at 9:44 AM, Mark Dilger wrote:
>>
>>> On Jul 3, 2017, at 10:25 PM, Amit Kapila wrote:
>>>
>>> On Mon, Jul 3, 2017 at 8:57 PM, Simon Riggs wrote:
>>>> On 30 June
;t have such a support.
I can understand this, but wonder if I could use something like
FOR I TOTALLY PROMISE TO USE ALL ROWS rec IN EXECUTE sql LOOP
...
END LOOP;
if I hacked the grammar up a bit. Would the problem go away, or would
I still have problems when exceptions beyond my control get th
> On Jun 29, 2017, at 8:55 PM, Mark Dilger 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-world example where
> On Jun 29, 2017, at 9:14 PM, Amit Kapila wrote:
>
> On Fri, Jun 30, 2017 at 9:25 AM, Mark Dilger wrote:
>> Hackers,
>>
>> In src/pl/plpgsql/src/pl_exec.c: exec_run_select intentionally does not
>> allow a parallel plan if a portal will be returned. This
otherwise trip over this limitation. Perhaps 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
eck if the Datum was null and its type, I had 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 e
results(src/test/regress/expected/arrays.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
uch 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 GinContainsStrate
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 publica
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 that
• 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.
◦
and I do have access to some mathematicians 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
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-han
logic-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-ha
> On Jun 4, 2017, at 2:19 PM, Andres Freund 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 case statements, you might for
> On Jun 4, 2017, at 12:35 PM, Andres Freund 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. Neither is really resonab
> On Jun 4, 2017, at 11:55 AM, Mark Dilger 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_columns_x_and_y_and_z
--
Sent via p
row per table row where 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 merely lacking sufficient imagination to
think of a proper example.
Mark Dilger
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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 ap
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 t
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-m
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 the
> On Jun 1, 2017, at 6:31 AM, Tom Lane wrote:
>
> Mark Dilger 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 the change that got
>> committed was not thought throug
> On May 31, 2017, at 6:32 PM, Amit Langote
> wrote:
>
> On 2017/06/01 4:50, Robert Haas wrote:
>> On Wed, May 31, 2017 at 3:40 PM, Mark Dilger wrote:
>>> recent changes have introduced the :location field to the partboundspec
>>> in pg_catalog.pg_clas
> On May 31, 2017, at 4:00 PM, Alvaro Herrera wrote:
>
> Mark Dilger wrote:
>
>>>>
>>>>
> On May 31, 2017, at 3:42 PM, Andres Freund 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:
>>> postgres[3008][1]=# S
> On May 31, 2017, at 3:17 PM, Andres Freund 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 wrote a bit of
>
> On May 31, 2017, at 2:49 PM, Alvaro Herrera 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 identical tables with
>> identical p
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
> On May 31, 2017, at 7:58 AM, Bruce Momjian 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 that, right? One
> On May 31, 2017, at 6:04 AM, Bruce Momjian 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 wrote:
>>>> On May 29, 2017, at 11:53 AM, Bruce Momjian wrote:
>>>> Right now we don&#
tend 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.org
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
ed in the source code
Best Regards,
Mark Rofail
LSNs 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 (pgs
On 29/05/17 13:33, Jeff Janes wrote:
On Sun, May 28, 2017 at 3:17 PM, Mark Kirkwood
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 - will update.
The framework ran 600 test
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 (al
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 (get
ams use /bin/bash as
interpreter (/bin/sh just does not work 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/
1 - 100 of 1847 matches
Mail list logo
