#x27;s the starting point for an index
> scan -- it is the TID that is stored in indexes that needs to be
> stable over time. And so pruning needs to leave behind coherent
> looking whole entire HOT chains, just as we ought to verify that
> pruning consistently gets it right.
Thanks, Peter, for this analysis. It's getting a bit late in the day, but I'll
try this out tomorrow, I expect.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 5, 2021, at 8:56 PM, Tom Lane wrote:
>
> Some of the buildfarm is unimpressed with this --- looks like the test
> output is less stable than you thought.
Yes, it does. I had to play with it a bit to be sure the test itself is
faulty, and I believe that it is.
—
nflicts?
I'm cc'ing Andrew to get his thoughts about the buildfarm integration
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nefits from this
syntax. I would expect the amount of locking and checking for pre-existing
roles that such logic would require would make the IF NOT EXIST option useless.
Perhaps I'm wrong?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
y could be addressed in
a series of follow-on patches?
I understand this idea is not as useful for creating idempotent scripts, but
maybe it gets you part of the way there?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
erhaps this would be ok if all roles granted into "charlie" had
grantor="super_alice". I'm not sure that is really good enough, but it is a
lot closer to making this safe than allowing the command to succeed when role
"charlie" has been granted away by someone else.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
roles which alice owns.
This sounds reasonable. It means, of course, implementing a role ownership
system. I thought you had other concerns about doing so.
> I appreciate that the case of 'super_alice' doing things where they're
> an actual superuser might still be an issue, but running around doing
> things with superuser is already risky business and the point here is to
> get away from doing that by splitting superuser up, ideally in a way
> that privileges can be given out to non-superusers in a manner that's
> safer than doing things as a superuser and where independent
> non-superusers aren't able to do bad things to each other.
I'm not sure what to do about this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
future work on roles may
benefit if we close the testing gap.
For consideration:
v1-0001-Add-test-for-REVOKE-ADMIN-OPTION.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 16, 2021, at 6:31 AM, Daniel Gustafsson wrote:
>
>> On 16 Nov 2021, at 00:58, Mark Dilger wrote:
>
>> While working on a fix for dangling references to dropped roles in the
>> pg_auth_members.grantor field, I happened to notice we entirely lack
>>
ones, changes function signatures, or whatever. The
same is true here for GUCs.
I don't think we support using a .so that is mismatched against the version of
the extension that is installed.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 16, 2021, at 7:32 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I don't think we support using a .so that is mismatched against the
>> version of the extension that is installed.
>
> You are entirely mistaken. That's not only "supp
is than I'm aware? It can be a bit challenging to run performance
tests on such things, given the way everything interacts with everything else.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 16, 2021, at 10:08 AM, Jeff Davis wrote:
>
> On Mon, 2021-11-01 at 10:58 -0700, Mark Dilger wrote:
>> It is unclear .
>>
>> Thoughts?
>
> What if we just say that OWNER TO must be done by a superuser, changing
> from one superuser to
ich is probably just as well,
> since it's work that I'd be wanting to reject.
Yeah, that's why I didn't write it. I wanted feedback on the basic
implementation before doing that work.
> (Hm, but actually,
> doesn't pg_dump need work anyway to dump t
> On Nov 16, 2021, at 12:06 PM, Andrew Dunstan wrote:
>
> There doesn't seem to be a CF item for it but I'm
> inclined to commit it in a couple of days time.
https://commitfest.postgresql.org/36/3414/
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
his means. Are you suggesting that the (or in your formulation ) should have a "bool enabled"
field, and when the guc gets dropped, the "enabled" field gets set to false?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ation parameters to be proper objects with OIDs and with entries in
pg_depend and/or pg_shdepend. Maybe there is some better way to do it, but
that's why I've been doing this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
verify that it is unique. (We wouldn't want multiple records for the
same pair.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 16, 2021, at 8:11 PM, Jeff Davis wrote:
>
> On Wed, 2021-11-03 at 12:50 -0700, Mark Dilger wrote:
>> The first two patches are virtually unchanged. The third updates the
>> behavior of the apply workers, and updates the documentation to
>> match.
>
>
#x27;t understand why this table has as the primary
> key rather than just guc.
I was responding to Tom's recommendation that I follow the pattern in
pg_db_role_setting, and speculating how that would work. I was not proposing
to do it that way.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
So it amuses me that we'd now be
talking about granting some of these to predefined roles, as that is a
regression in flexibility. (How would a site revoke it from one of those
predefined roles if they wanted a different policy?)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
tter problem would
seem to be a mere matter of programming, something I'm working on but don't
have finished. (But maybe you see dragons ahead for me that I'm not seeing
yet?)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
patch. The only sense in which this patch depends on that issue is that this
patch proposes that non-superuser subscription owners are already an issue, and
therefore that this patch isn't creating a new issue, but rather making more
sane something that already can happen.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
vilege bits and define
new privileges that can be granted per subscription rather than globally. (I
think that last one is a non-starter, but just mention it as an example of
another approach.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
rights that only have meaning for subscriptions is
going to be accepted. For full disclosure, I'm proposing adding ACL_SET and
ACL_ALTER_SYSTEM in another patch and my proposal there could get shot down for
the same reasons, but I think your argument would be even harder to defend.
Maybe oth
> On Nov 17, 2021, at 1:06 PM, Jeff Davis wrote:
>
> On Wed, 2021-11-17 at 10:25 -0800, Mark Dilger wrote:
>> We may eventually allow non-superusers to create subscriptions, but
>> there are lots of details to work out.
>
> I am setting aside the idea of s
with how the system is already designed to work. You can't drop the
subscription's owner without first running REASSIGN OWNED, or ALTER
SUBSCRIPTION..OWNER TO, or simply dropping the subscription:
DROP ROLE regress_subscription_user;
ERROR: role "regress_subscription_user" cannot be dropped because some
objects depend on it
DETAIL: owner of subscription regress_testsub
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ons without noticing
the change. Now, it is limited to finishing the current transaction. Would
you prefer that the worker noticed the change in ownership and aborted the
transaction on the subscriber side? Or should the ALTER SUBSCRIPTION..OWNER TO
block? I don't see much advantage to eith
TO .. behavior. Is there a reason why 0003* patch (or
> something on those lines) shouldn't be considered to be applied?
Jeff Davis and I had a long conversation off-list yesterday and reached the
same conclusion. I will be submitting a version of 0003 which does not depend
on the prior t
t, but consider it a WIP patch
until then.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t; still need a superuser to create subscription and change properties
> like CONNECTION for a subscription but we can solve that by having
> roles specific to it as being indicated by Mark in some of his
> previous emails.
I feel disquieted about the "runas" idea. I can't really say
> On Nov 19, 2021, at 7:25 AM, Mark Dilger wrote:
>
> Jeff Davis and I had a long conversation off-list yesterday and reached the
> same conclusion. I will be submitting a version of 0003 which does not
> depend on the prior two patches.
Renamed as 0001 in version 3, as
catalog with a bunch of entries that aren't needed.
Grants on GUCs create a new catalog entry if necessary, or update the existing
catalog entry if found.
There is a new information_schema.guc_privileges view, not present in v2.
v3-0001-Allow-GRANT-of-SET-and-ALTER-SYSTEM-for-
(ctx->tuphdr->t_infomask & HEAP_XMAX_COMMITTED)
{
if (ctx->tuphdr->t_infomask & HEAP_XMAX_LOCK_ONLY)
... report something ...
else if ((ctx->tuphdr->t_infomask & (HEAP_XMAX_IS_MULTI | HEAP_LOCK_MASK))
== HEAP_XMAX_EXCL_LOCK)
... report a different thing ...
}
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ving that,
which they may not be, it is an extra round trip to the customer asking for
stuff.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
v9.2 or earlier are (or
become) rare, servers initialized that far back which have been upgraded one or
more times since then may be common.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
change, and possibly one we do not
want. Can we consider this out of scope?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e owned by users who lack bypassrls is interesting.
If we make that work, it will be a more complete solution than option (d).
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
he old owner has
privileges increased.
In both cases, a currently running logical replication worker may finish a
transaction in progress acting with the current privileges of the old owner.
The clearest solution is, as you suggest, to refuse transfer of ownership of
subscriptions that
so it needs to know the type of anyelement (to know if it needs to
> detoast, etc). But there is as far as I can tell no way to check the
> type of anyelement in this context.
>
>
If there is any way to obtain a copy of the datum I would be more than
happy to integrate the GIN operator to the patch.
Best.
Mark Rofail
. Some of the django
web app work needs to be moved up into phase one, because I'd propose
the web app should also have an API that the build farm plants should
use to transfer results.
Good luck!
Regards,
Mark
--
Mark Wonghttp://www.2ndQuadrant.com/
Postgr
On Tue, Mar 27, 2018 at 11:09:37AM +1030, Andrew Dunstan wrote:
> On Tue, Mar 27, 2018 at 10:57 AM, Alvaro Herrera
> wrote:
> > Andrew Dunstan wrote:
> >
> >> I am in discussions with Mark, he's going to disable the animals from
> >> build
their database is corrupt. All this time, I
have been blaming this on virtualization and thin provisioning.
mark
he master, leaving all copies of the database unusable.
If this bug corrupts the standby servers, too, then it is a whole different
class of problem than the one folks have come to expect.
Your comment reads as if this is a problem isolated to whichever server has
the problem, and will not get propagated to other servers. Am I reading
that right?
Can anybody clarify this for non-core-hacker folks following along at home?
mark
> On Apr 9, 2018, at 1:43 PM, Tomas Vondra wrote:
>
>
>
> On 04/09/2018 10:25 PM, Mark Dilger wrote:
>>
>>> On Apr 9, 2018, at 12:13 PM, Andres Freund wrote:
>>>
>>> Hi,
>>>
>>> On 2018-04-09 15:02:11 -0400, Robert Ha
> On Apr 9, 2018, at 2:25 PM, Tomas Vondra wrote:
>
>
>
> On 04/09/2018 11:08 PM, Andres Freund wrote:
>> Hi,
>>
>> On 2018-04-09 13:55:29 -0700, Mark Dilger wrote:
>>> I can also imagine a master and standby that are similarly provisioned,
>>&
go down, it doesn't appear
> that the tests were run more than once for each case therefore the
> numbers are pretty noisy
>
Any ideas how to perform more exhaustive tests ?
On 3/26/18 4:50 PM, Mark Rofail wrote:
> > On Wed, Jan 31, 2018 at 1:52 AM, Andre
On Tue, Apr 10, 2018 at 3:59 PM, Alvaro Herrera
wrote:
>
> documentation to it and a few extensive tests to ensure it works well);
I think the existing regression tests verify that the patch works as
expectations, correct?
We need more *exhaustive* tests to test performance, not functionality.
On Tue, 10 Apr 2018 at 4:17 pm, Alvaro Herrera
wrote:
> Mark Rofail wrote:
> I meant for the GIN operator. (Remember, these are two patches, and each
> of them needs its own tests.)
Yes, you are right. I have been dealing with the code as a single patch
that I almost forgot.
Tru
ur freshly attached
devices on AWS (for performance mainly IIRC), but that would help
prevent some failure scenarios for any thin provisioned storage (but
probably really annoy the admins' thereof).
regards
Mark
> On Apr 25, 2018, at 1:00 PM, Robert Haas wrote:
>
> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger wrote:
>> There still seems to be a lot of boilerplate in the .dat files
>> that could be eliminated. Tom mentioned upthread that he did
>> not want too much magic
> On Apr 25, 2018, at 1:31 PM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Wed, Apr 25, 2018 at 3:44 PM, Mark Dilger wrote:
>>> There still seems to be a lot of boilerplate in the .dat files
>>> that could be eliminated. ...
>
>>> {... typ
to read lines like:
{ opcmethod => 'btree', opcintype => 'bytea' },
which is also great, because you're really just declaring that type bytea has a
btree opclass and letting the system do the rest of the work. Having to
manually
specify opfamily and the opname just clutters the row and makes it less
intuitive.
There are a bunch more of varying quality, depending on which automations
you like or don't like.
mark
ng cleaning up all
such incomplete initializations within the project?
I understand that your INIT_ALL_ZEROS macro does nothing to change
whether -Wmissing-field-initializers would raise a warning. I'm
just asking about the decree you propose, and I used that warning flag
to get the compiler to spit out relevant examples.
mark
On 10/2/19 11:02 AM, Tom Lane wrote:
Mark Dilger writes:
On 10/2/19 8:46 AM, Tom Lane wrote:
Right. I think that in general it's bad practice for an initializer
to not specify all fields/elements of the target.
There are numerous locations in the code that raise warnings when
-Wmi
Hi,
I apologize for the mistake.
For the mailing list correspondence I created this mail account. But I
forgot to change the sender name. So, the "postgres" name appeared as
sender name in the mailing list. I changed it.
Kind regards,
Mark/S-Man42
Hi,
some days ago I ran into
On Thu, Oct 10, 2019 at 05:34:51PM -0400, Tom Lane wrote:
> A nearer-term solution would be to reproduce this manually and
> dig into the core. Mark, are you in a position to give somebody
> ssh access to wobbegong's host, or another similarly-configured VM?
>
> (While at
[2], for what it's worth...
"... cluster is an OpenStack based cluster offering POWER8 & POWER9 LE
instances running on KVM ..."
But to keep you on your toes, some of my ppc animals are Docker within
other OpenStack/KVM instance...
Regards,
Mark
[1] https://github.com/torval
don't have a strong reason to advocate dropping
support other than that this #define appears to be undocumented.
mark
ication.
>
> [2]:
> https://www.postgresql.org/message-id/flat/qfkua9$2q0e$1...@blaine.gmane.org
>
> [3]: https://git.pleroma.social/pleroma/pleroma/issues/1324 is an
> example of data loss induced by this issue.
>
> Ariadne
>
This should be directed towards the h
On 10/15/19 5:23 AM, Andrew Gierth wrote:
"Mark" == Mark Dilger writes:
>> +#ifdef HSTORE_IS_HSTORE_NEW
Mark> Checking the current sources, git history, and various older
Mark> commits, I did not find where HSTORE_IS_HSTORE_NEW was ever
Mark> defined.
In
even more so seeing that only HEAD is
> failing, while the change was back-patched into all branches.
>
> Mark Wong and I poked into this off-list, and what we find is that
> this seems to be a compiler bug. Those animals are all running
> nearly the same version of clang (3.8.x / pp
Hello all,
While looking over the new jsonpath stuff I noticed the keyword table
wasn't declared const. Shouldn't the table and the actual keyword
strings both be declared const? Perhaps something like the attached
(untested) patch.
-Mark
diff --git a/src/backend/utils/adt/jsonpath_sc
ir adm 4096 Dec 31 1998 pg_dump
drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_encoding
drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_id
drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_passwd
drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pgtclsh
drwxr-sr-x 3 markir adm 4096 Dec 31 1998 pg_version
drwxr-sr-x 3 markir adm 4096 Dec 31 1998 psql
--
Mark
Hello all,
Please find attached a trivial patch making a few arrays const (in addition
to the data they point to).
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index f553523857..aafc7187b0 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access
On Thu, Aug 8, 2019 at 8:51 PM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> How did you find this? Any special compiler settings?
>
16 hours stuck in a plane on an international flight. I was just eyeballing
the code to kill the boredom.
-Mark
On Thu, Aug 8, 2019 at 8:25 PM Ibrar Ahmed wrote:
> +1
>
> Patch successfully applied to the master (
> 43211c2a02f39d6568496168413dc00e0399dc2e)
>
That change looks like an unrelated patch for initdb. I'm still not seeing
my patch there.
-Mark
oes to append both
result sets so I was wondering if someone would be able to help me out with
this.
Mark
ults in the UNION ALL command.
I was wondering if this is normal behaviour.
In my mind, I wouldn't expect appending 2 resultsets to have such a
relative huge cost associated with it.
This is also why I asked what exactly a UNION ALL does to achieve its
functionality, to perhaps gain some ins
" rather than having unnest() in the target
> list. This way you would not need to rename all columns and the code paths
> for the array case could look more like the code path for the normal case.
>
I have repeatedly tried to generate the suggested query using C code and I
failed. I would like some help with it
Best Regards,
Mark Rofail
.y = a2.v WHERE [...]
>
> rather than:
>
> SELECT fk.k1, fk.ak2 FROM (SELECT x k1, pg_catalog.unnest(ys) k2, ys ak2
> FROM ONLY t2) fk LEFT OUTER JOIN ONLY t1 pk ON pk.x = fk.k1 AND pk.y =
> fk.k2 WHERE [...]
>
Andreas has kindly written the SQL query for us. My problem is generatin
sure they are the same type. Can't
we get the type from the anyarray ? the type is already stored in `
arr_type`.
Best Regards,
Mark Rofail
g that
won't affect the core mechanics of the patch.
So yes, I move towards delaying the introduction of @>> to the patch.
A new patch will be ready by tomorrow.
Besr Regards,
Mark Rofail
>
>
er adding test coverage for deprecated classes? There was another
thread that discussed removing these types. The consensus seemed to
be in favor of removing them, though I have not seen a patch for that yet.
mark
her users.
Extending this to help the community as a whole in the form of something
general purpose seems difficult, which is why I never tried to
contribute it.
Could you perhaps tell me how similar your situation is to mine, and
whether my approach is anything like what you were contemplating? I am
curious to hear an answer to Tom's question, upthread, about why you
would not just use the enumeration type that postgres already supplies.
Mark Dilger
ity dynamic_enum);
Do you imagine that myusers and yourusers are referring to the
same enum or to two different enums? Are the enums stored in
a new table within pg_catalog, or are they stored in something akin
to a toast table? If you insert billions of rows into a table, but only
have 30 distinct values, can you quickly query for all 30 distinct enum
values, or would you have to walk billions of rows to find them all?
mark
> On Feb 12, 2018, at 6:35 PM, Tom Lane wrote:
>
> Andrew Kane writes:
>> Thanks everyone for the feedback. The current enum implementation requires
>> you to create a new type and add labels outside a transaction prior to an
>> insert.
>
> Right ...
>
>> Since enums have a fixed number of la
y in making changes to
functions that already exist in production deployments. An additional function
like this would be helpful to many.
--
Mark Felder
ports-secteam & portmgr alumni
f...@freebsd.org
On 10/29/19 11:32 PM, Andres Freund wrote:
Hi,
On 2019-10-29 16:31:11 -0400, Tom Lane wrote:
Andres Freund writes:
one of the most frequent conflicts I see is that two patches add files
to OBJS (or one of its other spellings), and there are conflicts because
another file has been added.
..
Hackers,
please find attached a patch fixing a problem previously discussed [1]
about the code inappropriately ignoring the return value from SPI_execute.
I will be adding this to https://commitfest.postgresql.org/26/ shortly.
Mark Dilger
[1] https://www.postgresql.org/message-id
On 11/5/19 8:27 PM, Michael Paquier wrote:
On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote:
please find attached a patch fixing a problem previously discussed [1] about
the code inappropriately ignoring the return value from SPI_execute.
I will be adding this to https
On 11/5/19 9:54 PM, Pavel Stehule wrote:
st 6. 11. 2019 v 5:28 odesílatel Michael Paquier <mailto:mich...@paquier.xyz>> napsal:
On Tue, Nov 05, 2019 at 05:21:25PM -0800, Mark Dilger wrote:
> please find attached a patch fixing a problem previously
discuss
ble to commit this patch even if other
SPI patches are rejected.
--
Mark Dilger
>From 019a37280145ef437acd26b4cd2c0ce58aa7709a Mon Sep 17 00:00:00 2001
From: Mark Dilger
Date: Wed, 6 Nov 2019 15:37:50 -0800
Subject: [PATCH v1] Testing COPY inside PL/pgSQL
Adding a test for COPY being run insi
On 11/6/19 6:27 PM, Michael Paquier wrote:
On Wed, Nov 06, 2019 at 04:16:14PM -0800, Mark Dilger wrote:
While working on cleaning up the SPI interface, I found that one of the SPI
error codes, SPI_ERROR_COPY, is never encountered in any test case when
running `make check-world`. This case
ting would indicate the need to
fix bad C code, not the need to catch an exception and take remedial
action at run time. Does this adequately address your concern?
My research so far indicates that most return codes are either totally
unused or of type (b), with only a few of type (a).
--
Mark Dilger
27;ve done and tell me if I've broken it.
--
Mark Dilger
diff --git a/src/backend/storage/file/fd.c b/src/backend/storage/file/fd.c
index fe2bb8f859..1cddd590b8 100644
--- a/src/backend/storage/file/fd.c
+++ b/src/backend/storage/file/fd.c
@@ -330,6 +330,41 @@ static int fsync_parent_path(co
an optional $kwargs hash reference.
--
Mark Dilger
eel about it?
If more places like this can be converted to use elog(ERROR), it may be
possible to convert more functions to return void.
[1] https://www.postgresql.org/message-id/13404.1558558354%40sss.pgh.pa.us
[2]
https://www.postgresql.org/message-id/20191106151112.GA1225
On 11/8/19 6:33 AM, Andrew Dunstan wrote:
On 11/8/19 1:16 AM, Craig Ringer wrote:
On Fri, 8 Nov 2019 at 06:28, Mark Dilger mailto:hornschnor...@gmail.com>> wrote:
On 10/31/19 10:02 AM, Andrew Dunstan wrote:
>
> This small patch authored by my colleague
uot;, "bar", and "baz" above are shorthand notation for
things in practice that are already somewhat hard to read, as in:
command_fails_like(
[ 'pg_dump', 'qqq', 'abc' ],
qr/\Qpg_dump: error: too many command-line arguments (first is
"abc")\E/,
'pg_dump: too many command-line arguments');
but adding more to that cruft just makes it worse. Right?
--
Mark Dilger
taking long enough to be significant compared to how
long send() takes?
A bit more information about the performance problem you are
encountering might make it easier to understand the motivation for this
patch.
--
Mark Dilger
output? If so, can you provide a test example that works
differently under your patch?
Thanks!
--
Mark Dilger
diff --git a/src/test/regress/expected/stats_ext.out
b/src/test/regress/expected/stats_ext.out
index b65228fa07..8e20df25fc 100644
--- a/src/test/regress/expected/stats_ext.out
+++ b/s
On 11/9/19 12:33 PM, Mark Dilger wrote:
On 11/6/19 11:58 AM, Tomas Vondra wrote:
On Wed, Nov 06, 2019 at 08:54:40PM +0100, Tomas Vondra wrote:
On Mon, Oct 28, 2019 at 04:20:48PM +0100, Tomas Vondra wrote:
Hi,
PostgreSQL 10 introduced extended statistics, allowing us to consider
eady uses TestLib, so perhaps setting up the environment
can be abstracted into something, perhaps TestLib::run, and then used
everywhere that IPC::Run::run currently is used.
--
Mark Dilger
On 11/11/19 11:28 AM, Andrew Dunstan wrote:
On 11/11/19 1:27 PM, Mark Dilger wrote:
On 11/11/19 8:48 AM, Andrew Dunstan wrote:
On 11/9/19 8:25 AM, Andrew Dunstan wrote:
OK, I agree that we're getting rather baroque here. I could go with
your
suggestion of YA function, or possi
add a node to it might not occur to
people. If the repeated use of
else if (IsA(node, XXX))
were replaced with
switch (nodeTag(node)) {
case XXX:
then the compiler, ala -Wswitch, would alert folks when they forget to
handle a new node type.
--
Mark Dilger
On 11/11/19 2:33 PM, Mark Dilger wrote:
On 11/11/19 1:41 PM, Tom Lane wrote:
Would it be a good idea to move find_expr_references_walker to
nodeFuncs.c, in hopes of making it more visible to people adding
new node types?
I'm not sure that would be enough. The logic of that functi
r, in the form of a patch applied
on top of yours.
--
Mark Dilger
diff --git a/src/backend/statistics/dependencies.c b/src/backend/statistics/dependencies.c
index a6ca11c675..ccf6e41b9c 100644
--- a/src/backend/statistics/dependencies.c
+++ b/src/backend/statistics/dependencies.c
@@ -850,7 +
erested. Currently, the patch is over 2.2MB, gzip'd. I'll
only bother distilling it if you don't already know about these cache
lookup failures.
--
Mark Dilger
On 11/13/19 4:46 PM, Tomas Vondra wrote:
On Wed, Nov 13, 2019 at 03:00:03PM -0800, Mark Dilger wrote:
On 11/11/19 1:41 PM, Tom Lane wrote:
I happened to notice that find_expr_references_walker has not
been taught anything about TableFunc nodes, which means it will
miss the type and
301 - 400 of 1160 matches
Mail list logo
