(relation->rd_replidindex);
for (i = 0; i < indexDesc->rd_index->indnatts; i++)
is unsafe without further checks, also attached.
Would you mind taking a look?
v1-0001-Fixing-bug-in-logical-replication.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.ente
> On Jun 16, 2021, at 10:19 PM, osumi.takami...@fujitsu.com wrote:
>
> I started to analyze your report and
> will reply after my idea to your modification is settled.
Thank you.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
would work in almost all cases. In any event, they seemed
better than no checks, which is what we have now.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
mment was insufficient. I have added a more detailed code comment to
explain the purpose of the check. I also changed the first check to use
RelationIsValid(), as suggested upthread.
v2-0001-Fixing-bug-in-logical-replication.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
scriptions-on-error.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s will results in more and more
data integrity problems (foreign key references, etc.) such that the failures
will snowball with skipping becoming the norm rather than the exception. Users
with those usage patterns would likely prefer the subscription to automatically
be disabled until manual
ra field, and am inclined to think it
would be excessive, but maybe others feel differently?
> ==
>
> Test: Cause a PK violation in the Tablesync copy (DATASYNC) phase.
> (when disable_on_error = true)
> Observation: This patch changes nothing for this case. The Ta
https://www.postgresql.org/message-id/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK%3D30xJfUVihNZDA%40mail.gmail.com
[2] -
https://www.postgresql.org/message-id/flat/915B995D-1D79-4E0A-BD8D-3B267925FCE9%40enterprisedb.com#dbbce39c9e460183b67ee44b647b1209
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jun 19, 2021, at 7:44 AM, Mark Dilger wrote:
>
> Wouldn't the user rather skip just the problematic rows? I understand that
> on the subscriber side it is difficult to do so, but if you are going to
> implement this sort of thing, it makes more sense to allow the u
case and publish quantitative results about
how bad it is.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
transactions to purge is small, but I don't like designing the feature around
that assumption.
All the same, I'm looking forward to seeing your patch!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
kipped, it
would seem that arbitrarily many such transactions could be committed on the
publisher side.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
is akin
to a statement level trigger and not a row level trigger, so a number of things
you might want to do would be hard to do from this. But perhaps the equivalent
of row level triggers could also be written?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
the first is cleared, but that still leaves the
user having to clear one after the next until arbitrarily many of them coming
from the publisher side are cleared.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
aybe that needs to be
stored somewhere else. Do you believe pg_subscription_rel is a suitable
location?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ubmitted, the
error message will remain, though I take Amit's point that there are
deficiencies in handling parallel tablesync workers, etc.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
if you are writing a TAP test, you should be the one controlling whether
that is the case. I don't think it would be unpredictable from the point of
view of the test author.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
us short network outages, but then gets
autodisabled after a longer network outage. I'm not sure why anybody would
want that. You might argue for exponential backoff, where it never gets
autodisabled on transient errors, but retries less frequently. But I don't
want to expand the scope of this patch to include that, at least not without a
lot more evidence that it is needed.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
equently contains
strings shorter than 16 bytes. Is it worth sharting a static inline function
that uses your optimization in other places? How confident are you that your
optimization really helps?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jun 28, 2021, at 9:05 AM, Mark Dilger wrote:
>
> Is it worth sharting a static inline function that uses your optimization in
> other places?
s/sharting/sharing/
> How confident are you that your optimization really helps?
By which I mean, is the optimization worth t
le ways to
cut up the set of all GUCs. database/host/network is not an entirely clean
distinction, and perhaps database/host/network/replication is better, but I'm
uncertain.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
?
Thanks, Peter, for drawing my attention to this. I had already been following
this thread, but had not yet thought about the problem in terms of amcheck.
I will investigate possible solutions in verify_heapam().
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 27, 2022, at 6:26 PM, Andres Freund wrote:
>
> I'm a bit confused - what's the relation of that failure to this thread / the
> tests / this commit?
None, upon further reflection. It turned out to be unrelated. Sorry for the
noise.
—
Mark Dil
bject to the table's row-level security policies (Mark Dilger)
... should mention, independent of any RLS considerations, subscriptions are
now applied under the privilege of the subscription owner. I don't think we
can fit it in the release note, but the basic idea is that:
> On May 10, 2022, at 6:46 PM, Bruce Momjian wrote:
>
> Allow logical replication to run as the owner of the publication
Make that "owner of the subscription". This change operates on the
subscriber-side.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The En
> On Jun 6, 2022, at 9:02 AM, Tom Lane wrote:
>
> Thoughts?
I think it depends on your mental model of what \dconfig is showing you. Is it
showing you the list of configs that you can SET, or just the list of all
configs?
he problem to manifest itself.
As a simple example, text[] constructed using array_agg over sorted data can be
corrupted by a collation change, and reindex won't fix it.
If we extend the table-AM interface to allow query quals to be pushed down to
the table-AM, we might develop
tile
marking is wrong, and a warning when you cannot prove the marking is correct?
That would tend to give warnings for polymorphic functions that use functions
or operators over the polymorphic types, or which use dynamic sql, but maybe
that's ok. Those functions probably deserve closer sc
did not (and likely will not)
back port it. I have had several occasions to want this functionality
recently, but the customers were on pre-v14 servers, so these tools were not
available anyway.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ay not be clustered" interface overly
simplistic?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
tomers, etc., and for a given piece of DDL that
you want to release you only want to say which TAMs not to use, not to nail
down which TAM must be used.
Thoughts? I'll hold off posting a patch until the general idea is debated.
[*] It takes some extra work to get the TAP tests to play al
> On Jun 15, 2022, at 6:01 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 17:21:56 -0700, Mark Dilger wrote:
>> While developing various Table Access Methods, I have wanted a callback for
>> determining if CLUSTER (and VACUUM FULL) should be run against a tab
he target is
pre-clustered, and both will run against the table if the user has run an ALTER
TABLE..CLUSTER ON. Now, we could try to catch that latter command with a
utility hook, but since the VACUUM FULL is still problematic, it seems cleaner
to just add the callback I am proposi
> On Jun 15, 2022, at 7:14 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 19:07:50 -0700, Mark Dilger wrote:
>>> On Jun 15, 2022, at 6:55 PM, Andres Freund wrote:
>>>
>>> I think nothing would happen in this case - only pre-clustered tables ge
> On Jun 15, 2022, at 7:21 PM, Mark Dilger wrote:
>
>> If a user does that for a table that doesn't support clustering, well, I
>> don't
>> see what's gained by not erroring out.
>
> Perhaps they want to give the TAM information about which in
ble with the new one. I'm left no choices but to
copy my data over, loose my data, or abort the command. None of those are OK
options for me.
I'm open to different solutions. If a simple callback like
relation_supports_cluster(Relation rel) is too simplistic, and more parameters
with mo
just trying to leverage the existing tests as much
as I can without having to reinvent tests to cover "chicago", and then reinvent
again to cover "detroit", and so forth.
If you develop enough TAMs in parallel, and go with the "using heap" solution,
you eventually
> On Jun 15, 2022, at 8:18 PM, Andres Freund wrote:
>
> Hi,
>
> On 2022-06-15 20:10:30 -0700, Mark Dilger wrote:
>>> On Jun 15, 2022, at 7:30 PM, Andres Freund wrote:
>>>> But it's up to the TAM what it wants to do with that boolean, if in fact it
&g
lause or appending no clause. Since the user can do this anyway, what's the
security implication in some syntactic sugar?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
In what sense does this made-up TAM conflict with mvcc and wal? It doesn't
have all the features of heap, but that's not the same thing as violating mvcc
or breaking wal.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nt, but what about a TAM that wants to
route different tuples to different pages? The "current_buf" isn't enough
information, and there's no void *extra field, so you're just sunk.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ot
asking the community to accept the TAM back as a patch. The freedom I'm
talking about is the freedom to design and implement such a third-party TAM
without seeking community approval of the TAM's merits.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t comments down-thread seem reasonable, so I suspect a new
patch will be needed. Would you like to author it, or would you prefer that I,
as the guilty party, do so?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
en it's not another backend, but our own, and we'd want to debug why
we're pinning the same page twice (or more) while replaying wal. Otherwise,
maybe it's a race condition with some other process that transiently pins a
buffer and occasionally causes this code to panic?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
invalidate that assumption.
v1-0001-WIP-patch-to-support-amcheck-of-sequences.patch.WIP
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
er parallel reindexes
and vacuums running in backends. It should be just as safe to ctrl-c out of
pg_amcheck as out of those two. They all three use fe_utils/cancel.h's
setup_cancel_handler(), so I would expect modifying verify_heapam would be
enough.
—
Mark Dilger
EnterpriseDB: htt
> On Aug 26, 2021, at 4:39 PM, Peter Geoghegan wrote:
>
>> Not any good one that I can see.
>
> Seems that way. Want to post a patch?
Sure. I just posted another unrelated patch for amcheck this morning, so it
seems a good day for it :)
—
Mark Dilger
> On Aug 26, 2021, at 4:41 PM, Mark Dilger wrote:
>
>> Seems that way. Want to post a patch?
>
> Sure.
v1-0001-Add-CHECK_FOR_INTERRUPTS-to-verify_heapam.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
, but
that seems confusing more than helpful.
Thoughts?
[1] https://www.postgresql.org/message-id/17554.1120258001%40sss.pgh.pa.us
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
appears not
to be. Do you think you could save the results rather than recomputing them?
It's a little messy, since these are the only two functions out of about ten
which follow this pattern, so you'd have to pass NULLs into
get_restriction_variable() from the other eight callers, but it still looks
like that would be a win.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
rate case of only one table end up with a table
column compared against itself.
You could argue that those people need to fix their queries/generators to not
do this sort of thing, but the end user affected by such queries may have
little ability to fix it.
—
Mark Dilger
EnterpriseDB: http
> On Aug 30, 2021, at 1:22 AM, Peter Eisentraut
> wrote:
>
> On 26.08.21 21:02, Mark Dilger wrote:
>> I understand that sequences are really just heap tables, and since we
>> already test corrupted heap tables, we could assume that we already have
>> sufficie
> On Aug 31, 2021, at 10:50 AM, Tomas Vondra
> wrote:
>
> I've pushed a fix for this. And then a fix for the fix :-( because I forgot
> about the rule that role names in regression tests should start with regress_
> prefix, so animals enforcing this failed.
rsion?
0001-Adding-tests-of-subscription-errors.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
(either a DELETE or an UPDATE) on the
existing data in the table where the conflict arises. These other options are
DDL and do not easily come to mind when I read that phrase.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Aug 31, 2021, at 5:15 AM, Amul Sul wrote:
>
> Attached is the rebased version for the latest master head.
Hi Amul!
Could you please rebase again?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Sep 7, 2021, at 9:00 PM, Noah Misch wrote:
>
> I wondered about using PGXS:: as the namespace for all these modules
That immediately suggests perl modules wrapping C code, which is misleading for
these. See `man perlxstut`
—
Mark Dilger
EnterpriseDB: http://www.enterprised
clear? This also would
be a better interface if taking the system read-only had a timeout as I
suggested above, as such a timeout parameter when allowing wal is less clearly
useful.
That's enough code review for now. Next I will review your regression tests
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
out. If
not, a mia culpa saying, "hey, were not terribly safe about this" should be
explicit in the comment.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to jump to the
definition, particularly if you are logged into a production server where
non-essential software is intentionally missing. Then you have to wonder, what
exactly is the boolean argument toggling here?
I don't feel strongly about this, though, and you don't need to change it.
> Apart from this, recently while testing this patch with
> pgbench where I have exhausted the connection limit and want to change
> the system's prohibited state in between but I was unable to do that,
> I wish I could do that using the pg_clt option. How about having a
> pg_clt option to alter wal prohibited state?
I'd have to review the implementation, but sure, that sounds like a useful
ability.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Sep 10, 2021, at 8:42 AM, Mark Dilger wrote:
>
> Take for example a code stanza from heapam.c:
>
>if (needwal)
>CheckWALPermitted();
>
>/* NO EREPORT(ERROR) from here till changes are logged */
>START_CRIT_SECTION();
>
> Now
ite.
uses "immediately" and "will kill the running transaction" which reenforced the
impression that this mechanism is heavier handed than it is.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
isolationtester-handle-closed-sessions.patch
Description: Binary data
v34-0010-Test-ALTER-SYSTEM-READ-ONLY-against-cursors.patch
Description: Binary data
[1]
https://www.postgresql.org/message-id/flat/CAP4vRV5gEHFLB7NwOE6_dyHAeVfkvqF8Z_g5GaCQZNgBAE0Frw%40mail.gmail.com#e10861372aec22119b66756ec
I have added in the latest version, but that test does not
> reinitiate the same connection again, I think that is not possible
> there too.
Perhaps you can point me to a TAP test that does this in a concise fashion.
When I tried writing a TAP test for this, it was much longer than the
equiv
e in such a
way as, for example, to make the attempt to open the cursor be a FATAL error,
you'd see a change in the test output.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ad that gave rise to the related commit. That test
happens to be stable on my laptop until I change GUC settings to both reduce
max_wal_size=32MB and to set wal_consistency_checking=all.
Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
it feels like we're just papering over the problem.
I'm inclined to guess that the problem in
src/bin/pg_basebackup/t/020_pg_receivewal.pl is similar.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
by doing so, though?
Does using a replication slot to force the wal to not be removed early break
what the test is designed to check?
The other tests raise similar questions. Is the brittleness intentional?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
rtful first post was really meant to say, "here is a problem that I
perceive about tap tests vis-a-vis wal files, do people disagree with me that
this is a problem, and would patches to address the problem be welcome?"I
took Tom's response to be, "yeah, go ahead", an
of that role before they can create subscriptions. That seems,
however, like something to do as a follow-on patch, since tightening up the
security on subscriptions as done in this patch doesn't depend on that.
v8.tar.bz2
Description: BZip2 compressed data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Sep 25, 2021, at 11:04 AM, Mark Dilger
> wrote:
>
> I took Tom's response to be, "yeah, go ahead", and am mostly waiting for the
> weekend to be over to see if anybody else has anything to say about it.
Here is a patch set, one patch per test. The third
sense of how stable it is. Applying my
patches too soon would just add more variables to a not-so-well understood
situation.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
,
which is certainly order dependent.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Sep 28, 2021, at 11:07 AM, Mark Dilger
> wrote:
>
> Looking closer at the TAP test, it's not ORDERing the result set from the
> SELECTs on either node, but it is comparing the sets for stringwise equality,
> which is certainly order dependent.
Taking the ou
les work
differently than for other object types. I have a patch pending [1] for the
version 15 development cycle that fixes this and other problems. I'd
appreciate feedback on the design and whether it addresses your concerns.
[1] https://commitfest.postgresql.org/34/3223/
—
Mark
when parsing
reloptions for views and instead create a VIEW_RELOPT_NAMESPACES array which
does not include "toast".
I've already fixed this, mixed into some other work. I'll pull it out as its
own patch if there is any interest.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
EATE ROLE command may now fail if the creating role has
insufficient privilege on the roles so listed. Such failures were
not possible before, since the CREATEROLE privilege was always
sufficient.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 1, 2021, at 6:15 AM, Alvaro Herrera wrote:
>
> On 2021-Sep-30, Mark Dilger wrote:
>
>> The solution is simple enough: stop using HEAP_RELOPT_NAMESPACES when
>> parsing reloptions for views and instead create a
>> VIEW_RELOPT_NAMESPACES array which doe
> On Oct 3, 2021, at 10:04 AM, Mark Dilger wrote:
>
>> On Oct 2, 2021, at 10:32 AM, Peter Geoghegan wrote:
>>
>> On Sat, Oct 2, 2021 at 4:49 AM PG Bug reporting form
>> wrote:
>>> Although you can add --exclude-relation=*.pg_temp*.*, this behaviour di
or ShareLock on relation 16406 of database 16384; blocked
by process 9555.
HINT: See server log for query details.
ERROR: cannot check index "t_idx"
DETAIL: Index is not valid.
[1] + exit 1 psql -c "CREATE INDEX CONCURRENTLY t_idx ON t(i);"
If Peter agrees that this is n
> On Oct 4, 2021, at 10:58 AM, Peter Geoghegan wrote:
>
> On Mon, Oct 4, 2021 at 8:10 AM Mark Dilger
> wrote:
>>> There is another issue, that maybe should be discussed separately (or
>>> this thread could be renamed to "... on checking specific relatio
hing other than a silent success is needed to
let them know what is going on.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 4, 2021, at 4:28 PM, Mark Dilger wrote:
>
> pg_amcheck -i idx1 -i idx2 -i idx3
I forgot to mention: There's a continuum between `pg_amcheck -a` which checks
everything in all databases of the cluster, and `pg_amcheck -i just_one_index`.
There are any number of c
say that a deadlock is possible, merely that the function may return with
an error. I was totally content to get an error back, since errors are how the
verify_nbtree functions communicate everything else, and the handler for those
functions is already prepared to deal with the error messages
ck or less can be acquired on database objects
during recovery.
It doesn't get as far as btree_index_mainfork_expected(). So I am changing
pg_amcheck to filter out indexes when pg_is_in_recovery() is true and
relpersistence='u'. Does that sound right to you?
—
Mark Dilger
E
le creation:
superuser
+---> alice
+---> charlie
+---> diane
+---> bob
It makes sense that alice can take ownership of diane and drop charlie, but not
that bob can do so. Nor should charlie be able to transfer ownership of diane
to alice. Nor should charlie be able to drop hi
t for the concern.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 5, 2021, at 10:14 AM, Stephen Frost wrote:
>
> What does the “ownership” concept actually buy us then?
DROP ... CASCADE.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 5, 2021, at 10:20 AM, Stephen Frost wrote:
>
> Greetings,
>
> On Tue, Oct 5, 2021 at 13:17 Mark Dilger wrote:
> > On Oct 5, 2021, at 10:14 AM, Stephen Frost wrote:
> >
> > What does the “ownership” concept actually buy us then?
>
> DROP ...
other stuff, then dropping the role cascade
means dropping the other stuff.
Could you elaborate more on the difference between object management and
consistency as it applies to this issue?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
reviewing!
I expect to post a new version shortly.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hecking options should be automatically downgraded under circumstances
where they cannot be applied
3) unlogged relations during replication are by definition not corrupt
I think #1 and #3 are unsurprising enough that they need no documentation
update. #2 is slightly surprising (at least to me)
tinguish between statements
like X SHALL DO Y and X SHALL DO NOTHING BUT Y. I don't know if the spec
contains a concept of roles owning other roles, and if not, does it forbid that
concept? I should think that if that concept is a postgres extension not
present in the spec, then
re, and now it just downgrades the check. This is
hardly tautological. I'm only willing to post a patch with that change because
I can see a practical argument that somebody might run that as a cron job and
they don't want the cron job failing when the database happens to go into
recovery. But again, not at all tautological.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
x27;d say that's irrelevant. I'm not
proposing to change what REVOKE does. If not, could you clarify? Did I
misunderstand?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
pg_amcheck --relation=unlogged_relation, I'd rather get a complaint that I
can't check an unlogged relation on a standby than get nothing. Sure, what I
did doesn't make sense, but why should the application paper over that mistake?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hat say what Vertica does. I found
some Enterprise DB docs about what Advanced Server does (or course, since I
work here.) I don't see much else.
You have quoted me parts of the spec about what REVOKE is supposed to do, and I
have responded about why I don't see the connection to DROP ROLE...CASCADE.
Are there any other references to either the spec or how other common databases
handle this?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
#x27;s circumstances are different from one database to
the next, and likewise for the pattern /*alexander*/ except that in some
databases it matches an index and in others it matches a table.
I thought that we were headed toward a decision where (despite my discomfort)
pg_amcheck would downgrade options as necessary, but now it sounds like that's
not so. So what should it do
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 6, 2021, at 2:45 PM, Mark Dilger wrote:
>
> and db3 is in recovery.
> they're scattered across different databases, some in recovery, some not.
What I mean here is that, since pg_amcheck might run for many hours, and
database may start in recovery but then exit
emporary table named
"xyzacountngo" and that gets skipped because it's a temp table, I don't know
what feedback the user should get. That's a thorny user interfaces question,
not a corruption checking question, and I don't think you need to weigh in
unless you want to. I'll most likely go with whatever is the simplest to code
and/or most similar to what is currently in the tree, because I don't see any
knock-down arguments one way or the other.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
601 - 700 of 980 matches
Mail list logo
