Ah. It was obvious from the first.
Sorry for the sloppy diagnosis.
At Fri, 20 Nov 2020 16:08:40 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Thu, 19 Nov 2020 15:23:05 +0900 (JST), Kyotaro Horiguchi
> wrote in
> > At Wed, 18 Nov 2020 21:42:02 -0800, Andres Freund
> > wrote in
> > > Hi,
>
On 2020-11-20 06:37, Michael Paquier wrote:
But if you consider materialized views as a variant of normal views,
then the INSERT privilege would be applicable if you pass an INSERT on
the materialized view through to the underlying tables, like for a view.
INSERT to materialized views is not sup
On Mon, Nov 16, 2020 at 11:41:51AM +0100, Magnus Hagander wrote:
> I was referring to the latest patch on the thread. But as I said, I have
> not read up on all the different issues raised in the thread, so take it
> with a big grain os salt.
>
> And I would also echo the previous comment that thi
On 2020-11-19 17:35, Bharath Rupireddy wrote:
So, should we be doing it this way?
For CTAS: retain the existing CREATE privilege check and remove the
INSERT privilege check altogether for all the cases i.e. with data,
with no data, explain analyze, plain, with execute?
For CREATE MATERIALIZED VI
On 2020-11-10 16:21, Georgios Kokolatos wrote:
Hi,
I noticed that this patch fails on the cfbot.
For this, I changed the status to: 'Waiting on Author'.
Cheers,
//Georgios
The new status of this patch is: Waiting on Author
Here is an updated patch to get it building again.
--
Peter Eisentr
Hello Andrew,
I noticed somewhat to my surprise as I was prepping the tests for the
"match the whole DN" patch that pg_ident.conf is parsed using the same
routines used for pg_hba.conf, and as a result the DN almost always
needs to be quoted, because they almost all contain a comma e.g.
"O=PGDG
At Thu, 19 Nov 2020 15:23:05 +0900 (JST), Kyotaro Horiguchi
wrote in
> At Wed, 18 Nov 2020 21:42:02 -0800, Andres Freund wrote
> in
> > Hi,
> >
> > On 2020-11-19 14:25:36 +0900, Kyotaro Horiguchi wrote:
> > > # Creation, searching and expiration
> > > master : 6393.23(100.0)
> > > p
Thanks you for the new version.
At Tue, 17 Nov 2020 18:56:02 +0900, Etsuro Fujita
wrote in
> On Mon, Oct 5, 2020 at 3:35 PM Etsuro Fujita wrote:
> > Yes, if there are no objections from you or Thomas or Robert or anyone
> > else, I'll update Robert's patch as such.
>
> Here is a new version o
On 2020/11/19 20:27, Pavel Borisov wrote:
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I decided to add my re
On Thu, Nov 19, 2020 at 08:47:51AM +0200, Heikki Linnakangas wrote:
> Yeah, I believe it's always been like that. Yeah, arguably it should be
> backpatched. I felt conservative and didn't backpatch, but feel free to do
> it if you think it should be.
+1 for a backpatch. The difference in runtime
On Thu, Nov 19, 2020 at 03:39:51PM +0800, japin wrote:
> In the lwlock.c, InitializeLWLocks() calculate the LWLock offset by itself
> (c319991bcad),
> however, there are macros defined in lwlock.h, I think, we can use the
> macros.
I agree that this makes this code a bit cleaner, so let's use thos
James Hilliard writes:
> On Thu, Nov 19, 2020 at 9:02 PM Tom Lane wrote:
>> True. Also, while actual documentation on -isysroot seems to be damn
>> near nonexistent, all the example usages I can find on the net appear
>> to put it into both compile and link steps. So maybe we're just doing
>> i
Here's a mailing list for Postgres development. Please post user questions to
pgsql-gene...@lists.postgresql.org.
With that said, your system seems to be short of memory.
System Error Codes (1300-1699) (WinError.h) - Win32 apps | Microsoft Docs
https://docs.microsoft.com/en-us/windows/win32/deb
On Thu, Nov 19, 2020 at 10:05:19PM +0530, Bharath Rupireddy wrote:
> On Thu, Nov 19, 2020 at 8:47 PM Peter Eisentraut
> wrote:
>> Materialized views are not in the SQL standard.
>>
>> But if you consider materialized views as a variant of normal views,
>> then the INSERT privilege would be applic
On Thu, Nov 19, 2020 at 9:02 PM Tom Lane wrote:
>
> James Hilliard writes:
> > On Thu, Nov 19, 2020 at 7:48 PM Tom Lane wrote:
> >> Oh, scratch that, I fat-fingered the experiment somehow. The issue
> >> is still there. Still, I'm hesitant to apply the fix you suggest,
> >> because of the law
James Hilliard writes:
> On Thu, Nov 19, 2020 at 7:48 PM Tom Lane wrote:
>> Oh, scratch that, I fat-fingered the experiment somehow. The issue
>> is still there. Still, I'm hesitant to apply the fix you suggest,
>> because of the law of unintended consequences. In particular, I'm
>> afraid tha
On Thu, Nov 19, 2020 at 5:58 PM Masahiko Sawada wrote:
> Several months passed from the discussion. We decided not to do
> anything on back branches but IIUC the fundamental issue is not fixed
> yet. The issue pointed out by Andres that we should leave the index AM
> to decide whether doing vacuum
On Fri, Nov 20, 2020 at 6:02 AM Simon Riggs wrote:
>
> On Wed, 18 Nov 2020 at 02:04, Alvaro Herrera wrote:
> >
> > On 2020-Nov-17, Simon Riggs wrote:
> >
> > > As an additional optimization, if we do find a row that needs freezing
> > > on a data block, we should simply freeze *all* row versions
On Fri, Nov 20, 2020 at 9:12 AM Ajin Cherian wrote:
>
> On Fri, Nov 20, 2020 at 12:23 AM Amit Kapila wrote:
> >
> > On Thu, Nov 19, 2020 at 2:52 PM Ajin Cherian wrote:
> > >
> > > On Thu, Nov 19, 2020 at 5:06 PM Amit Kapila
> > > wrote:
> > >
> > > > I think the same check should be there in t
On Fri, Nov 20, 2020 at 7:54 AM Masahiko Sawada wrote:
>
> On Wed, Nov 18, 2020 at 12:42 PM Amit Kapila wrote:
> >
> > > IIUC logical replication workers always set the origin's commit
> > > timestamp as the commit timestamp of the replicated transaction. OTOH,
> > > the timestamp of PREPARE, ‘pr
On Fri, Nov 20, 2020 at 12:23 AM Amit Kapila wrote:
>
> On Thu, Nov 19, 2020 at 2:52 PM Ajin Cherian wrote:
> >
> > On Thu, Nov 19, 2020 at 5:06 PM Amit Kapila wrote:
> >
> > > I think the same check should be there in truncate as well to make the
> > > APIs consistent and also one can use it fo
On Thu, Nov 19, 2020 at 7:48 PM Tom Lane wrote:
>
> I wrote:
> > However ... it then occurred to me to blow away my ccache and accache,
> > and after rebuilding from scratch, everything's fine. So, are you
> > using ccache?
>
> Oh, scratch that, I fat-fingered the experiment somehow. The issue
>
Hi,
I'm not sure how to reach the cause and reproduce it.
Any suggestion will be appreciated.
PostgreSQL 11.7
postgresql-42.2.12.jar
Windows Server 2016
Thanks,
Kiyoshi
2020-11-13 21:11:51.535 JST [3652] LOG: CreateProcess call failed: A
blocking operation was interrupted by a call to WSACance
I wrote:
> However ... it then occurred to me to blow away my ccache and accache,
> and after rebuilding from scratch, everything's fine. So, are you
> using ccache?
Oh, scratch that, I fat-fingered the experiment somehow. The issue
is still there. Still, I'm hesitant to apply the fix you sugge
On Thu, Nov 19, 2020 at 09:49:05PM +0100, Magnus Hagander wrote:
> Ugh, that's pretty terrible.
I have spent some time testing this part this morning, and I can see
that genhtml does not complain with your patch. It looks like in the
case of 2771fce the tool got confused because the same function
On Thu, Nov 19, 2020 at 7:20 PM Tom Lane wrote:
>
> James Hilliard writes:
> > On Thu, Nov 19, 2020 at 6:04 PM Tom Lane wrote:
> >> The cases we've got in the buildfarm are Xcode 12.0 on Catalina (10.15.7)
> >> and Xcode 12.2 on Big Sur (11.0.1 ... although that one is ARM not Intel).
> >> Maybe
On Wed, Nov 18, 2020 at 12:42 PM Amit Kapila wrote:
>
> On Wed, Nov 18, 2020 at 7:54 AM Masahiko Sawada wrote:
> >
> > On Tue, Nov 17, 2020 at 9:05 PM Amit Kapila wrote:
> > >
> > > On Tue, Nov 17, 2020 at 5:02 PM Ajin Cherian wrote:
> > > >
> > > > On Tue, Nov 17, 2020 at 10:14 PM Amit Kapila
James Hilliard writes:
> On Thu, Nov 19, 2020 at 6:04 PM Tom Lane wrote:
>> The cases we've got in the buildfarm are Xcode 12.0 on Catalina (10.15.7)
>> and Xcode 12.2 on Big Sur (11.0.1 ... although that one is ARM not Intel).
>> Maybe you're found some corner case in between those, but I guess
Dear Li,
> Thanks! Add the comment for idle-session timeout.
I confirmed it. OK.
I don't have any comments anymore. If no one has,
I will change the status few days later.
Other comments or suggestions to him?
Best Regards,
Hayato Kuroda
FUJITSU LIMITED
On Mon, Jun 29, 2020 at 9:51 PM Masahiko Sawada
wrote:
>
> On Sun, 28 Jun 2020 at 02:44, Peter Geoghegan wrote:
> >
> > On Fri, Jun 26, 2020 at 10:15 PM Masahiko Sawada
> > wrote:
> > > Regarding to the extent of the impact, this bug will affect the user
> > > who turned vacuum_index_cleanup off
On Thu, Nov 19, 2020 at 6:04 PM Tom Lane wrote:
>
> James Hilliard writes:
> > Hmm, maybe it's a more recent issue then, I took the version number
> > from the qt patch assuming it was the same issue, I hit it trying to build
> > master on Xcode 12.2 Build version 12B45b on Catalina version 10.15
On Thu, Nov 19, 2020 at 8:02 PM Simon Riggs wrote:
>
> On Wed, 18 Nov 2020 at 17:59, Robert Haas wrote:
> >
> > On Wed, Nov 18, 2020 at 12:54 PM Simon Riggs wrote:
> > > Patches attached.
> > > 1. vacuum_anti_wraparound.v2.patch
> > > 2. vacuumdb_anti_wrap.v1.patch - depends upon (1)
> >
> > I d
Hello
On Friday, Nov 20, 2020 9:33 AM Tsunakawa, Takayuki
wrote:
> From: Kyotaro Horiguchi
> > At Thu, 19 Nov 2020 11:04:17 -0500, Stephen Frost
> > > * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > > > I missed that this is only a warning when I looked at it before.
> > > > Yes, it shou
James Hilliard writes:
> Hmm, maybe it's a more recent issue then, I took the version number
> from the qt patch assuming it was the same issue, I hit it trying to build
> master on Xcode 12.2 Build version 12B45b on Catalina version 10.15.7.
Hm, maybe you're using some unusual configure options
I think I figured it out, it only happens on systems where the Xcode version is
newer than the OS it seems.
See:
https://forum.unity.com/threads/il2cpp-macstandalone-and-xcode-11-4.855187/
So looks like the failure happens due to the system sysroot or something like
that missing symbols from the
On Thu, Nov 19, 2020 at 03:15:21PM -0300, Alvaro Herrera wrote:
> On 2020-Nov-19, Justin Pryzby wrote:
>
> > On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
>
> > > Your patch didn't actually say "try_relation_open", so didn't work.
> > > But it does works if I do that, and close t
Howdy,
Well I certainly wasn't trying to make work out of that blog but I am glad
to see it was productive.
JD
On Thu, Nov 19, 2020 at 2:43 PM Tom Lane wrote:
> After digging a bit more I noticed that we'd discussed removing
> IS OF in the 2007 thread, but forebore because there wasn't an easy
On Thu, Nov 19, 2020 at 5:40 PM Tom Lane wrote:
>
> James Hilliard writes:
> > It would appear weak symbol linking is not handled properly without
> > 'isysroot' parameter passed to linker.
>
> Nobody else has reported this problem, so maybe you should tell us
> how to reproduce it before you sug
James Hilliard writes:
> It would appear weak symbol linking is not handled properly without
> 'isysroot' parameter passed to linker.
Nobody else has reported this problem, so maybe you should tell us
how to reproduce it before you suggest a build process change.
(And yes, we have buildfarm memb
Hi,
On 2020-11-15 17:10:53 +0200, Heikki Linnakangas wrote:
> Yep, quite right. Fixed that way, thanks for the debugging!
I locally, on a heavily modified branch (AIO support), started to get
consistent failures in this test. I *suspect*, but am not sure, that
it's the test's fault, not the fault
On Thu, Nov 19, 2020 at 02:05:35PM +0100, Daniel Gustafsson wrote:
> IIUC, this patchset moves the allocation of the context inside the API rather
> than having the caller be responsible for providing the memory (and thus be
> able to use the stack). This in turn changes the API to returning int r
It would appear weak symbol linking is not handled properly without
'isysroot' parameter passed to linker.
Fixes:
Undefined symbols for architecture x86_64:
"___darwin_check_fd_set_overflow", referenced from:
_ClientAuthentication in auth.o
_pgstat_init in pgstat.o
_ServerLoop
From: Kyotaro Horiguchi
> At Thu, 19 Nov 2020 11:04:17 -0500, Stephen Frost
> > * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > > I missed that this is only a warning when I looked at it before.
> > > Yes, it should be a fatal error.
> >
> > Yeah, the more that I think about it, the more tha
At Thu, 19 Nov 2020 11:04:17 -0500, Stephen Frost wrote in
> Greetings,
>
> * Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> > On Thu, 2020-11-19 at 05:24 +, osumi.takami...@fujitsu.com wrote:
> > > > > > ereport(WARNING,
> > > > > > (errmsg("WAL was generated with wal_level=minim
On Thu, Nov 19, 2020 at 1:50 PM Mark Dilger
wrote:
> It makes sense to me to have a "don't run through minefields" option, and a
> "go ahead, run through minefields" option for pg_amcheck, given that users in
> differing situations will have differing business consequences to bringing
> down th
After digging a bit more I noticed that we'd discussed removing
IS OF in the 2007 thread, but forebore because there wasn't an easy
replacement. pg_typeof() was added a year later (b8fab2411), so we
could have done this at any point since then.
Pushed.
regards, tom lane
On Wed, Nov 18, 2020 at 10:55 AM Thomas Munro wrote:
> > Should this commit be back-ported to earlier versions of postgres to
> > prevent this error in other versions?
>
> Yeah, that seems like a good idea anyway. I will do that tomorrow,
> barring objections.
Done, for 10, 11 and 12.
> On Nov 19, 2020, at 11:47 AM, Peter Geoghegan wrote:
>
>> I think in general you're worrying too much about the possibility of
>> this tool causing backend crashes. I think it's good that you wrote
>> the heapcheck code in a way that's hardened against that, and I think
>> we should try to h
On Thu, Nov 19, 2020 at 12:06 PM Robert Haas wrote:
> I originally intended to review the docs and regression tests in the
> same email as the patch itself, but this email has gotten rather long
> and taken rather longer to get together than I had hoped, so I'm going
> to stop here for now and com
On Thu, Nov 19, 2020 at 2:48 PM Peter Geoghegan wrote:
> Ideally heapallindex verification would verify 1:1 correspondence. It
> doesn't do that right now, but it could.
Well, that might be a cool new mode, but it doesn't necessarily have
to supplant the thing we have now. The problem immediately
On Wed, 18 Nov 2020 at 02:04, Alvaro Herrera wrote:
>
> On 2020-Nov-17, Simon Riggs wrote:
>
> > As an additional optimization, if we do find a row that needs freezing
> > on a data block, we should simply freeze *all* row versions on the
> > page, not just the ones below the selected cutoff. This
On Thu, Nov 19, 2020 at 12:04 PM Michael Paquier wrote:
>
> On Thu, Nov 19, 2020 at 11:00:40AM +0100, Magnus Hagander wrote:
> > I'm thinking the code might get a lot cleaner if we just make a single
> > set of ifdefs, even if that means repeating the function header. In
> > theory we could put th
Hi,
On 2020-11-12 11:40:22 +0100, Gilles Darold wrote:
> The problem we are encountering is when PostgreSQL is compiled in debug
> mode with --enable-cassert. At line 1327 of src/backend/tcop/pquery.c
> the following assert fail:
>
> /*
> * Clear subsidiary contexts to recover temporary
Joe Conway writes:
> On 11/19/20 12:08 PM, Tom Lane wrote:
>> Here's a proposed patch for that. I was amused to discover that we have
>> a couple of regression test cases making use of IS OF.
> I didn't check but those might be my fault ;-)
I suspect at least one of them is mine ;-). But I did
On 11/19/20 12:08 PM, Tom Lane wrote:
> Bruce Momjian writes:
>> On Thu, Nov 19, 2020 at 11:15:33AM -0500, Joe Conway wrote:
>>> On 11/19/20 11:06 AM, Tom Lane wrote:
Let's just rip it out and be done. If anyone is ever
motivated to make it work per spec, they can resurrect
whateve
>> BTW, in your most recent patch:
>> s/empty rows/empty lines/
>> unbalanced parens: "invalid option type (use [+-]"
>>
>
> should be fixed now, thank you for check
>
minor update - fixed handling of processing names with double quotes inside
>
> Regards
>
> Pavel
>
>
>
>> @cfbot: I renamed t
út 17. 11. 2020 v 22:53 odesílatel Justin Pryzby
napsal:
> On Wed, Nov 11, 2020 at 06:49:43AM +0100, Pavel Stehule wrote:
> > Perhaps this feature could co-exist with a full blown configuration for
> > >> pg_dump, but even then there's certainly issues with what's proposed-
> > >> how would you h
On Thu, Nov 19, 2020 at 9:06 AM Robert Haas wrote:
> I'm also not sure if these descriptions are clear enough, but it may
> also be hard to do a good job in a brief space. Still, comparing this
> to the documentation of heapallindexed makes me rather nervous. This
> is only trying to verify that t
I noticed somewhat to my surprise as I was prepping the tests for the
"match the whole DN" patch that pg_ident.conf is parsed using the same
routines used for pg_hba.conf, and as a result the DN almost always
needs to be quoted, because they almost all contain a comma e.g.
"O=PGDG,OU=Testing". Ev
Hello
Thank you! I'm on vacation, so I was finally able to review the patch.
Seems WAIT_EVENT_RECOVERY_PAUSE addition was lost during patch simplification.
> ereport(FATAL,
> (errmsg("recovery aborted because of
> insufficient parameter settings"),
>
On 2020-Nov-19, Justin Pryzby wrote:
> On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
> > Your patch didn't actually say "try_relation_open", so didn't work.
> > But it does works if I do that, and close the table.
Thanks for fixing and testing.
> That patch broke the case that
On Fri, Nov 13, 2020 at 12:11:21PM -0600, Justin Pryzby wrote:
> On Fri, Nov 13, 2020 at 01:39:31PM -0300, Alvaro Herrera wrote:
> > On 2020-Nov-13, Justin Pryzby wrote:
> >
> > > I saw a bunch of these in my logs:
> > >
> > > log_time | 2020-10-25 22:59:45.619-07
> > > database |
> > > left
Hello Tom,
On 2020-11-18 16:49, Tom Lane wrote:
Tels writes:
On 2020-11-18 06:06, Michael Paquier wrote:
On Mon, Nov 16, 2020 at 10:14:10PM -0500, Tom Lane wrote:
Agreed, I'm not trying to block this patch. Just wishing
there were a better way.
To me the code looks like a prime candidate
Bruce Momjian writes:
> On Thu, Nov 19, 2020 at 11:15:33AM -0500, Joe Conway wrote:
>> On 11/19/20 11:06 AM, Tom Lane wrote:
>>> Let's just rip it out and be done. If anyone is ever
>>> motivated to make it work per spec, they can resurrect
>>> whatever seems useful from the git history.
>> +1
On Mon, Oct 26, 2020 at 12:12 PM Mark Dilger
wrote:
> The v20 patches 0002, 0003, and 0005 still apply cleanly, but 0004 required a
> rebase. (0001 was already committed last week.)
>
> Here is a rebased set of 4 patches, numbered 0002..0005 to be consistent with
> the previous naming. There a
On Thu, Nov 19, 2020 at 8:47 PM Peter Eisentraut
wrote:
>
> On 2020-11-17 02:32, Michael Paquier wrote:
> >> The SQL standard says that for CREATE TABLE AS, the INSERT "is effectively
> >> executed without further Access Rule checking", which means the INSERT
> >> privilege shouldn't be required a
On Thu, Nov 19, 2020 at 11:15:33AM -0500, Joe Conway wrote:
> On 11/19/20 11:06 AM, Tom Lane wrote:
> > Let's just rip it out and be done. If anyone is ever
> > motivated to make it work per spec, they can resurrect
> > whatever seems useful from the git history.
>
> +1
+1
--
Bruce Momjian
On 11/19/20 11:06 AM, Tom Lane wrote:
> Let's just rip it out and be done. If anyone is ever
> motivated to make it work per spec, they can resurrect
> whatever seems useful from the git history.
+1
Joe
--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulti
Joe Conway writes:
> Here is a link to previous list discussions:
> https://www.postgresql.org/message-id/45DA44F3.3010401%40joeconway.com
Ah, thanks, I was intending to go do some searching for that.
So at this point this has been re-debated at least three times.
I think it's time to put it out
Greetings,
* Laurenz Albe (laurenz.a...@cybertec.at) wrote:
> On Thu, 2020-11-19 at 05:24 +, osumi.takami...@fujitsu.com wrote:
> > > > > ereport(WARNING,
> > > > > (errmsg("WAL was generated with wal_level=minimal, data may
> > > > > be missing"),
> > > > > errhint("This hap
>
> One thing that doesn't matter is that the modify here seems unnecessary,
> right?
>
> > mdunlinkfork(RelFileNodeBackend rnode, ForkNumber forkNum, bool isRedo)
> > {
> > char *path;
> > - int ret;
> > + int ret = 0;
> > path = relpath(rnode, f
Andy Fan writes:
> create table su (a int, b int);
> insert into su values(1, 1);
> - session 1:
> begin;
> update su set b = 2 where b = 1;
> - sess 2:
> select * from su where a in (select a from su where b = 1) for update;
This'd probably work the way you expect if there were "for update"
in
On 2020-11-17 02:32, Michael Paquier wrote:
The SQL standard says that for CREATE TABLE AS, the INSERT "is effectively
executed without further Access Rule checking", which means the INSERT
privilege shouldn't be required at all. I suggest we consider doing that
instead. I don't see a use for t
Hi All,
There are currently 2 ways as per my knowledge to get the creation time
(CREATE TABLE/FUNCTION/PROC/etc...) or modified time (ALTER ) of an
Object.
1. Using track_commit_timestamp
- Can be a slight overhead as this is applicable globally.
2. Using Event Triggers.
- Does every
On Wed, Nov 18, 2020 at 3:05 PM Tom Lane wrote:
> John Naylor writes:
> > Here are the next couple of sections with items proposed to be moved to
> the
> > "not worth doing" page. As before, if there are any objections, let me
> > know. I'll make the move in a few days.
>
> > - Fix /contrib/ltre
On Wed, Nov 18, 2020 at 2:42 PM Bruce Momjian wrote:
> On Wed, Nov 18, 2020 at 02:26:46PM -0400, John Naylor wrote:
> > Here are the next couple of sections with items proposed to be moved to
> the
> > "not worth doing" page. As before, if there are any objections, let me
> know.
> > I'll make th
On 11/19/20 3:43 AM, tsunakawa.ta...@fujitsu.com wrote:
> From: Tomas Vondra
>> Unfortunately, this does not compile for me, because
>> nodeModifyTable calls ExecGetTouchedPartitions, which is not
>> defined anywhere. Not sure what's that about, so I simply
>> commented-out this. That probably fai
On 11/19/20 2:03 AM, Tom Lane wrote:
> "David G. Johnston" writes:
>> Is there a feature code? I skimmed the standard and non-standard tables in
>> our appendix and couldn’t find this in either.
>
> a19d9d3c4 seems to have thought it was S151.
Here is a link to previous list discussions:
https:
On Thu, Nov 19, 2020 at 2:52 PM Ajin Cherian wrote:
>
> On Thu, Nov 19, 2020 at 5:06 PM Amit Kapila wrote:
>
> > I think the same check should be there in truncate as well to make the
> > APIs consistent and also one can use it for writing another test that
> > has a truncate operation.
>
> Updat
We can reproduce this difference with the following steps.
create table su (a int, b int);
insert into su values(1, 1);
- session 1:
begin;
update su set b = 2 where b = 1;
- sess 2:
select * from su where a in (select a from su where b = 1) for update;
- sess 1:
commit;
Then session 2 can get
> On 13 Nov 2020, at 04:14, Michael Paquier wrote:
> I got to think more about this stuff and attached is a new patch set
> that redesigns the generic interface used for the crypto hash
> functions
I've spent some time on this, and the gist of the patchset is clearly something
we want to do: mov
On Thu, Nov 19, 2020 at 5:39 PM Alexey Kondratov
wrote:
>
> >
> > By clearing the cache entry we will have 2 advantages: 1) we could
> > save a(small) bit of memory 2) we could allow new connections to be
> > cached, currently ConnectionHash can have only 8 entries. IMHO, along
> > with disconnect
On 2020-11-19 07:11, Bharath Rupireddy wrote:
On Wed, Nov 18, 2020 at 10:32 PM Alexey Kondratov
wrote:
Thanks! I will make separate patches and post them soon.
>> Attached is a small POC patch, which implements this contrib-level
>> postgres_fdw.keep_connections GUC. What do you think?
>
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
I decided to add my review to this simple patch.
I applied Fuji's pat
Hi Vignesh,
I took a look at the v10 patch set. Here are some comments:
1.
+/*
+ * CheckExprParallelSafety
+ *
+ * Determine if where cluase and default expressions are parallel safe & do not
+ * have volatile expressions, return true if condition satisfies else return
+ * false.
+ */
'cluase'
On Thu, Nov 19, 2020 at 11:00:40AM +0100, Magnus Hagander wrote:
> I'm thinking the code might get a lot cleaner if we just make a single
> set of ifdefs, even if that means repeating the function header. In
> theory we could put them in different *.c files as well, but that
> seems overkill given
On Wed, 18 Nov 2020 at 17:59, Robert Haas wrote:
>
> On Wed, Nov 18, 2020 at 12:54 PM Simon Riggs wrote:
> > Patches attached.
> > 1. vacuum_anti_wraparound.v2.patch
> > 2. vacuumdb_anti_wrap.v1.patch - depends upon (1)
>
> I don't like the use of ANTI_WRAPAROUND as a name for this new option.
>
[off-list for now]
On Tue, Nov 17, 2020 at 10:21 PM Heikki Linnakangas wrote:
>
> 2. It's difficult for extensions to use. There is a callback mechanism
> for extensions, but it's much less convenient to use than the built-in
> functions. The pgcrypto code uses the callbacks currently, and Micha
On 29/10/2020 19:48, Andres Freund wrote:
On 2020-10-29 10:17:20 +0200, Heikki Linnakangas wrote:
On 28/10/2020 21:59, Andres Freund wrote:
It wouldn't surprise me to see a small execution time speedup here -
I've seen the load of the aggno show up in profiles.
I think you'd be hard-pressed t
On Wed, Nov 18, 2020 at 5:25 PM Heikki Linnakangas wrote:
> On 11/08/2020 03:41, Andres Freund wrote:
> > On 2020-08-10 18:27:17 -0400, Robert Haas wrote:
> >> On Tue, Jun 2, 2020 at 8:25 AM Drouvot, Bertrand
> wrote:
> >>> the patch adds into the LWLock struct:
> >>>
> >>>
Hi all
Here's a patch I wrote a while ago to detect and report when a
LWLockAcquire() results in a simple self-deadlock due to the caller already
holding the LWLock.
To avoid affecting hot-path performance, it only fires the check on the
first iteration through the retry loops in LWLockAcquire()
Hello, Laurenz
On Thursday, Nov19, 2020 4:50 PM Laurenz Albe wrote
> On Thu, 2020-11-19 at 05:24 +, osumi.takami...@fujitsu.com wrote:
> > > > > ereport(WARNING,
> > > > > (errmsg("WAL was generated with wal_level=minimal, data
> > > > > may be missing"),
> > > > > errhint
On Thu, Nov 19, 2020 at 4:34 AM Michael Paquier wrote:
>
> On Wed, Nov 18, 2020 at 10:43:35AM +0100, Daniel Gustafsson wrote:
> > While it does simplify configure.ac, I'm just not a fan of the strict
> > ordering
> > which is required without the labels even implying it. But that might just
> >
On Wed, 18 Nov 2020 at 22:37, Tomas Vondra
wrote:
>
> Seems fine to me, although the "_opt_ext_stats" is rather cryptic.
> AFAICS we use "_internal" for similar functions.
>
There's precedent for using "_opt_xxx" for function variants that add
an option to existing functions, but I agree that in
> On 19 Nov 2020, at 02:37, Michael Paquier wrote:
>
> On Wed, Nov 18, 2020 at 10:19:40AM +0100, Daniel Gustafsson wrote:
>> I agree that we should fix this even if it will have quite limited impact in
>> production settings. Patch LGTM, +1.
>
> Thanks. I have reviewed that again this morning
hi, Kuroda
On 11/19/20 4:32 PM, kuroda.hay...@fujitsu.com wrote:
Dear Li,
Thanks for your suggestion. Attached!
I prefer your comments:-).
I think this patch is mostly good.
I looked whole the codes again and I found the following comment in the
PostgresMain():
```c
/*
On Thu, Nov 19, 2020 at 10:16 AM Michael Paquier wrote:
>
> On Wed, Nov 18, 2020 at 10:50:08AM +0200, Heikki Linnakangas wrote:
> > If RESOWNER_ARRAY_STATS is increased to 16, all the lookups fit in the
> > array. But I haven't done any benchmarking to see which is faster.
>
> My gut tells me that
> On 19 Nov 2020, at 04:34, Michael Paquier wrote:
>
> On Wed, Nov 18, 2020 at 10:43:35AM +0100, Daniel Gustafsson wrote:
>> While it does simplify configure.ac, I'm just not a fan of the strict
>> ordering
>> which is required without the labels even implying it. But that might just
>> be
>>
On 2020-11-17 20:33, Tom Lane wrote:
Peter Eisentraut writes:
I wrote a new patch to add a lot more tests around hash-based plans.
This is intended to apply separately from the other patch, and the other
patch would then "flip" some of the test cases.
OK, that addresses my concerns.
Thanks.
Hi, I’ve run a couple of pgbenchmarks using this patch with odyssey connection pooler, with client-to-pooler ZSTD compression turned on. pgbench --builtin tpcb-like -t 75 --jobs=32 --client=1000 CPU utilization chart of the configuration above:https://storage.yandexcloud.net/usernamedt/odyssey-comp
1 - 100 of 104 matches
Mail list logo
