> On Dec 5, 2017, at 4:07 PM, Thomas Munro
> wrote:
>
> On Wed, Dec 6, 2017 at 9:35 AM, Mark Dilger wrote:
>>> On Dec 5, 2017, at 11:25 AM, Thomas Munro
>>> wrote:
>>> Does the plan have multiple Gather nodes with Parallel Bitmap Heap Scan?
>>
grate the statistics to the
new database, as long as it set the PgStat_StatTabEntry for each table where
statistics were migrated, then the user would just have to execute a
"VACUUM CONDITIONALLY" after upgrade, and the database would either
do a lot of analyze work, a little analyze work, or no analyze work depending
on which tables needed analyzing.
The main advantage here is that the user would always run this command
after pg_upgrade, without having to think about whether pg_upgrade had
migrated statistics or not.
If the community thinks this is useful, I could put together a patch.
mark
> On Dec 8, 2017, at 9:21 AM, Stephen Frost wrote:
>
> Mark,
>
> * Mark Dilger (hornschnor...@gmail.com) wrote:
>>> On Dec 7, 2017, at 10:24 PM, Bruce Momjian wrote:
>>> I think the big problem with two-stage pg_upgrade is that the user steps
>>> are
On 04/12/17 17:20, Mark Kirkwood wrote:
On 04/12/17 16:08, Ashutosh Bapat wrote:
On Sun, Dec 3, 2017 at 5:56 AM, legrand legrand
wrote:
Hello,
I have a typical star schema, having dimension tables "product",
"calendar"
and "country" and a fact tab
> On Dec 13, 2017, at 12:07 AM, Andres Freund wrote:
>
> Hi,
>
> On 2017-07-17 12:54:31 -0700, Mark Dilger wrote:
>> These types provide a 4-byte datatype for storing real-world second
>> precision timestamps, as occur in many log files.
>
> These seem to
> On Nov 27, 2017, at 8:47 AM, Tomas Vondra
> wrote:
>
> Hi,
>
> Attached is an updated version of the patch series, fixing the issues
> reported by Mark Dilger:
>
> 1) Fix fabs() issue in histogram.c.
>
> 2) Do not rely on extra_data being StdAnalyze
ngetbitmap.patch.gz>
After applying these four patches to my copy of master, the regression
tests fail for F_SATISFIES_HASH_PARTITION 5028 as attached.
mark
regression.diffs
Description: Binary data
tput, which does not seem to restrict the scan
to just the relevant partitions. You could easily argue that this is beyond
the scope
of your patch (and therefore not your problem), but I doubt it makes much sense
to have boolean partitions without planner support for skipping partitions like
is
don
> On Dec 19, 2017, at 4:31 PM, Tomas Vondra
> wrote:
>
> Hi,
>
> On 12/19/2017 08:17 PM, Mark Dilger wrote:
>>
>> I tested your latest patches on my mac os x laptop and got one test
>> failure due to the results of 'explain' coming up differe
> On Dec 19, 2017, at 5:16 PM, Tomas Vondra
> wrote:
>
>
>
> On 12/19/2017 08:38 PM, Mark Dilger wrote:
>>
>>> On Nov 18, 2017, at 12:45 PM, Tomas Vondra
>>> wrote:
>>>
>>> Hi,
>>>
>>> Apparently there
> On Dec 19, 2017, at 5:16 PM, Tomas Vondra
> wrote:
>
>
>
> On 12/19/2017 08:38 PM, Mark Dilger wrote:
>>
>>> On Nov 18, 2017, at 12:45 PM, Tomas Vondra
>>> wrote:
>>>
>>> Hi,
>>>
>>> Apparently there
erate complex (e.g. span multiple lines). In
> these cases the performance was not really up to par, so I experimented
> and in the end rewrote the functions in plperl. Which fixed the
> performance, so we no longer had this issue.
+1. I have done something similar, though in C rather than plperl.
As for the length limit, I have only hit that in stress testing, not in
practice.
mark
erIdAndSecContext(&saved_uid, &save_sec_context);
...
if (saved_uid != authid_uid)
SetUserIdAndSecContext(authid_uid,
save_sec_context |
SECURITY_LOCAL_USERID_CHANGE);
...
SetUserIdAndSecContext(saved_uid, save_sec_context);
need to have a third variable, saved_search_path or similar.
Thoughts?
mark
> On Aug 15, 2018, at 9:02 AM, Robert Haas wrote:
>
> On Tue, Aug 14, 2018 at 5:14 PM, Mark Dilger wrote:
>> I think you are interpreting the problem too broadly. This is basically
>> just a privilege escalation attack vector.
>
> Hmm. Well, I think you'
> On Aug 15, 2018, at 9:27 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> Go ahead and define some new lexical scope mechanism. I'm probably
>> going to move into the 21st century with you and use it. (I mostly
>> use "my", not "local"
mber of variations might be too many things to trend on this page, but
we can change that.
Regards,
Mark
--
Mark Wonghttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services
p;enable_seqscan,
.boot_val = true,
.check_hook = NULL,
.assign_hook = NULL,
.show_hook = NULL,
.reset_val = false,
.reset_extra = NULL
},
This sort of thing happens an awful lot in guc.c, but it comes up in syscache.c
also, and perhaps other places, though I don't recall any longer which other
files
were like this.
What should the general rule be for initializing arrays of structs such as
these?
mark
f it emerges as a problem
regards
Mark
regards, tom lane
, discarding the rest, right? It's
only when an explicit ordering is given that the need to store the results
arises. Even with
FETCH FIRST 50 PERCENT name FROM foo ORDER BY name;
you can return one row for every two rows that you get back from the
sort node, reducing the maximum number you need to store at any time to
no more than 25% of all rows.
Or am I missing something?
mark
> On Sep 20, 2018, at 5:29 PM, Andres Freund wrote:
>
> Hi,
>
> On 2018-09-20 17:06:36 -0700, Mark Dilger wrote:
>> I should think that spilling anything to a tuplestore would only be needed
>> if the query contains an ORDER BY expression. If you query
>>
While looking at some of the recent churn in DSA I noticed that
dsa_size_class_map should probably be declared const.
diff --git a/src/backend/utils/mmgr/dsa.c b/src/backend/utils/mmgr/dsa.c
index 33ab8d05d3..70ce7ce7da 100644
--- a/src/backend/utils/mmgr/dsa.c
+++ b/src/backend/utils/mmgr/dsa.c
@@
> On Sep 25, 2018, at 5:07 AM, Surafel Temesgen wrote:
>
> hey
>
> On 9/21/18, Mark Dilger wrote:
>
>> Surafel, there are no regression tests that I can see in your patch. It
>> would help if you added some, as then I could precisely what behavior you
>
> On Sep 25, 2018, at 8:08 AM, Mark Dilger wrote:
>
>
>
>> On Sep 25, 2018, at 5:07 AM, Surafel Temesgen wrote:
>>
>> hey
>>
>> On 9/21/18, Mark Dilger wrote:
>>
>>> Surafel, there are no regression tests that I can see in yo
BoxPGetDatum(in->leafDatum), true,
+ out->distances = spg_key_orderbys_distances(in->leafDatum, true,
in->orderbys, in->norderbys);
mark
On Fri, Sep 28, 2018 at 11:52:15AM -0700, Andres Freund wrote:
> Mark, is there anything odd for specific branches?
No... I don't have anything in the config that would be applied to
specific branches...
Regards,
Mark
--
Mark Wonghttp://www.2ndQuad
Hi Andres,
On Fri, Sep 28, 2018 at 03:41:27PM -0700, Andres Freund wrote:
> On 2018-09-28 15:22:23 -0700, Mark Wong wrote:
> > On Fri, Sep 28, 2018 at 11:52:15AM -0700, Andres Freund wrote:
> > > Mark, is there anything odd for specific branches?
> >
> > No... I don
3433a2313e | ---- |
1
3f3e3c3b-3a30-3938-3736-353433a2313e | ---- |
1
3f3e3c3b-3a30-3938-3736-353433a2313e | 3f3e3c3b-3a30-3938-3736-353433a2313e |
0
(9 rows)
Regards,
Mark
--
Mark Wonghttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, RemoteDBA, Training & Services
ef.pl does. How do
we build Postgres for Windows
using Visual Studio?
Thanks, Mark
Thanks Bill! Do you have a sample meson command for building that you could
share?
Thanks, Mark
From: Bill Smith
Sent: Friday, October 18, 2024 4:11 PM
To: Mark Hill
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: msvc directory missing in PostgreSQL 17.0
EXTERNAL
On Oct 18, 2024
ndex AM strategy numbers and
> RowCompareType (with some small extensions). This is what this
> patch does.
As the patch author, obviously this is the one I chose. The "small extensions"
are just to handle "no such value" type cases.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
95 bytes
0 Dir(s) 210,974,670,848 bytes free
I don't know why meson cannot find the OpenSSL installation I've specified via
the options:
extra_lib_dirs
extra_include_dirs
Thanks, Mark
Build started at 2024-11-13T09:37:45.113951
Main binary: C:\Python\Python310\python.exe
Bu
ch series, and it also
> makes the affected code areas simpler and more consistent and robust.
>
Thanks for the review!
Yes, I found the existing use of a btree strategy number rather than a boolean
"reverse" flag made using the code from other index AMs needlessly harder. I
a
tions.
How do I specify to meson that I want it to use the versions of those 3
software packages that I have built
e.g. the openssl I want it to use is located in
D:\Postgres-Builds\OpenSSL\OpenSSL-Install\OpenSSL-3.1.6-wx6
and similar locations for icu and zlib?
Thanks, Mark
Srinath is in India I believe and not available currently. Does anybody have
any idea why meson
is not finding the paths I'm specifying with the -Dextra_lib_dirs and
-Dextra_include_dirs? See below.
Thanks, Mark
From: Mark Hill
Sent: Wednesday, November 6, 2024 10:33 AM
To: 'Sri
ed 1 (wstat 256, 0x100)
Failed 1/272 subtests
The first part of your patch which checks the xmin_status seems ok at first
glance.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 27, 2024, at 4:57 AM, Peter Eisentraut wrote:
>
> On 26.11.24 15:27, Andrew Dunstan wrote:
>> On 2024-11-19 Tu 6:26 PM, Mark Dilger wrote:
>>>> On Nov 16, 2024, at 9:10 AM, Kirill Reshke wrote:
>>>>
>>>> Hi! Can we please have a
> On Nov 16, 2024, at 9:10 AM, Kirill Reshke wrote:
>
> Hi! Can we please have a rebased version of this patch series?
Sorry for the delay, and thanks for your interest. I will try to get around to
rebasing in the next few days.
—
Mark Dilger
EnterpriseDB: http://www.enterprised
resolved
external symbol errors (see below.) I checked a few of the symbols and they
appear in the Postgres source without the "_72" text on
the end. Is it getting "72" from the version of icu4c I'm using, 72.1?
Anyone know how to prevent these errors?
Thanks, Mar
Does the CVE-2024-10979 affect Postgres that is NOT built with the --with-perl
option?
Thanks, Mark
g back
several versions.
How about we fix this now? I threw this together in a hurry, and might have
screwed it up, so please check carefully. If you like this, we should go at
least one more round of making sure this has thorough regression testing, but
just to get your feedback, this can b
ned that all up.
Regards,
Mark
> On Feb 21, 2025, at 9:07 AM, Mark Dilger wrote:
>
> I infer that you intend to make v34-0004, v34-0006, and v35-0001 apply
> cleanly without the other patches and commit it that way. If that is
> correct, be advised that I'm doing a review and will respond back shortl
> On Feb 21, 2025, at 12:16 PM, Mark Dilger
> wrote:
>
> The pgbench script is not corrupting anything overtly, so this looks to
> either be a bug in gin or a bug in the check.
I suspected the AccessShareLock taken by verify_gin() might be too weak, and
u
be
advised that I'm doing a review and will respond back shortly, maybe in a few
hours.
—
Mark Dilger
+001 (360) 271-8498
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
but I'm really dubious that it's worth
> > > the work.
> >
> > Agreed.
>
> This means that unless Mark is willing to install OpenSSL 3 from source,
> these buildfarm animals are not viable. I'll wait for Mark to confirm,
> but given the number
ersions ship with OpenSSL 1.1,
> though of course OpenSSL 3 could be installed on them. Should I just
> delete these requests?
I’m away from my desk until later this week so I don’t recall whether Ubuntu
with FIPS is supposed to work. If someone already knows I’m ok with deleting
them. Otherwise I will double check soon…
Regards,
Mark
On Tue, Mar 4, 2025 at 6:05 AM Mark Dilger
wrote:
> But then I tried:
>
> +DO $$
> +DECLARE
> + a jsonb := '{"": 6, "NU": [{"": [[3]]}, [6], [2], "bCi"], "aaf": [-6,
> -8]}'::jsonb;
> +BEGIN
> + WHILE
t assignment
which suggests the plpgsql parser does not recognize a."NU" as we'd
expect. Any thoughts on this?
I notice there are no changes in src/interfaces/ecpg/test, which concerns
me. The sqljson.pgc and sqljson_jsontable.pgc files are already testing
json handling in ecpg; perhaps just extend those a bit?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
-6, "__": [""], "YMb":
-22}'::jsonb;
SELECT COUNT(*) FROM tbl WHERE j @> '{"853": -60, "pjx": "",
"TGLUG_jxmrggv": null}'::jsonb;
SELECT COUNT(*) FROM tbl WHERE j @>
'"D3BDA069074174vx48A37IVHWVXLUP9382542ypsl1465pixtryzCBgrkkhrvCC_BDDFat
ews. These were v21-0011 and v21-0012, except that
> I'm combining the switch from strategies to compare types (which was in
> v21-0006 or so) with the removal of the btree requirements.
>
v21.2-0004-* is ready for commit.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
;
seems fine. There are no other callers as yet.
You have made me a bit paranoid that, in future, we might add additional
callers who are not anticipating the error. Should we solve that with a
more complete code comment, or do you think refactoring is in order?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
mily_properties(opno, opfamily, isorderby,
&op_strategy,
+ NULL,/* don't need
cmptype */
&op_lefttype,
&op_r
're at v34 already, and the
> recent changes were mostly cosmetic. Does anyone object to me polishing
> and pushing those parts?
>
Kirill may have addressed my concerns in the latest version. I have not
had time for another review. Tomas, would you still like to review and
pu
up | n_dead_tup | n_tup_ins | n_ins_since_vacuum
++---+
2 | 8 |10 | 10
(1 row)
If we went with your suggestion, I think the final n_ins_since_vacuum
column would be 2. Do you think the n_tup_ins should also be 2? Should
those
*/
What work do you believe the word "mainly" does in that paragraph? The
presence of the word "mainly" rather than "only" somewhat cuts against your
argument that we should only be counting tuples that get inserted without
aborting.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
xplicit, it is hard for others to get
behind your proposal.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
What are the economics of this? I used PostgreSQL and Cygwin 25 years ago
and am amazed it is still a thing.
How much effort is it to support PostgreSQL on Cygwin?
How many actual users are using PostgreSQL on cygwin in production? (I
should hope none!)
I would say it is something that should be a
000103030c00 help + 0
18 dyld0x00018eb17154 start + 2476
This looks sufficiently different from the assertion mentioned on the other
thread to be worth posting here.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
_skipscan2.sql
Description: application/sql
few days
ago. I have not encountered any of the problems that I had been
encountering previously. That's not proof, but I was hitting these
failures pretty consistently before the patches.
I have no objection.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
the review process, making the initial review barrier that
little bit higher.
ATB,
Mark.
On 20/05/2024 06:56, Mark Cave-Ayland wrote:
In general you find that a series consists of 2 parts: 1) a set of refactorings to
enable a new feature and 2) the new feature itself. Even if the details of 2) are
still under discussion, often it is possible to merge 1) fairly quickly which also
1101 - 1161 of 1161 matches
Mail list logo
