On Fri, Jan 29, 2021 at 1:17 PM Fujii Masao wrote:
> >> But if the issue is only the inconsistency of test results,
> >> we can go with the option (2)? Even with (2), we can make the test
> >> stable by removing "valid" column and executing
> >> postgres_fdw_get_connections() within the transactio
On 2021/01/29 16:12, Bharath Rupireddy wrote:
On Fri, Jan 29, 2021 at 12:36 PM Fujii Masao
wrote:
On 2021/01/29 15:44, Bharath Rupireddy wrote:
On Fri, Jan 29, 2021 at 11:54 AM Fujii Masao
wrote:
IIRC, when we were finding a way to close the invalidated connections
so that they don't leak
On Tue, Jan 26, 2021 at 2:46 AM Tommy Li wrote:
>
> Hi Stephen
>
> > ... can set vacuum options on a table level which autovacuum should respect,
> > such as vacuum_index_cleanup and vacuum_truncate. For skip locked,
> > autovacuum already will automatically release it's attempt to acquire a
> >
On Wed, Jan 27, 2021 at 02:52:14PM +0900, Michael Paquier wrote:
> And attached is a patch to clarify all that. I am letting that sleep
> for a couple of days for now, so please let me know if you have any
> comments.
I have spent some time on that, and applied this stuff as of 2a5862f
after some
On Thu, Jan 28, 2021 at 06:16:09PM +, Bossart, Nathan wrote:
> I chose TOAST_TABLE_CLEANUP to match the INDEX_CLEANUP option, but I'm
> not wedded to that name. What do you think about PROCESS_TOAST_TABLE?
Most of the other options use a verb, so using PROCESS, or even SKIP
sounds like a good
On Fri, Jan 29, 2021 at 12:36 PM Fujii Masao
wrote:
> On 2021/01/29 15:44, Bharath Rupireddy wrote:
> > On Fri, Jan 29, 2021 at 11:54 AM Fujii Masao
> > wrote:
> IIRC, when we were finding a way to close the invalidated connections
> so that they don't leaked, we had two options:
>
On 2021/01/29 15:44, Bharath Rupireddy wrote:
On Fri, Jan 29, 2021 at 11:54 AM Fujii Masao
wrote:
IIRC, when we were finding a way to close the invalidated connections
so that they don't leaked, we had two options:
1) let those connections (whether currently being used in the xact or
not) g
> Hi,
>
> Attatching v1 patches, introducing options which let user manually control
> whether to use parallel dml.
>
> About the patch:
> 1. add a new guc option: enable_parallel_dml (boolean) 2. add a new
> tableoption: parallel_dml (boolean)
>
>The default of both is off(false).
>
> User
On Fri, Jan 29, 2021 at 11:54 AM Fujii Masao
wrote:
> >> IIRC, when we were finding a way to close the invalidated connections
> >> so that they don't leaked, we had two options:
> >>
> >> 1) let those connections (whether currently being used in the xact or
> >> not) get marked invalidated in pgf
Hi,
Attatching v1 patches, introducing options which let user manually control
whether to use parallel dml.
About the patch:
1. add a new guc option: enable_parallel_dml (boolean)
2. add a new tableoption: parallel_dml (boolean)
The default of both is off(false).
User can set enable_paralle
On Fri, Jan 22, 2021, at 16:42, Tom Lane wrote:
>"Joel Jacobson" writes:
>> I ran this query (on a patched database) to see if there are still any
>> catalog tables without primary keys:
>> ...
>> pg_depend
>> pg_shdepend
>
>Yeah, this is noted in the patch's own regression tests.
Thanks. Looks
On 2021/01/29 14:46, Bharath Rupireddy wrote:
On Fri, Jan 29, 2021 at 11:08 AM Bharath Rupireddy
wrote:
On Fri, Jan 29, 2021 at 10:55 AM Fujii Masao
wrote:
On 2021/01/29 14:12, Bharath Rupireddy wrote:
On Fri, Jan 29, 2021 at 10:28 AM Fujii Masao
wrote:
On 2021/01/29 11:09, Tom Lane wr
On Fri, Jan 29, 2021 at 11:38 AM Fujii Masao
wrote:
> On 2021/01/29 14:53, Bharath Rupireddy wrote:
> > On Fri, Jan 29, 2021 at 10:55 AM Fujii Masao
> > wrote:
> BTW, even if we change pgfdw_inval_callback() so that it doesn't close
> the connection at all, ISTM that the results of
> >
Hi Mark,
On Thu, Jan 28, 2021, at 22:41, Mark Rofail wrote:
>Please find v16 with the error message implemented. You can find it in the
>previous message.
Thanks! It's working fine:
ERROR: (int2vector) is not an array type, cannot be used as a referencing
column
I've pushed a first working dr
On 2021/01/29 14:53, Bharath Rupireddy wrote:
On Fri, Jan 29, 2021 at 10:55 AM Fujii Masao
wrote:
BTW, even if we change pgfdw_inval_callback() so that it doesn't close
the connection at all, ISTM that the results of postgres_fdw_get_connections()
would not be stable because entry->invalidat
On Fri, Jan 29, 2021 at 12:20:21AM +0100, Daniel Gustafsson wrote:
> SSL is admittedly an obsolete technical term, but it's one that enough people
> have decided is interchangeable with TLS that it's not a hill worth dying on
> IMHO. Since postgres won't allow for using libnss or OpenSSL for crypt
On Fri, Jan 29, 2021 at 10:55 AM Fujii Masao
wrote:
> >> BTW, even if we change pgfdw_inval_callback() so that it doesn't close
> >> the connection at all, ISTM that the results of
> >> postgres_fdw_get_connections()
> >> would not be stable because entry->invalidated would vary based on
> >> whe
On Sat, Jan 23, 2021 at 3:46 AM Paul Martinez wrote:
>
>
> Unless I'm mistaken, the apply worker process runs as the user that created
> the subscription. Thus, it is the requirement that only superusers can create
> subscriptions that leads to two warnings in the Security documentation:
>
> https
On Fri, Jan 29, 2021 at 11:08 AM Bharath Rupireddy
wrote:
>
> On Fri, Jan 29, 2021 at 10:55 AM Fujii Masao
> wrote:
> > On 2021/01/29 14:12, Bharath Rupireddy wrote:
> > > On Fri, Jan 29, 2021 at 10:28 AM Fujii Masao
> > > wrote:
> > >> On 2021/01/29 11:09, Tom Lane wrote:
> > >>> Bharath Rupire
Thanks for having a look at this.
I've taken most of your suggestions. The things quoted below are just
the ones I didn't agree with or didn't understand.
On Thu, 28 Jan 2021 at 18:43, Justin Pryzby wrote:
>
> On Tue, Dec 08, 2020 at 08:15:52PM +1300, David Rowley wrote:
> > +typedef struct Esti
On Fri, Jan 29, 2021 at 10:55 AM Fujii Masao
wrote:
> On 2021/01/29 14:12, Bharath Rupireddy wrote:
> > On Fri, Jan 29, 2021 at 10:28 AM Fujii Masao
> > wrote:
> >> On 2021/01/29 11:09, Tom Lane wrote:
> >>> Bharath Rupireddy writes:
> On Fri, Jan 29, 2021 at 1:52 AM Tom Lane wrote:
>
On 2021/01/29 14:12, Bharath Rupireddy wrote:
On Fri, Jan 29, 2021 at 10:28 AM Fujii Masao
wrote:
On 2021/01/29 11:09, Tom Lane wrote:
Bharath Rupireddy writes:
On Fri, Jan 29, 2021 at 1:52 AM Tom Lane wrote:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2021-01-2
On Fri, Jan 29, 2021 at 10:42 AM Bharath Rupireddy
wrote:
> > > Also, now that I've looked at pgfdw_inval_callback, it scares
> > > the heck out of me. Actually disconnecting a connection during
> > > a cache inval callback seems quite unsafe --- what if that happens
> > > while we're using the c
2021年1月28日(木) 17:18 Peter Eisentraut :
> On 2021-01-12 06:53, Ian Lawrence Barwick wrote:
> > postgres=# SELECT has_column_privilege('foo', 999::int2, 'SELECT');
> > has_column_privilege
> > --
> > t
> > (1 row)
> >
> > The comment on the relevant cod
On Fri, Jan 29, 2021 at 10:28 AM Fujii Masao
wrote:
> On 2021/01/29 11:09, Tom Lane wrote:
> > Bharath Rupireddy writes:
> >> On Fri, Jan 29, 2021 at 1:52 AM Tom Lane wrote:
> >>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2021-01-26%2019%3A59%3A40
> >>> This is a CLOBB
On 2021/01/29 11:09, Tom Lane wrote:
Bharath Rupireddy writes:
On Fri, Jan 29, 2021 at 1:52 AM Tom Lane wrote:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2021-01-26%2019%3A59%3A40
This is a CLOBBER_CACHE_ALWAYS build, so I suspect what it's
telling us is that the
On Fri, Jan 29, 2021 at 9:47 AM Neha Sharma
wrote:
>
> Hi,
>
> I have been testing the patches for a while , below is the code coverage
> observed on the v19 patches.
>
> Sr NoFile nameCode Coverage
> BeforeAfter
> Line %Function %Line %Function %
> 1src/backend/access/brin/brin_tuple.c96.710096.
Hi,
I have been testing the patches for a while , below is the code coverage
observed on the v19 patches.
Sr No File name Code Coverage
Before After
Line % Function % Line % Function %
1 src/backend/access/brin/brin_tuple.c 96.7 100 96.7 100
2 src/backend/access/common/detoast.c 88 100 88.6 100
On Thu, Jan 28, 2021 at 1:51 PM Paul Martinez wrote:
>
> Hey, all,
>
> When creating a logical replication connection that isn't allowed by the
> current pg_hba.conf, the error message states that a "replication
> connection" is not allowed.
>
> This error message is confusing because although the
Hi,
Just found another crash.
Seems that commit a929e17e5a8c9b751b66002c8a89fdebdacfe194 broke something.
Attached is a minimal case and the stack trace.
--
Jaime Casanova
Director de Servicios Profesionales
SystemGuards - Consultores de PostgreSQL
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/
From: Jamison, Kirk/ジャミソン カーク
> I realized that existing libpq regression tests in src/test/examples do not
> test PQtrace(). At the same time, no other functions Is calling PQtrace(),
> so it's expected that by default if there are no compilation errors, then it
> will pass all the tests. And it
Bharath Rupireddy writes:
> On Fri, Jan 29, 2021 at 1:52 AM Tom Lane wrote:
>> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=trilobite&dt=2021-01-26%2019%3A59%3A40
>> This is a CLOBBER_CACHE_ALWAYS build, so I suspect what it's
>> telling us is that the patch's behavior is unstable in t
On Fri, Jan 29, 2021 at 11:13 AM Thomas Munro wrote:
> On Thu, Jan 28, 2021 at 8:36 PM Michael Paquier wrote:
> > On Wed, Jan 27, 2021 at 05:08:56PM +0900, Fujii Masao wrote:
> > > But one question is; shouldn't we follow "usual" way to retire the
> > > feature instead of dropping that immediatel
On Fri, Jan 29, 2021 at 1:52 AM Tom Lane wrote:
>
> Bharath Rupireddy writes:
> > On Tue, Jan 26, 2021 at 1:55 PM Fujii Masao
> > wrote:
> >> Thanks for the patch! I also created that patch, confirmed that the test
> >> successfully passed with -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS,
> >>
On Thu, 2021-01-21 at 20:16 +, Jacob Champion wrote:
> I think we're missing a counterpart to this piece of the OpenSSL
> implementation, in be_tls_init():
Never mind. Using SSL_SetTrustAnchor is something we could potentially
do if we wanted to further limit the CAs that are actually sent to
> > Hi
> >
> > I have an issue about the parameter for DML.
> >
> > If we define the parameter as a tableoption.
> >
> > For a partitioned table, if we set the parent table's parallel_dml=on,
> > and set one of its partition parallel_dml=off, it seems we can not divide
> the plan for the separate t
From: Jamison, Kirk/ジャミソン カーク
> To make the CFBot happy, I fixed the compiler errors.
> I have not included here the change proposal to move the tracing functions to
> a
> new file: fe-trace.c or something, so I retained the changes .
> Maybe Iwata-san can consider the proposal.
> Current
Alexander Korotkov writes:
> The patch, which clarifies this situation in the docs is attached.
> I'm going to push it if no objections.
+1, but the English in this seems a bit shaky. Perhaps more
like the attached?
regards, tom lane
diff --git a/doc/src/sgml/func.sgml
> On 28 Jan 2021, at 07:06, Michael Paquier wrote:
> On Wed, Jan 27, 2021 at 06:47:17PM +, Jacob Champion wrote:
>> Since SSL is an obsolete term, and the choice of OpenSSL vs NSS vs
>> [nothing] affects server operation (such as cryptohash) regardless of
>> whether or not connection-level TL
On Thu, Jan 28, 2021 at 8:36 PM Michael Paquier wrote:
> On Wed, Jan 27, 2021 at 05:08:56PM +0900, Fujii Masao wrote:
> > But one question is; shouldn't we follow "usual" way to retire the
> > feature instead of dropping that immediately? That is, mark
> > pg_standby as obsolete, announce that pg_
On 1/28/21 11:39 AM, Jacob Champion wrote:
> On Wed, 2021-01-27 at 15:42 -0500, Andrew Dunstan wrote:
>> I'm not sure where we want to go with the present patch. Do we want to
>> go with what we have and document the limitations more, or try to do
>> something more elaborate? If so, exactly what?
On Mon, Jan 25, 2021 at 6:33 PM Alexander Korotkov wrote:
> On Thu, Jan 21, 2021 at 4:35 PM Alvaro Herrera
> wrote:
> > On 2021-Jan-21, Alexander Korotkov wrote:
> >
> > > Requiring strict mode for ** is a solution, but probably too
> > > restrictive...
> > >
> > > What do you think about makin
Hello Joel,
This means, as a user, I might not be aware of the vector restriction when
> adding the foreign keys
> for my existing schema, and think everything is fine, and not realize
> there is a problem until
> new data arrives.
>
Please find v16 with the error message implemented. You can find
Bharath Rupireddy writes:
> On Tue, Jan 26, 2021 at 1:55 PM Fujii Masao
> wrote:
>> Thanks for the patch! I also created that patch, confirmed that the test
>> successfully passed with -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS,
>> and pushed the patch.
> Thanks a lot!
Seems you're not out of
On Thu, Jan 28, 2021 at 02:41:09PM -0500, Tom Kincaid wrote:
> I would also like to add a "not wanted" entry for this feature on the
> TODO list, baaed on the feature's limited usefulness, but I already
> asked about that and no one seems to feel we don't want it.
>
>
> I want to avoi
Hello,
> > I don't think it makes sense to think about committing this to v14. I
> > believe it only makes sense if we have a TDE patch that is relatively
> > close to committable that can be used with it. I also don't think that
> > this patch is in good enough shape to commit yet in terms of wh
Hello all,
First, the context: recently I've been digging into the use of third-
party authentication systems with Postgres. One sticking point is the
need to have a Postgres role corresponding to the third-party user
identity, which becomes less manageable at scale. I've been trying to
come up wi
On 1/27/21, 5:08 PM, "Justin Pryzby" wrote:
> Thanks, I wrote my message after running into the issue and remembered this
> thread. I didn't necessarily mean to send another patch :)
No worries. I lost track of this thread, but I don't mind picking it
up again.
> My only comment is on the name
Hello, Peter.
> I wonder if it would help to not actually use the LP_DEAD bit for
> this. Instead, you could use the currently-unused-in-indexes
> LP_REDIRECT bit.
Hm… Sound very promising - an additional bit is a lot in this situation.
> Whether or not "recently dead" means "dead to my
> parti
> On Jan 28, 2021, at 9:41 AM, Mark Dilger wrote:
>
>
>
>> On Jan 28, 2021, at 9:13 AM, Robert Haas wrote:
>>
>> I like 0007 quite a bit and am inclined to commit it soon, as it
>> doesn't depend on the earlier patches. But:
>>
>> - I think the residual comment in processSQLNamePattern beg
On Thu, Jan 28, 2021 at 9:30 AM Robert Haas wrote:
> On Thu, Jan 14, 2021 at 8:09 PM Peter Geoghegan wrote:
> > So dirty pages are debt that VACUUM can easily create, whereas buffer
> > misses are paid directly by VACUUM. It is its own backpressure, for
> > the most part. Making the costing stuff
> On Jan 28, 2021, at 9:49 AM, Robert Haas wrote:
>
> On Thu, Jan 28, 2021 at 12:40 PM Mark Dilger
> wrote:
>>> On Jan 28, 2021, at 9:13 AM, Robert Haas wrote:
>>> If I run pg_amcheck --all -j4 do I get a serialization boundary across
>>> databases? Like, I have to completely finish db1 befo
On Thu, Jan 28, 2021 at 12:40 PM Mark Dilger
wrote:
> > On Jan 28, 2021, at 9:13 AM, Robert Haas wrote:
> > If I run pg_amcheck --all -j4 do I get a serialization boundary across
> > databases? Like, I have to completely finish db1 before I can go onto
> > db2, even though maybe only one worker i
> On Jan 28, 2021, at 9:13 AM, Robert Haas wrote:
>
> I like 0007 quite a bit and am inclined to commit it soon, as it
> doesn't depend on the earlier patches. But:
>
> - I think the residual comment in processSQLNamePattern beginning with
> "Note:" could use some wordsmithing to account for
> On Jan 28, 2021, at 9:13 AM, Robert Haas wrote:
>
> If I run pg_amcheck --all -j4 do I get a serialization boundary across
> databases? Like, I have to completely finish db1 before I can go onto
> db2, even though maybe only one worker is still busy with it?
Yes, you do. That's patterned o
On Thu, Jan 14, 2021 at 8:09 PM Peter Geoghegan wrote:
> So dirty pages are debt that VACUUM can easily create, whereas buffer
> misses are paid directly by VACUUM. It is its own backpressure, for
> the most part. Making the costing stuff highly sensitive to dirtying
> pages (but not sensitive to
I like 0007 quite a bit and am inclined to commit it soon, as it
doesn't depend on the earlier patches. But:
- I think the residual comment in processSQLNamePattern beginning with
"Note:" could use some wordsmithing to account for the new structure
of things -- maybe just "this pass" -> "this func
Peter Eisentraut writes:
> I have studied this patch and this functionality. I don't think
> collation differences between remote and local instances are handled
> sufficiently. This bug report and patch addresses one particular case,
> where the database-wide collation of the remote and loca
On Wed, 2021-01-27 at 15:42 -0500, Andrew Dunstan wrote:
> I'm not sure where we want to go with the present patch. Do we want to
> go with what we have and document the limitations more, or try to do
> something more elaborate? If so, exactly what?
After sleeping on it:
I think that if you expec
> On Thu, Jan 28, 2021 at 09:49:26PM +0900, Masahiko Sawada wrote:
> Hi Dmitry,
>
> Status update for a commitfest entry.
>
> This patch entry has been "Waiting on Author" on CF app and the
> discussion seems inactive from the last CF. Could you share the
> current status of this patch? Heikki alre
On 2021-Jan-26, Tom Lane wrote:
> Alvaro Herrera writes:
> > pgbench has one occurrence of the old pattern in master, in line 6043.
> > However, since doConnect() returns NULL when it gets CONNECTION_BAD,
> > that seems dead code. This patch kills it.
>
> Oh ... I missed that because it wasn't
On 1/28/21 9:24 AM, Alvaro Herrera wrote:
> On 2021-Jan-28, Andrew Dunstan wrote:
>
> ... neat stuff, thanks.
>
>> +# Windows picks up DLLs from the PATH rather than
>> *LD_LIBRARY_PATH
>> +# choose the right path separator
>> +if ($Config{osname} eq 'MSWin32')
On Thu, Jan 28, 2021 at 09:51:51PM +0900, Masahiko Sawada wrote:
> On Mon, Nov 30, 2020 at 5:22 AM Justin Pryzby wrote:
> > On Sat, Oct 31, 2020 at 01:31:17AM -0500, Justin Pryzby wrote:
> > > Forking this thread, since the existing CFs have been closed.
> > > https://www.postgresql.org/message-id
On 2021-Jan-28, Andrew Dunstan wrote:
... neat stuff, thanks.
> +# Windows picks up DLLs from the PATH rather than
> *LD_LIBRARY_PATH
> +# choose the right path separator
> +if ($Config{osname} eq 'MSWin32')
> +{
> + $ENV{PATH} = "$in
On 2021-Jan-28, k.jami...@fujitsu.com wrote:
> I realized that existing libpq regression tests in src/test/examples do not
> test PQtrace(). At the same time, no other functions Is calling PQtrace(),
> so it's expected that by default if there are no compilation errors, then it
> will pass all the
On Thu, Jan 28, 2021 at 5:22 PM vignesh C wrote:
> Thanks for the comments, I have fixed and attached an updated patch
> with the fixes for the same.
> Thoughts?
Thanks for the patch. Here are few comments:
1) I think it's return SIGNAL_BACKEND_SUCCESS; instead of return 0; in
check_valid_pid?
On 1/13/21 7:56 AM, Andrew Dunstan wrote:
> On 1/11/21 9:34 AM, Peter Eisentraut wrote:
>> On 2020-12-20 18:09, Andrew Dunstan wrote:
>>> On 12/19/20 11:19 AM, Andrew Dunstan wrote:
This turns out to be remarkably short, with the use of a little eval
magic.
Give the attached, t
On Thu, 28 Jan 2021 at 12:53, Masahiko Sawada wrote:
> This entry has been "Waiting on Author" status and the patch has not
> been updated since Nov 30. Are you still planning to work on this?
Yes, new patch version tomorrow. Thanks for the nudge and the review.
--
Simon Riggsh
On 28/01/2021 01:23, John Naylor wrote:
Hi Heikki,
0001 through 0003 are straightforward, and I think they can be committed
now if you like.
0004 is also pretty straightforward. The check you proposed upthread for
pg_upgrade seems like the best solution to make that workable. I'll take
a lo
Hi Simon,
On Mon, Jan 4, 2021 at 11:45 PM Masahiko Sawada wrote:
>
> On Tue, Dec 1, 2020 at 10:45 AM Masahiko Sawada wrote:
> >
> > On Fri, Nov 20, 2020 at 8:47 PM Simon Riggs wrote:
> > >
> > > On Fri, 20 Nov 2020 at 10:15, Simon Riggs wrote:
> > > >
> > > > On Fri, 20 Nov 2020 at 01:40, Masa
On Mon, Nov 30, 2020 at 5:22 AM Justin Pryzby wrote:
>
> On Sat, Oct 31, 2020 at 01:31:17AM -0500, Justin Pryzby wrote:
> > Forking this thread, since the existing CFs have been closed.
> > https://www.postgresql.org/message-id/flat/20200914143102.GX18552%40telsasoft.com#58b1056488451f8594b0f0ba40
On Sat, Nov 28, 2020 at 5:49 AM Tom Lane wrote:
>
> Heikki Linnakangas writes:
> > Other than that, and a quick pgdindent run, this seems ready to me. I'll
> > mark it as Ready for Committer.
>
> I dunno, this seems largely misguided to me.
>
> It's already the case that index correlation is just
On Tue, Dec 1, 2020 at 4:09 AM Tom Lane wrote:
>
> Justin Pryzby writes:
> > I think this is waiting on me to provide a patch for the contrib/ modules
> > with
> > update script removing the SQL operators, and documentating their
> > deprecation.
>
> Right. We can remove the SQL operators, but
Hi Dmitry,
On Sun, Oct 25, 2020 at 1:45 AM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Tue, Oct 06, 2020 at 05:20:39PM +0200, Dmitry Dolgov wrote:
> > > On Mon, Sep 21, 2020 at 05:59:32PM -0700, Peter Geoghegan wrote:
> > >
> > > * I see the following compiler warning:
> > >
> > > /code/
Hello,
On Thu, 12 Nov 2020 23:10:05 +0300
e.sokol...@postgrespro.ru wrote:
> New version of this patch prints extra statistics for all cases of
> multiple loops, not only for Nested Loop. Also I fixed the example by
> adding VERBOSE.
I think this extra statistics seems good because it is usefu
On 2020-08-18 22:09, Tom Lane wrote:
Here's a full patch addressing this issue. I decided that the best
way to address the test-instability problem is to explicitly give
collations to all the foreign-table columns for which it matters
in the postgres_fdw test. (For portability's sake, that has
On Thu, Jan 28, 2021 at 5:00 PM Hou, Zhijie wrote:
>
> > From: Amit Kapila
> > > Good question. I think if we choose to have a separate parameter for
> > > DML, it can probably a boolean to just indicate whether to enable
> > > parallel DML for a specified table and use the parallel_workers
> > >
On Wed, Jan 27, 2021 at 10:40 PM Andres Freund wrote:
>
> Hi,
>
> On 2021-01-27 19:05:16 +0530, vignesh C wrote:
>
> > /*
> > + * LogBackTrace
> > + *
> > + * Get the backtrace and log the backtrace to log file.
> > + */
> > +void
> > +LogBackTrace(void)
> > +{
> > + int s
On 2021-01-28 00:36, Alvaro Herrera wrote:
On 2021-Jan-28, Alexey Kondratov wrote:
I have read more about lock levels and ShareLock should prevent any
kind of
physical modification of indexes. We already hold ShareLock doing
find_all_inheritors(), which is higher than ShareUpdateExclusiveLock,
Hi all,
We're about 3 days from the end of this Commitfest. The current status is:
Needs review: 150 (+1)
Waiting on Author: 24 (-5)
Ready for Committer: 24 (+0)
Committed: 52 (+2)
Withdrawn: 8 (+0)
Moved to next CF: 2 (+2)
This weekend, I'm planning to look through Waiting-on-Author patches
and
On 28/01/2021 01:23, John Naylor wrote:
Hi Heikki,
0001 through 0003 are straightforward, and I think they can be committed
now if you like.
Thanks for the review!
I did some more rigorous microbenchmarking of patch 1 and 2. I used the
attached test script, which calls convert_from() functi
> From: Amit Kapila
> > Good question. I think if we choose to have a separate parameter for
> > DML, it can probably a boolean to just indicate whether to enable
> > parallel DML for a specified table and use the parallel_workers
> > specified in the table used in SELECT.
>
> Agreed.
Hi
I have
> 22 янв. 2021 г., в 07:48, Justin Pryzby написал(а):
>
> @cfbot: rebased
> <0001-Reorganize-pglz-compression-code.patch>
Thanks!
I'm experimenting with TPC-C over PostgreSQL 13 on production-like cluster in
the cloud. Overall performance is IO-bound, but compression is burning a lot
energ
On Thu, Jan 28, 2021 at 12:32 PM Peter Smith wrote:
>
> On Wed, Jan 27, 2021 at 2:53 PM Amit Kapila wrote:
> >
> > On Sat, Jan 23, 2021 at 5:56 PM Amit Kapila wrote:
> > >
> > > On Sat, Jan 23, 2021 at 4:55 AM Peter Smith wrote:
> > > >
> > > > PSA the v18 patch for the Tablesync Solution1.
> >
On Mon, January 25, 2021 4:13 PM (JST), Tsunakawa-san wrote:.
> Also, please note this as:
>
> > Also, why don't you try running the regression tests with a temporary
> modification to PQtrace() to output the trace to a file? The sole purpose is
> to confirm that this patch doesn't make the test
On 28.01.2021 5:47, Amit Kapila wrote:
On Mon, Dec 28, 2020 at 5:46 PM Masahiko Sawada wrote:
On Sat, Dec 26, 2020 at 4:04 PM Pavel Stehule wrote:
so 26. 12. 2020 v 8:00 odesílatel Pavel Stehule
napsal:
Hi
Thank you.
I have applied all your fixes in on_connect_event_trigger-12.patc
At Wed, 27 Jan 2021 23:10:53 -0800, Noah Misch wrote in
> On Thu, Jan 28, 2021 at 12:06:27PM +0900, Kyotaro Horiguchi wrote:
> > At Wed, 27 Jan 2021 02:48:48 -0800, Noah Misch wrote in
> > > On Thu, Jan 21, 2021 at 01:23:36AM -0800, Noah Misch wrote:
> > > > On Thu, Jan 21, 2021 at 06:02:11PM +
Hey, all,
When creating a logical replication connection that isn't allowed by the
current pg_hba.conf, the error message states that a "replication
connection" is not allowed.
This error message is confusing because although the user is trying to
create a replication connection and specified "re
On 2021-01-12 06:53, Ian Lawrence Barwick wrote:
postgres=# SELECT has_column_privilege('foo', 999::int2, 'SELECT');
has_column_privilege
--
t
(1 row)
The comment on the relevant code section in "src/backend/utils/adt/acl.c"
(related to "column_priv
At Thu, 28 Jan 2021 16:50:44 +0900 (JST), Kyotaro Horiguchi
wrote in
> I was going to write in the doc something like "you can inspect memory
> consumption by catalog caches using pg_backend_memory_contexts", but
> all the memory used by catalog cache is in CacheMemoryContext. Is it
> sensible
90 matches
Mail list logo
