Sorry for the silly mistake.
At Fri, 17 Dec 2021 15:40:10 +0900 (JST), Kyotaro Horiguchi
wrote in
> > NSS departs slightly from the spec and will additionally try to match
> > an IP address against the CN, but only if there are no iPAddresses in
> > the SAN. It roughly matches the logic for
At Fri, 17 Dec 2021 14:50:37 +0900, Fujii Masao
wrote in
> > FWIW, I don't understand why we care of the case where the function
> > itself changes its mind to set values[i] to null
>
> Whether we add this check or not, the behavior is the same, i.e., that
> setting value is not used. But by
On Mon, Dec 13, 2021 at 8:43 PM Shruthi Gowda wrote:
>
> On Mon, Dec 6, 2021 at 11:25 PM Robert Haas wrote:
> >
> > On Sun, Dec 5, 2021 at 11:44 PM Sadhuprasad Patro wrote:
> > > 3.
> > > @@ -504,11 +525,15 @@ createdb(ParseState *pstate, const CreatedbStmt
> > > *stmt)
> > > */
> > >
On 15.12.21 16:59, Brar Piening wrote:
On Dec 15, 2021 at 15:49, Alvaro Herrera wrote:
On 2021-Dec-15, Brar Piening wrote:
Since I can't argue towards some general utility for the xreflabels
and don't have any other solid argument in favor of adding more, I
will remove them from my current
On 17.12.21 05:47, Amit Kapila wrote:
I think in the above sentence, you mean to say "dropped from the
publication". So, IIUC, you are proposing that if one drops a column
that was part of the column list of a relation in a publication, an
error will be raised. Also, if the user specifies
On Thu, Dec 16, 2021 at 5:27 AM Peter Geoghegan wrote:
>
> On Fri, Dec 10, 2021 at 1:48 PM Peter Geoghegan wrote:
> > * I'm still working on the optimization that we discussed on this
> > thread: the optimization that allows the final relfrozenxid (that we
> > set in pg_class) to be determined
On Fri, Dec 17, 2021 at 9:41 AM Peter Smith wrote:
>
> PSA the v47* patch set.
>
I found that even though there are now separately-maintained WHERE clauses
per pubaction, there still seem to be problems when applying the old/new
row rules for UPDATE.
A simple example of this was previously
On 17.12.21 03:25, Shinya Kato wrote:
For now, I'v attached the patch that fixed the compilation error.
I think it would be good if you could split the uncontroversial new
EmitErrorsOnPlaceholders() calls into a separate patch. And please add
an explanation what exactly the rest of the
On Thu, 16 Dec 2021 at 22:18, Tom Lane wrote:
>
> * If the sort order is underspecified, or you omit ORDER BY
> entirely, then it's not clear which rows will be operated on.
> The LIMIT might stop after just some of the rows in a peer
> group, and you can't predict which ones.
Meh, that never
At Thu, 16 Dec 2021 18:44:54 +, Jacob Champion wrote
in
> On Thu, 2021-12-16 at 14:54 +0900, Kyotaro Horiguchi wrote:
> > It seems like saying that we must search for iPAddress and mustn't use
> > CN nor dNSName if the client connected using IP address. Otherwise, if
> > the host name is a
On Thu, 16 Dec 2021 20:56:59 -0700
"David G. Johnston" wrote:
> On Thursday, December 16, 2021, Yugo NAGATA wrote:
>
> >
> > Also, here seem to be some use cases. For example,
> > - when you want to delete the specified number of rows from a table
> > that doesn't have a primary key and
On 2021/12/17 12:06, Kyotaro Horiguchi wrote:
At Fri, 17 Dec 2021 02:42:25 +, "kuroda.hay...@fujitsu.com"
wrote in
Dear Fujii-san,
Sorry I forgot replying your messages.
if (strcmp(keywords[i], "application_name") == 0 &&
On Thu, 16 Dec 2021 22:17:58 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > We cannot use ORDER BY or LIMIT/OFFSET in the current
> > DELETE statement syntax, so all the row matching the
> > WHERE condition are deleted. However, the tuple retrieving
> > process of DELETE is basically same as
On Thu, Dec 16, 2021 at 4:27 PM houzj.f...@fujitsu.com
wrote:
>
> On Wed, Dec 15, 2021 4:03 PM Masahiko Sawada wrote:
> > On Tue, Dec 14, 2021 at 12:03 PM Amit Kapila
> > wrote:
> > > There is still pending
> > > work related to moving parallel vacuum code to a separate file and a
> > > few
On Fri, 3 Dec 2021 at 22:04, Zhihong Yu wrote:
>
>
> On Fri, Dec 3, 2021 at 3:15 AM Dinesh Chemuduru
> wrote:
>
>> Hi Michael,
>>
>> Attaching the latest patch here(It's the recent patch), and looking for
>> more suggestions/inputs from the team.
>>
>> On Fri, 3 Dec 2021 at 13:09, Michael
On Thu, Dec 16, 2021 at 10:38 PM Amit Kapila wrote:
>
> On Thu, Dec 16, 2021 at 6:13 PM Masahiko Sawada wrote:
> >
> > On Thu, Dec 16, 2021 at 1:56 PM Amit Kapila wrote:
> > >
> > > On Wed, Dec 15, 2021 at 1:33 PM Masahiko Sawada
> > > wrote:
> > > >
> > > > I've attached an updated patch.
At Thu, 16 Dec 2021 11:36:46 +, "osumi.takami...@fujitsu.com"
wrote in
> On Thursday, December 16, 2021 4:00 PM I wrote:
> > Thank you, everyone for confirming the direction.
> > I'll follow the consensus of the community and fix the patch, including
> > other
> > comments.
> > I'll treat
On 2021/12/17 11:25, Shinya Kato wrote:
For now, I'v attached the patch that fixed the compilation error.
Thanks for updating the patch! I confirmed that the compilation was completed
successfully with this new patch. But the regression test failed. You can see
that Patch Tester [1] also
On Wed, Dec 15, 2021 at 1:05 AM Alvaro Herrera wrote:
>
> On 2021-Dec-14, Tomas Vondra wrote:
>
> > Yeah. I think it's not clear if this should behave more like an index or a
> > view. When an indexed column gets dropped we simply drop the index. But if
> > you drop a column referenced by a view,
Greg Stark writes:
> But if you're interested and can explain the tests to run I can try to
> get the tests running on this machine:
I'm not sure that machine is close enough to prove much, but by all
means give it a go if you wish. My test setup was explained in [1]:
>> To recap, the test
On Fri, Dec 17, 2021 at 09:00:04AM +0530, Dilip Kumar wrote:
> On Tue, Dec 14, 2021 at 3:57 AM Bossart, Nathan wrote:
> >
> > On 12/13/21, 6:30 AM, "Dilip Kumar" wrote:
> > > On Tue, Dec 7, 2021 at 11:11 AM Justin Pryzby
> > > wrote:
> > >> Since I think this field is usually not interesting
On Thursday, December 16, 2021, Yugo NAGATA wrote:
>
> Also, here seem to be some use cases. For example,
> - when you want to delete the specified number of rows from a table
> that doesn't have a primary key and contains tuple duplicated.
Not our problem…use the tools correctly; there is
On Tue, Dec 14, 2021 at 6:23 PM Ashutosh Sharma wrote:
>
> Hi,
>
> I have looked into the v2 patch and here are my comments:
>
> + PG_RETURN_INT32(local_beentry->subxact_overflowed);
> +}
>
> Should this be PG_RETURN_BOOL instead of PG_RETURN_INT32??
>
> --
>
> +{ oid => '6107', descr =>
On Tue, Dec 14, 2021 at 3:57 AM Bossart, Nathan wrote:
>
> On 12/13/21, 6:30 AM, "Dilip Kumar" wrote:
> > On Tue, Dec 7, 2021 at 11:11 AM Justin Pryzby wrote:
> >> Since I think this field is usually not interesting to most users of
> >> pg_stat_activity, maybe this should instead be
Yugo NAGATA writes:
> We cannot use ORDER BY or LIMIT/OFFSET in the current
> DELETE statement syntax, so all the row matching the
> WHERE condition are deleted. However, the tuple retrieving
> process of DELETE is basically same as SELECT statement,
> so I think that we can also allow DELETE to
The actual hardware of this machine is a Mac Mini Core 2 Duo. I'm not
really clear how the emulation is done and whether it makes a
reasonable test environment or not.
Hardware Overview:
Model Name: Mac mini
Model Identifier: Macmini2,1
Processor Name: Intel Core 2 Duo
At Fri, 17 Dec 2021 02:42:25 +, "kuroda.hay...@fujitsu.com"
wrote in
> Dear Fujii-san,
>
> Sorry I forgot replying your messages.
>
> > >> if (strcmp(keywords[i], "application_name") == 0 &&
> > >> values[i] != NULL && *(values[i]) != '\0')
> > >
Dear Fujii-san,
Sorry I forgot replying your messages.
> >>if (strcmp(keywords[i], "application_name") == 0 &&
> >>values[i] != NULL && *(values[i]) != '\0')
> >
> > I'm not sure but do we have a case that values[i] becomes NULL
> > even if
On Fri, 26 Nov 2021 at 21:47, Tom Lane wrote:
>
> Yeah ... on the one hand, that machine has shown signs of
> hard-to-reproduce flakiness, so it's easy to write off the failures
> I saw as hardware issues. On the other hand, the flakiness I've
> seen has otherwise manifested as kernel crashes,
On 2021-12-17 01:55, Fujii Masao wrote:
On 2021/12/16 16:31, Shinya Kato wrote:
Thank you for the review and sorry for the late reply.
On 2021-11-16 19:25, Bharath Rupireddy wrote:
> I observed an odd behaviour:
> 1) I set postgres_fdw.XXX = 'I_messed_up_conf_file' in postgresql.conf
> 2)
Dear Fujii-san,
> Thanks for the review! At first I pushed 0001 patch.
I found your commit. Thanks!
> BTW, 0002 patch adds the regression test that checks
> pg_stat_activity.application_name. But three months before, we added the
> similar
> test when introducing postgres_fdw.application_name
On Fri, 17 Dec 2021 09:47:18 +0900
Yugo NAGATA wrote:
> Hello hackers,
>
> We cannot use ORDER BY or LIMIT/OFFSET in the current
> DELETE statement syntax, so all the row matching the
> WHERE condition are deleted. However, the tuple retrieving
> process of DELETE is basically same as SELECT
On Fri, Dec 17, 2021 at 9:38 AM Tom Lane wrote:
> Daniel Gustafsson writes:
> >> On 16 Dec 2021, at 19:22, Tom Lane wrote:
> >> Having said that, I'm not seeing any such warning when I build
> >> with openssl 1.1.1k on my own Mac, so I'm a bit confused why
> >> Thomas sees it.
>
> > Maybe it's
On Fri, 2021-12-10 at 15:43 +0200, Heikki Linnakangas wrote:
> ProcessStartupPacket() currently reads the first 4 bytes coming from the
> client to decide what kind of a connection it is, and I believe a TLS
> ClientHello message always begins with the same sequence of bytes, so it
> would be
On Tue, Dec 14, 2021 at 10:12 PM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 10:50 AM Amit Kapila wrote:
> >
> > On Tue, Dec 14, 2021 at 4:44 AM Peter Smith wrote:
> >
> > Few other comments:
> > ===
>
> Few more comments:
> ==
> v46-0001/0002
>
Hello hackers,
We cannot use ORDER BY or LIMIT/OFFSET in the current
DELETE statement syntax, so all the row matching the
WHERE condition are deleted. However, the tuple retrieving
process of DELETE is basically same as SELECT statement,
so I think that we can also allow DELETE to use ORDER BY
On Tue, Dec 14, 2021 at 4:20 PM Amit Kapila wrote:
>
> On Tue, Dec 14, 2021 at 4:44 AM Peter Smith wrote:
> >
> > On Tue, Dec 7, 2021 at 5:48 PM tanghy.f...@fujitsu.com
> > wrote:
> > >
> > > I think for "FOR ALL TABLE" publication(p2 in my case), table tbl should
> > > be
> > > treated as no
On Thu, 2021-12-09 at 11:04 +0100, Tomas Vondra wrote:
> On 12/9/21 01:12, Jacob Champion wrote:
> >
> > The rabbit hole I led you down is one where we use the rest of the row
> > as AD, to try to freeze pieces of it in place. That might(?) have some
> > useful security properties (if the client
On Thu, Dec 16, 2021, at 8:55 PM, Michael Paquier wrote:
> On Thu, Dec 16, 2021 at 03:08:46PM -0300, Alvaro Herrera wrote:
> > Hmm, so if a table has REPLICA IDENTITY INDEX and there is a publication
> > with an explicit column list, then we need to forbid the DROP INDEX for
> > that index.
>
>
On Thu, Dec 16, 2021 at 03:08:46PM -0300, Alvaro Herrera wrote:
> Hmm, so if a table has REPLICA IDENTITY INDEX and there is a publication
> with an explicit column list, then we need to forbid the DROP INDEX for
> that index.
Hmm. I have not followed this thread very closely.
> I wonder why
Hi all,
In keeping with my theme of expanding the authentication/authorization
options for the server, attached is an experimental patchset that lets
Postgres determine an authenticated user's allowed roles by querying an
LDAP server, and enables SASL binding for those queries.
This lets you
On Wed, Dec 15, 2021 at 3:50 PM Greg Nancarrow wrote:
>
> On Mon, Dec 13, 2021 at 8:49 PM Peter Smith wrote:
> >
> > PSA the v46* patch set.
> >
>
> 0001
>
...
> (2) In the 0001 patch comment, the term "publication filter" is used
> in one place, and in others "row filter" or "row-filter".
>
On Fri, Dec 17, 2021 at 7:11 AM Alvaro Herrera wrote:
>
> Kindly do not change the mode of src/backend/parser/gram.y.
>
Oops. Sorry that was not deliberate.
I will correct that in the next version.
--
Kind Regards,
Peter Smith.
Fujitsu Australia
I had a similar question. And I'm still not clear from the response
what exactly index_blks_total is and whether it addresses it.
I think I agree that a user is likely to want to see the progress in a
way they can understand which means for a single index at a time.
I think what you're
On 12/15/21, 4:10 PM, "Bossart, Nathan" wrote:
On 12/1/21, 3:02 PM, "Imseih (AWS), Sami" wrote:
> The current implementation of pg_stat_progress_vacuum does not
> provide progress on which index is being vacuumed making it
> difficult for a user to determine if the "vacuuming
On 2021-Dec-15, Melanie Plageman wrote:
> I noticed after changing the docs on the "bgwriter" target for
> pg_stat_reset_shared to say "checkpointer", that it still said "bgwriter" in
> src/backend/po/ko.po
> src/backend/po/it.po
> ...
> I presume these are automatically updated with some
On 12/16/21 15:53, Larry Rosenman wrote:
>
>
> I get:
> ERROR for site owner:
> Invalid domain for site key
>
> on https://pgbuildfarm.org/cgi-bin/register-form.pl
try https://buildfarm.postgresql.org/cgi-bin/register-form.pl
cheers
andrew
On Thu, Dec 09, 2021 at 09:53:23AM -0600, Justin Pryzby wrote:
> On Thu, Dec 09, 2021 at 05:17:54PM +0900, Michael Paquier wrote:
> > On Wed, Dec 08, 2021 at 01:23:51PM +0100, Peter Eisentraut wrote:
> > > I wasn't really aware of this script either. But I think it's a good idea
> > > to have it.
On 12/16/2021 2:47 pm, Andrew Dunstan wrote:
On 12/16/21 12:26, Larry Rosenman wrote:
On 12/16/2021 11:17 am, Andrew Dunstan wrote:
On 12/16/21 11:11, Larry Rosenman wrote:
A new animal, because we're not supporting every build option. On
the
non-live branches you really only want:
On 12/16/21 12:26, Larry Rosenman wrote:
> On 12/16/2021 11:17 am, Andrew Dunstan wrote:
>> On 12/16/21 11:11, Larry Rosenman wrote:
>>>
A new animal, because we're not supporting every build option. On the
non-live branches you really only want:
--enable-debug
Daniel Gustafsson writes:
>> On 16 Dec 2021, at 19:22, Tom Lane wrote:
>> Having said that, I'm not seeing any such warning when I build
>> with openssl 1.1.1k on my own Mac, so I'm a bit confused why
>> Thomas sees it.
> Maybe it's dependant on macOS/XCode release? I see the warning on my
Hi,
On 2021-12-15 16:40:27 -0500, Melanie Plageman wrote:
> > > +/*
> > > + * Before exiting, a backend sends its IO op statistics to the collector
> > > so
> > > + * that they may be persisted.
> > > + */
> > > +void
> > > +pgstat_send_buffers(void)
> > > +{
> > > + PgStat_MsgIOPathOps msg;
> On 16 Dec 2021, at 19:22, Tom Lane wrote:
> Having said that, I'm not seeing any such warning when I build
> with openssl 1.1.1k on my own Mac, so I'm a bit confused why
> Thomas sees it.
Maybe it's dependant on macOS/XCode release? I see the warning on my Catalina
laptop.
--
Daniel
Kindly do not change the mode of src/backend/parser/gram.y.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
On 2021-Dec-14, Tomas Vondra wrote:
> 7) There's a couple places doing this
>
> if (att_map != NULL &&
> !bms_is_member(att->attnum - FirstLowInvalidHeapAttributeNumber,
>att_map) &&
> !bms_is_member(att->attnum - FirstLowInvalidHeapAttributeNumber,
>
On Wed, 2021-12-15 at 23:10 +0100, Daniel Gustafsson wrote:
> > On 30 Nov 2021, at 20:03, Jacob Champion wrote:
> >
> > On Mon, 2021-09-27 at 15:44 +0200, Daniel Gustafsson wrote:
> > > > Speaking of IP addresses in SANs, it doesn't look like our OpenSSL
> > > > backend can handle those. That's
On Wed, Dec 15, 2021 at 11:23:12PM -0500, Greg Stark wrote:
>>> +one that must cannot be delayed right away (because of outer join
>> must cannot?
> Actually on further reading... "delayed right away"?
There are two ways of writing this sentence, and I see that I tried to use
both of them in the
On Thu, 2021-12-16 at 10:50 -0500, Andrew Dunstan wrote:
> Good job, this is certainly going to be useful.
Thanks!
> I don't think we should fall back on the CN. It would seem quite odd to
> do so for IP addresses but not for DNS names.
So there's at least one compatibility concern with
On Thu, 2021-12-16 at 14:54 +0900, Kyotaro Horiguchi wrote:
> In RFC2828 and 6125,
>
> > In some cases, the URI is specified as an IP address rather than a
> > hostname. In this case, the iPAddress subjectAltName must be present
> > in the certificate and must exactly match the IP in the
On Thu, Dec 16, 2021 at 12:53 PM Mark Dilger
wrote:
>
>
>
> > On Dec 16, 2021, at 7:43 AM, Joshua Brindle
> > wrote:
> >
> > Ah, I understand now. Would it be possible to pass the
> > SettingAclRelationId if it exists or InvalidOid if not?
>
> SettingAclRelationId is always defined, so we can
Thomas Munro writes:
> On Fri, Dec 17, 2021 at 4:48 AM Peter Eisentraut
> wrote:
>> These are not errors, right? So why is this a problem?
> Yeah they're just warnings. I don't personally care if we just ignore
> them until we drop OpenSSL < 1.1.0 or macOS < 10.something. I
> mentioned it
On 2021-Dec-15, Michael Paquier wrote:
> On Tue, Dec 14, 2021 at 07:10:49PM +0530, Ashutosh Bapat wrote:
> > This code in RelationGetIndexList() is not according to that comment.
> >
> >if (replident == REPLICA_IDENTITY_DEFAULT && OidIsValid(pkeyIndex))
> > relation->rd_replidindex =
On 2021-Dec-16, houzj.f...@fujitsu.com wrote:
> The patch ensures all columns of RT are in column list when CREATE/ALTER
> publication, but it seems doesn't prevent user from changing the replica
> identity or dropping the index used in replica identity. Do we also need to
> check those cases ?
> On Dec 16, 2021, at 7:43 AM, Joshua Brindle
> wrote:
>
> Ah, I understand now. Would it be possible to pass the
> SettingAclRelationId if it exists or InvalidOid if not?
SettingAclRelationId is always defined, so we can always pass that value. But
the settingId itself may sometimes be
On Fri, Dec 17, 2021 at 4:48 AM Peter Eisentraut
wrote:
> These are not errors, right? So why is this a problem?
Yeah they're just warnings. I don't personally care if we just ignore
them until we drop OpenSSL < 1.1.0 or macOS < 10.something. I
mentioned it because in the past we worked to
On 12/16/2021 11:17 am, Andrew Dunstan wrote:
On 12/16/21 11:11, Larry Rosenman wrote:
A new animal, because we're not supporting every build option. On the
non-live branches you really only want:
--enable-debug --enable-cassert --enable-nls
--enable-tap-tests --with-perl
You can
On Thu, Dec 16, 2021 at 12:16 PM Tomas Vondra
wrote:
> Maybe, but other places (predating incremental sort) creating Gather
> Merge do the same thing, and commit ba3e76cc57 merely copied this. For
> example generate_gather_paths() does this:
>
> foreach(lc, rel->partial_pathlist)
> {
>
On 12/16/21 11:11, Larry Rosenman wrote:
>
>>
>> A new animal, because we're not supporting every build option. On the
>> non-live branches you really only want:
>>
>> --enable-debug --enable-cassert --enable-nls
>>
>> --enable-tap-tests --with-perl
>>
>> You can make it share the same
On 12/16/21 17:48, Robert Haas wrote:
This code introduced in ba3e76cc571eba3dea19c9465ff15ac3ac186576 looks
wrong to me:
total_groups = cheapest_partial_path->rows *
cheapest_partial_path->parallel_workers;
path = (Path *)
On 12/16/21 17:03, Ronan Dunklau wrote:
Le jeudi 16 décembre 2021, 11:56:15 CET Ronan Dunklau a écrit :
I will follow up with a benchmark of the test sorting a table with a width
varying from 1 to 32 columns.
So please find attached another benchmark for that case.
The 3 different patchsets
On 2021/12/16 16:31, Shinya Kato wrote:
Thank you for the review and sorry for the late reply.
On 2021-11-16 19:25, Bharath Rupireddy wrote:
> I observed an odd behaviour:
> 1) I set postgres_fdw.XXX = 'I_messed_up_conf_file' in postgresql.conf
> 2) With
This code introduced in ba3e76cc571eba3dea19c9465ff15ac3ac186576 looks
wrong to me:
total_groups = cheapest_partial_path->rows *
cheapest_partial_path->parallel_workers;
path = (Path *)
create_gather_merge_path(root, ordered_rel,
> As I said before, your position seems reasonable. I've also got a couple
of reasonable complaints about IF EXISTS out there. But there is little
interest in changing the status quo with regards to the promises that IF
EXISTS makes. And even with my less constrained views I find that doing
On 12/16/2021 10:02 am, Andrew Dunstan wrote:
On 12/15/21 21:36, Larry Rosenman wrote:
On 12/15/2021 11:15 am, Andrew Dunstan wrote:
OK, old_branches_of_interest.txt now exists on the buildfarm server,
and
the code has been modified to take notice of it (i.e. to accept
builds
for branches
Le jeudi 16 décembre 2021, 11:56:15 CET Ronan Dunklau a écrit :
> I will follow up with a benchmark of the test sorting a table with a width
> varying from 1 to 32 columns.
>
So please find attached another benchmark for that case.
The 3 different patchsets tested are:
- master
- fixed
On 12/15/21 21:36, Larry Rosenman wrote:
> On 12/15/2021 11:15 am, Andrew Dunstan wrote:
>> OK, old_branches_of_interest.txt now exists on the buildfarm server, and
>> the code has been modified to take notice of it (i.e. to accept builds
>> for branches listed there). The contents are the
On Thu, Dec 16, 2021 at 3:38 AM Shay Rojansky wrote:
> >> Now, before creating tables, the ORM generates CREATE SCHEMA IF NOT
> EXISTS, to ensure that the schema exists before CREATE TABLE; that's
> reasonable general-purpose behavior.
> >
> > If the user hasn’t specified they want the schema
Hi,
While testing the v8 patches in a hot-standby setup, it was observed the
master is crashing with the below error;
2021-12-16 19:32:47.757 +04 [101483] PANIC: could not fsync file
"pg_tblspc/16385/PG_15_202112111/16386/16391": No such file or directory
2021-12-16 19:32:48.917 +04 [101482]
On 12/15/21 20:13, Jacob Champion wrote:
> Hello all,
>
> libpq currently supports server certificates with a single IP address
> in the Common Name. It's fairly brittle; as far as I can tell, the
> single name you choose has to match the client's address exactly.
>
> Attached is a patch for
On 16.12.21 16:25, Tom Lane wrote:
Thomas Munro writes:
Apple's ranlib doesn't like empty translation units[1], but
protocol_openssl.c doesn't define any symbols (unless you have an
ancient EOL'd openssl), so longfin and CI say:
On Wed, Dec 15, 2021 at 1:18 PM Mark Dilger
wrote:
>
> > On Dec 15, 2021, at 10:02 AM, Joshua Brindle
> > wrote:
> >
> > Ah, I was actually requesting a hook where the acl check was done for
> > setting a GUC, such that we could deny setting them in a hook,
> > something that would be useful
Thomas Munro writes:
> Apple's ranlib doesn't like empty translation units[1], but
> protocol_openssl.c doesn't define any symbols (unless you have an
> ancient EOL'd openssl), so longfin and CI say:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib:
Peter Eisentraut writes:
> This rearranges the version-dependent pieces in the new more modular style.
> I had originally written this before pre-9.2 support was removed and it
> had a few more branches then. But I think it is still useful, and there
> are some pending patches that might add
On 12/16/21 12:59, Amit Kapila wrote:
> On Wed, Dec 15, 2021 at 7:21 PM Tomas Vondra
> wrote:
>>
>> On 12/15/21 14:20, Amit Kapila wrote:
>>> On Tue, Dec 14, 2021 at 7:02 AM Tomas Vondra
>>> wrote:
Hi,
here's an updated version of the patches, dealing with almost all of
On Thu, Dec 16, 2021 at 6:13 PM Masahiko Sawada wrote:
>
> On Thu, Dec 16, 2021 at 1:56 PM Amit Kapila wrote:
> >
> > On Wed, Dec 15, 2021 at 1:33 PM Masahiko Sawada
> > wrote:
> > >
> > > I've attached an updated patch. The patch incorporated several changes
> > > from the last version:
> > >
On Thursday, December 16, 2021 8:37 PM I wrote:
> Hi, created a new version v17 according to the recent discussion with changes
> to address other review comments.
FYI, in v17 I've removed one part of commit message
about spool file statistics on the subscriber.
My intention is just to make the
On Thursday, December 16, 2021 2:32 PM Greg Nancarrow
wrote:
> On Tue, Dec 14, 2021 at 4:34 PM osumi.takami...@fujitsu.com
> wrote:
> >
> > Besides all of those changes, I've removed the obsolete comment of
> > DisableSubscriptionOnError in v12.
> >
>
> I have a few minor comments, otherwise
On Thu, Dec 16, 2021 at 1:56 PM Amit Kapila wrote:
>
> On Wed, Dec 15, 2021 at 1:33 PM Masahiko Sawada wrote:
> >
> > I've attached an updated patch. The patch incorporated several changes
> > from the last version:
> >
> > * Rename parallel_vacuum_begin() to parallel_vacuum_init()
> > * Unify
On Thu, Dec 16, 2021 at 12:15 AM Bruce Momjian wrote:
>
> On Thu, Dec 2, 2021 at 07:19:50PM +0530, Dilip Kumar wrote:
> From the patch:
>
> > Currently, CREATE DATABASE forces a checkpoint, then copies all the files,
> > then forces another checkpoint. The comments in the createdb() function
> >
On Wed, Dec 15, 2021 at 7:21 PM Tomas Vondra
wrote:
>
> On 12/15/21 14:20, Amit Kapila wrote:
> > On Tue, Dec 14, 2021 at 7:02 AM Tomas Vondra
> > wrote:
> >>
> >> Hi,
> >>
> >> here's an updated version of the patches, dealing with almost all of the
> >> issues (at least in the 0001 and 0002
On Tuesday, December 14, 2021 12:45 AM vignesh C wrote:
> Thanks for the updated patch, few comments:
> 1) Can we change this:
> /*
> +* Report the success of table sync as one commit to consolidate all
> +* transaction stats into one record.
> +*/
> +
On Monday, December 13, 2021 6:19 PM Amit Kapila
wrote:
> On Tue, Dec 7, 2021 at 3:12 PM osumi.takami...@fujitsu.com
> wrote:
> >
>
> Few questions and comments:
>
> 1.
> The pg_stat_subscription_workers view will
> contain
> one row per subscription worker on
On Thursday, December 16, 2021 4:00 PM I wrote:
> Thank you, everyone for confirming the direction.
> I'll follow the consensus of the community and fix the patch, including other
> comments.
> I'll treat only the stats for apply workers.
Hi, created a new version v17 according to the recent
On 16.12.21 05:47, Greg Stark wrote:
In the server, the encrypted datums are stored in types called
encryptedr and encryptedd (for randomized and deterministic
encryption). These are essentially cousins of bytea.
Does that mean someone could go in with psql and select out the data
without any
> On 16 Dec 2021, at 12:11, Peter Eisentraut
> wrote:
> Could we make it write just one log file? Is having multiple log files
> better?
Having individual .txt files from checks with additional information
on how to handle the error are quite convenient when writing wrappers around
On 16.12.21 02:39, Michael Paquier wrote:
On Wed, Dec 15, 2021 at 04:13:10PM -0600, Justin Pryzby wrote:
On Wed, Dec 15, 2021 at 05:04:54PM -0500, Andrew Dunstan wrote:
The directory name needs to be predictable somehow, or maybe optionally
set as a parameter. Having just a timestamped
Le mercredi 8 décembre 2021, 22:07:12 CET Tomas Vondra a écrit :
> On 12/8/21 16:51, Ronan Dunklau wrote:
> > Le jeudi 9 septembre 2021, 15:37:59 CET Tomas Vondra a écrit :
> >> And now comes the funny part - if I run it in the same backend as the
> >>
> >> "full" benchmark, I get roughly the
>> Now, before creating tables, the ORM generates CREATE SCHEMA IF NOT
EXISTS, to ensure that the schema exists before CREATE TABLE; that's
reasonable general-purpose behavior.
>
> If the user hasn’t specified they want the schema created it’s arguable
that executing create schema anyway is
At Wed, 15 Dec 2021 17:01:24 -0800, Soumyadeep Chakraborty
wrote in
> Sure, that makes more sense. Fixed.
As I played with this briefly. I started a standby from a backup that
has an access to archive. I had the following log lines steadily.
[139535:postmaster] LOG: database system is
This rearranges the version-dependent pieces in the new more modular style.
I had originally written this before pre-9.2 support was removed and it
had a few more branches then. But I think it is still useful, and there
are some pending patches that might add more branches for newer
1 - 100 of 104 matches
Mail list logo
