public inbox for [email protected]
help / color / mirror / Atom feedSmall fixes about backup history file in doc and pg_standby
10+ messages / 6 participants
[nested] [flat]
* Small fixes about backup history file in doc and pg_standby
@ 2018-06-26 08:47 Yugo Nagata <[email protected]>
2018-06-26 11:19 ` Re: Small fixes about backup history file in doc and pg_standby Kyotaro HORIGUCHI <[email protected]>
2018-06-26 15:58 ` Re: Small fixes about backup history file in doc and pg_standby Fujii Masao <[email protected]>
0 siblings, 2 replies; 10+ messages in thread
From: Yugo Nagata @ 2018-06-26 08:47 UTC (permalink / raw)
To: pgsql-hackers
Hi,
While looking into the backup and recovery code, I found small documentation bugs.
The documatation says that the backup history files can be requested for recovery,
but it's not used by the system and not requested anymore since PG 9.0
(commit 06f82b29616cd9effcaefd99c6b6e2e80697482f) and never be requested.
Attached patch (doc_backup_history_file.patch) corrects the description about this.
In addition, the current pg_standby still can handle a backup history file that are
never requested. It is harmless but unnecessary code. Another attached patch
(pg_standby.patch) removes this part of code.
Regards,
--
Yugo Nagata <[email protected]>
Attachments:
[text/x-diff] pg_standby.patch (632B, ../../[email protected]/2-pg_standby.patch)
download | inline diff:
diff --git a/contrib/pg_standby/pg_standby.c b/contrib/pg_standby/pg_standby.c
index cb78597..d957f44 100644
--- a/contrib/pg_standby/pg_standby.c
+++ b/contrib/pg_standby/pg_standby.c
@@ -211,15 +211,9 @@ CustomizableNextWALFileReady(void)
}
/*
- * If it's a backup file, return immediately. If it's a regular file
* return only if it's the right size already.
*/
- if (IsBackupHistoryFileName(nextWALFileName))
- {
- nextWALFileType = XLOG_BACKUP_LABEL;
- return true;
- }
- else if (WalSegSz > 0 && stat_buf.st_size == WalSegSz)
+ if (WalSegSz > 0 && stat_buf.st_size == WalSegSz)
{
#ifdef WIN32
[text/x-diff] doc_backup_hisotry_file.patch (1.5K, ../../[email protected]/3-doc_backup_hisotry_file.patch)
download | inline diff:
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 982776c..3fa5efd 100644
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -1288,7 +1288,7 @@ restore_command = 'cp /mnt/server/archivedir/%f %p'
<para>
Not all of the requested files will be WAL segment
files; you should also expect requests for files with a suffix of
- <literal>.backup</literal> or <literal>.history</literal>. Also be aware that
+ <literal>.history</literal>. Also be aware that
the base name of the <literal>%p</literal> path will be different from
<literal>%f</literal>; do not expect them to be interchangeable.
</para>
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 46bf198..934eb90 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1524,7 +1524,7 @@ synchronous_standby_names = 'ANY 2 (s1, s2, s3)'
processing would request a file from the WAL archive, reporting failure
if the file was unavailable. For standby processing it is normal for
the next WAL file to be unavailable, so the standby must wait for
- it to appear. For files ending in <literal>.backup</literal> or
+ it to appear. For files ending in
<literal>.history</literal> there is no need to wait, and a non-zero return
code must be returned. A waiting <varname>restore_command</varname> can be
written as a custom script that loops after polling for the existence of
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Small fixes about backup history file in doc and pg_standby
2018-06-26 08:47 Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
@ 2018-06-26 11:19 ` Kyotaro HORIGUCHI <[email protected]>
2018-06-27 08:52 ` Re: Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Kyotaro HORIGUCHI @ 2018-06-26 11:19 UTC (permalink / raw)
To: [email protected]; +Cc: pgsql-hackers
Hello.
Good catch!
At Tue, 26 Jun 2018 17:47:52 +0900, Yugo Nagata <[email protected]> wrote in <[email protected]>
> Hi,
>
> While looking into the backup and recovery code, I found small documentation bugs.
> The documatation says that the backup history files can be requested for recovery,
> but it's not used by the system and not requested anymore since PG 9.0
> (commit 06f82b29616cd9effcaefd99c6b6e2e80697482f) and never be requested.
>
> Attached patch (doc_backup_history_file.patch) corrects the description about this.
>
> In addition, the current pg_standby still can handle a backup history file that are
> never requested. It is harmless but unnecessary code. Another attached patch
> (pg_standby.patch) removes this part of code.
The comment fix seems fine and they seem to be all occurances of
the word ".backup" in the context of recovery_command.
The definition of the symbol XLOG_BACKUP_LABEL is no longer
useful after your patch applied. Removing the symbol makes
XLOG_DATA and the variable nextWALFileName useless and finally we
can remove all branching using it.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Small fixes about backup history file in doc and pg_standby
2018-06-26 08:47 Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
2018-06-26 11:19 ` Re: Small fixes about backup history file in doc and pg_standby Kyotaro HORIGUCHI <[email protected]>
@ 2018-06-27 08:52 ` Yugo Nagata <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Yugo Nagata @ 2018-06-27 08:52 UTC (permalink / raw)
To: Kyotaro HORIGUCHI <[email protected]>; +Cc: pgsql-hackers
On Tue, 26 Jun 2018 20:19:42 +0900 (Tokyo Standard Time)
Kyotaro HORIGUCHI <[email protected]> wrote:
> Hello.
>
> Good catch!
>
> At Tue, 26 Jun 2018 17:47:52 +0900, Yugo Nagata <[email protected]> wrote in <[email protected]>
> > Hi,
> >
> > While looking into the backup and recovery code, I found small documentation bugs.
> > The documatation says that the backup history files can be requested for recovery,
> > but it's not used by the system and not requested anymore since PG 9.0
> > (commit 06f82b29616cd9effcaefd99c6b6e2e80697482f) and never be requested.
> >
> > Attached patch (doc_backup_history_file.patch) corrects the description about this.
> >
> > In addition, the current pg_standby still can handle a backup history file that are
> > never requested. It is harmless but unnecessary code. Another attached patch
> > (pg_standby.patch) removes this part of code.
>
> The comment fix seems fine and they seem to be all occurances of
> the word ".backup" in the context of recovery_command.
>
> The definition of the symbol XLOG_BACKUP_LABEL is no longer
> useful after your patch applied. Removing the symbol makes
> XLOG_DATA and the variable nextWALFileName useless and finally we
> can remove all branching using it.
Thank you for your reviewing my patch.
I've also removed XLOG_BACKUP_LABEL, but I left nextWALFileName
since this is still referred in CustomizableCleanupPriorWALFiles().
Attached is the updated patch.
Regards,
>
> regards.
>
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center
>
>
--
Yugo Nagata <[email protected]>
Attachments:
[text/x-diff] pg_standby_v2.patch (832B, ../../[email protected]/2-pg_standby_v2.patch)
download | inline diff:
diff --git a/contrib/pg_standby/pg_standby.c b/contrib/pg_standby/pg_standby.c
index cb78597..b37cf6d 100644
--- a/contrib/pg_standby/pg_standby.c
+++ b/contrib/pg_standby/pg_standby.c
@@ -94,7 +94,6 @@ int restoreCommandType;
#define XLOG_DATA 0
#define XLOG_HISTORY 1
-#define XLOG_BACKUP_LABEL 2
int nextWALFileType;
#define SET_RESTORE_COMMAND(cmd, arg1, arg2) \
@@ -211,15 +210,9 @@ CustomizableNextWALFileReady(void)
}
/*
- * If it's a backup file, return immediately. If it's a regular file
* return only if it's the right size already.
*/
- if (IsBackupHistoryFileName(nextWALFileName))
- {
- nextWALFileType = XLOG_BACKUP_LABEL;
- return true;
- }
- else if (WalSegSz > 0 && stat_buf.st_size == WalSegSz)
+ if (WalSegSz > 0 && stat_buf.st_size == WalSegSz)
{
#ifdef WIN32
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Small fixes about backup history file in doc and pg_standby
2018-06-26 08:47 Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
@ 2018-06-26 15:58 ` Fujii Masao <[email protected]>
2018-06-27 08:42 ` Re: Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
1 sibling, 1 reply; 10+ messages in thread
From: Fujii Masao @ 2018-06-26 15:58 UTC (permalink / raw)
To: Yugo Nagata <[email protected]>; +Cc: pgsql-hackers
On Tue, Jun 26, 2018 at 5:47 PM, Yugo Nagata <[email protected]> wrote:
> Hi,
>
> While looking into the backup and recovery code, I found small documentation bugs.
> The documatation says that the backup history files can be requested for recovery,
> but it's not used by the system and not requested anymore since PG 9.0
> (commit 06f82b29616cd9effcaefd99c6b6e2e80697482f) and never be requested.
>
> Attached patch (doc_backup_history_file.patch) corrects the description about this.
Pushed. Thanks!
> In addition, the current pg_standby still can handle a backup history file that are
> never requested. It is harmless but unnecessary code. Another attached patch
> (pg_standby.patch) removes this part of code.
Since this is not bug fix, let's discuss this in 12dev cycle.
Regards,
--
Fujii Masao
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Small fixes about backup history file in doc and pg_standby
2018-06-26 08:47 Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
2018-06-26 15:58 ` Re: Small fixes about backup history file in doc and pg_standby Fujii Masao <[email protected]>
@ 2018-06-27 08:42 ` Yugo Nagata <[email protected]>
2018-06-27 09:36 ` Re: Small fixes about backup history file in doc and pg_standby Michael Paquier <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Yugo Nagata @ 2018-06-27 08:42 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: pgsql-hackers
On Wed, 27 Jun 2018 00:58:18 +0900
Fujii Masao <[email protected]> wrote:
> On Tue, Jun 26, 2018 at 5:47 PM, Yugo Nagata <[email protected]> wrote:
> > Hi,
> >
> > While looking into the backup and recovery code, I found small documentation bugs.
> > The documatation says that the backup history files can be requested for recovery,
> > but it's not used by the system and not requested anymore since PG 9.0
> > (commit 06f82b29616cd9effcaefd99c6b6e2e80697482f) and never be requested.
> >
> > Attached patch (doc_backup_history_file.patch) corrects the description about this.
>
> Pushed. Thanks!
Thanks!
>
> > In addition, the current pg_standby still can handle a backup history file that are
> > never requested. It is harmless but unnecessary code. Another attached patch
> > (pg_standby.patch) removes this part of code.
>
> Since this is not bug fix, let's discuss this in 12dev cycle.
Certainly.
Regards,
>
> Regards,
>
> --
> Fujii Masao
>
--
Yugo Nagata <[email protected]>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Small fixes about backup history file in doc and pg_standby
2018-06-26 08:47 Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
2018-06-26 15:58 ` Re: Small fixes about backup history file in doc and pg_standby Fujii Masao <[email protected]>
2018-06-27 08:42 ` Re: Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
@ 2018-06-27 09:36 ` Michael Paquier <[email protected]>
2018-06-27 16:22 ` Re: Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Michael Paquier @ 2018-06-27 09:36 UTC (permalink / raw)
To: Yugo Nagata <[email protected]>; +Cc: Fujii Masao <[email protected]>; pgsql-hackers
On Wed, Jun 27, 2018 at 05:42:07PM +0900, Yugo Nagata wrote:
> On Wed, 27 Jun 2018 00:58:18 +0900
> Fujii Masao <[email protected]> wrote:
>>> In addition, the current pg_standby still can handle a backup history file that are
>>> never requested. It is harmless but unnecessary code. Another attached patch
>>> (pg_standby.patch) removes this part of code.
>>
>> Since this is not bug fix, let's discuss this in 12dev cycle.
+1.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Small fixes about backup history file in doc and pg_standby
2018-06-26 08:47 Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
2018-06-26 15:58 ` Re: Small fixes about backup history file in doc and pg_standby Fujii Masao <[email protected]>
2018-06-27 08:42 ` Re: Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
2018-06-27 09:36 ` Re: Small fixes about backup history file in doc and pg_standby Michael Paquier <[email protected]>
@ 2018-06-27 16:22 ` Yugo Nagata <[email protected]>
2018-07-01 13:12 ` Re: Small fixes about backup history file in doc and pg_standby Peter Eisentraut <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Yugo Nagata @ 2018-06-27 16:22 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Fujii Masao <[email protected]>; pgsql-hackers
On Wed, 27 Jun 2018 18:36:46 +0900
Michael Paquier <[email protected]> wrote:
> On Wed, Jun 27, 2018 at 05:42:07PM +0900, Yugo Nagata wrote:
> > On Wed, 27 Jun 2018 00:58:18 +0900
> > Fujii Masao <[email protected]> wrote:
> >>> In addition, the current pg_standby still can handle a backup history file that are
> >>> never requested. It is harmless but unnecessary code. Another attached patch
> >>> (pg_standby.patch) removes this part of code.
> >>
> >> Since this is not bug fix, let's discuss this in 12dev cycle.
>
> +1.
I added this to CF.
> --
> Michael
--
Yugo Nagata <[email protected]>
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: Small fixes about backup history file in doc and pg_standby
2018-06-26 08:47 Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
2018-06-26 15:58 ` Re: Small fixes about backup history file in doc and pg_standby Fujii Masao <[email protected]>
2018-06-27 08:42 ` Re: Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
2018-06-27 09:36 ` Re: Small fixes about backup history file in doc and pg_standby Michael Paquier <[email protected]>
2018-06-27 16:22 ` Re: Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
@ 2018-07-01 13:12 ` Peter Eisentraut <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Peter Eisentraut @ 2018-07-01 13:12 UTC (permalink / raw)
To: Yugo Nagata <[email protected]>; Michael Paquier <[email protected]>; +Cc: Fujii Masao <[email protected]>; pgsql-hackers
On 27.06.18 18:22, Yugo Nagata wrote:
> On Wed, 27 Jun 2018 18:36:46 +0900
> Michael Paquier <[email protected]> wrote:
>
>> On Wed, Jun 27, 2018 at 05:42:07PM +0900, Yugo Nagata wrote:
>>> On Wed, 27 Jun 2018 00:58:18 +0900
>>> Fujii Masao <[email protected]> wrote:
>>>>> In addition, the current pg_standby still can handle a backup history file that are
>>>>> never requested. It is harmless but unnecessary code. Another attached patch
>>>>> (pg_standby.patch) removes this part of code.
>>>>
>>>> Since this is not bug fix, let's discuss this in 12dev cycle.
>>
>> +1.
>
> I added this to CF.
committed
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
^ permalink raw reply [nested|flat] 10+ messages in thread
* \d with triggers: more than one row returned by a subquery used as an expression
@ 2021-12-17 15:43 Justin Pryzby <[email protected]>
2021-12-22 21:03 ` Re: \d with triggers: more than one row returned by a subquery used as an expression Justin Pryzby <[email protected]>
0 siblings, 1 reply; 10+ messages in thread
From: Justin Pryzby @ 2021-12-17 15:43 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers; Amit Langote <[email protected]>
I want to mention that the 2nd problem I mentioned here is still broken.
https://www.postgresql.org/message-id/[email protected]
It happens if non-inheritted triggers on child and parent have the same name.
On Fri, Jul 16, 2021 at 08:02:59PM -0500, Justin Pryzby wrote:
> On Fri, Jul 16, 2021 at 06:01:12PM -0400, Alvaro Herrera wrote:
> > On 2021-Jul-16, Justin Pryzby wrote:
> > > CREATE TABLE p(i int) PARTITION BY RANGE(i);
> > > CREATE TABLE p1 PARTITION OF p FOR VALUES FROM (1)TO(2);
> > > CREATE FUNCTION foo() returns trigger LANGUAGE plpgsql AS $$begin end$$;
> > > CREATE TRIGGER x AFTER DELETE ON p1 EXECUTE FUNCTION foo();
> > > CREATE TRIGGER x AFTER DELETE ON p EXECUTE FUNCTION foo();
> >
> > Hmm, interesting -- those statement triggers are not cloned, so what is
> > going on here is just that the psql query to show them is tripping on
> > its shoelaces ... I'll try to find a fix.
> >
> > I *think* the problem is that the query matches triggers by name and
> > parent/child relationship; we're missing to ignore triggers by tgtype.
> > It's not great design that tgtype is a bitmask of unrelated flags ...
>
> I see it's the subquery Amit wrote and proposed here:
> https://www.postgresql.org/message-id/[email protected]...
>
> .. and I realize that I've accidentally succeeded in breaking what I first
> attempted to break 15 months ago:
>
> On Mon, Apr 20, 2020 at 02:57:40PM -0500, Justin Pryzby wrote:
> > I'm happy to see that this doesn't require a recursive cte, at least.
> > I was trying to think how to break it by returning multiple results or results
> > out of order, but I think that can't happen.
>
> If you assume that pg_partition_ancestors returns its results in order, I think
> you can fix it by adding LIMIT 1. Otherwise I think you need a recursive CTE,
> as I'd feared.
>
> Note also that I'd sent a patch to add newlines, to make psql -E look pretty.
> v6-0001-fixups-c33869cc3bfc42bce822251f2fa1a2a346f86cc5.patch
^ permalink raw reply [nested|flat] 10+ messages in thread
* Re: \d with triggers: more than one row returned by a subquery used as an expression
2021-12-17 15:43 \d with triggers: more than one row returned by a subquery used as an expression Justin Pryzby <[email protected]>
@ 2021-12-22 21:03 ` Justin Pryzby <[email protected]>
0 siblings, 0 replies; 10+ messages in thread
From: Justin Pryzby @ 2021-12-22 21:03 UTC (permalink / raw)
To: Alvaro Herrera <[email protected]>; +Cc: Tom Lane <[email protected]>; pgsql-hackers; Amit Langote <[email protected]>
On Fri, Dec 17, 2021 at 09:43:56AM -0600, Justin Pryzby wrote:
> I want to mention that the 2nd problem I mentioned here is still broken.
> https://www.postgresql.org/message-id/[email protected]
>
> It happens if non-inheritted triggers on child and parent have the same name.
This is the fix I was proposing
It depends on pg_partition_ancestors() to return its partitions in order:
this partition => parent => ... => root.
^ permalink raw reply [nested|flat] 10+ messages in thread
end of thread, other threads:[~2021-12-22 21:03 UTC | newest]
Thread overview: 10+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2018-06-26 08:47 Small fixes about backup history file in doc and pg_standby Yugo Nagata <[email protected]>
2018-06-26 11:19 ` Kyotaro HORIGUCHI <[email protected]>
2018-06-27 08:52 ` Yugo Nagata <[email protected]>
2018-06-26 15:58 ` Fujii Masao <[email protected]>
2018-06-27 08:42 ` Yugo Nagata <[email protected]>
2018-06-27 09:36 ` Michael Paquier <[email protected]>
2018-06-27 16:22 ` Yugo Nagata <[email protected]>
2018-07-01 13:12 ` Peter Eisentraut <[email protected]>
2021-12-17 15:43 \d with triggers: more than one row returned by a subquery used as an expression Justin Pryzby <[email protected]>
2021-12-22 21:03 ` Re: \d with triggers: more than one row returned by a subquery used as an expression Justin Pryzby <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox