Thanks for your review!
2023年9月27日(水) 8:33 Michael Paquier :
> On Tue, Sep 26, 2023 at 06:44:50PM +0300, Aleksander Alekseev wrote:
> >> And also, I'm afraid that I'm not sure what kind of tests I have to make
> >> for fix this behavior. Would you mind giving me some advice?
> >
> > Personally I
>
> Committed, with some minor wordsmithing. Thanks!
>
Thanks for tweaking and pushing, Daniel-san!
Masaki Kuwamura
>
> I've applied this down to v16 now, thanks for the submission!
>
Thanks for pushing!
Masaki Kuwamura
Hi,
Recently I read the document about ereport()[1].
Then, I felt that there is little information about severity level.
So I guess it can be kind to clarify where severity level is defined(see
attached patch please).
Any thoughts?
[1] https://www.postgresql.org/docs/devel/error-message-reporti
LGTM too!
>> a bit to make the diff smaller,
I couldn't think from that perspective. Thanks for your update, Daniel-san.
Masaki Kuwamura
>
> No worries at all. If you look at the page now you will see all green
> checkmarks indicating that the patch was tested in CI. So now we know that
> your tests fail without the fix and work with the fix applied, so all is
> well.
>
Thank you for your kind words!
And it seems to me that all
>
> I agree. Supporting pattern matching should, if anyone is interested in
> trying, be done separately in its own thread, no need to move the goalposts
> here. Sorry if I made it sound like so upthread.
>
I got it.
> When sending an update, please include the previous patch as well with
> you
Thank you for all your reviews!
>>> PATTERN should be changed to SCHEMA because -n and -N options don't
support
>>> pattern matching for schema names. The attached patch 0001 fixes this.
>>
>> True, there is no pattern matching performed. I wonder if it's worth
lifting
>> the pattern matching fro
>> IMO a test is needed that makes sure no one is going to break this in
>> the future.
>
> You definitely need more complex test scenarios for that. If you can
> come up with new ways to make the TAP tests of pg_rewind mode modular
> in handling more complicated node setups, that would be a nice
Hi there,
I have 1 trivial fix, 1 bug fix, and 1 suggestion about vacuumdb.
First, I noticed that the help message of `vacuumdb` is a bit incorrect.
`vacuumdb -?` displays the following message
```
...
-n, --schema=PATTERNvacuum tables in the specified schema(s)
only
-N, --exclud
> Consider a scenario like this,
>
> Server A: primary
> Server B :replica of A
> Server C :replica of B
>
> and somehow A down ,so B gets promoted.
> Server A: down
> Server B :new primary
> Server C :replica of B
>
> In this case, pg_rewind can be used to reconstruct the cascade; the
source is C
Hi there,
I tested pg_rewind behavior and found a suspicious one.
Consider a scenario like this,
Server A: primary
Server B :replica of A
Server C :replica of B
and somehow A down ,so B gets promoted.
Server A: down
Server B :new primary
Server C :replica of B
In this case, pg_rewind can be u
Hi, Fujii-san
> Regarding the WARNING message, another idea is to pass the return value
> of PQgetCancel() directly to PQcancel() as follows. If NULL is passed,
> PQcancel() will detect it and set the proper error message to errbuf.
> Then the warning message "WARNING: could not send cancel reque
13 matches
Mail list logo
