pg.ddx.io pgsql-hackers@postgresql.org mailing list archive
help / color / mirror / Atom feedA weird bit in pg_upgrade/exec.c
6+ messages / 3 participants
[nested] [flat]
* A weird bit in pg_upgrade/exec.c
@ 2017-11-09 15:07 a.akenteva@postgrespro.ru
2017-11-09 16:06 ` Re: A weird bit in pg_upgrade/exec.c Alvaro Herrera <alvherre@alvh.no-ip.org>
2017-11-09 16:17 ` Re: A weird bit in pg_upgrade/exec.c Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 6+ messages in thread
From: a.akenteva@postgrespro.ru @ 2017-11-09 15:07 UTC (permalink / raw)
To: pgsql-hackers
Hello!
I've came across a weird bit in pg_upgrade/exec.c
We have a function check_bin_dir() which goes like this (old_cluster and
new_cluster are global variables):
void check_bin_dir(ClusterInfo *cluster)
{
...
get_bin_version(&old_cluster);
get_bin_version(&new_cluster);
...
}
This function has two calls:
check_bin_dir(&old_cluster);
check_bin_dir(&new_cluster);
I'd like to substitute these last two lines with this:
get_bin_version(cluster);
Doing it would simplify the patch I'm writing, but I'm worried I might
break something that's been there for a long time and has been working
fine. Is there maybe a reason for it to be this way that I don't happen
to understand?
Also, there's the exact same situation with the get_bin_version()
function in the same file.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: A weird bit in pg_upgrade/exec.c
2017-11-09 15:07 A weird bit in pg_upgrade/exec.c a.akenteva@postgrespro.ru
@ 2017-11-09 16:06 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2017-11-09 16:21 ` Re: A weird bit in pg_upgrade/exec.c Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 6+ messages in thread
From: Alvaro Herrera @ 2017-11-09 16:06 UTC (permalink / raw)
To: a.akenteva@postgrespro.ru; +Cc: pgsql-hackers
a.akenteva@postgrespro.ru wrote:
> This function has two calls:
> check_bin_dir(&old_cluster);
> check_bin_dir(&new_cluster);
>
> I'd like to substitute these last two lines with this:
> get_bin_version(cluster);
Odd indeed. One would think that if a cluster variable is passed as
parameter, the global vars should not be used. +1 for fixing it, and
your proposal sounds as good as any.
> Doing it would simplify the patch I'm writing, but I'm worried I might break
> something that's been there for a long time and has been working fine.
I think odd coding this was introduced recently because of the
pg_resetxlog -> pg_resetwal renaming.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: A weird bit in pg_upgrade/exec.c
2017-11-09 15:07 A weird bit in pg_upgrade/exec.c a.akenteva@postgrespro.ru
2017-11-09 16:06 ` Re: A weird bit in pg_upgrade/exec.c Alvaro Herrera <alvherre@alvh.no-ip.org>
@ 2017-11-09 16:21 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2017-11-09 16:21 UTC (permalink / raw)
To: Alvaro Herrera <alvherre@alvh.no-ip.org>; +Cc: a.akenteva@postgrespro.ru; pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> I think odd coding this was introduced recently because of the
> pg_resetxlog -> pg_resetwal renaming.
Dunno about that, but certainly somebody fat-fingered a refactoring
there. The 9.6 code looks quite different but doesn't seem to be
doing anything silly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: A weird bit in pg_upgrade/exec.c
2017-11-09 15:07 A weird bit in pg_upgrade/exec.c a.akenteva@postgrespro.ru
@ 2017-11-09 16:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-11-16 12:05 ` Re: [HACKERS] A weird bit in pg_upgrade/exec.c a.akenteva@postgrespro.ru
1 sibling, 1 reply; 6+ messages in thread
From: Tom Lane @ 2017-11-09 16:17 UTC (permalink / raw)
To: a.akenteva@postgrespro.ru; +Cc: pgsql-hackers
a.akenteva@postgrespro.ru writes:
> I've came across a weird bit in pg_upgrade/exec.c
> We have a function check_bin_dir() which goes like this (old_cluster and
> new_cluster are global variables):
> void check_bin_dir(ClusterInfo *cluster)
> {
> ...
> get_bin_version(&old_cluster);
> get_bin_version(&new_cluster);
> ...
> }
> This function has two calls:
> check_bin_dir(&old_cluster);
> check_bin_dir(&new_cluster);
> I'd like to substitute these last two lines with this:
> get_bin_version(cluster);
Yeah, the way it is now seems outright broken. It will try to do
get_bin_version on the new cluster before having done validate_exec
there, violating its own comment.
I think we should change this as a bug fix, independently of whatever
else you had in mind to do here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [HACKERS] A weird bit in pg_upgrade/exec.c
2017-11-09 15:07 A weird bit in pg_upgrade/exec.c a.akenteva@postgrespro.ru
2017-11-09 16:17 ` Re: A weird bit in pg_upgrade/exec.c Tom Lane <tgl@sss.pgh.pa.us>
@ 2017-11-16 12:05 ` a.akenteva@postgrespro.ru
2017-11-16 16:20 ` Re: [HACKERS] A weird bit in pg_upgrade/exec.c Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 6+ messages in thread
From: a.akenteva@postgrespro.ru @ 2017-11-16 12:05 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: pgsql-hackers; pgsql-hackers-owner@postgresql.org
Tom Lane <tgl@sss.pgh.pa.us> writes:
> Yeah, the way it is now seems outright broken. It will try to do
> get_bin_version on the new cluster before having done validate_exec
> there, violating its own comment.
>
> I think we should change this as a bug fix, independently of whatever
> else you had in mind to do here.
I see this bug is now fixed in pg_upgrade/exec.c => check_bin_dir().
There's another bit exactly like that in check_data_dir() though.
We use global variables instead of using the argument passed to the
function,
which makes the function not reusable. Sorry if I mentioned it too
vaguely
in the previous letter.
I attached a patch with the change that would fix it.
In pg_upgrade/exec.c => check_data_dir() I substituted these two lines
old_cluster.major_version = get_major_server_version(&old_cluster);
new_cluster.major_version = get_major_server_version(&new_cluster);
with this line:
cluster->major_version = get_major_server_version(cluster);
and changed the comment accordingly.
Attachments:
[text/x-diff] Fixed-exec-c.patch (1.0K, ../../ba81b93e77c4bc1778ae6f0def7be883@postgrespro.ru/2-Fixed-exec-c.patch)
download | inline diff:
From 9b63a7fc5d1dce6d254aec0abe412f2c1cd5f889 Mon Sep 17 00:00:00 2001
From: Akenteva Anna <a.akenteva@postgrespro.ru>
Date: Thu, 16 Nov 2017 13:25:29 +0300
Subject: [PATCH] Fixed check_data_dir in pg_upgrade/exec.c
Changed using global variables (old_cluster and new_cluster) into
using the argument of the check_data_dir function.
---
src/bin/pg_upgrade/exec.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/src/bin/pg_upgrade/exec.c b/src/bin/pg_upgrade/exec.c
index 810a5a0..f5cd74f 100644
--- a/src/bin/pg_upgrade/exec.c
+++ b/src/bin/pg_upgrade/exec.c
@@ -331,9 +331,8 @@ check_data_dir(ClusterInfo *cluster)
{
const char *pg_data = cluster->pgdata;
- /* get old and new cluster versions */
- old_cluster.major_version = get_major_server_version(&old_cluster);
- new_cluster.major_version = get_major_server_version(&new_cluster);
+ /* get the cluster version */
+ cluster->major_version = get_major_server_version(cluster);
check_single_dir(pg_data, "");
check_single_dir(pg_data, "base");
--
2.7.4
^ permalink raw reply [nested|flat] 6+ messages in thread
* Re: [HACKERS] A weird bit in pg_upgrade/exec.c
2017-11-09 15:07 A weird bit in pg_upgrade/exec.c a.akenteva@postgrespro.ru
2017-11-09 16:17 ` Re: A weird bit in pg_upgrade/exec.c Tom Lane <tgl@sss.pgh.pa.us>
2017-11-16 12:05 ` Re: [HACKERS] A weird bit in pg_upgrade/exec.c a.akenteva@postgrespro.ru
@ 2017-11-16 16:20 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 6+ messages in thread
From: Tom Lane @ 2017-11-16 16:20 UTC (permalink / raw)
To: a.akenteva@postgrespro.ru; +Cc: pgsql-hackers
a.akenteva@postgrespro.ru writes:
> I see this bug is now fixed in pg_upgrade/exec.c => check_bin_dir().
> There's another bit exactly like that in check_data_dir() though.
Oh, so there is ... and looking around, that seems to have been
copied-and-pasted out of check_cluster_versions(), without any
thought for the fact that those calls were thereby made redundant.
Fix pushed, thanks for noticing!
regards, tom lane
^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2017-11-16 16:20 UTC | newest]
Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2017-11-09 15:07 A weird bit in pg_upgrade/exec.c a.akenteva@postgrespro.ru
2017-11-09 16:06 ` Alvaro Herrera <alvherre@alvh.no-ip.org>
2017-11-09 16:21 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-11-09 16:17 ` Tom Lane <tgl@sss.pgh.pa.us>
2017-11-16 12:05 ` a.akenteva@postgrespro.ru
2017-11-16 16:20 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox