On Mon, 2022-11-07 at 22:43 -0500, Bruce Momjian wrote:
> > I thought some more about the patch, and I don't like the title
> > "Transaction Management" for the new chapter. I'd expect some more
> > from a chapter titled "Internals" / "Transaction Management".
> >
> > In reality, the new chapter
On 2022-Nov-09, Michael Paquier wrote:
> I got to look at that, now that the minor releases have been tagged,
> and the change has no conflicts down to 9.3. 9.2 needed a slight
> tweak, though, but it seemed fine as well. (Tested the build on all
> branches.) So done all the way down, sticking
I don't think walsenders fetching segment from archive is totally
stupid. With that feature, we can use fast and expensive but small
storage for pg_wal, while avoiding replciation from dying even in
emergency.
At Tue, 8 Nov 2022 19:39:58 -0800, sirisha chamarthi
wrote in
> > If it's a streaming
On Tue, Nov 8, 2022 at 3:18 AM Nathan Bossart wrote:
>
> The call to snprintf() should take care of adding a terminating null byte
> in the right place.
Ah, my bad. MemSet is avoided in v5 patch setting only the first byte.
> > So, IIUC, your point here is what if the copy_file fails to create t
On Wed, Nov 9, 2022 at 2:02 PM Kyotaro Horiguchi
wrote:
>
> I don't think walsenders fetching segment from archive is totally
> stupid. With that feature, we can use fast and expensive but small
> storage for pg_wal, while avoiding replciation from dying even in
> emergency.
It seems like a usefu
On Sun, 06 Nov 2022 12:54:17 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> >> The attached patch tries to add comments explaining it on the functions.
>
> > I forward it to the hackers list because the patch is to fix comments.
>
> What do you think of the attached wording?
It looks good to m
On Wed, Nov 9, 2022 at 3:00 PM Bharath Rupireddy
wrote:
>
> On Wed, Nov 9, 2022 at 2:02 PM Kyotaro Horiguchi
> wrote:
> >
> > I don't think walsenders fetching segment from archive is totally
> > stupid. With that feature, we can use fast and expensive but small
> > storage for pg_wal, while avoi
On Tue, Nov 1, 2022 at 12:46 PM Bharath Rupireddy
wrote:
>
> > Updated patch attached.
>
> Thanks. It looks good to me. However, some minor comments on the v3 patch:
>
> 1.
> -if (MyProc->lwWaiting)
> +if (MyProc->lwWaiting != LW_WS_NOT_WAITING)
> elog(PANIC, "queueing for lock wh
On Wed, Nov 9, 2022 at 3:53 PM Amit Kapila wrote:
>
> On Wed, Nov 9, 2022 at 3:00 PM Bharath Rupireddy
> wrote:
> >
> > On Wed, Nov 9, 2022 at 2:02 PM Kyotaro Horiguchi
> > wrote:
> > >
> > > I don't think walsenders fetching segment from archive is totally
> > > stupid. With that feature, we ca
On 2022-11-06 Su 08:51, Álvaro Herrera wrote:
> On 2022-Jun-14, Andrew Dunstan wrote:
>
>> OK, here's a more principled couple of patches. For config_data, if you
>> give multiple options it gives you back the list of values. If you don't
>> specify any, in scalar context it just gives you back a
On Fri, Nov 4, 2022 at 1:40 PM sirisha chamarthi
wrote:
>
Is the intent of setting restart_lsn to InvalidXLogRecPtr was to
disallow reviving the slot?
>
I think the intent is to compute the correct value for
replicationSlotMinLSN as we use restart_lsn for it and using the
invalidated slot's rest
Commit b7eda3e0e3 moves XidINMVCCSnapshot into snapmgr.{c,h},
however, it forgets the declaration of XidINMVCCSnapshot in
heapam.h.
Attached removes the redundant declaration in heapam.h.
--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.
>From 16f4bd33d7886c872319393dfebb5dd5
On Mon, Nov 7, 2022 at 1:46 PM Peter Smith wrote:
>
> Here are my review comments for v42-0001
...
...
>
> 8.
>
> + /*
> + * Resend the pending message to parallel apply worker to cleanup the
> + * queue. Note that parallel apply worker will just ignore this message
> + * as it has already handled
Hello
I gave this series a quick look. Overall it seems a good idea, since
the issue of newlines-or-not is quite bothersome for the libpq
translations.
> +/*
> + * Append a formatted string to the given buffer, after translation. A
> + * newline is automatically appended; the format should not
On Wed, Nov 9, 2022 at 5:08 AM David Christensen
wrote:
>
> Enclosed is v6, which squashes your refactor and adds the additional
> recent suggestions.
Thanks for working on this feature. Here are some comments for now. I
haven't looked at the tests, I will take another look at the code and
tests
Hi Andres,
Thanks for looking at this and for the feedback. Responses inline below.
On Fri, 2022-11-04 at 19:41 -0700, Andres Freund wrote:
> Hi,
>
> On 2022-11-04 08:56:13 -0400, Reid Thompson wrote:
>
> I'm not convinced that counting DSM values this way is quite right.
> There are a few uses
Hi Himanshu,
> Test cases are now part of this v6 patch.
I believe the patch is in pretty good shape now. I'm going to change
its status to "Ready for Committer" soon unless there are going to be
any objections.
--
Best regards,
Aleksander Alekseev
On Wed, Nov 09, 2022 at 06:00:40PM +0530, Bharath Rupireddy wrote:
> On Wed, Nov 9, 2022 at 5:08 AM David Christensen
> wrote:
> >
> > Enclosed is v6, which squashes your refactor and adds the additional
> > recent suggestions.
>
> Thanks for working on this feature. Here are some comments for n
On Mon, Nov 7, 2022 at 5:04 PM Laurenz Albe wrote:
>
> On Sat, 2022-11-05 at 10:08 +, Simon Riggs wrote:
> > Agreed; new compilation patch attached, including mine and then
> > Robert's suggested rewordings.
>
> Thanks. There is clearly a lot of usefule information in this.
>
> Some comments:
This arose during the review of another patch.
We often omit the default case of a switch statement to allow the
compiler to complain if an enum case has been missed. I found a few
where that wasn't done yet, but it would make sense and would have found
an omission in another patch.From 37a03
Hi Melanie,
Thank you for looking at this and for the feedback. Responses inline
below.
On Mon, 2022-11-07 at 16:17 -0500, Melanie Plageman wrote:
> On Fri, Nov 04, 2022 at 08:56:13AM -0400, Reid Thompson wrote:
> > From a8de5d29c0c6f10962181926a49ad4fec1e52bd1 Mon Sep 17 00:00:00
> > 2001
> > Fro
While looking through vacuum code, I noticed that
unlike non-parallel vacuum, parallel vacuum only gets
a failsafe check after an entire index cycle completes.
In vacuumlazy.c, lazy_check_wraparound_failsafe is checked
after every index completes, while in parallel, it is checked
after an entire i
On 2022-Nov-09, Justin Pryzby wrote:
> On Wed, Nov 09, 2022 at 06:00:40PM +0530, Bharath Rupireddy wrote:
> > 1. For ease of review, please split the test patch to 0002.
>
> This is just my opinion, but .. why ? Since it's easy to
> filter/skip/display a file, I don't think it's usually useful
Hi,
2022-11-09 08:54:54 -0500, Reid Thompson wrote:
> Thanks for looking at this and for the feedback. Responses inline below.
> > > +void
> > > +pgstat_report_backend_allocated_bytes_decrease(uint64
> > > deallocation)
> > > +{
> > > + volatile PgBackendStatus *beentry = MyBEEntry;
> > > +
Yugo NAGATA writes:
> Tom Lane wrote:
>> What do you think of the attached wording?
> It looks good to me. That describes the expected behaviour exactly.
Pushed that, then.
>> I don't think the pipeline angle is of concern to anyone who might be
>> reading these comments with the aim of unders
Peter Eisentraut writes:
> This has broken the following use:
> parse: create temporary table t1 (a int) on commit drop
> bind
> execute
> parse: analyze t1
> bind
> execute
> parse: select * from t1
> bind
> execute
> sync
> I think the behavior of IsInTransactionBlock() needs to be further
>
On 08.08.22 17:21, Yugo NAGATA wrote:
In fact, the result of IsInTransactionBlock does not make senses at
all in pipe-line mode regardless to the fix. ANALYZE could commit all
previous commands in pipelining, and this may not be user expected
behaviour.
This seems pretty much isomorphic to the f
Simon Riggs writes:
> Karina's changes make sense to me, so +1.
> This is a minor patch, so I will set this as Ready For Committer.
Pushed with minor fiddling:
* I concur with Karina's thought that ERRCODE_WRONG_OBJECT_TYPE
is the most on-point errcode for this. The complaint is specifically
ab
On 2022-Nov-09, Japin Li wrote:
> Commit b7eda3e0e3 moves XidINMVCCSnapshot into snapmgr.{c,h},
> however, it forgets the declaration of XidINMVCCSnapshot in
> heapam.h.
True. Pushed, thanks.
--
Álvaro HerreraBreisgau, Deutschland — https://www.EnterpriseDB.com/
#error "Operator live
Hi,
On 2022-11-09 15:54:16 +0530, Bharath Rupireddy wrote:
> On Tue, Nov 1, 2022 at 12:46 PM Bharath Rupireddy
> wrote:
> >
> > > Updated patch attached.
> >
> > Thanks. It looks good to me. However, some minor comments on the v3 patch:
> >
> > 1.
> > -if (MyProc->lwWaiting)
> > +if (MyPr
And now a version of the patch including documentation and regression tests.
Anything you see I should improve ?
--strk;
On Fri, Nov 04, 2022 at 06:31:58PM +0100, Sandro Santilli wrote:
> On Mon, Oct 31, 2022 at 01:55:05AM -0400, Regina Obe wrote:
> >
> > Sandro, can you submit an updated versio
>
> After considering this again, I decided to brute-force this and get rid
> of all the trivial wrapper functions and also several of the special
> cases. That way, there is less confusion at the call sites about why
> this or that style is used in a particular case. Also, it now makes
> sure yo
Peter Eisentraut wrote:
> Is there a use case for a global setting?
I assume that we may sometimes want to use the
extended protocol on all queries of a script, like
pgbench does with --protocol=extended.
Outside of psql, it's too complicated to parse a SQL script to
replace the end-of-qu
On 2022-11-08 18:28:08 -0800, Andres Freund wrote:
> On 2022-11-07 21:36:33 -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2022-11-07 12:52:25 -0500, Tom Lane wrote:
> > >> How about instead allowing the segment size to be set in pages?
> >
> > > In addition or instead of --with-segsiz
Andres Freund writes:
> A second question: Both autoconf and meson print the segment size as GB right
> now. Obviously that'll print out a size of 0 for a segsize < 1GB.
> The easiest way to would be to just display the number of blocks, but that's
> not particularly nice.
Well, it would be fine
On Wed, Nov 9, 2022 at 6:30 AM Bharath Rupireddy
wrote:
>
> On Wed, Nov 9, 2022 at 5:08 AM David Christensen
> wrote:
> >
> > Enclosed is v6, which squashes your refactor and adds the additional
> > recent suggestions.
>
> Thanks for working on this feature. Here are some comments for now. I
> ha
> > 6.
> > +if (dir_status == 0 && mkdir(config.save_fpw_path, 0700) < 0)
> > Use pg_dir_create_mode instead of hard-coded 0007?
>
> I think I thought of that when I first looked at the patch ... but, I'm
> not sure, since it says:
>
> src/include/common/file_perm.h-/* Modes for creating d
Hi,
On 2022-11-09 14:44:42 -0500, Tom Lane wrote:
> Andres Freund writes:
> > A second question: Both autoconf and meson print the segment size as GB
> > right
> > now. Obviously that'll print out a size of 0 for a segsize < 1GB.
>
> > The easiest way to would be to just display the number of b
On Wed, Nov 9, 2022 at 2:08 PM David Christensen
wrote:
> Justin sez:
> > I was wondering if there's any reason to do "CREATE DATABASE". The vast
> > majority of TAP tests don't.
> >
> > $ git grep -ho 'safe_psql[^ ]*' '*pl' |sort |uniq -c |sort -nr |head
> >1435 safe_psql('postgres',
> >
On Thu, Nov 03, 2022 at 09:55:22AM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On 01.11.22 09:15, Tom Lane wrote:
> >> Agreed that the libpq manual is not the place for this, but I feel
> >> like it will also be clutter in "Data Types". Perhaps we should
> >> invent a new appendix or th
Peter Eisentraut writes:
> On 11.10.22 18:04, Tom Lane wrote:
>> Hmm ... the individual allocators have that info, but mcxt.c doesn't
>> have access to it. I guess we could invent an additional "method"
>> to return the requested size of a chunk, which is only available in
>> MEMORY_CONTEXT_CHECK
On Wed, Nov 9, 2022 at 6:29 AM Imseih (AWS), Sami wrote:
> When a user is running a parallel vacuum and the vacuum is long running
>
> due to many large indexes, it would make sense to check for failsafe earlier.
It makes sense to prefer consistency here, I suppose. The reason why
we're not consi
Hi,
To start with: I think this is an extremely helpful and important
feature. Both for checking production systems and for finding problems during
development.
> From 08fe01f5073c0a850541265494bb4a875bec7d3f Mon Sep 17 00:00:00 2001
> From: Himanshu Upadhyaya
> Date: Fri, 30 Sep 2022 17:44:56
On Mon, Nov 7, 2022 at 5:19 PM Peter Smith wrote:
> On Mon, Nov 7, 2022 at 5:50 AM Tom Lane wrote:
> >
> > Peter Smith writes:
> > > Sorry, I forgot the attachments in the previous post. PSA.
> >
> > I spent a bit of time looking at this. I agree that a lot of the
> > current ordering choices
On Wed, Nov 9, 2022 at 2:08 PM Andres Freund wrote:
> To start with: I think this is an extremely helpful and important
> feature. Both for checking production systems and for finding problems during
> development.
+1.
It's painful to get this in, in part because we now have to actually
decide w
Hi,
On 2022-11-09 15:03:39 -0800, Peter Geoghegan wrote:
> > > + /*
> > > + * Add a line pointer offset to the predecessor
> > > array if xmax is
> > > + * matching with xmin of next tuple (reaching via
> > > its t_ctid).
> > > +
Hi,
On 2022-11-08 13:08:45 -0500, Tom Lane wrote:
> I happened to notice that these lists of supported versions haven't
> been updated in a good long time:
>
> PGAC_PATH_PROGS(LLVM_CONFIG, llvm-config llvm-config-7 llvm-config-6.0
> llvm-config-5.0 llvm-config-4.0 llvm-config-3.9)
>
> PGAC_
Inspired by a recent posting on Slack...
diff --git a/doc/src/sgml/limits.sgml b/doc/src/sgml/limits.sgml
index d5b2b627dd..5d68eef093 100644
--- a/doc/src/sgml/limits.sgml
+++ b/doc/src/sgml/limits.sgml
@@ -97,6 +97,13 @@
32
can be increased by recompiling
PostgreSQL
+
+
+pa
On 2022-11-09 09:38:08 -0800, Andres Freund wrote:
> I'm on a hike, without any connectivity, Thu afternoon - Sun. I think it's OK
> to push it to HEAD if I get it done in the next few hours. Bigger issues,
> which I do not expect, should show up before tomorrow afternoon. Smaller
> things could wa
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
PURPOSE:
This feature is intended to allow projects with m
On Wed, Nov 09, 2022 at 12:09:01PM +0800, Julien Rouhaud wrote:
> On Wed, Nov 09, 2022 at 09:51:17AM +0900, Michael Paquier wrote:
>> Julien, please note that this is waiting on author for now. What do
>> you think about the now-named v18-0001 and the addition of an
>> ErrorContextCallback to prov
On Wed, Nov 9, 2022 at 4:15 PM Andres Freund wrote:
> To me this is extending the problem into more areas rather than reducing
> it. I'd have *zero* confidence in any warnings that amcheck issued that
> involved <9.4 special cases.
Maybe you would at first. But then we get to learn what mistake w
Hi,
On 2022-11-09 17:32:46 -0800, Peter Geoghegan wrote:
> > The xmin horizon is very coarse grained. Just because it is 7 doesn't mean
> > that xid 10 is still running. All it means that one backend or slot has an
> > xmin or xid of 7.
>
> Of course that's true. But I wasn't talking about the ge
Hi,
And thinking about it, it'd be quite bad if the horizon worked that way. You
can easily construct a workload where every single xid would "skewer" some
chain, never allowing the horizon to be raised.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Wed, Nov 9, 2022 at 5:46 PM Andres Freund wrote:
> > Putting all 3 together: doesn't it seem quite likely that the way that
> > we compute OldestXmin is the factor that prevents "skewering" of an
> > update chain? What else could possibly be preventing corruption here?
> > (Theoretically it mig
Attached some new patches. I think you were right that the API of
pg_strcoll() was strange before, so I changed it to:
* pg_strcoll() takes nul-terminated arguments
* pg_strncoll() takes arguments and lengths
The new pg_strcoll()/pg_strncoll() api in 0001 seems much reasonable to
support in t
On Wed, Nov 9, 2022 at 6:10 PM Andres Freund wrote:
> And thinking about it, it'd be quite bad if the horizon worked that way. You
> can easily construct a workload where every single xid would "skewer" some
> chain, never allowing the horizon to be raised.
Your whole scenario is one involving
I think I had brought this up a while ago, but I forget what the opinion was
on the matter.
PostGIS has a number of extensions that rely on it. For the extensions that
are packaged with PostGIS, we force them all into the same schema except for
the postgis_topology and postgis_tiger_geocoder exte
"Regina Obe" writes:
> My proposal is this. If you think it's a good enough idea I can work up a
> patch for this.
> Extensions currently are allowed to specify a requires in the control file.
> I propose to use this information, to allow replacement of phrases
> @extschema_nameofextension@ as a
On Tue, Nov 01, 2022 at 12:42:47PM +0100, Daniel Verite wrote:
> It's a follow up to the discussion at [1]. Since this discussion
> already has a slot in the CF [2] with a committed patch, let's start a
> new separate thread.
+psql_like($node, "SELECT 'one' \\g | cat >$g_file", qr//, "one command
> "Regina Obe" writes:
> > My proposal is this. If you think it's a good enough idea I can work
> > up a patch for this.
> > Extensions currently are allowed to specify a requires in the control
file.
> > I propose to use this information, to allow replacement of phrases
> > @extschema_nameofexte
On Wed, 09 Nov 2022 11:17:29 -0500
Tom Lane wrote:
> Yugo NAGATA writes:
> > Tom Lane wrote:
> >> What do you think of the attached wording?
>
> > It looks good to me. That describes the expected behaviour exactly.
>
> Pushed that, then.
Thank you.
> >> I don't think the pipeline angle is o
On Tue, Oct 18, 2022 at 05:17:32PM +1100, Peter Smith wrote:
> I re-tested and confirm that the patch does indeed fix the quirk I'd
> previously reported.
>
> But, looking at the patch code, I don't know if it is the best way to
> fix the problem or not. Someone with more experience of the
> tab-c
On Tue, Oct 18, 2022 at 04:55:46AM +0200, Laurenz Albe wrote:
> I tend to agree with you. It is easy to break PostgreSQL by manipulating
> or removing "backup_label", and copying a file from the WAL archive and
> renaming it to "backup_label" sounds like a footgun of the first order.
> There is no
On Wed, 09 Nov 2022 11:38:05 -0500
Tom Lane wrote:
> Peter Eisentraut writes:
> > This has broken the following use:
>
> > parse: create temporary table t1 (a int) on commit drop
> > bind
> > execute
> > parse: analyze t1
> > bind
> > execute
> > parse: select * from t1
> > bind
> > execute
> >
On Wed, Apr 13, 2022 at 03:51:30PM +0400, Pavel Borisov wrote:
> Only one thing to note. Maybe it would be good not to copy-paste Assert
> after every call of SimpleLruInit, putting it into the wrapper function
> instead. So the test can call calling the inner function (without assert)
> and all ot
On Tue, Nov 1, 2022 at 2:37 PM Thomas Munro wrote:
> Memory alignment patches:
>
> Direct I/O generally needs to be done to/from VM page-aligned
> addresses, but only "standard" 4KB pages, even when larger VM pages
> are in use (if there is an exotic system where that isn't true, it
> won't work)
On Wed, 2022-11-09 at 09:16 -0500, Robert Treat wrote:
> On Mon, Nov 7, 2022 at 5:04 PM Laurenz Albe wrote:
> > Some comments:
> >
>
> > > --- a/doc/src/sgml/ref/release_savepoint.sgml
> > > +++ b/doc/src/sgml/ref/release_savepoint.sgml
> > > @@ -34,23 +34,16 @@ RELEASE [ SAVEPOINT ]
> > > save
68 matches
Mail list logo
