Hi,
This feature adds an option to skip changes of all tables in specified
schema while creating publication.
This feature is helpful for use cases where the user wants to
subscribe to all the changes except for the changes present in a few
schemas.
Ex:
CREATE PUBLICATION pub1 FOR ALL TABLES SKIP
>BTW have we discussed another idea I mentioned before that we have the
>leader process periodically check the number of completed indexes and
>advertise it in its progress information? I'm not sure which one is
>better but this idea would require only changes of vacuum code and
>
Hi Peter,
> I think there needs to be a bit more soul searching here on how to
> handle that in the future and how to transition it. I don't think
> targeting this patch for PG15 is useful at this point.
The patches can be reordered so that we are still able to deliver SLRU
refactoring in PG15.
On Tue, Mar 22, 2022 at 4:27 PM Imseih (AWS), Sami wrote:
>
> >BTW have we discussed another idea I mentioned before that we have the
> >leader process periodically check the number of completed indexes and
> >advertise it in its progress information? I'm not sure which one is
> >b
On 22.03.22 00:51, Nathan Bossart wrote:
On Wed, Mar 16, 2022 at 11:12:06AM +0100, Peter Eisentraut wrote:
Right, the previous behaviors were clearly faulty. I have updated the
commit message to call out the behavior change more clearly.
This patch is now complete from my perspective.
I took
On 21.03.22 22:54, Tomas Vondra wrote:
On 3/21/22 14:05, Peter Eisentraut wrote:
On 20.03.22 23:55, Tomas Vondra wrote:
Attached is a rebased patch, addressing most of the remaining issues.
This looks okay to me, if the two FIXMEs are addressed. Remember to
also update protocol.sgml if you c
On Tue, 22 Mar 2022 09:08:15 +0900
Yugo NAGATA wrote:
> Hi Ishii-san,
>
> On Sun, 20 Mar 2022 09:52:06 +0900 (JST)
> Tatsuo Ishii wrote:
>
> > Hi Yugo,
> >
> > I have looked into the patch and I noticed that > linkend=... endterm=...> is used in pgbench.sgml. e.g.
> >
> >
> >
> > AFAIK th
>
> > I think there needs to be a bit more soul searching here on how to
> > handle that in the future and how to transition it. I don't think
> > targeting this patch for PG15 is useful at this point.
>
> The patches can be reordered so that we are still able to deliver SLRU
> refactoring in PG15
> On 22 Mar 2022, at 04:48, Andres Freund wrote:
> docs fail to build:
> https://cirrus-ci.com/task/5556234047717376?logs=docs_build#L349
Ugh, that one was on me and not the original author. Fixed.
--
Daniel Gustafsson https://vmware.com/
v29-0001-Provide-a-GUC-for-temporarily
On Sat, 19 Mar 2022 19:31:59 +0900
Michael Paquier wrote:
> On Fri, Mar 18, 2022 at 03:13:05PM +0900, Michael Paquier wrote:
> > Thanks. This looks rather sane to me. I'll split things into 3
> > commits in total, as of the psql completion, SET TABLESPACE and SET
> > ACCESS METHOD. The first a
On Tue, Mar 22, 2022 at 10:28 AM Dilip Kumar wrote:
>
>
> I think this make sense. I haven't changed the original patch as you
> told you were improving on some comments, so in order to avoid
> conflict I have created this add on patch.
>
In my previous patch mistakenly I used src_dboid instead
Hi,
On Tue, Mar 22, 2022 at 3:32 AM Andres Freund wrote:
>
> Doesn't apply once more: http://cfbot.cputube.org/patch_37_3213.log
>
Thanks for the reminder, a rebased version is attached.
Regards
--
Alexey Kondratov
From df56b5c7b882e781fdc0b92e7a83331f0baab094 Mon Sep 17 00:00:00 2001
From: A
Thanks, Thomas for reviewing the patch!
Yes, we cannot turn off ASLR for Arm64 targets with MSVC. I haven't seen
any issues so far on win/arm64 with this option turned off. I guess it
should be okay. If we really need ASLR turned off, then I guess might have
to use clang.
Yes, we could look into
>> I've checked other places using referring to , and found
>> that "xreflabel"s are used in such tags. So, I'll fix it
>> in this style.
>
> I attached the updated patch. I also fixed the following paragraph which I had
> forgotten to fix in the previous patch.
>
> The first seven lines repo
Hi everyone!
I am watching this thread since quite a while and I am waiting eagerly a
long time already that this feature finally lands in PostgreSQL.
Given that in around 2 weeks PostgreSQL 15 will go into feature freeze (in
the last years that usually happened around the 8th of April AFAIK), is
On Tue, Mar 22, 2022 at 5:29 AM Andres Freund wrote:
>
> On 2022-02-13 19:34:05 +0530, vignesh C wrote:
> > Thanks for the comments, the attached v14 patch has the changes for the
> > same.
>
> The patch needs a rebase, it currently fails to apply:
> http://cfbot.cputube.org/patch_37_2957.log
Th
Hi,
Please don't top-post here. See
https://wiki.postgresql.org/wiki/Mailing_Lists#Email_etiquette_mechanics.
On Tue, Mar 22, 2022 at 09:37:46AM +, Niyas Sait wrote:
>
> Yes, we could look into providing a build machine. Do you have any
> reference to what the CI system looks like now for Po
On Tue, Mar 22, 2022 at 12:20 AM Andres Freund wrote:
> > Something like attached
> > v6-0001-Deduplicate-checkpoint-restartpoint-complete-mess.patch?
>
> Mostly. I don't see a reason for the use of the stringinfo. And I think
> LogCheckpointStart() should be dealt with similarly.
>
> I'd just mak
Am 22.03.22 um 02:17 schrieb Andres Freund:
> Hi,
>
> On 2022-03-08 19:32:03 +0100, Gunnar "Nick" Bluth wrote:
>> v8 (applies cleanly to today's HEAD/master) attached.
>
> This doesn't apply anymore, likely due to my recent pgstat changes - which
> you'd need to adapt to...
Now, that's been quit
On Mon, 21 Mar 2022 at 09:47, Laurenz Albe wrote:
>
> Thanks for your diligent work on this, and the patch looks good to me.
Thanks for looking again. Pushed.
Regards,
Dean
On Tue, Mar 22, 2022 at 7:25 AM houzj.f...@fujitsu.com
wrote:
>
> > On Monday, March 21, 2022 6:01 PM Amit Kapila
> > wrote:
>
> Oh, sorry, I posted the wrong patch, here is the correct one.
>
The test change looks good to me. I think additionally we can verify
that the record is not reflected i
Hello, Peter.
Thanks for your comments.
> There is one FPI per checkpoint for any leaf page that is modified
> during that checkpoint. The difference between having that happen once
> or twice per leaf page and having that happen many more times per leaf
> page could be very large.
Yes, I am alm
On Mon, Mar 21, 2022 at 4:25 AM Tomas Vondra
wrote:
>
> Hi,
>
> Attached is a rebased patch, addressing most of the remaining issues.
>
It appears that on the apply side, the patch always creates a new
relfilenode irrespective of whether the sequence message is
transactional or not. Is it require
> On 22. 3. 2022, at 13:09, Amit Kapila wrote:
>
> On Mon, Mar 21, 2022 at 4:25 AM Tomas Vondra
> wrote:
>>
>> Hi,
>>
>> Attached is a rebased patch, addressing most of the remaining issues.
>>
>
> It appears that on the apply side, the patch always creates a new
> relfilenode irrespective
Hi hackers,
> The cfbot says that the patch doesn't apply anymore, so here's a v3 with
the
> changes mentioned below.
I came across this thread while looking for the patches that need review.
The v3-0001 patch LGTM.
Since v3-0002 adds a new view and alters pg_proc.dat shouldn't it also
increase
On 3/22/22 01:49, Andres Freund wrote:
> On 2022-01-17 15:27:53 +0300, Alexander Pyhalov wrote:
>> Alexander Pyhalov писал 2022-01-17 15:26:
>>> Updated patch.
>>
>> Sorry, missed attachment.
>
> Needs another update: http://cfbot.cputube.org/patch_37_3369.log
>
> Marked as waiting on author.
>
Hi hackers,
> It passes `make installcheck` ...
`make installcheck-world`, of course. Sorry for the confusion.
--
Best regards,
Aleksander Alekseev
On Tue, Mar 15, 2022 at 3:19 PM Amit Langote wrote:
> On Tue, Mar 15, 2022 at 5:06 AM Robert Haas wrote:
> > On Mon, Mar 14, 2022 at 3:38 PM Tom Lane wrote:
> > > Also, while I've not spent much time at all reading this patch,
> > > it seems rather desperately undercommented, and a lot of the
>
> On Mar 21, 2022, at 10:03 PM, Thomas Munro wrote:
>
> On Fri, Mar 18, 2022 at 4:22 PM Mark Dilger
> wrote:
>> (FYI, I got a test failure from src/test/recovery/t/013_crash_restart.pl
>> when testing v1-0001. I'm not sure yet what that is about.)
>
> Doesn't look like 0001 has anything to
Hi hackers,
> Here is v23. As was suggested by Alexander above, I've changed the order of
> the patches and improved the commit message. Now, SLRU patch is the first.
Many thanks!
> There were proposals to make use of SLRU pages numbers that are in fact
> unsigned and change from int to uint64
On 3/22/22 01:03, Thomas Munro wrote:
> On Fri, Mar 18, 2022 at 4:22 PM Mark Dilger
> wrote:
>> (FYI, I got a test failure from src/test/recovery/t/013_crash_restart.pl
>> when testing v1-0001. I'm not sure yet what that is about.)
> Doesn't look like 0001 has anything to do with that... Are
On Tue, Mar 22, 2022 at 12:53 PM Matthias Kurz wrote:
> Hi everyone!
>
> I am watching this thread since quite a while and I am waiting eagerly a
> long time already that this feature finally lands in PostgreSQL.
> Given that in around 2 weeks PostgreSQL 15 will go into feature freeze (in
> the l
Hi,
On Tue, Mar 22, 2022 at 03:21:20PM +0300, Aleksander Alekseev wrote:
>
> The v3-0001 patch LGTM.
>
> Since v3-0002 adds a new view and alters pg_proc.dat shouldn't it also
> increase CATALOG_VERSION_NO? Not sure if we generally do this in the
> patches or expect the committer to make the chang
On 2022-Mar-21, Andres Freund wrote:
> This patch currently doesn't apply: http://cfbot.cputube.org/patch_37_2716.log
Updated.
> Are you aiming this for v15? Otherwise I'd like to move the entry to the next
> CF. Marked as waiting-on-author.
I'd like to get 0001 pushed to pg15, yes. I'll let 0
Hello, Andres.
> Fails to apply at the moment: http://cfbot.cputube.org/patch_37_2947.log
Thanks for notifying me. BTW, some kind of automatic email in case of
status change could be very helpful.
> Marked as waiting for author.
New version is attached, build is passing
(https://cirrus-ci.com/b
Alvaro Herrera writes:
> On 2022-Mar-21, Andres Freund wrote:
>> Are you aiming this for v15? Otherwise I'd like to move the entry to the next
>> CF. Marked as waiting-on-author.
> I'd like to get 0001 pushed to pg15, yes. I'll let 0002 sit here for
> discussion, but I haven't seen any evidence
Thomas Munro writes:
> On Tue, Mar 22, 2022 at 4:13 PM Tom Lane wrote:
>> OK. You want me to push 75674c7e to HEAD?
> Thanks, yes, please do.
Done.
regards, tom lane
On 3/22/22 09:28, Oleg Bartunov wrote:
>
>
> On Tue, Mar 22, 2022 at 12:53 PM Matthias Kurz
> wrote:
>
> Hi everyone!
>
> I am watching this thread since quite a while and I am waiting
> eagerly a long time already that this feature finally lands in
> PostgreSQL.
> Given that
On 3/21/22 19:08, Mark Dilger wrote:
>
>> On Mar 21, 2022, at 1:30 PM, Andrew Dunstan wrote:
>>
>> To the best of my knowledge .control files are only used by extensions,
>> not by other modules. They are only referenced in
>> src/backend/commands/extension.c in the backend code. For example,
>>
Hi,
On 2022-03-22 16:32:24 +0530, Bharath Rupireddy wrote:
> On Tue, Mar 22, 2022 at 12:20 AM Andres Freund wrote:
> > > Something like attached
> > > v6-0001-Deduplicate-checkpoint-restartpoint-complete-mess.patch?
> >
> > Mostly. I don't see a reason for the use of the stringinfo. And I think
>
On Tue, 22 Mar 2022 at 15:31, Andrew Dunstan wrote:
>
> I'm planning on pushing the functions patch set this week and json-table
> next week.
>
Great! Thank you very much!
On 17.03.22 19:04, Fabien COELHO wrote:
Hello Peter,
See attached v16 which removes the libpq workaround.
I suppose this depends on
https://www.postgresql.org/message-id/flat/ab4288f8-be5c-57fb-2400-e3e857f53e46%40enterprisedb.com
getting committed, because right now this makes the psql
On 2022-Mar-22, Andrew Dunstan wrote:
> I'm planning on pushing the functions patch set this week and json-table
> next week.
I think it'd be a good idea to push the patches one by one and let a day
between each. That would make it easier to chase buildfarm issues
individually, and make sure the
> On 22 Mar 2022, at 16:31, Andrew Dunstan wrote:
> I'm planning on pushing the functions patch set this week and json-table
> next week.
My comments from 30827b3c-edf6-4d41-bbf1-298181874...@yesql.se are yet to be
addressed (or at all responded to) in this patchset. I'll paste the ones which
s
On 17.03.22 19:04, Fabien COELHO wrote:
Indeed! The missing part was put back in v17.
Some unrelated notes on this v17 patch:
-use Test::More;
+use Test::More tests => 41;
The test counts are not needed/wanted anymore.
+
+\set ECHO none
+
This seems inappropriate.
+--
+-- autocommit
+--
On Wed, 23 Feb 2022 at 15:25, Andres Freund wrote:
> On 2022-02-18 12:10:51 +1300, David Rowley wrote:
> > The other way I thought to fix it was by changing the logic for when
> > generation blocks are freed. In the problem case mentioned above, the
> > block being freed is the current block (whi
Hi,
On Tue, Mar 22, 2022 at 10:41:05AM -0400, Andrew Dunstan wrote:
>
> Pushed with slight adjustments - the LOAD was unnecessary as was the
> setting of client_min_messages - the latter would have made buildfarm
> animals unhappy.
For the record this just failed on my buildfarm animal:
https://
On Tue, Mar 22, 2022 at 5:00 AM Dilip Kumar wrote:
> In my previous patch mistakenly I used src_dboid instead of
> dest_dboid. Fixed in this version. For destination db I have used
> lock mode as AccessSharedLock. Logically if we see access wise we
> don't want anyone else to be accessing that
On Tue, Mar 22, 2022 at 11:23 AM Robert Haas wrote:
> Here's my worked-over version of your previous patch. I haven't tried
> to incorporate your incremental patch that you just posted.
Also, please have a look at the XXX comments that I added in a few
places where I think you need to make furthe
On Tue, Mar 22, 2022 at 5:32 PM Andrew Dunstan wrote:
>
> On 3/22/22 09:28, Oleg Bartunov wrote:
> >
> >
> > On Tue, Mar 22, 2022 at 12:53 PM Matthias Kurz
> > wrote:
> >
> > Hi everyone!
> >
> > I am watching this thread since quite a while and I am waiting
> > eagerly a long time a
> On Mar 22, 2022, at 8:14 AM, Julien Rouhaud wrote:
>
> Hi,
>
> On Tue, Mar 22, 2022 at 10:41:05AM -0400, Andrew Dunstan wrote:
>>
>> Pushed with slight adjustments - the LOAD was unnecessary as was the
>> setting of client_min_messages - the latter would have made buildfarm
>> animals unha
On 3/22/22 10:53, Alvaro Herrera wrote:
> On 2022-Mar-22, Andrew Dunstan wrote:
>
>> I'm planning on pushing the functions patch set this week and json-table
>> next week.
> I think it'd be a good idea to push the patches one by one and let a day
> between each. That would make it easier to chas
On 3/22/22 10:55, Daniel Gustafsson wrote:
>> On 22 Mar 2022, at 16:31, Andrew Dunstan wrote:
>> I'm planning on pushing the functions patch set this week and json-table
>> next week.
> My comments from 30827b3c-edf6-4d41-bbf1-298181874...@yesql.se are yet to be
> addressed (or at all responded
Hi,
On 2022-03-22 18:09:08 +1300, Thomas Munro wrote:
> On Tue, Mar 22, 2022 at 4:14 PM Andres Freund wrote:
> > The problem looks to be that pg_dumpall doesn't have a dependency on OBJs,
> > which in turn is what contains the dependency on WIN32RES, which in turn
> > contains win32ver.o. So the
On Mon, Mar 21, 2022 at 2:41 PM Dagfinn Ilmari Mannsåker
wrote:
> This is no longer the accurate. How about something like like "Specifies
> details of the chosen compression method"?
Good catch. v5 attached.
--
Robert Haas
EDB: http://www.enterprisedb.com
v5-0001-Replace-BASE_BACKUP-COMPRESS
On Sat, Mar 19, 2022 at 11:43 AM Fabien COELHO wrote:
>
> Hi Sami,
>
> > Pgbench is a simple benchmark tool by design, and I wonder if adding
> > a multiconnect feature will cause pgbench to be used incorrectly.
>
> Maybe, but I do not see how it would be worse that what pgbench already
> allows.
Hi,
On 2022-03-22 11:23:16 -0400, Robert Haas wrote:
> From 116bcdb6174a750b7ef7ae05ef6f39cebaf9bcf5 Mon Sep 17 00:00:00 2001
> From: Robert Haas
> Date: Tue, 22 Mar 2022 11:22:26 -0400
> Subject: [PATCH v1] Add new block-by-block strategy for CREATE DATABASE.
I might have missed it because I ju
On 3/22/22 11:26, Mark Dilger wrote:
>
>> On Mar 22, 2022, at 8:14 AM, Julien Rouhaud wrote:
>>
>> Hi,
>>
>> On Tue, Mar 22, 2022 at 10:41:05AM -0400, Andrew Dunstan wrote:
>>> Pushed with slight adjustments - the LOAD was unnecessary as was the
>>> setting of client_min_messages - the latter wo
On Mon, Mar 21, 2022 at 8:52 PM Andres Freund wrote:
> I noticed this still has an open CF entry:
> https://commitfest.postgresql.org/37/3296/
> I assume it can be marked as committed?
Yeah, done now. But don't forget that we still need to do something on
the "wrong fds used for refilenodes afte
On Tue, Mar 22, 2022 at 11:42 AM Andres Freund wrote:
> I might have missed it because I just skimmed the patch. But I still think it
> should contain a comment detailing why accessing catalogs from another
> database is safe in this instance, and perhaps a comment or three in places
> that could
Hi Andres,
Rebased it.
I also removed the temp installation task and
used NoDefaultCurrentDirectoryInExePath env variable instead.
Best,
Melih
From e8a1dae0ec10efd8a967070e0d412d2bf875fa93 Mon Sep 17 00:00:00 2001
From: Melih Mutlu
Date: Mon, 21 Feb 2022 14:46:05 +0300
Subject: [PATCH] Added Win
Andrew Dunstan writes:
> That seems quite weird. I'm not sure how it's getting loaded at all if
> not via shared_preload_libraries
Some other animals are showing this:
diff -U3
/home/postgres/pgsql/src/test/modules/test_oat_hooks/expected/test_oat_hooks.out
/home/postgres/pgsql/src/test/module
On 3/22/22 12:02, Tom Lane wrote:
> Andrew Dunstan writes:
>> That seems quite weird. I'm not sure how it's getting loaded at all if
>> not via shared_preload_libraries
> Some other animals are showing this:
>
> diff -U3
> /home/postgres/pgsql/src/test/modules/test_oat_hooks/expected/test_oat_h
> On Mar 22, 2022, at 9:09 AM, Andrew Dunstan wrote:
>
> If I can't com up with a very quick fix I'll revert it.
The problem is coming from the REGRESS_exec_check_perms, which was included in
the patch to demonstrate when the other hooks fired relative to the
ExecutorCheckPerms_hook, but si
On 2022-Mar-22, Tom Lane wrote:
> I looked briefly at 0001, and I've got to say that I disagree with
> your decision to rearrange the representation of the local LogwrtResult
> copy. It clutters the patch tremendously and makes it hard to
> understand what the actual functional change is. Moreov
Tomas Vondra писал 2022-03-22 15:28:
On 3/22/22 01:49, Andres Freund wrote:
On 2022-01-17 15:27:53 +0300, Alexander Pyhalov wrote:
Alexander Pyhalov писал 2022-01-17 15:26:
Updated patch.
Sorry, missed attachment.
Needs another update: http://cfbot.cputube.org/patch_37_3369.log
Marked as
> On Mar 22, 2022, at 9:11 AM, Mark Dilger wrote:
>
> Give me a couple minutes
v1-0001-Fix-build-farm-failures-in-test_oat_hooks.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Mark Dilger writes:
> The problem is coming from the REGRESS_exec_check_perms, which was included
> in the patch to demonstrate when the other hooks fired relative to the
> ExecutorCheckPerms_hook, but since it is causing problems, I can submit a
> patch with that removed. Give me a couple min
On Sat, Mar 19, 2022 at 5:18 AM Andres Freund wrote:
>
> Hi,
>
> First look at this patch, so I might be repeating stuff already commented on /
> discussed.
Thanks for taking a look at the patch.
> On 2022-03-17 13:25:35 +0530, Bharath Rupireddy wrote:
> > +--
> > +-- pg_get_raw_wal_record()
>
>
Andrew Dunstan writes:
> On 3/22/22 11:26, Mark Dilger wrote:
>> culicidae is complaining:
>> 2022-03-22 14:53:27.198 UTC [2167008][not initialized][:0] FATAL:
>> test_oat_hooks must be loaded via shared_preload_libraries
> That seems quite weird. I'm not sure how it's getting loaded at all if
> On Mar 22, 2022, at 9:33 AM, Tom Lane wrote:
>
> Andrew Dunstan writes:
>> On 3/22/22 11:26, Mark Dilger wrote:
>>> culicidae is complaining:
>>> 2022-03-22 14:53:27.198 UTC [2167008][not initialized][:0] FATAL:
>>> test_oat_hooks must be loaded via shared_preload_libraries
>
>> That seem
Mark Dilger writes:
> On Mar 22, 2022, at 9:33 AM, Tom Lane wrote:
>> As a quick-n-dirty fix to avoid reverting the entire test module,
>> perhaps just delete this error check for now.
> Ok, done as you suggest:
I only suggested removing the error check in _PG_init, not
changing the way the tes
On 3/22/22 12:58, Tom Lane wrote:
> Mark Dilger writes:
>> On Mar 22, 2022, at 9:33 AM, Tom Lane wrote:
>>> As a quick-n-dirty fix to avoid reverting the entire test module,
>>> perhaps just delete this error check for now.
>> Ok, done as you suggest:
> I only suggested removing the error check
> On Mar 22, 2022, at 9:58 AM, Tom Lane wrote:
>
>> Ok, done as you suggest:
>
> I only suggested removing the error check in _PG_init, not
> changing the way the test works.
I should have been more explicit and said, "done as y'all suggest". The "To"
line of that email was to you and Andr
Andrew Dunstan writes:
> On 3/22/22 12:58, Tom Lane wrote:
>> I only suggested removing the error check in _PG_init, not
>> changing the way the test works.
> Mark and I discussed this offline, and decided there was no requirement
> for the module to be preloaded. Do you have a different opinion?
Hi,
When LockAcquireExtended(dontWait=false) acquires a lock where we already hold
stronger lock and somebody else is also waiting for that lock, it goes through
a fairly circuitous path to acquire the lock:
A conflicting lock is detected: if (lockMethodTable->conflictTab[lockmode] &
lock->waitM
On 3/22/22 13:08, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 3/22/22 12:58, Tom Lane wrote:
>>> I only suggested removing the error check in _PG_init, not
>>> changing the way the test works.
>> Mark and I discussed this offline, and decided there was no requirement
>> for the module to be p
Hi,
On 2022-03-22 21:57:51 +0530, Bharath Rupireddy wrote:
> On Sat, Mar 19, 2022 at 5:18 AM Andres Freund wrote:
> > On 2022-03-17 13:25:35 +0530, Bharath Rupireddy wrote:
> > > +--
> > > +-- pg_get_raw_wal_record()
> >
> > What is raw about the function?
>
> It right now gives data starting fr
Andrew Dunstan writes:
> OK, I have pushed that.
It seems like you could remove the NO_INSTALLCHECK restriction
too. You already removed the comment defending it, and it
seems to work fine as an installcheck now if I remove that
locally.
Other nitpicks:
* the IsParallelWorker test could use a
On Mon, Mar 21, 2022 at 9:32 PM Mark Dilger
wrote:
> [ new patch version ]
This patch adds three new arguments to processSQLNamePattern() and
documents one of them. It adds three new parameters to
patternToSQLRegex() as well, and documents none of them. I think that
the text of the comment might
> On Mar 21, 2022, at 7:53 PM, Tom Lane wrote:
>
> Andres Freund writes:
>> My impression is that there's not a lot of enthusiasm for the concept? If
>> that's true we maybe ought to mark the CF entry as rejected?
>
> Yeah, I'm kind of leaning that way too. I don't see how we can
> incorpor
On Tue, Mar 22, 2022 at 1:43 PM Andres Freund wrote:
> When LockAcquireExtended(dontWait=false) acquires a lock where we already hold
> stronger lock and somebody else is also waiting for that lock, it goes through
> a fairly circuitous path to acquire the lock:
>
> A conflicting lock is detected:
So I've been wondering about this block at the bottom of XLogWrite:
/*
* Make sure that the shared 'request' values do not fall behind the
* 'result' values. This is not absolutely essential, but it saves some
* code in a couple of places.
*/
{
Hi,
On 2022-03-22 14:20:55 -0400, Robert Haas wrote:
> On Tue, Mar 22, 2022 at 1:43 PM Andres Freund wrote:
> > When LockAcquireExtended(dontWait=false) acquires a lock where we already
> > hold
> > stronger lock and somebody else is also waiting for that lock, it goes
> > through
> > a fairly
On 2022-03-22 13:15:34 -0500, David Christensen wrote:
> > On Mar 21, 2022, at 7:53 PM, Tom Lane wrote:
> > If we'd done it like this from the beginning, it'd have been
> > great, but retrofitting it now is a lot less appealing.
>
> Yeah, agreed on this. As far as I’m concerned we can reject.
Upd
On Tue, Mar 22, 2022 at 3:01 PM Andres Freund wrote:
> We clearly already know how to compute whether a lock is "included" in
> something we already hold - after all ProcSleep() successfully does so.
>
> Isn't it a pretty trivial test? Seems like it'd boil down to something like
I don't mind you
On 2022-Mar-19, Tomas Vondra wrote:
> @@ -174,7 +182,13 @@ ALTER PUBLICATION noinsert SET (publish = 'update,
> delete');
>
> Add some tables to the publication:
>
> -ALTER PUBLICATION mypublication ADD TABLE users, departments;
> +ALTER PUBLICATION mypublication ADD TABLE users (user_i
> On Mon, Mar 21, 2022 at 06:34:09PM -0700, Andres Freund wrote:
>
> > I don't mind having all of the alternatives under the same CF item, only
> > one being tested seems to be only a small limitation of cfbot.
>
> IMO it's pretty clear that having "duelling" patches below one CF entry is a
> bad i
On Thu, Mar 17, 2022 at 4:05 PM Nathan Bossart wrote:
> On Thu, Mar 17, 2022 at 01:04:17PM -0400, Robert Haas wrote:
> > Right, so perhaps the ultimate thing here would be a more fine-grained
> > knob than SET STORAGE EXTERNAL -- something that allows you to specify
> > that you want to compress o
On Tue, Mar 22, 2022 at 2:34 PM Andres Freund wrote:
> IMO it's pretty clear that having "duelling" patches below one CF entry is a
> bad idea. I think they should be split, with inactive approaches marked as
> returned with feeback or whatnot.
I have the impression that this thread is getting so
On 3/22/22 14:01, Tom Lane wrote:
> Andrew Dunstan writes:
>> OK, I have pushed that.
> It seems like you could remove the NO_INSTALLCHECK restriction
> too. You already removed the comment defending it, and it
> seems to work fine as an installcheck now if I remove that
> locally.
>
> Other ni
On Tue, 2022-03-22 at 13:32 +0900, Kyotaro Horiguchi wrote:
> At Fri, 18 Mar 2022 16:38:57 +0900 (JST), Kyotaro Horiguchi
> wrote in
> >
> > fe-secure-common.c doesn't need netinet/in.h.
> >
> >
> > +++ b/src/include/utils/inet.h
> > ..
> > +#include "common/inet-common.h"
> >
> > I'm not sur
On Mon, Mar 21, 2022 at 2:23 PM Robert Haas wrote:
> On Mon, Mar 21, 2022 at 11:21 AM Dilip Kumar wrote:
> > I tried to debug the case but I realized that somehow
> > CHECK_FOR_INTERRUPTS() is not calling the
> > AcceptInvalidationMessages() and I could not find the same while
> > looking into th
Peter Geoghegan writes:
> Like many difficult patches, the skip scan patch is not so much
> troubled by problems with the implementation as it is troubled by
> *ambiguity* about the design. Particularly concerning how skip scan
> meshes with existing designs, as well as future designs --
> particu
On 3/22/22 11:27, Andrew Dunstan wrote:
> On 3/22/22 10:53, Alvaro Herrera wrote:
>> On 2022-Mar-22, Andrew Dunstan wrote:
>>
>>> I'm planning on pushing the functions patch set this week and json-table
>>> next week.
>> I think it'd be a good idea to push the patches one by one and let a day
>>
On Tue, Mar 22, 2022 at 04:34:05PM -0400, Robert Haas wrote:
> We seem to have a shortage of "others" showing up with opinions on
> this topic, but I guess I'm not very confident about the general
> utility of such a setting. Just to be clear, I'm also not very
> confident about the usefulness of t
Hi Jacob,
Thank you for porting this on top of the pluggable auth methods API. I've
addressed the feedback around other backend changes in my latest patch, but
the client side changes still remain. I had a few questions to understand
them better.
(a) What specifically do the client side changes i
>Can the leader pass a callback that checks PVIndStats to ambulkdelete
>an amvacuumcleanup callbacks? I think that in the passed callback, the
>leader checks if the number of processed indexes and updates its
>progress information if the current progress needs to be updated.
Thanks
On 3/5/22 09:39, Andrew Dunstan wrote:
>
> here's a new set of patches, omitting the GUC patch and with the
> beginnings of some message cleanup - there's more work to do there.
>
>
>
> This patchset restores the RETURNING clause for JSON() and JSON_SCALAR()
> but without the GUC
>
>
I have com
Andrew Dunstan writes:
> Fixed
Now that we got past the hard failures, we can see that the test
falls over with (some?) non-default encodings, as for instance
here:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2022-03-22%2020%3A23%3A13
I can replicate that by running the tes
1 - 100 of 153 matches
Mail list logo
