Mention FK creation take ShareRowExclusiveLock on referenced table
Hello, A few days ago I was surprised a CREATE TABLE containing FK constraint was stuck due to an automatic vacuum freeze (which took ShareUpdateExclusiveLock if I remember) on referenced table. After digging into the code I found theses lines in tablecmds.c : /* * Grab ShareRowExclusiveLock on the pk table, so that someone doesn't * delete rows out from under us. */ Maybe it should be documented in theses pages? https://www.postgresql.org/docs/current/static/sql-createtable.html https://www.postgresql.org/docs/current/static/sql-altertable.html If you agree I can send a patch. Regards,
Ambiguity in restore_command for recovery.conf
The following documentation comment has been logged on the website: Page: https://www.postgresql.org/docs/10/static/archive-recovery-settings.html Description: Documentation for restore_command in recovery.conf only says, "This parameter is required for archive recovery, but optional for streaming replication," but it doesn't say specifically when the restore_command string will be used and why. My guess is that as long as the WAL files are still available on the master (primary) host, the recovery will fetch them via the replication slot, but if a WAL is missing on the primary, only then will the restore_command be used. But this isn't explicitly stated. It could be that the restore_command is always used, even if the WAL file is still available on the primary.
Re: Ambiguity in restore_command for recovery.conf
On Tue, Sep 18, 2018 at 04:10:17PM +, PG Doc comments form wrote: > Documentation for restore_command in recovery.conf only says, "This > parameter is required for archive recovery, but optional for streaming > replication," but it doesn't say specifically when the restore_command > string will be used and why. My guess is that as long as the WAL files > are still available on the master (primary) host, the recovery will > fetch them via the replication slot, but if a WAL is missing on the > primary, only then will the restore_command be used. But this isn't > explicitly stated. It could be that the restore_command is always > used, even if the WAL file is still available on the primary. The logic around the source used to fetch WAL segments is defined in WaitForWALToBecomeAvailable/xlog.c. A standby would give priority to what is present in the local pg_wal or in the WAL archive before switching to streaming. If fetching a segment from the archive or the local pg_wal fails, then a switch to streaming happens (of course if primary_conninfo is defined). There is nothing really linked to replication slots in this case. -- Michael signature.asc Description: PGP signature
Re: Mention FK creation take ShareRowExclusiveLock on referenced table
On Tue, Sep 18, 2018 at 12:32:54PM +0200, Adrien NAYRAT wrote: > A few days ago I was surprised a CREATE TABLE containing FK constraint was > stuck due to an automatic vacuum freeze (which took ShareUpdateExclusiveLock > if I remember) on referenced table. Right. See the top of vacuum_rel() where lmode is set. > After digging into the code I found theses lines in tablecmds.c : > > /* > * Grab ShareRowExclusiveLock on the pk table, so that someone doesn't > * delete rows out from under us. > */ > > Maybe it should be documented in theses pages? > > https://www.postgresql.org/docs/current/static/sql-createtable.html > https://www.postgresql.org/docs/current/static/sql-altertable.html > > If you agree I can send a patch. That looks like a good idea. Are you thinking about adding a comment about that in "ADD table_constraint" for the ALTER TABLE page, and in "FOREIGN KEY" for the CREATE TABLE page? -- Michael signature.asc Description: PGP signature
