Add rule_number to pg_hba_file_rules and map_number to pg_ident_file_mappings
These numbers are strictly-monotone identifiers assigned to each rule
of pg_hba_file_rules and each map of pg_ident_file_mappings when loading
the HBA and ident configuration files, indicating the order in which
they are
On Wed, Oct 26, 2022 at 12:54:24PM +0900, Michael Paquier wrote:
> On Wed, Oct 26, 2022 at 11:27:30AM +0800, Julien Rouhaud wrote:
> > I fixed it in the v14 sent on the main thread, unfortunately sent a bit too
> > late.
>
> Nya, yeah. It looks like I fat-fingered a copy-paste here. The
> result
Fix variable assignment thinko in hba.c
The intention behind 1b73d0b was to limit the use of TokenizedAuthLine,
but I have fat-fingered one location in parse_hba_line() when creating
the HbaLine, where this should use the local variable and not the value
coming from TokenizedAuthLine. This logic
On Wed, Oct 26, 2022 at 11:27:30AM +0800, Julien Rouhaud wrote:
> I fixed it in the v14 sent on the main thread, unfortunately sent a bit too
> late.
Nya, yeah. It looks like I fat-fingered a copy-paste here. The
result is the same, still your suggested change is more consistent
with the rest of
Hi,
On Wed, Oct 26, 2022 at 02:53:08AM +, Michael Paquier wrote:
> Refactor code handling the names of files loaded in hba.c
For the record there is a couple of thinko in the extracted patch:
@@ -1063,6 +1064,7 @@ HbaLine *
parse_hba_line(TokenizedAuthLine *tok_line, int elevel)
{
int
Refactor code handling the names of files loaded in hba.c
This has the advantage to limit the presence of the GUC values
hba_file and ident_file to the code paths where these files are loaded,
easing the introduction of an upcoming feature aimed at adding inclusion
logic for files and directories
On Wed, Oct 26, 2022 at 12:57 PM Justin Pryzby wrote:
> On Wed, Oct 26, 2022 at 11:15:16AM +1300, Thomas Munro wrote:
> > On Wed, Oct 26, 2022 at 10:31 AM Justin Pryzby wrote:
> > > > If I'm not wrong, this didn't fix the issue you said it fixed.
> > >
> > > s/said/hoped/sorry
> >
> > Drat. More
Fix ordering issue with WAL operations in GIN fast insert path
Contrary to what is documented in src/backend/access/transam/README,
ginHeapTupleFastInsert() had a few ordering issues with the way it does
its WAL operations when inserting items in its fast path.
First, when using a separate list,
Fix ordering issue with WAL operations in GIN fast insert path
Contrary to what is documented in src/backend/access/transam/README,
ginHeapTupleFastInsert() had a few ordering issues with the way it does
its WAL operations when inserting items in its fast path.
First, when using a separate list,
Fix ordering issue with WAL operations in GIN fast insert path
Contrary to what is documented in src/backend/access/transam/README,
ginHeapTupleFastInsert() had a few ordering issues with the way it does
its WAL operations when inserting items in its fast path.
First, when using a separate list,
Fix ordering issue with WAL operations in GIN fast insert path
Contrary to what is documented in src/backend/access/transam/README,
ginHeapTupleFastInsert() had a few ordering issues with the way it does
its WAL operations when inserting items in its fast path.
First, when using a separate list,
Fix ordering issue with WAL operations in GIN fast insert path
Contrary to what is documented in src/backend/access/transam/README,
ginHeapTupleFastInsert() had a few ordering issues with the way it does
its WAL operations when inserting items in its fast path.
First, when using a separate list,
Fix ordering issue with WAL operations in GIN fast insert path
Contrary to what is documented in src/backend/access/transam/README,
ginHeapTupleFastInsert() had a few ordering issues with the way it does
its WAL operations when inserting items in its fast path.
First, when using a separate list,
On Wed, Oct 26, 2022 at 11:15:16AM +1300, Thomas Munro wrote:
> On Wed, Oct 26, 2022 at 10:31 AM Justin Pryzby wrote:
> > On Tue, Oct 25, 2022 at 04:21:02PM -0500, Justin Pryzby wrote:
> > > > Restore that behavior with an explicit check, to see if it fixes the
> > > > occasional 'directory not em
On Wed, Oct 26, 2022 at 10:31 AM Justin Pryzby wrote:
> On Tue, Oct 25, 2022 at 04:21:02PM -0500, Justin Pryzby wrote:
> > > Restore that behavior with an explicit check, to see if it fixes the
> > > occasional 'directory not empty' failures seen in the pg_upgrade tests
> > > on CI. Further impro
Doc/improve confusing, inefficient tests to locate CTID variable.
The IsCTIDVar() tests in nodeTidscan.c and nodeTidrangescan.c
look buggy at first sight: they aren't checking that the varno
matches the table to be scanned. Actually they're safe because
any Var in a scan-level qual must be for th
On Tue, Oct 25, 2022 at 04:21:02PM -0500, Justin Pryzby wrote:
> > Restore that behavior with an explicit check, to see if it fixes the
> > occasional 'directory not empty' failures seen in the pg_upgrade tests
> > on CI. Further improvements are possible with proposed upgrades to
> > modern Windo
On Tue, Oct 25, 2022 at 03:29:42AM +, Thomas Munro wrote:
> Fix unlink() for STATUS_DELETE_PENDING on Windows.
>
> Commit f357233c assumed that it was OK to return ENOENT directly if
> lstat() failed that way. If we got STATUS_DELETE_PENDING while trying
> to unlink a file that we had already
Update outdated comment for TransactionIdSetTreeStatus
Commit 06da3c570f changed the way subtransactions are marked as
SUBCOMMITTED, but the example it included actually documented the old
way. Update it.
Author: Japin Li
Discussion:
https://www.postgresql.org/message-id/MEYP282MB16690BC96DFBE08
19 matches
Mail list logo
