Tested this patch by running several upgrades from different major
versions and different setups.
ACL, that are impossible to apply, are detected and reported, so it
looks good for me.
patch are attached.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index 7c11e1ab44..63a3d0c1e6 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src
avoided the point-2 pitfall, but didn't
do anything about point 1.
BTW, another thing that needs to be considered is the interaction with
rotation_disabled. Right now we automatically drop that on SIGHUP, but
I'm unclear on whether it should be different for logrotate requests.
.ru
Poor guy repeatedly run VACUUM after VACUUM and had no clue what to do.
He even considered to just restore from backup and be done with it. It
took some time to figure out a true culprit, and time = money.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ork with
respect to user`s understanding of his data and application.
Also It`s would be great to sort tables according to dead/live tuple
ratio and relfrozenxid.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ery_target parameter.
Old recovery behavior is still available if no recovery target is
provided. I`m not sure, whether it should it be left as it is now, or not.
Another open question is what to do with recovery_target_inclusive if
recovery_target = "latest" is used.
--
Grig
Thank you for you interest in this topic!
On 11/5/19 10:41 AM, Kyotaro Horiguchi wrote:
Hello.
At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin
wrote in
Hello, hackers!
I`d like to propose a new argument for recovery_target parameter,
which will stand to recovering until all available
Attached new version of a patch with TAP test.
On 11/5/19 11:51 AM, Grigory Smolkin wrote:
Thank you for you interest in this topic!
On 11/5/19 10:41 AM, Kyotaro Horiguchi wrote:
Hello.
At Mon, 4 Nov 2019 16:03:38 +0300, Grigory Smolkin
wrote in
Hello, hackers!
I`d like to propose a new
st, which is, of
course, subjective.
But if we want an argument name to be technically accurate, then, I
think, something like "end-of-available-WAL"/"all-WAL", "end-of-WAL" is
a way to go.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 11/6/19 12:56 PM, Fujii Masao wrote:
On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin wrote:
On 11/6/19 10:39 AM, Peter Eisentraut wrote:
This seems to also be related to this discussion:
<https://www.postgresql.org/message-id/flat/993736dd3f1713ec1f63fc3b65383...@lako.no>
Yes, in
On 11/6/19 1:55 PM, Grigory Smolkin wrote:
On 11/6/19 12:56 PM, Fujii Masao wrote:
On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin
wrote:
On 11/6/19 10:39 AM, Peter Eisentraut wrote:
This seems to also be related to this discussion:
<https://www.postgresql.org/message-id/f
On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin
wrote in
On 11/6/19 1:55 PM, Grigory Smolkin wrote:
On 11/6/19 12:56 PM, Fujii Masao wrote:
On Wed, Nov 6, 2019 at 6:33 PM Grigory Smolkin
wrote:
On 11/6/19 10:39 AM, Peter Eisentraut wrote
On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin
wrote in
On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin
wrote in
On 11/6/19 1:55 PM, Grigory Smolkin wrote:
On 11/6/19 12:56 PM, Fujii Masao
On 11/7/19 4:36 PM, Grigory Smolkin wrote:
On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin
wrote in
On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin
wrote in
On 11/6/19 1:55 PM, Grigory
On 11/8/19 7:00 AM, Grigory Smolkin wrote:
On 11/7/19 4:36 PM, Grigory Smolkin wrote:
On 11/7/19 12:56 PM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 12:22:28 +0300, Grigory Smolkin
wrote in
On 11/7/19 8:36 AM, Kyotaro Horiguchi wrote:
At Thu, 7 Nov 2019 02:28:39 +0300, Grigory Smolkin
nstallation contains non-default
privileges for system procedures for which the API has changed." must
contain versions:
"Your PostgreSQL 9.5 installation contains non-default privileges for
system procedures for which the API has changed in PostgreSQL 12."
--
Grigory Smolkin
y.
I think it should generate 'catalog_procedures.sql' script as in
previous version with all REVOKE statements, that are required to
execute for pg_upgrade to work.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On 11/21/19 1:46 PM, Peter Eisentraut wrote:
On 2019-11-08 05:00, Grigory Smolkin wrote:
Attached new patch revision, now end of available WAL is defined as the
fact of missing required WAL.
In case of standby, the end of WAL is defined as 2 consecutive switches
of WAL source, that didn`t
ch, I noticed a bit of dead code
and some discordant comments in postmaster.c.
I see no reason to leave it as is.
So there is a small remove_dead_shmem_reinit_code_v0.patch.
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
--
Grigory S
ld have to find the syslogger
and deliver the signal directly, rather than through the postmaster
but it would be pretty easy for them.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
f macro ‘Assert’
Assert(MultiXactIdIsValid(minmutli));
^~
autovacuum.c:1980:9: note: in expansion of macro ‘MultiXactIdIsValid’
Assert(MultiXactIdIsValid(minmutli));
^~
: recipe for target 'autovacuum.o' failed
make[3]: *** [autovacuum.o] Error 1
--
Grigory
2018-03-04 17:10:59.017058+01 | 2018-03-04 17:10:59.022071+01
(1 row)
test=# select pg_shmem_init_time() = pg_postmaster_start_time();
?column?
--
f
(1 row)
So there would have to be some sort of "fuzz" parameter when comparing
the value
ed
on the next timeline.
Is there a reason behind this behavior?
Also I`ve attached a patch, which fixed this issue for me, but I`m not
sure, that chosen approach is sound and didn`t break something.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Com
On 4/6/20 9:17 PM, David Steele wrote:
Hi Grigory,
Hello!
On 4/5/20 8:02 PM, Grigory Smolkin wrote:
Hello, hackers!
I`m investigating a complains from our clients about archive recovery
speed been very slow, and I`ve noticed a really strange and, I think,
a very dangerous recovery
On 4/6/20 10:51 PM, David Steele wrote:
On 4/6/20 3:23 PM, Grigory Smolkin wrote:
On 4/6/20 9:17 PM, David Steele wrote:
Hi Grigory,
Hello!
On 4/5/20 8:02 PM, Grigory Smolkin wrote:
Hello, hackers!
I`m investigating a complains from our clients about archive
recovery speed been very
+
NUM_INDIVIDUAL_LWLOCKS + NAMED_LWLOCK_RESERVE.
Because I was involved in this particular case and don`t want it to
became a habit, I`m volunteering to test whatever patch this discussion
will produce.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres
ached patch solves the issue. I think when reqLen
== state->readLen the requested block already is in the xlogreader's
buffer.
What do you think?
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
if (d->handle == INVALID_HANDLE_VALUE)
{
errno = ENOENT;
return NULL;
}
}
Attached please find small patch fixing the problem.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
nt in catalog.
And vacuum probably should ignore them during datfrozenxid calculation.
In single mode at least. Or just drop them in single mode.
And it would be good to have advice 'drop temp schemas' in HINT message.
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
e is an improvement or not. But if we apply
the patch I proposed, maybe we should mention also history file here.
For example, "but will not archive any WAL or timeline history files
that it did not generate itself".
make sense for me
So I included this change in the patch. Patch attached.
Regards,
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
res Professional:http://www.postgrespro.com
The Russian Postgres Company
--
Grigory Smolkin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
31 matches
Mail list logo
