On Thu, Jun 30, 2022 at 04:26:54PM -0700, Jacob Champion wrote:
> Yeah, maybe it'd be better to tell the user the correct context for an
> otherwise-valid option ("the 'sslcert' option may only be applied to
> USER MAPPING"), and avoid the option dump entirely?
Yes, that would be nice. Now, this
On Mon, Jul 18, 2022 at 03:11:51PM +0800, Julien Rouhaud wrote:
> So first, even if we can test 99% of the features with just testing the views
> output, I think it's should use the TAP framework since the tests will have to
> mess with the pg_ident/pg_hba files. It's way easier to modify the auth
At Wed, 13 Jul 2022 18:54:45 -0500, Justin Pryzby wrote
in
> On Thu, Jul 14, 2022 at 08:46:02AM +0900, Michael Paquier wrote:
> > On Wed, Jul 13, 2022 at 12:30:00PM -0500, Justin Pryzby wrote:
> > > How did you make this list ? Was it by excluding things that failed for
> > > you ?
Yes. I did
Thanks a lot for the feedback Nathan.
Taking your options into consideration, for me the correct behaviour should
be:
- The ALTER ROLE placeholder should always be stored with a PGC_USERSET
GucContext. It's a placeholder anyway, so it should be the less restrictive
one. If the user wants to defin
On Tue, Jul 19, 2022 at 4:54 PM Michael Paquier wrote:
> Do you still need HAVE_DECL_FDATASYNC?
I guess so, because that is currently used for macOS, and with this
patch would also be used to control the declaration for Windows. The
alternative would be to explicitly test for WIN32 or __darwin__
On Mon, Jul 18, 2022 at 05:14:00PM +, Justin Kwan wrote:
> Thank you for taking a look at this and that sounds good. I will
> send over a patch compatible with Postgres v16.
+$node_2->psql(
+ 'postgres',
+ "SELECT extract(epoch from modification) FROM
pg_stat_file('pg_wal/0001
On Tue, Jul 19, 2022 at 1:22 PM Tom Lane wrote:
>
> Bruce Momjian writes:
> > On Sat, Jul 16, 2022 at 10:53:17AM +0200, Peter Eisentraut wrote:
> >> Maybe this whole notion that "system views" is one thing is not suitable.
>
> > Are you thinking we should just call the chapter "System Catalogs an
On Mon, Jul 18, 2022 at 03:26:36PM +1200, Thomas Munro wrote:
> My plan now is to commit this patch so that problem #1 is solved, prod
> conchuela's owner to upgrade to solve #2, and wait until Tom shuts
> down prairiedog to solve #3. Then we could consider removing the
> HAVE_FDATASYNC probe and
On Tue, Jul 19, 2022 at 6:34 AM Masahiko Sawada wrote:
>
> On Mon, Jul 18, 2022 at 1:12 PM Amit Kapila wrote:
> >
> > On Fri, Jul 15, 2022 at 8:09 PM Masahiko Sawada
> > wrote:
> > >
> > > This patch should have the fix for the issue that Shi yu reported. Shi
> > > yu, could you please test it
(Mmm. I haven't noticed an annoying misspelling in the subejct X( )
> Thank you for checking that! It got a wider attack by b0a55e4329
> (RelFileNumber). The commit message suggests "relfilenode" as files
Then, now I stepped on my own foot. Rebased also on nodefuncs
autogeneration.
regards.
--
On Tue, Jul 19, 2022 at 9:11 AM Masahiko Sawada
wrote:
> I’d like to keep the first version simple. We can improve it and add
> more optimizations later. Using radix tree for vacuum TID storage
> would still be a big win comparing to using a flat array, even without
> all these optimizations. In
On Mon, Jul 18, 2022 at 9:10 PM John Naylor
wrote:
> On Tue, Jul 19, 2022 at 9:24 AM Andres Freund wrote:
> > FWIW, I think the best path forward would be to do something similar to the
> > simplehash.h approach, so it can be customized to the specific user.
>
> I figured that would come up at so
On Mon, Jul 18, 2022 at 09:26:53PM -0500, Justin Pryzby wrote:
> Sorry, I meant to send this earlier..
No problem.
> It looks like you named the table "toast_relfilenodes", but then also store
> to it data for non-toast tables.
How about naming that index_relfilenodes? One difference with what
On Tue, Jul 19, 2022 at 9:24 AM Andres Freund wrote:
> FWIW, I think the best path forward would be to do something similar to
the
> simplehash.h approach, so it can be customized to the specific user.
I figured that would come up at some point. It may be worth doing in the
future, but I think it
On Mon, Jul 18, 2022 at 8:55 PM Tom Lane wrote:
> Um ... you seem to have removed some useful comments?
I don't think that the stuff about making them into a GUC is useful myself.
> Personally I wouldn't do this, as I don't think the renaming
> brings much benefit, and it will create a hazard fo
Peter Geoghegan writes:
> I propose to rename some of the rel truncation related constants at
> the top of vacuumlazy.c, per the attached patch. The patch
> consolidates related constants into a single block/grouping, and
> imposes a uniform naming scheme.
Um ... you seem to have removed some use
I propose to rename some of the rel truncation related constants at
the top of vacuumlazy.c, per the attached patch. The patch
consolidates related constants into a single block/grouping, and
imposes a uniform naming scheme.
--
Peter Geoghegan
0001-vacuumlazy.c-rename-rel-truncation-constants.p
On Sun, Jul 17, 2022 at 10:58:26AM +0100, Simon Riggs wrote:
> Sounds great, looks fine. Thanks for your review.
Ok, cool. At the end, I have decided to split the tests and the main
patch into two different commits, as each is useful on its own. Doing
so also helps in seeing the difference of be
On Mon, Jul 18, 2022 at 8:16 PM Bruce Momjian wrote:
> On Mon, Jul 18, 2022 at 07:39:55PM -0700, David G. Johnston wrote:
> > On Mon, Jul 18, 2022 at 6:27 PM Japin Li wrote:
> >
> >
> > +0.90
> >
> > Consider changing:
> >
> > "makes any base backups taken before this unusable"
> >
> > to:
> >
>
On Mon, Jul 18, 2022 at 07:39:55PM -0700, David G. Johnston wrote:
> On Mon, Jul 18, 2022 at 6:27 PM Japin Li wrote:
>
>
> +0.90
>
> Consider changing:
>
> "makes any base backups taken before this unusable"
>
> to:
>
> "makes existing base backups unusable"
>
> As I try to justify this, th
Hi,
On 2022-07-18 19:47:39 -0700, David G. Johnston wrote:
> On Thu, Jul 14, 2022 at 4:31 PM Andres Freund wrote:
> > It might make sense to still say semi-accurate, but adjust the explanation
> > to
> > say that stats reporting is not instantaneous?
> >
> >
> Unless that delay manifests in execu
At Tue, 5 Jul 2022 11:32:42 -0700, Jacob Champion
wrote in
> On Thu, Mar 31, 2022 at 11:53 PM Kyotaro Horiguchi
> wrote:
> > So this is that. v5 creates a regular snapshot.
>
> This patch will need a quick rebase over 905c020bef9, which added
> `extern` to several missing locations.
Thanks! J
On Thu, Jul 14, 2022 at 4:31 PM Andres Freund wrote:
> Hi,
>
> I had missed David's original email on this topic...
>
> On 2022-07-14 18:58:09 -0400, Bruce Momjian wrote:
> > On Wed, Apr 20, 2022 at 04:40:44PM -0700, David G. Johnston wrote:
> > > The new cumulative stats subsystem no longer has
On Tue, Jul 19, 2022 at 10:58 AM Thomas Munro wrote:
> Here's a patch.
I added this to the next commitfest, and cfbot promptly told me about
some warnings I needed to fix. That'll teach me to post a patch
tested with "ci-os-only: windows". Looking more closely at some error
messages that report
On Mon, Jul 18, 2022 at 6:27 PM Japin Li wrote:
>
> On Tue, 19 Jul 2022 at 03:58, Bruce Momjian wrote:
> > On Fri, Jul 15, 2022 at 09:29:20PM +0800, Japin Li wrote:
> >>
> >> On Fri, 15 Jul 2022 at 08:49, Bruce Momjian wrote:
> >> > On Tue, Jul 5, 2022 at 08:02:33PM -0400, Tom Lane wrote:
> >>
Sorry, I meant to send this earlier..
On Sun, Jul 17, 2022 at 03:19:47PM +0900, Michael Paquier wrote:
> The second thing is test coverage. Using a REINDEX DATABASE/SYSTEM
> +my $catalog_toast_index = $node->safe_psql('postgres',
> + "SELECT indexrelid::regclass FROM pg_index WHERE indrelid
Hi,
On 2022-07-08 11:09:44 +0900, Masahiko Sawada wrote:
> I think that at this stage it's better to define the design first. For
> example, key size and value size, and these sizes are fixed or can be
> set the arbitary size? Given the use case of buffer mapping, we would
> need a wider key to st
On Thu, Jul 14, 2022 at 1:17 PM John Naylor
wrote:
>
> On Tue, Jul 12, 2022 at 8:16 AM Masahiko Sawada wrote:
>
> > > > I think that at this stage it's better to define the design first. For
> > > > example, key size and value size, and these sizes are fixed or can be
> > > > set the arbitary siz
On Mon, Jul 18, 2022 at 01:53:21PM +0300, Alexander Korotkov wrote:
> Looks good to me as well. I'm going to push this if no objections.
FWIW, I find the extra mention of PGOPTIONS with the specific point of
table AMs added within the part of the environment variables a bit
confusing, because we
On Mon, Jul 18, 2022 at 9:58 AM Andres Freund wrote:
> > 0001 is just boilerplate, same as v1
>
> If we were to go for this, I wonder if we should backpatch the cast
containing
> version of GESTRUCT for less pain backpatching bugfixes. That'd likely
require
> using a different name for the cast c
On Tue, 19 Jul 2022 at 03:58, Bruce Momjian wrote:
> On Fri, Jul 15, 2022 at 09:29:20PM +0800, Japin Li wrote:
>>
>> On Fri, 15 Jul 2022 at 08:49, Bruce Momjian wrote:
>> > On Tue, Jul 5, 2022 at 08:02:33PM -0400, Tom Lane wrote:
>> >> "Precondition" is an overly fancy word that makes things
> Increase hash_mem_multiplier default to 2.0 (Peter Geoghegan)
> This allows query hash operations to use double the amount of work_mem memory
> as other operations.
I wonder if it's worth pointing out that a query may end up using not just 2x
more memory (since work_mem*hash_mem_multiplier is p
Bruce Momjian writes:
> On Sat, Jul 16, 2022 at 10:53:17AM +0200, Peter Eisentraut wrote:
>> Maybe this whole notion that "system views" is one thing is not suitable.
> Are you thinking we should just call the chapter "System Catalogs and
> Views" and just place them alphabetically in a single ch
On Mon, Jul 18, 2022 at 12:28 PM shiy.f...@fujitsu.com
wrote:
>
> On Fri, Jul 15, 2022 10:39 PM Masahiko Sawada wrote:
> >
> > This patch should have the fix for the issue that Shi yu reported. Shi
> > yu, could you please test it again with this patch?
> >
>
> Thanks for updating the patch!
> I
On Tue, Jul 19, 2022 at 8:15 AM Martin Kalcher
wrote:
> Am 18.07.22 um 21:29 schrieb Tom Lane:
> > The preferred thing to do is to add it to our "commitfest" queue,
> > which will ensure that it gets looked at eventually. The currently
> > open cycle is 2022-09 [1] (see the "New Patch" button the
On Mon, Jul 18, 2022 at 1:12 PM Amit Kapila wrote:
>
> On Fri, Jul 15, 2022 at 8:09 PM Masahiko Sawada wrote:
> >
> > This patch should have the fix for the issue that Shi yu reported. Shi
> > yu, could you please test it again with this patch?
> >
>
> Can you explain the cause of the failure and
On Tue, Jul 19, 2022 at 1:30 AM Tom Lane wrote:
> Alvaro Herrera writes:
> > On 2022-Jul-18, Richard Guo wrote:
> >> BTW, not related to this patch, the new lines for parallel_aware check
> >> in setrefs.c are very wide. How about wrap them to keep consistent with
> >> arounding codes?
>
> > Not
On Sat, Jul 16, 2022 at 10:53:17AM +0200, Peter Eisentraut wrote:
> Now that I see the result, I don't think this is really the right
> improvement yet.
>
> The new System Views chapter lists views that are effectively quasi-system
> catalogs, such as pg_shadow or pg_replication_origin_status -- t
On Fri, Jul 01, 2022 at 04:40:27PM -0700, Nathan Bossart wrote:
> On Sun, Jun 05, 2022 at 11:20:38PM -0500, Steve Chavez wrote:
>> However, defining placeholders at the role level require superuser:
>>
>> alter role myrole set my.username to 'tomas';
>> ERROR: permission denied to set paramet
On Fri, May 13, 2022 at 09:10:52AM -0400, Robert Haas wrote:
> I suggest that if log_startup_progress_interval doesn't meet your
> needs here, we should try to understand why not and maybe enhance it,
> instead of adding a separate facility.
+1. AFAICT it should be possible to make the log_startu
On Wed, Dec 15, 2021 at 11:32 PM Juan José Santamaría Flecha
wrote:
> On Sun, May 16, 2021 at 6:29 AM Noah Misch wrote:
>> On Mon, Apr 19, 2021 at 05:42:51PM +1200, Thomas Munro wrote:
>> > The question we asked ourselves
>> > multiple times in the other thread was how we're supposed to get to
>>
On 7/18/22 15:32, Justin Pryzby wrote:
> On Mon, Jul 18, 2022 at 12:00:01PM -0700, Jacob Champion wrote:
>> And thank you for speaking up so quickly! It's a lot easier to undo
>> partial damage :D (Speaking of which: where is that CF update stream you
>> mentioned?)
>
> https://commitfest.postgres
Am 19.07.22 um 00:18 schrieb Tom Lane:
Independently of the dimensionality question --- I'd imagined that
array_sample would select a random subset of the array elements
but keep their order intact. If you want the behavior shown
above, you can do array_shuffle(array_sample(...)). But if we
ra
"David G. Johnston" writes:
> On Mon, Jul 18, 2022 at 3:18 PM Tom Lane wrote:
>> Independently of the dimensionality question --- I'd imagined that
>> array_sample would select a random subset of the array elements
>> but keep their order intact. If you want the behavior shown
>> above, you can
On Mon, Jul 18, 2022 at 12:00:01PM -0700, Jacob Champion wrote:
> And thank you for speaking up so quickly! It's a lot easier to undo
> partial damage :D (Speaking of which: where is that CF update stream you
> mentioned?)
https://commitfest.postgresql.org/activity/
--
Justin
On Mon, Jul 18, 2022 at 3:18 PM Tom Lane wrote:
>
> Independently of the dimensionality question --- I'd imagined that
> array_sample would select a random subset of the array elements
> but keep their order intact. If you want the behavior shown
> above, you can do array_shuffle(array_sample(..
Martin Kalcher writes:
> If we go with (1) array_shuffle() and array_sample() should shuffle each
> element individually and always return a one-dimensional array.
>select array_shuffle('{{1,2},{3,4},{5,6}}');
>---
> {1,4,3,5,6,2}
>select array_sample('{{1,2},{3,4},{5,6}
On Fri, Jun 24, 2022 at 11:42:29AM +0100, Simon Riggs wrote:
> This patch would undo a very important change - to keep servers
> available by default and go back to the old behavior for a huge fleet
> of Postgres databases. The old behavior of shutdown-on-change caused
> catastrophe many times for
Hi,
On 2022-07-18 00:05:16 -0700, Andres Freund wrote:
> It looks like we might be missing out on benefiting from this on more
> platforms - the test right now is in the gcc specific section of configure.ac,
> but it looks like at least Intel's, sun's and AIX's compilers might all
> support -fvisi
On Thu, Jul 14, 2022 at 03:57:35PM -0700, Nathan Bossart wrote:
> However, ALTER ROLE RESET ALL will be blocked, while resetting only the
> individual GUC will go through.
>
> postgres=> ALTER ROLE other RESET ALL;
> ALTER ROLE
> postgres=> SELECT * FROM pg_db_role_setting;
>
Am 18.07.22 um 23:03 schrieb Tom Lane:
I wrote:
Martin had originally proposed (2), which I rejected on the grounds
that we don't treat multi-dimensional arrays as arrays-of-arrays for
any other purpose.
Actually, after poking at it for awhile, that's an overstatement.
It's true that the type
I wrote:
> Martin had originally proposed (2), which I rejected on the grounds
> that we don't treat multi-dimensional arrays as arrays-of-arrays for
> any other purpose.
Actually, after poking at it for awhile, that's an overstatement.
It's true that the type system doesn't think N-D arrays are
a
Hi,
On 2022-07-18 13:34:52 -0700, Jacob Champion wrote:
> On 7/18/22 12:32, Andres Freund wrote:
> > I'm not following - I'm talking about the patch author needing a while to
> > address the higher level feedback given by a reviewer. The author might put
> > out a couple new versions, which each m
On Thu, Jul 14, 2022 at 06:27:17PM -0700, David G. Johnston wrote:
> Thank you and apologies for being quiet here and on a few of the other
> threads.
> I've been on vacation and flagged as ToDo some of the non-simple feedback
> items
> that have come this way.
No need to worry --- we will incor
Robert Haas writes:
> On Mon, Jul 18, 2022 at 3:03 PM Martin Kalcher
> wrote:
>> array_shuffle(anyarray) -> anyarray
>> array_sample(anyarray, integer) -> anyarray
> I think it's questionable whether the behavior of array_shuffle() is
> correct for a multi-dimensional array. The implemented beha
On 7/18/22 12:32, Andres Freund wrote:
> I'm not following - I'm talking about the patch author needing a while to
> address the higher level feedback given by a reviewer. The author might put
> out a couple new versions, which each might still benefit from review. In that
> - pretty common imo - s
On Mon, Jul 18, 2022 at 4:06 PM Andres Freund wrote:
> How about adding a new binary_upgrade_* helper function for this purpose
> instead, instead of tying it into truncate?
I considered that briefly, but it would need to do a lot of things
that TRUNCATE already knows how to do, so it does not se
On Mon, Jul 18, 2022 at 3:03 PM Martin Kalcher
wrote:
> Thanks for all your feedback and help. I got a patch that i consider
> ready for review. It introduces two new functions:
>
>array_shuffle(anyarray) -> anyarray
>array_sample(anyarray, integer) -> anyarray
>
> array_shuffle() shuffles
Hi,
On 2022-07-18 11:33:09 +0200, Peter Eisentraut wrote:
> The following patches are ok to commit IMO:
>
> a1c5542929 prereq: Deal with paths containing \ and spaces in
> basebackup_to_shell tests
> e37951875d meson: prereq: psql: Output dir and dependency generation for
> sql_help
> 18cc9fbd0
Am 18.07.22 um 21:29 schrieb Tom Lane:
The preferred thing to do is to add it to our "commitfest" queue,
which will ensure that it gets looked at eventually. The currently
open cycle is 2022-09 [1] (see the "New Patch" button there).
Thanks Tom, did that. I am not sure if "SQL Commands" is the
On Sun, Jul 17, 2022 at 9:04 PM Morris de Oryx wrote:
> This fails on a partitioned table because xmax() may not exist. In fact, it
> does exist in all of those tables, but the system doesn't know how to
> guarantee that. I know which tables are partitioned, and can downgrade the
> result on pa
On Mon, Jul 18, 2022 at 02:57:40PM -0400, Robert Haas wrote:
> So I tried implementing this but I didn't get it quite right the first
> time. It's not enough to call smgrdounlinkall() instead of
> RelationDropStorage(), because just as RelationDropStorage() does not
> actually drop the storage but
Hi,
On 2022-07-18 14:57:40 -0400, Robert Haas wrote:
> As to whether this is a good fix, I think someone could certainly
> argue otherwise. This is all a bit grotty. However, I don't find it
> all that bad. As long as we're moving files from between one PG
> cluster and another using an external t
On Mon, Jul 18, 2022 at 12:06:34PM -0700, Jacob Champion wrote:
> On 7/17/22 08:17, Nathan Bossart wrote:
>> Yeah, I happened to look in my commitfest update folder this morning and
>> was surprised to learn that I was no longer reviewing 3612. I spent a good
>> amount of time getting that patch i
On Fri, Jul 15, 2022 at 09:29:20PM +0800, Japin Li wrote:
>
> On Fri, 15 Jul 2022 at 08:49, Bruce Momjian wrote:
> > On Tue, Jul 5, 2022 at 08:02:33PM -0400, Tom Lane wrote:
> >> "Precondition" is an overly fancy word that makes things less clear
> >> not more so. Does it mean that setting wal_
On Thu, Jun 23, 2022 at 5:49 AM Jakub Wartak wrote:
> Cool. As for GUC I'm afraid there's going to be resistance of adding yet
> another GUC (to avoid many knobs). Ideally it would be nice if we had some
> advanced/deep/hidden parameters , but there isn't such thing.
> Maybe another option would
Hi,
On 2022-07-18 12:22:25 -0700, Jacob Champion wrote:
> [dev hat]
>
> On 7/15/22 18:07, Andres Freund wrote:
> > IDK, I've plenty times given feedback and it took months till it all was
> > implemented. What's the point of doing further rounds of review until then?
>
> I guess I would wonder w
Martin Kalcher writes:
> Is someone interested in looking at it? What are the next steps?
The preferred thing to do is to add it to our "commitfest" queue,
which will ensure that it gets looked at eventually. The currently
open cycle is 2022-09 [1] (see the "New Patch" button there).
I believe
On Thu, Jul 14, 2022 at 10:53 AM tushar wrote:
> GRANT "g2" TO "u1" WITH GRANTED BY "edb";
Another good catch. Here is v5 with a fix for that problem.
--
Robert Haas
EDB: http://www.enterprisedb.com
v5-0001-Allow-grant-level-control-of-role-inheritance-beh.patch
Description: Binary data
[dev hat]
On 7/15/22 18:07, Andres Freund wrote:
> IDK, I've plenty times given feedback and it took months till it all was
> implemented. What's the point of doing further rounds of review until then?
I guess I would wonder why we're optimizing for that case. Is it helpful
for that patch to stic
On 23.06.22 09:41, Markus Wanner wrote:
On 6/21/22 18:33, Tom Lane wrote:
My inclination at this point is to not back-patch the second change
12d768e70 ("Don't use static storage for
SaveTransactionCharacteristics").
It's not clear that the benefit would be worth even a small risk of
somebody
On 2022-07-15 Fr 17:07, Andres Freund wrote:
> Hi,
>
> On 2022-07-08 17:05:49 -0400, Andrew Dunstan wrote:
>> On 2022-07-05 Tu 15:04, Andrew Dunstan wrote:
>>> On 2022-07-05 Tu 14:36, Andres Freund wrote:
>> I think Andrew's beta 2 comment was more about my other architectural
>> complains
On 7/17/22 08:17, Nathan Bossart wrote:
> On Fri, Jul 15, 2022 at 09:37:14PM -0500, Justin Pryzby wrote:
>> I'm not suggesting to give the community regulars special treatment, but you
>> could reasonably assume that when they added themselves and then "didn't
>> remove
>> themself", it was on pur
On 7/15/22 19:59, Michael Paquier wrote:
> On this point, I'd like to think that a window of two weeks is a right
> balance. That's half of the commit fest, so that leaves plenty of
> time for one to answer. There is always the case where one is on
> vacations for a period longer than that, but i
Thanks for all your feedback and help. I got a patch that i consider
ready for review. It introduces two new functions:
array_shuffle(anyarray) -> anyarray
array_sample(anyarray, integer) -> anyarray
array_shuffle() shuffles an array (obviously). array_sample() picks n
random elements from
On 7/18/22 06:13, Justin Pryzby wrote:
> On Mon, Jul 18, 2022 at 03:05:51PM +0200, Alvaro Herrera wrote:
>> Maybe we should have two reviewers columns -- one for history-tracking
>> purposes (and commit msg credit) and another for current ones.
>
> Maybe. Or, the list of reviewers shouldn't be sh
Justin,
(Consolidating replies here.)
On 7/15/22 19:13, Justin Pryzby wrote:
> cfbot is Thomas's project, so moving it run on postgres vm was one step, but I
> imagine the "integration with cfapp" requires coordination with Magnus.
>
> What patch ?
https://www.postgresql.org/message-id/CAAWbhmg
On Tue, Jul 12, 2022 at 4:51 PM Robert Haas wrote:
> I have a few more ideas to try here. It occurs to me that we could fix
> this more cleanly if we could get the dump itself to set the
> relfilenode for pg_largeobject to the desired value. Right now, it's
> just overwriting the relfilenode store
ne 17. 7. 2022 v 16:01 odesílatel Justin Pryzby
napsal:
> Thanks for updating the patch.
>
> This failed to build on windows.
> http://cfbot.cputube.org/pavel-stehule.html
>
>
Yes, there was a significant problem with the function exit_nicely, that is
differently implemented in pg_dump and pg_dum
Tomas Vondra writes:
> Thanks. I'll switch this to "needs review" now.
OK, I looked through this, and attach some review suggestions in the
form of a delta patch. (0001 below is your two patches merged, 0002
is my delta.) A lot of the delta is comment-smithing, but not all.
After reflection I
Overall, these patches look reasonable.
On Mon, Jul 18, 2022 at 04:24:12PM +0530, Bharath Rupireddy wrote:
> record. Because the entire content of data pages is saved in the
> - log on the first page modification after a checkpoint (assuming
> + WAL record on the first page modification a
On Mon, Jul 18, 2022 at 04:53:18PM +0530, Bharath Rupireddy wrote:
> Just wondering - do we ever have a problem if we can't remove the
> snapshot or mapping file?
Besides running out of disk space, there appears to be a transaction ID
wraparound risk with the mappings files.
--
Nathan Bossart
Am
On Fri, Jul 15, 2022 at 05:23:48PM -0700, Jacob Champion wrote:
>> This is important stuff to discuss, for sure, but I also want to revisit
>> the thing I put on pause, which is to clear out old Reviewer entries to
>> make it easier for new reviewers to find work to do. If we're not using
>> Review
On Thu, Mar 17, 2022 at 04:30:43PM -0700, Nathan Bossart wrote:
> On Thu, Mar 17, 2022 at 04:26:31PM -0700, Swaha Miller wrote:
>> On Thu, Mar 17, 2022 at 4:16 PM Nathan Bossart
>> wrote:
>>> It seems unlikely that this will be committed for v15. Swaha, should the
>>> commitfest entry be adjusted
On 7/15/22 16:42, Jacob Champion wrote:
> If you have thoughts/comments on this approach, please share them!
Okay, plenty of feedback to sift through here.
[CFM hat]
First of all: mea culpa. I unilaterally made a change that I had assumed
would be uncontroversial; it clearly was not, and I inter
Tom Lane writes:
> I got annoyed just now upon finding that pprint() applied to the planner's
> "root" pointer doesn't dump root->agginfos or root->aggtransinfos. That's
> evidently because AggInfo and AggTransInfo aren't proper Nodes, just bare
> structs, which presumably is because somebody co
Hi Tom,
Thank you for taking a look at this and that sounds good. I will send over a
patch compatible with Postgres v16.
Justin
From: Tom Lane
Sent: July 17, 2022 2:40 PM
To: Justin Kwan
Cc: pgsql-hackers ; vignesh
; jk...@cloudflare.com ; vignesh
ravichandra
Alvaro Herrera writes:
> On 2022-Jul-18, Richard Guo wrote:
>> BTW, not related to this patch, the new lines for parallel_aware check
>> in setrefs.c are very wide. How about wrap them to keep consistent with
>> arounding codes?
> Not untrue! Something like this, you mean? Fixed the nearby typo
On 2022-Jul-18, Richard Guo wrote:
> BTW, not related to this patch, the new lines for parallel_aware check
> in setrefs.c are very wide. How about wrap them to keep consistent with
> arounding codes?
Not untrue! Something like this, you mean? Fixed the nearby typo while
at it.
--
Álvaro Herr
I got annoyed just now upon finding that pprint() applied to the planner's
"root" pointer doesn't dump root->agginfos or root->aggtransinfos. That's
evidently because AggInfo and AggTransInfo aren't proper Nodes, just bare
structs, which presumably is because somebody couldn't be bothered to
write
On Mon, Jul 18, 2022 at 6:53 AM Peter Eisentraut
wrote:
> I think a way to look at this is that this column encryption feature
> isn't suitable for disguising the existence or absence of data, it can
> only disguise the particular data that you know exists.
+1.
Even there, what can be accomplish
Hi,
On 2022-07-18 11:12:10 +0300, Aleksander Alekseev wrote:
> > Just a quick question - is there a reason for changing the subject of
> > the emails?
> >
> > Not all email clients handle this well, e.g. Google Mail considers
> > this being 10 separate threads. The CF application and/or
> > pgsql-
On 2022-07-18 Mo 10:33, Justin Pryzby wrote:
> It's easy to use CREATE TABLE..LIKE + ALTER..ATTACH PARTITION to avoid
> acquiring a strong lock when creating a new partition.
> But it's also easy to forget.
>
> commit 76c0d1198cf2908423b321cd3340d296cb668c8e
> Author: Justin Pryzby
> Date: Mon
po 18. 7. 2022 v 16:29 odesílatel Tom Lane napsal:
> Alvaro Herrera writes:
> > On 2022-Jul-18, Pavel Stehule wrote:
> >> I am trying to fix one slow query, and found that optimization of min,
> max
> >> functions is possible only when there is no JOIN in the query.
>
> > See preprocess_minmax_a
It's easy to use CREATE TABLE..LIKE + ALTER..ATTACH PARTITION to avoid
acquiring a strong lock when creating a new partition.
But it's also easy to forget.
commit 76c0d1198cf2908423b321cd3340d296cb668c8e
Author: Justin Pryzby
Date: Mon Jul 18 09:24:55 2022 -0500
doc: mention CREATE+ATTACH
Alvaro Herrera writes:
> On 2022-Jul-18, Pavel Stehule wrote:
>> I am trying to fix one slow query, and found that optimization of min, max
>> functions is possible only when there is no JOIN in the query.
> See preprocess_minmax_aggregates() in
> src/backend/optimizer/plan/planagg.c
> Maybe it i
On 2022-Jul-18, Pavel Stehule wrote:
> Hi
>
> I am trying to fix one slow query, and found that optimization of min, max
> functions is possible only when there is no JOIN in the query.
>
> Is it true?
See preprocess_minmax_aggregates() in
src/backend/optimizer/plan/planagg.c
> select max(inse
> On 23 Jun 2022, at 12:50, Jakub Wartak wrote:
>
> Thoughts?
I've looked into the patch one more time. And I propose to change this line
+ posix_fadvise(readFile, readOff + RACHUNK, RACHUNK,
POSIX_FADV_WILLNEED);
to
+ posix_fadvise(readFile, readOff + XLOG_BLCKSZ
John Naylor writes:
> On Mon, Jul 18, 2022 at 2:47 PM Martin Kalcher <
> martin.kalc...@aboutsource.net> wrote:
>> One more question. How do i pick a Oid for the functions?
> For this, we recommend running src/include/catalog/unused_oids, and it will
> give you a random range to pick from. That r
Hi
I am trying to fix one slow query, and found that optimization of min, max
functions is possible only when there is no JOIN in the query.
Is it true?
I need to do manual transformation of query
select max(insert_date) from foo join boo on foo.boo_id = boo.id
where foo.item_id = 100 and boo.i
1 - 100 of 128 matches
Mail list logo
