public inbox for [email protected]help / color / mirror / Atom feed
[PATCH v31 08/11] pg_stat_file and pg_ls_dir_* to use lstat().. 2+ messages / 2 participants [nested] [flat]
* [PATCH v31 08/11] pg_stat_file and pg_ls_dir_* to use lstat().. @ 2020-03-30 23:59 Justin Pryzby <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: Justin Pryzby @ 2020-03-30 23:59 UTC (permalink / raw) pg_ls_dir_* will now skip (no longer show) symbolic links, same as other non-regular file types, as we advertize we do since 8b6d94cf6. That seems to be the intented behavior, since irregular file types are 1) less portable; and, 2) we don't currently show a file's type except for "bool is_dir". pg_stat_file will now 1) show metadata of links themselves, rather than their target; and, 2) specifically, show links to directories with "is_dir=false"; and, 3) not error on broken symlinks. --- doc/src/sgml/func.sgml | 2 +- src/backend/utils/adt/genfile.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index 20e7f10e83..04d2d2c830 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -27454,7 +27454,7 @@ SELECT convert_from(pg_read_binary_file('file_in_utf8.txt'), 'UTF8'); Returns a record containing the file's size, last access time stamp, last modification time stamp, last file status change time stamp (Unix platforms only), file creation time stamp (Windows only), and a flag - indicating if it is a directory (or a symbolic link to a directory). + indicating if it is a directory. </para> <para> This function is restricted to superusers by default, but other users diff --git a/src/backend/utils/adt/genfile.c b/src/backend/utils/adt/genfile.c index 3c022cffd5..e907f39924 100644 --- a/src/backend/utils/adt/genfile.c +++ b/src/backend/utils/adt/genfile.c @@ -445,7 +445,7 @@ pg_stat_file(PG_FUNCTION_ARGS) filename = convert_and_check_filename(filename_t); - if (stat(filename, &fst) < 0) + if (lstat(filename, &fst) < 0) { if (missing_ok && errno == ENOENT) PG_RETURN_NULL(); @@ -635,7 +635,7 @@ pg_ls_dir_files(FunctionCallInfo fcinfo, const char *dir, int flags) /* Get the file info */ snprintf(path, sizeof(path), "%s/%s", dir, de->d_name); - if (stat(path, &attrib) < 0) + if (lstat(path, &attrib) < 0) { /* Ignore concurrently-deleted files, else complain */ if (errno == ENOENT) -- 2.17.0 --qZVVwWJgpX9Jzs7f Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="v31-0009-pg_ls_-pg_stat_file-to-show-file-type.patch" ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Doc: fix the note related to the GUC "synchronized_standby_slots" @ 2024-08-27 03:54 David G. Johnston <[email protected]> 0 siblings, 0 replies; 2+ messages in thread From: David G. Johnston @ 2024-08-27 03:54 UTC (permalink / raw) To: Amit Kapila <[email protected]>; +Cc: Zhijie Hou (Fujitsu) <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; shveta malik <[email protected]> On Monday, August 26, 2024, Amit Kapila <[email protected]> wrote: > On Mon, Aug 26, 2024 at 6:38 PM Zhijie Hou (Fujitsu) > <[email protected]> wrote: > > > > On Monday, August 26, 2024 5:37 PM Amit Kapila <[email protected]> > wrote: > > > > > > On Mon, Aug 26, 2024 at 1:30 PM <[email protected]> wrote: > > > > > > > > When I read the following documentation related to the > > > "synchronized_standby_slots", I misunderstood that data loss would not > occur > > > in the case of synchronous physical replication. However, this is > incorrect (see > > > reproduce.txt). > > > > > > > > > Note that in the case of asynchronous replication, there remains a > risk of > > > data loss for transactions committed on the former primary server but > have yet > > > to be replicated to the new primary server. > > > > https://www.postgresql.org/docs/17/logical-replication-failover.html > > > > > > > > Am I missing something? > > > > > > > > > > It seems part of the paragraph: "Note that in the case of asynchronous > > > replication, there remains a risk of data loss for transactions > committed on the > > > former primary server but have yet to be replicated to the new primary > server." is > > > a bit confusing. Will it make things clear to me if we remove that > part? > > > > I think the intention is to address a complaint[1] that the date > inserted on > > primary after the primary disconnects with the standby is still lost > after > > failover. But after rethinking, maybe it's doesn't directly belong to > the topic in > > the logical failover section because it's a general fact for async > replication. > > If we think it matters, maybe we can remove this part and slightly modify > > another part: > > > > parameter ensures a seamless transition of those subscriptions after > the > > standby is promoted. They can continue subscribing to publications on > the > > - new primary server without losing data. > > + new primary server without losing that has already been replicated > and > > + flushed on the standby server. > > > > Yeah, we can change that way but not sure if that satisfies the OP's > concern. I am waiting for his response. > I’d suggest getting rid of all mention of “without losing data” and just emphasize the fact that the subscribers can operate in a hot-standby publishing environment in an automated fashion by connecting using “failover” enabled slots, assuming the publishing group prevents any changes from propagating to any logical subscriber until all standbys in the group have been updated. Whether or not the primary-standby group is resilient in the face of failure during internal group synchronization is out of the hands of logical subscribers - rather they are only guaranteed to see a consistent linear history of activity coming out of the publishing group. Specifically, if the group synchronizes asynchronously there is no guarantee that every committed transaction on the primary makes its way through to the logical subscriber if a slot failover happens. But at the same time its view of the world will be consistent with the newly chosen primary. David J. ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2024-08-27 03:54 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2020-03-30 23:59 [PATCH v31 08/11] pg_stat_file and pg_ls_dir_* to use lstat().. Justin Pryzby <[email protected]> 2024-08-27 03:54 Re: Doc: fix the note related to the GUC "synchronized_standby_slots" David G. Johnston <[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