On Wed, Jun 16, 2021 at 9:24 AM Thomas Munro wrote:
> No change yet, just posting a rebase to keep cfbot happy.
>
>
Hi, Thomas
I think that the proposed feature is pretty cool not only because it fixes
some old issues with lseek() performance and reliability, but also because
it opens the door t
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I looked through the patch. Looks good to me.
CFbot tests are passi
Hi, hackers!
Many recently discussed features can make use of an extensible storage
manager API. Namely, storage level compression and encryption [1], [2], [3],
disk quota feature [4], SLRU storage changes [5], and any other features
that may want to substitute PostgreSQL storage layer with their
On Thu, Jun 10, 2021 at 10:52 AM Andres Freund wrote:
>
> I started to write a test for $Subject, which I think we sorely need.
>
> Currently my approach is to:
> - start a cluster, create a few tables with test data
> - acquire SHARE UPDATE EXCLUSIVE in a prepared transaction, to prevent
> aut
вт, 8 июн. 2021 г. в 02:44, Anastasia Lubennikova :
>
> вт, 8 июн. 2021 г. в 02:25, Thomas Munro :
>
>> Ok, here's a new version incorporating feedback so far.
>>
>> 1. Invoke pg_regress directly (no make).
>>
>> 2. Use PG_TEST_EXTRA="wal_consis
вт, 8 июн. 2021 г. в 02:25, Thomas Munro :
> Ok, here's a new version incorporating feedback so far.
>
> 1. Invoke pg_regress directly (no make).
>
> 2. Use PG_TEST_EXTRA="wal_consistency_checking" as a way to opt in to
> the more expensive test.
>
> 3. Use parallel schedule rather than serial.
BTGreaterEqualStrategyNumber:
case BTGreaterStrategyNumber:
See the comment for RowCompareExpr, which states that "A RowCompareExpr
node is only generated for the < <= > >= cases".
2) It's worth to add a regression test for this feature.
Other than that, the patch look
LID
5) Speaking of documentation, I think we need to add a paragraph about
CIC on partitioned indexes which will explain that invalid indexes may
appear and what user should do to fix them.
6) ReindexIndexesConcurrently() needs some code cleanup.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
LID
5) Speaking of documentation, I think we need to add a paragraph about
CIC on partitioned indexes which will explain that invalid indexes may
appear and what user should do to fix them.
6) ReindexIndexesConcurrently() needs some code cleanup.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ext format of
PostrgeSQL README files or we can use md?
[1] https://github.com/AmatanHead/psql-hooks/blob/master/Detailed.md
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I wonder, why this patch hangs on commitfest for so long.
The idea o
On 24.01.2021 11:39, Noah Misch wrote:
On Thu, Jan 21, 2021 at 01:03:58AM +0300, Anastasia Lubennikova wrote:
On 03.01.2021 14:29, Noah Misch wrote:
Overall, this patch predicts a subset of cases where pg_dump will emit a
failing GRANT or REVOKE that targets a pg_catalog object. Can you write
On 03.01.2021 14:29, Noah Misch wrote:
On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
On 08.06.2020 19:31, Alvaro Herrera wrote:
I'm thinking what's a good way to have a test that's committable. Maybe
it would work to add a TAP test to pg_upgrade that ru
strapping or in a recently-started system.
*/
if (targetBlock == InvalidBlockNumber)
{
BlockNumber nblocks = RelationGetNumberOfBlocks(relation);
if (nblocks > 0)
targetBlock = nblocks - 1;
}
I think we can use this code without regard to '
On 12.01.2021 00:51, Tomas Vondra wrote:
On 1/11/21 10:00 PM, Anastasia Lubennikova wrote:
On 11.01.2021 01:35, Tomas Vondra wrote:
Hi,
I started looking at this patch again, hoping to get it committed in
this CF, but I think there's a regression in handling TOAST tables
(compared t
test it properly in a couple of days and share results.
With this change a lot of new code is repeated in heap_insert() and
heap_multi_insert(). I think it's fine, because these functions already
have a lot in common.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgr
On 02.12.2020 23:59, Tom Lane wrote:
Anastasia Lubennikova writes:
Commitfest 2020-11 is officially closed now.
Many thanks to everyone who participated by posting patches, reviewing
them, committing and sharing ideas in discussions!
Thanks for all the hard work!
Today, me and Georgios will
On 30.10.2020 19:33, David G. Johnston wrote:
On Fri, Oct 30, 2020 at 9:16 AM Anastasia Lubennikova
mailto:lubennikov...@gmail.com>> wrote:
Status update for a commitfest entry.
It looks like there was no real progress on this issue since
April. I see only an experimental
pdate for a commitfest entry.
The commitfest is closed now. As this entry has been Waiting on Author
for a while, I've marked it as returned with feedback. Dmitry, feel free
to resubmit an updated version to a future commitfest.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
://www.enterprisedb.com/
Status update for a commitfest entry.
The commitfest is closed now. As this entry is a bug fix, I am moving it
to the next CF.
Are you planning to continue working on it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
entry.
The patch is Waiting on Author for some time. As this is a bug fix, I am
moving it to the next CF.
Ian, are you planning to continue working on it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
" during this CF, so I've marked it as
returned with feedback. Feel free to resubmit an updated version to a
future commitfest.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
is closed now and this entry is "Waiting on author".
As far as I see, part of the fixes is already committed. Is there
anything left to work on or this patch needs review/ ready for committer
now?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
commitfest entry.
As far as I see, all recommendations from reviewers were addressed in
the last version of the patch.
It passes CFbot successfully, so I move it to Ready For Committer.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
nning to leave Ready For Committer
till the end of the week, to make them more visible and let them get the
attention they deserve. And finally in the weekend I'll gather and share
some statistics.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russia
27;s fine to mark it as
Committed where it is now.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:tested, passed
I wonder, why this patch didn't get a review during the CF.
This minor im
Status update for a commitfest entry.
The commitfest is nearing the end and I wonder what is this discussion waiting
for.
It looks like the proposed patch received its fair share of review, so I mark
it as ReadyForCommitter and lay responsibility for the final decision on them.
The new status o
Status update for a commitfest entry.
The commitfest is nearing the end and this thread was inactive for a while. As
far as I see something got committed and now the discussion is stuck in arguing
about parenthesis.
FWIW, I think it is a matter of personal taste. Maybe we can compromise on
simp
entry.
The commitfest is nearing the end and this thread is "Waiting on
Author". As far as I see we don't have a patch here and discussion is a
bit stuck.
So, I am planning to return it with feedback. Any objections?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
please share your concerns about the interaction of the
patch with --binary-upgrade mode? If you don't have time to write tests,
you can just describe problems.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
varo, are you planning to
continue working on it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 09.11.2020 13:53, Anastasia Lubennikova wrote:
On 21.08.2020 09:02, Andrey V. Lepikhov wrote:
On 7/1/20 2:10 PM, Daniel Gustafsson wrote:
On 27 Dec 2019, at 08:34, Kohei KaiGai wrote:
The attached v2 fixed the problem, and regression test finished
correctly.
This patch no longer
e proposed idea is
great and it looks like the patch needs only a minor improvement.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
obably for the next CF. Can you park it
there?
Sure, I'll move it to the next CF then.
I also noticed, that the first message mentions the idea of refactoring
to use some code it in both pgbench and psql code. Can you, please,
share a link to the thread, if it exists?
--
Anastasia Luben
On 02.11.2020 18:02, Anastasia Lubennikova wrote:
Status update for a commitfest entry.
This thread was inactive for a while. Is anyone going to continue working on it?
My two cents on the topic:
I don’t see it as a big problem in the first place. In the source code, \dE
refers to foreign
work before review, so I changed it to "Withdrawn".
Feel free to resubmit an updated version to a future commitfest.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
, which
seems unlikely.).
regards.
Status update for a commitfest entry.
This entry was "Waiting on author" during this CF. As I see, the latest
message contains new version of the patch.
Does it need more work? Are you going to continue working on it?
--
Anastasia Lubennikova
Post
r
This patch was inactive during the commitfest, so I am going to mark it
as "Returned with Feedback".
Fabien, are you planning to continue working on it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
atch still applies and passes all cfbot checks. I also took a quick
look at the code and everything looks good to me.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
n of the patch. Does it need more work? Are
you going to continue working on it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 02.11.2020 22:08, John Naylor wrote:
On Mon, Nov 2, 2020 at 1:30 PM Alvaro Herrera <mailto:alvhe...@alvh.no-ip.org>> wrote:
On 2020-Nov-02, Anastasia Lubennikova wrote:
> Status update for a commitfest entry.
>
> This entry was inactive for a very lon
.
This entry is "Waiting on author" and the thread was inactive for a
while. As far as I see, part of the fixes is already committed. Is
there anything left to work on or this patch set needs review now?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
am not sure
it will be stable given that the RemovePgTempFiles() allows the
possibility of failure.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
commit 417581b287f4060178595cd96465adc639639290
Author: anastasia
Date: Thu Nov 26 11:45:05 2020 +030
t know where we
should document it. At the very least we can improve comments. For
example, describe the fact that custom signals are handled after
receiving SIGUSR1.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
me as other contrib modules do.
Agree. It will need a bit more work, though. Probably a new version of
pageinspect contrib, as the public API will change.
Ashutosh, are you going to continue working on it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Ru
_TABLESPACE <https://commitfest.postgresql.org/30/2269/>
range_agg / multiranges <https://commitfest.postgresql.org/30/2112/>
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
back" until a better time?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
this entry is "Waiting on Author" and the thread was inactive for a
while. I see this discussion still has some open questions. Are you
going to continue working on it, or should I mark it as "returned with
feedback" until a better time?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
se */
}
}
which will be called like
swap_lsn(XLogCtl->LogwrtRqst.Write, EndPos, true);
Greetings,
Andres Freund
This CF entry was inactive for a while. Alvaro, are you going to
continue working on it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
rg/message-id/flat/9df8a3d3-13d2-116d-26ab-6a273c1ed38c%402ndquadrant.com
Since there has been no activity on this thread since before the CF and
no response from the author I have marked this "returned with feedback".
Alexandra, feel free to resubmit it to the next commitfest
If there aren't any objections or further comments, I'll take another
look through it and will commit it during the upcoming CF.
Thanks!
Stephen
CFM reminder. Just in case you forgot about this thread)
The commitfest is heading to the end. And there was a plenty of time for
anyone
quot;Waiting on author".
Euler, are you going to continue working on it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 23.11.2020 18:35, Stephen Frost wrote:
Greetings,
* Anastasia Lubennikova (a.lubennik...@postgrespro.ru) wrote:
On 21.11.2020 04:30, Michael Paquier wrote:
The only method I can think as being really
reliable is based on two facts:
- Do a check only on pd_checksums, as that validates the
ut
create domain and create type I'll just stick to the implementation in
front of me.
David J.
Reminder from a CF manager, as this thread was inactive for a while.
Alexander, I see you signed up as a committer for this entry. Are you
going to continue this work?
--
Anastasia Lubennikova
Postgres
s. It looks like a
bullet-proof solution to me. Do you see any possible problems with it?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
quot;. Feel free to create a new
entry, if you're going to continue working on the remaining issue.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
considered stalled and returned with feedback.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
would be good to add a test to select_into.sql to show that it
only applies to 'WITH NO DATA' and that subsequent insertions will fail
if permissions are not set.
Maybe we should also mention it a documentation, but I haven't found any
specific paragraph about permission
he issue.
Do we only care about .sh scripts? There are also reindex_hash.sql and
pg_largeobject.sqlin src/bin/pg_upgrade/version.c with instructions.
How should we handle them?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Assert(nappinfos >= 1 && appinfos != NULL);
+ /* If there's nothing to adjust, just return a duplication */
+ if (nappinfos == 0)
+ return copyObject(node);
5. extract_asymmetric_partitionwise_subjoin() lacks a comment
The new status of this patch is: Waiting on Au
Status update for a commitfest entry.
This thread was inactive for a while and from the latest messages, I see that
the patch needs some further work.
So I move it to "Waiting on Author".
The new status of this patch is: Waiting on Author
Status update for a commitfest entry.
According to CFbot this patch fails to apply. Richard, can you send an update,
please?
Also, I see that the thread was inactive for a while.
Are you going to continue this work? I think it would be helpful, if you could
write a short recap about current sta
Status update for a commitfest entry
According to cfbot, the patch fails to apply. Could you please send a rebased
version?
I wonder why this patch hangs so long without a review. Maybe it will help to
move discussion forward, if you provide more examples of queries that can
benefit from this
Status update for a commitfest entry.
According to cfbot the patch no longer compiles.
Tomas, can you send an update, please?
I also see that a few last messages mention a data corruption bug. Sounds
pretty serious.
Alvaro, have you had a chance to look at it? I don't see anything committed
yet
Status update for a commitfest entry.
This thread was inactive for a while. The latest review suggests that it is
Ready For Committer.
I also took a quick look at the patch and agree that it looks sensible. Maybe
add a comment before the _bt_compare_inl() to explain the need for this code
chang
Status update for a commitfest entry.
This entry was inactive for a very long time.
John, are you going to continue working on this?
The last message mentions some open issues, namely backend crashes, so I move
it to "Waiting on author".
The new status of this patch is: Waiting on Author
Status update for a commitfest entry.
This patch implements useful improvement and the reviewer approved the code. It
lacks a test, but looking at previously committed hooks, I think it is not
mandatory.
So, I move it to RFC.
The new status of this patch is: Ready for Committer
Status update for a commitfest entry.
This thread was inactive for a while. Is anyone going to continue working on it?
My two cents on the topic:
I don’t see it as a big problem in the first place. In the source code, \dE
refers to foreign tables and \de refers to forign servers. So, it seems mo
OPY FREEZE and for matview operations. Can
you explain, what use-case are we trying to optimize by extending this
patch to heap_insert()?
The new version is attached.
I've also fixed a typo in the comment by Tatsuo Ishii suggestion.
Also, I tested this patch with replication and found no iss
patch review.
Also, check the state of your patch at http://cfbot.cputube.org/
Happy hacking!
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Status update for a commitfest entry.
I see quite a few unanswered questions in the thread since the last patch
version was sent. So, I move it to "Waiting on Author".
The new status of this patch is: Waiting on Author
Status update for a commitfest entry.
It looks like there was no real progress on this issue since April. I see only
an experimental patch. What kind of review does it need right now? Do we need
more testing or maybe production statistics for such queries?
David, are you going to continue worki
ср, 28 окт. 2020 г. в 08:02, Yugo NAGATA :
> Hi Anastasia Lubennikova,
>
> I am writing this to you because I would like to ask the commitfest
> manager something.
>
> The status of the patch was changed to "Waiting on Author" from
> "Ready for Committer&q
opinion on the remaining patch, it still looks
good to me.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
update for a commitfest entry.
According to cfbot patch no longer applies. So I moved it to waiting on
author.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Status update for a commitfest entry.
This patch is ReadyForCommitter. It applies and passes the CI. There are no
unanswered questions in the discussion.
The discussion started in 2015 with a patch by Jeff Janes. Later it was revived
by Pavan Deolasee. After it was picked up by Ibrar Ahmed an
ion to the thread.
[1]
https://www.postgresql.org/message-id/AxH0n_zLwwJ0MBN3uJpHfYDkV364diOGhtpLAv0OC0qHLN8ClyPsbRi1fSUAJLJZzObZE_y1qc-jqGravjIMoxVrdtLm74HmTUeIPWWkmSg%3D%40pm.me
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ches, so I will appreciate if you join me in
this task.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 22.10.2020 04:25, Michael Paquier wrote:
On Thu, Oct 22, 2020 at 12:47:03AM +0300, Anastasia Lubennikova wrote:
We can also read such pages via shared buffers to be 100% sure.
Yeah, but this has its limits as well. One can use
ignore_checksum_failure, but this can actually be very
etch [1].
[1]
https://www.postgresql.org/message-id/flat/601ee1f5-0b78-47e1-9aae-c15f74a1c...@postgrespro.ru
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 20.10.2020 09:24, Michael Paquier wrote:
On Fri, Oct 16, 2020 at 06:02:52PM +0300, Anastasia Lubennikova wrote:
In the current patch, PageIsVerifed called from pgbasebackup simply doesn't
Should we change this too? I don't see any difference.
I considered that, but now that doe
ed Loop (actual rows=N loops=N)
+ -> Nested Loop (actual min_rows=0 rows=0 max_rows=0 loops=2)
Pavel, Julien, could you please say if it looks good?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 16.10.2020 21:57, Tom Lane wrote:
Anastasia Lubennikova writes:
On the other hand, I noticed a lot of stall threads, that weren't
updated in months. Some of them seem to pass several CFs without any
activity at all. I believe that it is wrong for many reasons, the major
of which IMHO
CF management. I suppose, that
they are usually being discussed at pgcon meetings, but those won't
happen anytime soon. Is there a special place for such discussions, or I
may continue this thread?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
last two ones, I would use an extensible argument based on
bits32 with a set of flags that the caller can set at will.
Done.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
commit 553d62dbcdec1a00139f3c5ab6a325ed857b6c9d
Author: anastasi
ning queries, that now prevent vacuumfrom removing
recently-dead rows. How will we handle same situation with this
optimized deletion?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 28.09.2020 17:41, Andrey M. Borodin wrote:
Hi, Anastasia!
28 авг. 2020 г., в 23:08, Anastasia Lubennikova
написал(а):
1) The first patch is sensible and harmless, so I think it is ready for
committer. I haven't tested the performance impact, though.
2) I like the initial propos
n't provide a complete solution, because partition
number can contain several digits.
See also pg_partman documentation on the same issue:
https://github.com/pgpartman/pg_partman/blob/master/doc/pg_partman.md#naming-length-limits
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
| Storage | Stats
target | Description
+-+---+--+-+-+--+-
a | integer | | | | plain
| |
Partition key: LIST (a)
Partitions: list_parted_fail_0 FOR VALUES IN (1)
Do you think that it is a bug? For now, I removed this statement from
tests just to calm down the
t. I will fix these typos in next version of the patch.
Thank you,
Rahila Syed
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 24.09.2020 06:27, Michael Paquier wrote:
On Mon, Sep 14, 2020 at 02:38:56PM +0300, Anastasia Lubennikova wrote:
Fixed. This was also caught by cfbot. This version should pass it clean.
Please note that regression tests are failing, because of 6b2c4e59.
--
Michael
Thank you. Updated patch
On 22.09.2020 17:30, Michael Banck wrote:
Hi,
Am Dienstag, den 22.09.2020, 16:26 +0200 schrieb Michael Banck:
Am Mittwoch, den 02.09.2020, 16:50 +0300 schrieb Anastasia Lubennikova:
I've looked through the previous discussion. As far as I got it, most of
the controversy was about o
definitely needs more testing. I haven't thoroughly tested
following cases yet:
- how triggers and constraints are propagated to partitions;
- how does it handle some tricky clauses in list partitioning expr_list;
and so on.
Also, there is an open question about partition naming. Currently,
lf looks clear and committable.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
reindex_partitions() and new comments
added, I think this patch is ready for commit.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
oesn't get lost.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
se, it would be
good to document this behavior explicitly.
I need a bit more time to review this patch more thoroughly. Please,
wait for it, before committing.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
roof. Using it we can also check pages with lsn >=
startptr.
3) Judging by warning messages, we count checksum failures per file, not
per page, and don't report after a fifth failure. Why so? Is it a
common case that so many pages of one file are corrupted?
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
understand the logic around index list
check at first pass.
Does the version attached look fine to you? I have done one round of
indentation while on it.
Yes, this version is good.
--
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
1 - 100 of 180 matches
Mail list logo
