On Mon, Feb 14, 2022 at 11:12 AM Bharath Rupireddy
wrote:
> > FWIW, docs need to hold to a higher standard than code comments.
>
> Thanks. In general, I agree that the docs and error/log messages
> (user-facing) need to be of higher standard, but at the same time code
> comments too IMHO. Because
On Wed, Jan 19, 2022 at 11:32 AM John Naylor
wrote:
> I don't have anything really profound to say here, but in the last
> year I did on a couple occasions recommend clients to raise
> hash_mem_multiplier to 2.0 to fix performance problems.
I would like to push ahead with an increase in the defau
(This needs rebasing)
At Wed, 9 Feb 2022 00:52:48 +, Jacob Champion wrote
in
> On Mon, 2022-02-07 at 17:29 +0900, Kyotaro Horiguchi wrote:
> > I feel this should be a part of 0001. (But the patches will be
> > finally merged so maybe no need to bother moving it).
>
> Okay. I can move it e
On Tue, Feb 15, 2022 at 11:22 AM Peter Geoghegan wrote:
>
> On Mon, Feb 14, 2022 at 8:04 PM John Naylor
> wrote:
> > The failsafe mode does disable truncation as of v14:
> >
> > commit 60f1f09ff44308667ef6c72fbafd68235e55ae27
> > Author: Peter Geoghegan
> > Date: Tue Apr 13 12:58:31 2021 -0700
On Monday, February 14, 2022 8:58 PM Amit Kapila
wrote:
> On Thu, Jan 6, 2022 at 11:23 AM osumi.takami...@fujitsu.com
> wrote:
> >
> > Kindly have a look at the attached v16.
> >
>
> Few comments:
Hi, thank you for checking the patch !
> =
> 1.
> @@ -3594,13 +3698,29 @@ ApplyWorker
On Tues, Feb 08, 2022 at 17:18 PM Kuroda, Hayato
wrote:
> I applied your patch and confirmed that codes passed regression test.
> I put a short reviewing:
Thanks for your test and review.
> ```
> + static int skipped_changes_count = 0;
> + /*
> + * Conservatively, at least 150,000 c
On Thu, Feb 3, 2022 at 2:35 PM Masahiko Sawada wrote:
>
> On Thu, Feb 3, 2022 at 1:48 PM David G. Johnston
> wrote:
> >
> > On Wednesday, February 2, 2022, Masahiko Sawada
> > wrote:
> >>
> >> and have other error
> >> information in pg_stat_subscription_workers view.
> >
> >
> > What benefit i
On Tue, Feb 15, 2022 at 12:09 PM Kyotaro Horiguchi
wrote:
>
> At Mon, 14 Feb 2022 17:20:16 -0800, Andres Freund wrote
> in
> > Hi,
> >
> > On 2021-12-22 22:34:45 +0900, Masahiko Sawada wrote:
> > > I've attached an updated patch. Please review it.
> >
> > Sorry for dropping the ball on this agai
On Mon, Feb 14, 2022 at 10:53:04AM +0900, Michael Paquier wrote:
> A last thing, that has been mentioned by Andres upthread, is that we
> should be able to remove the extra commands run with --version in the
> tests of pg_basebackup, as of the attached. I have not done that yet,
> as it seems bett
On Mon, Feb 14, 2022 at 08:35:43PM -0500, Joseph Koshakow wrote:
> Good catch, I didn't think about that. Though if you are pre-justifying
> the days, then I don't think it's possible for the second addition to
> days to overflow. The maximum amount the days field could be after
> the first justifi
On Mon, Feb 14, 2022 at 8:04 PM John Naylor
wrote:
> The failsafe mode does disable truncation as of v14:
>
> commit 60f1f09ff44308667ef6c72fbafd68235e55ae27
> Author: Peter Geoghegan
> Date: Tue Apr 13 12:58:31 2021 -0700
>
> Don't truncate heap when VACUUM's failsafe is in effect.
That's tru
On Fri, Feb 4, 2022 at 4:58 AM Robert Haas wrote:
> As I said
> before, I know TRUNCATE has been an issue in the past, and if that's
> not already fixed in v14, we should. If there's other stuff, we should
> fix that too.
The failsafe mode does disable truncation as of v14:
commit 60f1f09ff4430
On Sat, Feb 12, 2022 at 08:50:41PM -0800, Andres Freund wrote:
> On 2022-01-18 11:20:16 +0900, Michael Paquier wrote:
>> +# required for 002_pg_upgrade.pl
>> +REGRESS_SHLIB=$(abs_top_builddir)/src/test/regress/regress$(DLSUFFIX)
>> +export REGRESS_SHLIB
>
> It seems weird to propagate this into mu
Amit Kapila writes:
> On Tue, Feb 15, 2022 at 3:42 AM Tom Lane wrote:
>> ... Maybe the error message
>> could be bikeshedded ... is "non-table relation" terminology
>> that we use in user-facing messages?
> The other option could be "logical replication source relation
> \"%s.%s\" is not a tabl
Andres Freund writes:
> On February 14, 2022 12:48:12 PM PST, Tom Lane wrote:
>> We could I guess, but does it really buy anything? I'm sure that
>> some of the buildfarm still hasn't updated their Python installation,
>> but it'll be about the same failure we'd get from the final patch.
> I gu
On Tue, Feb 15, 2022 at 3:42 AM Tom Lane wrote:
>
> In [1] there's a complaint that if you try to logically replicate
> a partitioned table from v13-or-later to v12-or-earlier, you get
> "table XXX not found on publisher", which is pretty confusing
> because the publisher certainly does have such
Hi,
On 2022-02-14 14:54:41 +0530, Amit Kapila wrote:
> On Fri, Feb 11, 2022 at 4:27 PM Amit Kapila wrote:
> >
> > On Fri, Feb 11, 2022 at 12:00 PM tanghy.f...@fujitsu.com
> > wrote:
> > >
> > > Attached the patches which fixed the above two comments and the first
> > > comment in
> > > my previ
At Mon, 14 Feb 2022 17:20:16 -0800, Andres Freund wrote in
> Hi,
>
> On 2021-12-22 22:34:45 +0900, Masahiko Sawada wrote:
> > I've attached an updated patch. Please review it.
>
> Sorry for dropping the ball on this again :(. I've pushed the fix with some
> very minor polishing.
Thanks!
> > >
Hi,
On February 14, 2022 12:48:12 PM PST, Tom Lane wrote:
>Andres Freund writes:
>> On 2022-02-14 14:18:58 -0500, Tom Lane wrote:
>>> Well, it's mid-February. Do we have a python2-removal patch
>>> that's ready to go?
>
>> I can refresh mine. Iit might be good to first reapply
>> f201da39edc -
At Mon, 14 Feb 2022 20:14:11 +0530, Ashutosh Sharma
wrote in
> No, I haven't tried to compare archive recovery to PITR or vice versa,
> instead I was trying to compare crash recovery with PITR. The message
> you're emitting says just before entering into the archive recovery is
> - "reached end-
Hi,
On 2022-02-14 20:47:33 -0500, Tom Lane wrote:
> I think that most of the intellectual content in this patch is getting
> the data source nailed down, ie putting the annotations into the *nodes.h
> files and building the code to parse that. I don't have a problem
> with throwing away and rewri
On Tue, Feb 15, 2022 at 2:09 PM Ranier Vilela wrote:
> Em seg., 14 de fev. de 2022 às 21:58, Justin Pryzby
> escreveu:
>> On Mon, Feb 14, 2022 at 09:19:54PM -0300, Ranier Vilela wrote:
>> > I've reported this issue, but without success in fixing it.
>>
>> It'd be helpful to provide a link to the
Hi,
On 2022-02-14 12:45:08 -0500, Robert Haas wrote:
> On Mon, Feb 14, 2022 at 12:34 PM Tom Lane wrote:
> > * If we institute a policy that all GUCs should be PGDLLIMPORT'd,
> > how will we enforce that new patches follow that? I don't want to be
> > endlessly going back and adding forgotten PGD
Andres Freund writes:
> On 2022-02-14 18:32:21 -0500, Tom Lane wrote:
>> I think that finishing out and committing this patch is a fine step
>> on the way to that.
> I think most of gen_node_support.pl would change - a lot of that is generating
> the node functions, which would not be needed anym
On Mon, Feb 14, 2022 at 7:59 PM Nathan Bossart wrote:
> I think it's possible to avoid overflow in justify_interval() in some cases
> by pre-justifying the days. I've attached a patch to demonstrate.
>
> --
> Nathan Bossart
> Amazon Web Services: https://aws.amazon.com
Good catch, I didn't think
Hi,
On 2022-02-14 18:32:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I do however not think it's a good idea to commit something generating
> > something like the existing node functions vs going for a metadata based
> > approach at dealing with node functions. That aspect of my patchset
Hi,
On 2022-02-14 14:36:12 -0800, Andres Freund wrote:
> On 2022-02-14 15:45:40 -0500, Tom Lane wrote:
> > I tried to replicate the problem described in [1] about logical
> > replication from a v14 source DB to a v11 target. It fails as
> > described there; I've not yet tracked down why, but it l
Hi,
On 2021-12-22 22:34:45 +0900, Masahiko Sawada wrote:
> I've attached an updated patch. Please review it.
Sorry for dropping the ball on this again :(. I've pushed the fix with some
very minor polishing.
> > The attached detects that bug, but I'm not sure it's worth expending
> > test time,
Em seg., 14 de fev. de 2022 às 21:58, Justin Pryzby
escreveu:
> On Mon, Feb 14, 2022 at 09:19:54PM -0300, Ranier Vilela wrote:
> > I've reported this issue, but without success in fixing it.
>
> It'd be helpful to provide a link to the prior discussions, and summarize
> it.
>
> https://wiki.postg
On Mon, Feb 14, 2022 at 04:57:07PM -0500, Joseph Koshakow wrote:
> On Mon, Feb 14, 2022 at 2:15 PM Nathan Bossart
> wrote:
>> Makes sense. So we could likely avoid it for justify_interval, but the
>> others are at the mercy of the interval implementation.
>
> I'm not entirely sure what you mean
On Mon, Feb 14, 2022 at 07:42:21PM -0500, Bruce Momjian wrote:
> On Mon, Feb 14, 2022 at 03:23:07PM -0800, Swaha Miller wrote:
> > A prominent use case for grouping functions into modules would
> > be access control on the group as a whole, with one command
> > for an entire module instead of many
On Mon, Feb 14, 2022 at 09:19:54PM -0300, Ranier Vilela wrote:
> I've reported this issue, but without success in fixing it.
It'd be helpful to provide a link to the prior discussions, and summarize it.
https://wiki.postgresql.org/wiki/PostgreSQL_14_Open_Items
https://www.postgresql.org/message-i
On Mon, Feb 14, 2022 at 03:23:07PM -0800, Swaha Miller wrote:
> A prominent use case for grouping functions into modules would
> be access control on the group as a whole, with one command
> for an entire module instead of many individual functions. One reason
> for such a grouping is to set ACLs.
Hi,
I've reported this issue, but without success in fixing it.
Now I have installed 14.2 and used in development environment, and
the log still reports:
2022-02-13 18:33:20.502 -03 [7976] LOG: could not rename temporary
statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat":
Permi
Hi Fujii san,
Thank you for updating the patch.
I have no additional comments.
Regards,
Ryohei Takahashi
Andres Freund writes:
> I do however not think it's a good idea to commit something generating
> something like the existing node functions vs going for a metadata based
> approach at dealing with node functions. That aspect of my patchset is
> independent of the libclang vs script debate.
I thin
Hi,
On 2022-02-14 12:09:47 -0500, Tom Lane wrote:
> I'm in favor of moving forward with this. I do not like the
> libclang-based approach that Andres was pushing, because of the
> jump in developer tooling requirements that it'd cause.
FWIW, while I don't love the way the header parsing stuff in
On Thu, Feb 10, 2022 at 1:06 PM Bruce Momjian wrote:
> On Thu, Feb 10, 2022 at 08:53:15AM -0800, Swaha Miller wrote:
> > On Fri, Feb 4, 2022 at 3:51 PM Tom Lane wrote:
> >
> > Hm. If the functional requirement is "group objects without needing
> > any out-in-the-filesystem infrastructure
On Mon, 2022-02-14 at 10:42 +0100, Peter Eisentraut wrote:
> This is a rebase of the patch from [0]. It removes the internal padding
> implementation in pgcrypto and lets OpenSSL do it. The internal
> implementation was once applicable to the non-OpenSSL code paths, but
> those have since been
Hi,
On 2022-02-14 23:06:20 +0100, Peter Eisentraut wrote:
> The attached patch cleans up the xhtml namespace declarations properly, I
> think.
Looks good to me.
> For the xlink business, I don't have a better idea than you, so your
> workaround proposal seems fine.
K. Will you apply your patch
Hi,
On 2022-02-14 17:32:11 -0500, Andrew Dunstan wrote:
> About the only thing missing in your recipe is this:
Re requiring out-of-tree builds: Thomas on IM noted that there's the
NoDefaultCurrentDirectoryInExePath environment variable. That should avoid the
problem leading to requiring out-of-tr
Peter Geoghegan writes:
> It isn't actually necessary for an index AM to use the standard
> slotted page format to get the benefits that you mention, of course --
> whether or not an index AM that uses standard page headers *also* uses
> slotted pages with standard line pointers is a separate ques
On 2022-02-14 17:32:11 -0500, Andrew Dunstan wrote:
> Working on that. There appear to be some issues with third party
> libraries. I might need to rebuild libxml2 and zlib for example.
Any reason not to use the ones from msys2?
Hi,
On 2022-02-14 15:45:40 -0500, Tom Lane wrote:
> I tried to replicate the problem described in [1] about logical
> replication from a v14 source DB to a v11 target. It fails as
> described there; I've not yet tracked down why, but it looks like
> the v11 apply worker fails and closes the conne
On 2/3/22 20:51, Andres Freund wrote:
> Hi,
>
> On 2022-02-03 17:25:51 -0500, Andrew Dunstan wrote:
>> OK, I have all the pieces working and I know what I need to do to adapt
>> fairywren. The patch you provided is not necessary any more.
> Cool. Are you going to post that?
About the only thin
On Mon, Feb 14, 2022 at 2:19 PM Tom Lane wrote:
> No, at least not unless you plan to reimplement much of the WAL
> mechanism. You do need at least an LSN in the right place.
> I kinda doubt that you can get away with ignoring checksumming,
> either. On the whole, I think you'd be best off to us
On 2/14/22 16:19, Tom Lane wrote:
Chris Cleveland writes:
Can I treat pages as just a flat, open 8k buffer and fill them with
arbitrary data?
No, at least not unless you plan to reimplement much of the WAL
mechanism. You do need at least an LSN in the right place.
I kinda doubt that you can
Chris Cleveland writes:
> Can I treat pages as just a flat, open 8k buffer and fill them with
> arbitrary data?
No, at least not unless you plan to reimplement much of the WAL
mechanism. You do need at least an LSN in the right place.
I kinda doubt that you can get away with ignoring checksummin
In [1] there's a complaint that if you try to logically replicate
a partitioned table from v13-or-later to v12-or-earlier, you get
"table XXX not found on publisher", which is pretty confusing
because the publisher certainly does have such a table. That
happens because fetch_remote_table_info is t
I'm writing an index access method with its own unique file format. It
involves storing large blobs that break across pages.
The file format itself doesn't need or use page headers. There's no need
for a checksum or to manage free space within the page.
Can I treat pages as just a flat, open 8k b
On 14.02.22 18:31, Peter Eisentraut wrote:
Yeah, that is currently clearly wrong. It appears I originally copied
the wrong namespace declarations from examples that show how to
customize the DocBook stylesheets, but those examples were apparently
wrong or outdated in this respect. It seems w
On Mon, Feb 14, 2022 at 2:15 PM Nathan Bossart wrote:
> Makes sense. So we could likely avoid it for justify_interval, but the
> others are at the mercy of the interval implementation.
I'm not entirely sure what you mean by "it", but for both
justify_interval and justify_days this commit throws
On Mon, Feb 14, 2022 at 10:15 Greg Stark wrote:
>
> For now my approach is to implement a background worker that listens
> on a new port and is basically its own small web server with shared
> memory access
This reminds me bg_mon (included into Spilo, docker image used by Zalando
operator
On Tue, Feb 15, 2022 at 3:25 AM Robert Haas wrote:
> It's not real clear to me that it's worth complicating the code to
> avoid a harmless compiler warning on an 11-year-old operating system
> with minimal real-world usage. On the other hand, if you really feel
> motivated to do something about it
[ Please keep the mailing list cc'd ]
Matheus Alcantara writes:
> On Monday, February 14th, 2022 at 17:01, Tom Lane wrote:
>> What exactly is the motivation for these particular tests?
> I was studying the source code and looking for projects that I could
> contribute so I decided
> to start w
On 2/12/22 12:25, Tom Lane wrote:
>
> An even slicker answer would be to set up a PG buildfarm machine
> that, in addition to the basic tests, builds PGroonga against the
> new PG sources and runs your tests. Andrew's machine "crake" does
> that for RedisFDW and BlackholeFDW, and the source code
Andres Freund writes:
> On 2022-02-14 14:18:58 -0500, Tom Lane wrote:
>> Well, it's mid-February. Do we have a python2-removal patch
>> that's ready to go?
> I can refresh mine. Iit might be good to first reapply
> f201da39edc - "Make configure prefer python3 to plain python."
> for a few days?
I tried to replicate the problem described in [1] about logical
replication from a v14 source DB to a v11 target. It fails as
described there; I've not yet tracked down why, but it looks like
the v11 apply worker fails and closes the connection after sending
CREATE_REPLICATION_SLOT. The v14 walse
Hi,
On 2022-02-14 14:18:58 -0500, Tom Lane wrote:
> Well, it's mid-February. Do we have a python2-removal patch
> that's ready to go?
I can refresh mine. Iit might be good to first reapply
f201da39edc - "Make configure prefer python3 to plain python."
for a few days?
Greetings,
Andres Freund
Andrew made a good case above for avoiding LOG:
>I do think we should be wary of any name starting with "LOG", though.
>Long experience tells us that's something that confuses users when it
refers to the WAL.
On Sun, Feb 13, 2022 at 4:55 PM David Rowley wrote:
> FWIW, that would remove the whole point in init run-time pruning. The
> reason I made two phases of run-time pruning was so that we could get
> away from having the init plan overhead of nodes we'll never need to
> scan. If we wanted to show
So I've been dealing a lot with building and maintaining dashboards
for (fleets of) Postgres servers. And it's a pain. I have a few
strongly held ideas about where the pain points are and what the right
ways to tackle them are. Some of which are going to be controversial I
think...
The state of th
On 2/12/22 16:13, Justin Pryzby wrote:
> Is there any check for warnings from new code, other than those buildfarm
> members with -Werror ?
I had forgotten about this :-) but a few years ago I provided a
check_warnings setting (and a --check-warnings command line parameter).
It's processed if s
On Fri, Feb 11, 2022 at 10:52 PM Michael Paquier wrote:
> > And, on a related note, Michael, do you plan to get something
> > committed here?
>
> Apart from f79962d, ba5 and 50e1441, I don't think that there was
> something left to do for this thread. Perhaps I am missing something?
Oh, my m
On Mon, Feb 14, 2022 at 1:58 PM Bruce Momjian wrote:
> > I think we have consensus on STRATEGY. I'm not sure if we have
> > consensus on what the option values should be. If we had an option to
> > use fs-based cloning, that would also need to issue a checkpoint,
> > which makes me think that CHEC
Matheus Alcantara writes:
> I'm attaching a patch that add some new test cases for tab completion of psql.
What exactly is the motivation for these particular tests?
I believe that most of tab-complete.c is already covered, outside
of the giant if-else chain at the heart of psql_completion().
It
I wrote:
> Peter Eisentraut writes:
>> On 12.01.22 19:49, Tom Lane wrote:
> Anyway, getting back to the point: I think we should notify the
> owners ASAP and set a 30-day deadline.
>> Sure, let's do that. I don't have a buildfarm animal these days, so I'm
>> not on that list, so it would be gre
On Mon, Feb 14, 2022 at 01:55:56PM -0500, Tom Lane wrote:
> Nathan Bossart writes:
>> On Sun, Feb 13, 2022 at 01:28:38PM -0500, Joseph Koshakow wrote:
>>> +SELECT justify_hours(interval '2147483647 days 24 hrs');
>>> +ERROR: interval out of range
>
>> The docs [0] claim that the maximum value fo
On Mon, Feb 14, 2022 at 12:27:10PM -0500, Robert Haas wrote:
> On Mon, Feb 14, 2022 at 11:26 AM Dilip Kumar wrote:
> > So do we have consensus to use (STRATEGY = LOG/CHECKPOINT or do we
> > think that keeping it bool i.e. Is LOG_COPIED_BLOCKS a better option?
> > Once we have consensus on this I w
Nathan Bossart writes:
> On Sun, Feb 13, 2022 at 01:28:38PM -0500, Joseph Koshakow wrote:
>> +SELECT justify_hours(interval '2147483647 days 24 hrs');
>> +ERROR: interval out of range
> The docs [0] claim that the maximum value for interval is 178 million
> years, but this test case is only ~6 m
Re: Peter Eisentraut
> This adds support in the lexer as well as in the integer type input
> functions.
>
> Those core parts are straightforward enough, but there are a bunch of other
> places where integers are parsed, and one could consider in each case
> whether they should get the same treatme
On Sun, Feb 13, 2022 at 01:28:38PM -0500, Joseph Koshakow wrote:
> +SELECT justify_hours(interval '2147483647 days 24 hrs');
> +ERROR: interval out of range
The docs [0] claim that the maximum value for interval is 178 million
years, but this test case is only ~6 million. Should we instead rewor
On Mon, Feb 14, 2022 at 12:55 PM Tom Lane wrote:
> Robert Haas writes:
> > An alternative rule which would dodge that particular issue would be
> > to just slap PGDLLIMPORT on every global variable in every header
> > file. That would arguably be a simpler rule, though it means even more
> > PGDL
On Wed, Feb 9, 2022 at 5:58 PM Justin Pryzby wrote:
> FYI, it has said "while..." and hasn't said "guc" since the 2nd revision of
> the
> patch.
The v3-0001 attached above had "while... for GUC..."--sorry I wasn't clear.
In v4, the message looks fine to me for shared_preload_libraries
(except t
Andres Freund writes:
> Even just getting rid of the "Tests were run but no plan was declared and
> done_testing() was not seen." noise would be helpful. So I think using a fatal
> error routine that forced a failure to be recognized via ok(0, 'fatal error')
> and then does done_testing() would be
Robert Haas writes:
> An alternative rule which would dodge that particular issue would be
> to just slap PGDLLIMPORT on every global variable in every header
> file. That would arguably be a simpler rule, though it means even more
> PGDLLIMPORT declarations floating around.
Yeah, if the objectiv
Hi,
On 2022-02-14 18:31:25 +0100, Peter Eisentraut wrote:
> > The reason that we end up with so many more xmlns:xlink is just that without
> > our customization there ends up being a single
> > http://www.w3.org/1999/xlink"; class="index">
> > and then everything below that doesn't need the xmlns:
On Sun, Feb 13, 2022 at 6:33 PM Tom Lane wrote:
> Huh, doesn't Test::More already provide a sane way to do this?
> If not, why isn't die() good enough? (I don't think you can
> realistically expect to prohibit die() anywhere in the TAP tests.)
+1 for die. There's very little reason to use BAIL_O
Hi,
On 2022-02-14 16:08:42 +, Dagfinn Ilmari Mannsåker wrote:
> die()-ing is the correct way to abort a single test script.
There's really no way to nice way to abort without the "Dubious, test returned
255 (wstat 65280, 0xff00)" stuff?
Even just getting rid of the "Tests were run but no pla
On Mon, Feb 14, 2022 at 12:34 PM Tom Lane wrote:
> I think you are attributing straw-man positions to me. What I'd actually
> *like* is some solution that has the effect of (1) without having to mark
> up our code with a bunch of Microsoft-isms. However I don't know how to
> do that, and I do ag
On Mon, Feb 14, 2022 at 12:25 PM Chapman Flack wrote:
> On 02/14/22 11:43, Robert Haas wrote:
> > On Mon, Feb 14, 2022 at 10:38 AM Tom Lane wrote:
> >> Robert Haas writes:
> >>> I don't particularly like Chapman's solution,
> > ... and (3) is an attempt at compromise that is nobody's first choic
Robert Haas writes:
> Hmm, I guess I'd need to know who those people are in order to be able
> to review their comments. I don't *like* the extra notational cruft,
> but applying it inconsistently isn't better than being consistent. As
> I see it, we have four choices: (1) apply PGDLLIMPORT markin
On 13.02.22 21:16, Andres Freund wrote:
The reason for the two xmlns= are different. The
xmlns="http://www.w3.org/1999/xhtml"; is afaict caused by confusion on our
part.
Some of our stylesheets use
xmlns="http://www.w3.org/TR/xhtml1/transitional";
others use
xmlns="http://www.w3.org/1999/xhtml";
On Mon, Feb 14, 2022 at 11:26 AM Dilip Kumar wrote:
> So do we have consensus to use (STRATEGY = LOG/CHECKPOINT or do we
> think that keeping it bool i.e. Is LOG_COPIED_BLOCKS a better option?
> Once we have consensus on this I will make this change and
> documentation as well along with the other
On 02/14/22 11:43, Robert Haas wrote:
> On Mon, Feb 14, 2022 at 10:38 AM Tom Lane wrote:
>> Robert Haas writes:
>>> I don't particularly like Chapman's solution,
> ... and (3) is an attempt at compromise that is nobody's first choice.
Ok, I guess that's )sniffle( a pretty fair way of putting it.
Peter Eisentraut writes:
> What do people think about this patch now?
I'm in favor of moving forward with this. I do not like the
libclang-based approach that Andres was pushing, because of the
jump in developer tooling requirements that it'd cause.
Eyeballing the patch a bit, I do have some co
Hi all,
again, many thanks for the reviews and testing!
On 2/4/22 17:09, Laurenz Albe wrote:
I also see no reason to split a small patch like this into three parts.
I've split it into the three unrelated parts (code, docs, tests) to ease
review, but I happily carry it as one patch too.
In t
On Mon, Feb 14, 2022 at 10:38 AM Tom Lane wrote:
> Robert Haas writes:
> > I don't particularly like Chapman's solution, but given that you've
> > repeatedly blocked every effort to just apply PGDLLIMPORT markings
> > across the board, I'm not sure what the realistic alternative is.
>
> You do re
On Sun, Feb 13, 2022 at 10:12 AM Dilip Kumar wrote:
>
> On Sat, Feb 12, 2022 at 2:38 AM Alvaro Herrera
> wrote:
> > It seems you're thinking deciding what to do based on an option that
> > gets a boolean argument. But what about making the argument be an enum?
> > For example
> >
> > CREATE DA
Andres Freund writes:
> Hi,
>
> On 2022-02-13 18:32:59 -0500, Tom Lane wrote:
>> Andres Freund writes:
>> > Best with a
>> > central function signalling fatal error, rather than individual uses of die
>> > or such.
>>
>> Huh, doesn't Test::More already provide a sane way to do this?
>
> I looked
On Mon, Feb 14, 2022 at 9:17 PM Ashutosh Sharma wrote:
>
>
> Is it possible to see the WAL size generated by these two statements:
> UPDATE 70% of the tuple in the base table (dirty 70% of the shared
> buffers) && CREATE database using template DB (Actual test target).
> Just wanted to know if it
On Sat, Feb 12, 2022 at 1:01 AM Shinoda, Noriyoshi (PN Japan FSIP)
wrote:
> Thank you for developing a great feature.
> The current help message shown below does not seem to be able to specify the
> 'client-' or 'server-' for lz4 compression.
> --compress = {[{client, server}-]gzip, lz4, none}[:
On 14.02.22 10:14, Julien Rouhaud wrote:
Do you plan to send a rebased version of the ICU default collation
soon or should I start looking at the current v4?
I will send an updated patch in the next few days.
Hi Dilip,
On Sun, Feb 13, 2022 at 12:04 PM Dilip Kumar wrote:
>
> On Sun, Feb 13, 2022 at 10:12 AM Dilip Kumar wrote:
> >
>
> I have done performance testing with different template DB sizes and
> different amounts of dirty shared buffers and I think as expected the
> bigger the dirty shared buf
Robert Haas writes:
> I don't particularly like Chapman's solution, but given that you've
> repeatedly blocked every effort to just apply PGDLLIMPORT markings
> across the board, I'm not sure what the realistic alternative is.
You do realize that I just have one vote in these matters? If I'm
out
On Sun, Feb 13, 2022 at 3:17 PM Tom Lane wrote:
> > ...
> > ObserveTypedConfigValue("log_statement_sample_rate",
> > &samprate, &gucs_changed, SAMPRATE_CHANGED);
> > ...
>
> > and will be subscribed to have the native-format value stored into samprate,
> > and SAMPRATE_CHANGED ORed into gucs
Thomas Munro writes:
> On Mon, Feb 14, 2022 at 7:19 PM Tom Lane wrote:
>> I'm leaning to adding a compile-time clamp on the value,
>> that is
>>
>> unp->sun_len = Min(sizeof(struct sockaddr_un),
>> (1 << (sizeof(unp->sun_len) * 8)) - 1);
> Any system that has sun_le
On 2/14/22 11:22, Andrey V. Lepikhov wrote:
On 2/11/22 20:12, Tomas Vondra wrote:
On 2/11/22 05:29, Andrey V. Lepikhov wrote:
On 2/11/22 03:37, Tomas Vondra wrote:
That being said, this thread was not really about foreign partitions,
but about re-analyzing inheritance trees in general. An
Here are few comments:
+/*
+ * Verify the authenticity of the given raw WAL record.
+ */
+Datum
+pg_verify_raw_wal_record(PG_FUNCTION_ARGS)
+{
Do we really need this function? I see that whenever the record is
read, we verify it. So could there be a scenario where any of these
functions would re
Thanks for working on my review comments. I'll take a look at the new
changes and let you know my comments, if any. I didn't get a chance to
check it out today as I was busy reviewing some other patches, but
I'll definitely take a look at the new patch in a day or so and let
you know my feedback.
1 - 100 of 128 matches
Mail list logo
