icu" and "libc" that it currently accepts, I wonder if it might
accept "test" or similar, and then you could create a test in src/test/modules
that compiles a "test" provider, creates a database with indexes dependent on
something from that provider, stops the
returns a different version string and has genuinely different collation rules
between versions, thereby breaking the index until it is updated. Is that
being tested?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 15, 2021, at 10:34 AM, Julien Rouhaud wrote:
>
> On Mon, Mar 15, 2021 at 10:13:55AM -0700, Mark Dilger wrote:
>>
>>
>>> On Mar 15, 2021, at 9:52 AM, Julien Rouhaud wrote:
>>>
>>> But there are also the tests in collate.icu.utf8.
> On Mar 15, 2021, at 10:50 AM, Julien Rouhaud wrote:
>
> On Mon, Mar 15, 2021 at 10:40:25AM -0700, Mark Dilger wrote:
>> I'm saying that your patch seems to call down to
>> get_collation_actual_version() via get_collation_version_for_oid()
sible that pg_statistic really is corrupt here, and that this is not a
bug in pg_amcheck? It's not like we've been checking for corruption in the
build farm up till now. I notice that this test, as well as test
005_opclass_damage.pl, neglects to turn off autovacuum for th
> On Mar 15, 2021, at 11:10 AM, Julien Rouhaud wrote:
>
> On Mon, Mar 15, 2021 at 10:56:50AM -0700, Mark Dilger wrote:
>>
>>
>>> On Mar 15, 2021, at 10:50 AM, Julien Rouhaud wrote:
>>>
>>> On Mon, Mar 15, 2021 at 10:40:25AM -0700, Mark Dil
> On Mar 15, 2021, at 11:11 AM, Mark Dilger
> wrote:
>
> I will submit a patch that turns off autovacuum for the test node shortly.
v5-0001-Turning-off-autovacuum-during-corruption-tests.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
Th
> On Mar 15, 2021, at 11:32 AM, Mark Dilger
> wrote:
>
> If you had a real, not fake, collation provider which actually provided a
> collation with an actual version number, stopped the server, changed the
> behavior of the collation as well as its version number,
reason to assume that is the issue. If we still see the complaint
on tern or hornet after committing the patch to turn off autovacuum, we will be
able to rule out the theory that the toast was removed by autovacuum.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
v6-0002-Fixing-a-confusing-amcheck-corruption-message.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ing-a-confusing-amcheck-corruption-message.patch
Description: Binary data
v7-0003-Extend-pg_amcheck-test-suite.patch
Description: Binary data
v7-0004-Add-extra-check-of-toast-pointer-in-amcheck.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
is
propogating corruptions into pg_statistic, and also the theory that it is
architecture dependent.
I'll investigate further.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 16, 2021, at 9:07 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I think autovacuum simply triggers the bug, and is not the cause of the bug.
>> If I turn autovacuum off and instead do an ANALYZE in each test database
>> rather than performing the corru
> On Mar 16, 2021, at 9:30 AM, Mark Dilger wrote:
>
>
>
>> On Mar 16, 2021, at 9:07 AM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> I think autovacuum simply triggers the bug, and is not the cause of the
>>> bug. If I turn autov
> On Mar 16, 2021, at 10:48 AM, Tom Lane wrote:
>
> Robert Haas writes:
>> On Tue, Mar 16, 2021 at 12:51 PM Mark Dilger
>> wrote:
>>> It shows them all has having attalign = 'd', but for some array types the
>>> alignment will be
for who owns
the toast. Is this safe? Looking at RemoveStatistics, I'm not sure that it
is. Anybody more familiar with this code care to give an opinion?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
*
> HEAPTUPLE_LIVE */
>else
>return false; /*
> HEAPTUPLE_RECENTLY_DEAD or HEAPTUPLE_DEAD */
>}
>return true; /* not dead */
> }
>
> That first case looks wrong to me. Do
about the xmax having been committed.
Either way, you've got corruption.
Your question "preventing cutoff_xid to be greater than XID of some transaction
which was aborted long time ago" seems to be ignoring that
TransactionIdDidCommit(xid) is returning true, suggesting the tran
> On Oct 28, 2020, at 8:56 AM, Konstantin Knizhnik
> wrote:
>
>
>
> On 28.10.2020 18:25, Mark Dilger wrote:
>>
>>> On Oct 28, 2020, at 6:44 AM, Konstantin Knizhnik
>>> wrote:
>>>
>>> Looks like there is no assumpti
TERIALIZED VIEW and also CREATE TABLE AS, which also do not return the row
count. I think this behavior is historical, and preserved for compatibility.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 5, 2020, at 4:45 PM, Fujii Masao wrote:
>
>
>
> On 2020/11/06 1:56, Mark Dilger wrote:
>>> On Nov 5, 2020, at 8:20 AM, Fujii Masao wrote:
>>>
>>> The patch that makes pg_stat_statements track the number of rows that
>>> REFRESH
;m happy to put together a more concrete proposal, but solicit your opinions
first on the merits of the idea generally, and if you think the idea good, on
the specifics you'd like to see included.
Thanks!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 15, 2020, at 10:47 PM, Bharath Rupireddy
> wrote:
>
> On Thu, Nov 12, 2020 at 4:01 AM Mark Dilger
> wrote:
>>
>> While supporting customers, it would frequently be useful to have more
>> information about the history of a cluster. For example, w
> On Nov 15, 2020, at 11:23 PM, Ian Lawrence Barwick wrote:
>
> 2020年11月16日(月) 15:48 Bharath Rupireddy
> :
>>
>> On Thu, Nov 12, 2020 at 4:01 AM Mark Dilger
>> wrote:
>>>
>>> While supporting customers, it would frequently be useful to h
ould therefore harden the
backend. The performance considerations of the backend are not well aligned
with the safety considerations of this tool. The backend code is written with
the assumption of non-corrupt data, and this tool with the assumption of
corrupt data, or at least a fair pro
Thanks for your reply. The patch is exactly what I want.
My English name is Mark Zhao, which should be the current email name.
Thanks,
Mark Zhao
-- Original --
From: "Amit Kapila";
Looking over the recently committed work for btree tuple deletion (d168b66)
should this variable not be declared static as in the attached patch?
Thanks,
Mark.
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c
index faffbb1..bbdc1ce 100644
--- a/src/backend/access
this patch?
Best Regards,
Mark Rofail
On Tue, 19 Jan 2021 at 2:22 PM Joel Jacobson wrote:
> On Mon, Jan 18, 2021, at 18:23, Tom Lane wrote:
> > I realized that there's a stronger roadblock for
> > treating catalog interrelationships as SQL foreign keys. Namely,
> &
I'll post tomorrow the latest rebased patch with a summary of the issues.
Let's continue this in the foreign key array thread, as to not clutter this
thread.
Regards, Mark Rofail.
On Tue, Jan 19, 2021, 11:00 PM Joel Jacobson wrote:
> On Tue, Jan 19, 2021, at 18:25, Mark Rofail w
ent issue blocked me from doing so.
Reviews and suggestions are most welcome, @Joel Jacobson
please
review and test as previously agreed.
/Mark
On Tue, Oct 2, 2018 at 7:13 AM Michael Paquier wrote:
> On Sat, Aug 11, 2018 at 05:20:57AM +0200, Mark Rofail wrote:
> > I am still having probl
ot;Array-containselem-gin-v1.patch" can you give the v13 patch a
try alone?
I will work on a fix and send it soon.
/Mark
correct me if I am
wrong. I feel that supporting vectors is our of the scope of this patch, if
you have an idea how to support it please let me know.
/Mark
se don't hesitate to give your feedback.
I would love some help with some performance comparisons if you are up to
it, between Many-to-Many, Foreign Key Arrays and Gin Indexed Foreign Key
Arrays.
/Mark
On Tue, Jan 26, 2021 at 1:51 PM Joel Jacobson wrote:
> Hi Mark,
>
> On Mon, Jan
p the good work testing this patch.
/Mark
On Wed, Jan 27, 2021 at 5:11 AM Joel Jacobson wrote:
> On Tue, Jan 26, 2021, at 12:59, Mark Rofail wrote:
> > Please don't hesitate to give your feedback.
>
> The error message for insert or update violations looks fine:
>
> U
didn't target the refrencing or refrenced columns
Vectors as refrencing columns are not supported and out of scope of this
patch. Try to use arrays.
/Mark
hat's patterned on reindexdb and vacuumdb.
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
use some wordsmithing to account for the new structure
> of things -- maybe just "this pass" -> "this function".
> - I suggest changing initializations like maxbuf = buf + 2 to maxbuf =
> &buf[2] for clarity.
Ok, I should be able to get you an updated version
> On Jan 28, 2021, at 9:49 AM, Robert Haas wrote:
>
> On Thu, Jan 28, 2021 at 12:40 PM Mark Dilger
> wrote:
>>> On Jan 28, 2021, at 9:13 AM, Robert Haas wrote:
>>> If I run pg_amcheck --all -j4 do I get a serialization boundary across
>>> databases
> On Jan 28, 2021, at 9:41 AM, Mark Dilger wrote:
>
>
>
>> On Jan 28, 2021, at 9:13 AM, Robert Haas wrote:
>>
>> I like 0007 quite a bit and am inclined to commit it soon, as it
>> doesn't depend on the earlier patches. But:
>>
>> -
mented. You can find it in the
previous message.
> As always thank you for your great insight and your help.
/Mark
being told to use
pg_file_read() instead also doesn't make sense, because it doesn't exist.
I was going to submit a patch for this, but the more I look at it the less I
understand what is intended by this code. Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
he FKARRAY as a future patch?
So basically reverse the order of the patches.
/Mark
erator patch):
- v1 (compatible with current master 2021-02-05,
commit c72af5c202067a9ecb0ff8df7370fb1ea8f4)
* add tests and documentation to array operators and gin index
/Mark
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index b7150510ab..3d36e88494 100644
--- a/doc/src/sgml/func.sgml
+++
re. I don't think I am well acquainted with the codebase to
actually mentor someone. Maybe if I get some experience I would be ready
for GSoC 2022.
Thanks again Stephen and Álvaro
/Mark
;public.junk"
Column | Type | Collation | Nullable | Default
+--+---+--+-
t | text | | |
Indexes:
"junk_idx" UNIQUE, btree (t)
\d junk_idx
Index "public.junk_idx"
Column | Type | Key? | Definition
+--+--+
t | text | yes | t
unique, btree, for table "public.junk"
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hey Joel,
> Here comes a first review of the anyarray_anyelement_operators-v1.patch.
Great, thanks! I’ll start applying your comments today and release a new
patch.
/Mark
y honoring those privilege restrictions.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
human intervention."
We shouldn't need to categorize all error codes perfectly, as long as we're
conservative. What I propose is similar to how we determine whether to mark a
function leakproof; we don't have to mark all leakproof functions as such, we
just can't mark
n-superuser (task 1,
above) without going so far as creating new paths by which that situation could
arise (tasks 2 and 3, above).
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ing the
subscription in response to an occasional deadlock against other database
users, or occasional resource pressure, might annoy people and lead to the
feature simply not being used.
I am happy to defer to your policy preference. Thanks for your work on the
patch!
—
Mark Dilger
Enterpri
We will talk about other points of the roadmap you mentioned once our
> understanding for the first one matches.
I am happy to have an off-list phone call with you, if you like.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
? For patches that apply trivially, that might not
be worth keeping, but if the merge is difficult, maybe sharing with the
community would make sense.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nstance) volunteers to do it for some subset of minor
releases. For my heap corruption checking work, I might want to be able to
build a small number of old minor releases that I know had corruption bugs.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> error_codes fall in the transient error category.
No need. We can revisit this design decision in a later release cycle if the
current patch's design proves problematic in the field.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Dec 8, 2021, at 8:09 PM, Amit Kapila wrote:
>
> So, do you agree that we can disable the subscription on any error if
> this parameter is set?
Yes, I think that is fine. We can commit it that way, and revisit the issue
for v16 if it becomes a problem in practice.
—
e
lock traffic would be worth expending. Between (a) changing roles
mid-transaction, and (b) locking the subscription for each transaction, I'd
prefer to do neither, but (b) seems far better than (a). Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
proposed seems right to me. We change subscriptions to
use a foreign server rather than a freeform connection string. When creating
or altering a subscription, the role performing the action must have privileges
on any foreign server they use.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
guration exists.
Jeff Davis and Andrew Dunstan have volunteered as committers.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
$subdir = 0;
> +$subdir++ while (-e "$tempbase/$subdir");
> +my $tempdir = "$tempbase/$subdir";
> +system("mkdir $tempdir");
>
>
>
> What's going on here?
Yeah, I hit that, too. That was an accidentally committed bit of local
testing. Please ignore it for now.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ing ExecInsert is quite appealing. I think that would require
reworking the logical replication protocol to send more than one row at a time,
so that the overhead of such a choice is not paid *per row*. That seems quite
out of scope for this release cycle, though.
—
Mark Dilger
EnterpriseDB:
but having a hook for grant/revoke is
> also helpful.
Yes, I see no reason to rip this out.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
it's less
> likely that we miss something in the future?
Let's just punt on this for now.
v4-0001-Respect-permissions-within-logical-replication.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ting
names, not Oids, and include additional information about whether the operation
is SET, RESET or ALTER SYSTEM, what the new value is (if any), what kind of
setting it is (bool, int, ...), etc. I don't think such a patch would even be
all that hard to write.
What do you t
e on version 1.3 and some on
version 1.4. Then test that the --checkunique option works adequately.
I have not reviewed the changes to verify_nbtree.c. I'll leave that to Peter.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Rebased patch attached:
v3-0001-Reject-patterns-with-too-many-parts-or-wrong-db.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Rebased patch attached:
v3-0001-Reject-storage-options-in-toast-namespace-in-view.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
have eliminated all pre-v9.3 bit patterns, and
therefore any such existing patterns are certainly corruption, or does it mean
that data written by pre-v9.3 servers (and not subsequently updated) is defined
as corrupt, or ?
I am not complaining that the logic is wrong, just trying to wra
;, oprright => 'money', oprresult => 'bool',
oprcom => '<>(money,money)', oprnegate => '=(money,money)',
oprcode => 'cash_ne', oprrest => 'neqsel', oprjoin => 'neqjoinsel' },
Looking at frame
> On Dec 21, 2021, at 4:28 PM, Mark Dilger wrote:
>
> Maybe there is some reason this is ok.
... and there is. Sorry for the noise. The planner appears to be smart enough
to know that column "salary" is not being changed, and therefore NEW.salary and
OLD.salary are
> On Dec 21, 2021, at 5:11 PM, Shinya Kato
> wrote:
>
> I fixed the patches because they cannot be applied to HEAD.
Thank you.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Dec 22, 2021, at 12:01 AM, Pavel Borisov wrote:
>
> Thank you, Mark!
>
> In v6 (PFA) I've made the changes on your advice i.e.
>
> - pg_amcheck with --checkunique option will ignore uniqueness check (with a
> warning) if amcheck version in a db is <1.4
e" with OID 16384 owns itself
No, that looks like a bug. Thanks for reviewing!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jan 4, 2022, at 9:07 AM, Mark Dilger wrote:
>
> No, that looks like a bug.
I was able to reproduce that using REASSIGN OWNED BY to cause a user to own
itself. Is that how you did it, or is there yet another way to get into that
state?
—
Mark Dilger
Enterpris
s now) for keeping an example contained within
a single function. The only reason I can come up with is to try to read
through an example with minimal jumping around.
Hoping this is a good start.
Regards,
Mark
diff --git a/src/test/modules/plsample/expected/plsample.out b/src/test/modules/plsampl
> On Mar 16, 2021, at 12:52 PM, Robert Haas wrote:
>
> On Mon, Mar 15, 2021 at 10:10 PM Mark Dilger
> wrote:
>> It is unfortunate that the failing test only runs pg_amcheck after creating
>> numerous corruptions, as we can't know if pg_amcheck would have comp
dn't you at least need a configure test to
verify that the version of gcc being used generates the desired assembly? Even
then, you'd be banking on gcc doing the same thing for the test code and for
the pglz code, which I guess might not be true. Have you considered using
inline asse
0.78% postgres [.] GetSnapshotData
>
> Overall cluster runs 862tps (52KtpmC, though only 26KtmpC is qualified on 2K
> warehouses).
>
> Thanks!
Robert Haas just committed Dilip Kumar's LZ4 compression,
bbe0a81db69bd10b
Hi Zhihing,
I think @Andreas ment to mark it as a todo to cleanup later.
On Sun, 21 Mar 2021 at 4:49 AM Zhihong Yu wrote:
> Hi,
> In v11-0004-fk_arrays_elems_edits.patch :
>
> + riinfo->fk_reftypes[i] ==
> FKCONSTR_REF_EACH_ELEMENT ? OID_ARRA
but
that would be more informative than no failures at all.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 17, 2021, at 9:00 PM, Mark Dilger wrote:
>
> Of the toast pointer fields:
>
>int32 va_rawsize; /* Original data size (includes header) */
>int32 va_extsize; /* External saved size (doesn't) */
>Oid va_valueid; /*
x @>> index”
thus indirectly using the GIN index.
We can definitely add tests to “ src/test/regress/sql/gin.sql” to test
this. Do you agree?
Also what do you mean by “ ginqueryarrayextract needs to be told about this
too”?
Best Regards,
Mark Rofail
>
> Hey Alvaro,
Well, if it's true that it's translated to the commutator, then I don't
>
think any other code changes are needed.
Great, I will get a patch ready tomorrow. Hopefully we’ll wrap up the GIN
part of the patch soon.
/Mark
, the pg_stat_database data is split up
between dbblk.c, dbtup.c, and dbxact.c.
Regards,
Mark
> On Mar 24, 2021, at 1:46 PM, Robert Haas wrote:
>
> Mark,
>
> Here's a quick and very dirty sketch of what I think perhaps this
> logic could look like. This is pretty much untested and it might be
> buggy, but at least you can see whether we're thinking
lacing-implementation-of-check_tuple_visibili.patch
Description: Binary data
v13-0003-Renaming-report_corruption-as-report_main_corrup.patch
Description: Binary data
v13-0004-Checking-toast-separately-from-the-main-table.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www
output of pg_config, though, since this problem
is likely to come up again with other options/commands.
Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 30, 2021, at 10:39 AM, Mark Dilger
> wrote:
>
> Andrew,
>
> While developing some cross version tests, I noticed that PostgresNode::init
> fails for postgres versions older than 9.3, like so:
>
> # Checking port 52814
> # Found port 52814
> Name: 9
> On Mar 30, 2021, at 3:12 PM, Alvaro Herrera wrote:
>
> On 2021-Mar-30, Mark Dilger wrote:
>
>> The problem is clear enough; -N/--nosync was added in 9.3, and
>> PostgresNode::init is passing -N to initdb unconditionally. I wonder
>> if during PostgresNode
Keeping the WIP marking on the patch until we hear Andrew's opinion on all this.
v2-0001-Extending-PostgresNode-cross-version-functionalit.patch.WIP
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 30, 2021, at 5:44 PM, Andrew Dunstan wrote:
>
> I'll try to come up with something tomorrow.
I hope the patch I sent is useful, at least as a starting point.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
in not being able to rely on the path. There really isn't enough
motivation for changing TestLib, I don't think, because subsequent calls to
pg_config don't need to be paranoid, just the first call.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Mar 30, 2021, at 12:45 PM, Robert Haas wrote:
>
> On Mon, Mar 29, 2021 at 7:16 PM Mark Dilger
> wrote:
>> Sure, here are four patches which do the same as the single v12 patch did.
>
> Thanks. Here are some comments on 0003 and 0004:
>
> When you posted v
> On Mar 31, 2021, at 10:11 AM, Robert Haas wrote:
>
> On Wed, Mar 31, 2021 at 12:34 AM Mark Dilger
> wrote:
>> I'm not looking at the old VACUUM FULL code, but my assumption is that if
>> the xvac code were resurrected, then when a tuple is moved off by a VACUU
> On Mar 31, 2021, at 10:31 AM, Mark Dilger
> wrote:
>
>
>
>> On Mar 31, 2021, at 10:11 AM, Robert Haas wrote:
>>
>> On Wed, Mar 31, 2021 at 12:34 AM Mark Dilger
>> wrote:
>>> I'm not looking at the old VACUUM FULL code, but my assu
> On Mar 30, 2021, at 5:41 PM, Mark Dilger wrote:
>
> 1) PostgresNode::init() doesn't work for older server versions
PostgresNode::start() doesn't work for servers older than version 10, either.
If I hack that function to sleep until the postmaster.pid file exists, it
> On Mar 31, 2021, at 1:05 PM, Andrew Dunstan wrote:
>
>
> On 3/31/21 3:48 PM, Alvaro Herrera wrote:
>> On 2021-Mar-31, Mark Dilger wrote:
>>
>>> PostgresNode::start() doesn't work for servers older than version 10,
>>> either. If I hack
> On Mar 31, 2021, at 1:07 PM, Mark Dilger wrote:
>
>
>
>> On Mar 31, 2021, at 1:05 PM, Andrew Dunstan wrote:
>>
>>
>> On 3/31/21 3:48 PM, Alvaro Herrera wrote:
>>> On 2021-Mar-31, Mark Dilger wrote:
>>>
>>>> Po
> On Apr 1, 2021, at 8:08 AM, Robert Haas wrote:
>
> On Wed, Mar 31, 2021 at 12:34 AM Mark Dilger
> wrote:
>> These changes got lost between v11 and v12. I've put them back, as well as
>> updating to use your language.
>
> Here's an updated patch
> On Apr 1, 2021, at 9:56 AM, Robert Haas wrote:
>
> On Thu, Apr 1, 2021 at 12:32 PM Mark Dilger
> wrote:
>>> - If xmax is a multi but seems to be garbled, I changed it to return
>>> true rather than false. The inserter is known to have committed by
>>>
> On Apr 1, 2021, at 10:20 AM, Robert Haas wrote:
>
> On Thu, Apr 1, 2021 at 1:06 PM Mark Dilger
> wrote:
>> Seems fine other than the typo.
>
> OK, let's try that again.
Looks good!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
101 - 200 of 1160 matches
Mail list logo
