On Tue, Sep 22, 2020 at 5:15 PM Dilip Kumar wrote:
>
> On Tue, Sep 22, 2020 at 12:02 PM Amit Kapila wrote:
> >
> >
> > I am not sure if this suggestion makes it better than what is purposed
> > by Dilip but I think we can declare them in define number order like
> > below:
> > #define LOGICALREP_
On Mon, Aug 17, 2020 at 05:47:13PM +0200, Drouvot, Bertrand wrote:
> I think it's good to guarantee that we'll always see the same piece of
> information (should a new RM desc() be created in the future for example),
> even if it could lead to some information overlap in some cases.
> I am ok too,
On Thu, Sep 24, 2020 at 2:39 AM Fujii Masao wrote:
> Does this patch work fine with warm-standby case using pg_standby?
> IIUC the startup process doesn't call WaitLatch() in that case, so ISTM that,
> with the patch, it cannot detect the postmaster death immediately.
Right, RestoreArchivedFile()
On Thu, Sep 24, 2020 at 4:25 AM Etsuro Fujita wrote:
> On Wed, Sep 23, 2020 at 10:12 PM Amit Langote wrote:
> > On Sun, Sep 20, 2020 at 11:41 PM Etsuro Fujita
> > wrote:
> > > On Mon, Sep 14, 2020 at 10:45 PM Amit Langote
> > > wrote:
> > > > Although, I am still not sure how to
> > > > "copy
Hi,
In (src/test/regress/sql/aggregates.sql)
I found some tables is not dropped at the end of the sqlscript,
It does not hava any problem, but I think it's better to drop the table in time.
Please see the attachment for the patch.
Best regards,
Houzj
0001-enhance-test-for-hashdisk.patch
De
> On 09/23/2020 9:26 PM Tom Lane wrote:
> ...
> > The hook I'd like to see would be in the PostgresMain() loop
> > for the API "firstchar" messages.
>
> What, to invent your own protocol? Where will you find client libraries
> buying into that?
No API/client changes are needed for:
1) API
On Thu, Sep 24, 2020 at 1:54 PM Michael Paquier wrote:
>
> On Thu, Sep 24, 2020 at 04:25:24AM +0900, Etsuro Fujita wrote:
> > Sorry, my thought was vague. To store xmin/xmax/cmin/cmax into a
> > given slot, we need to extend the TupleTableSlot struct to contain
> > these attributes as well? Or w
Hi,
Both are probably not needed.
I would prefer it accessible in a view live
Event | date | victims
Eviction...
Reset...
Part reset ...
As there are other needs to track reset times.
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html
On Thu, 24 Sep 2020 at 16:26, Tom Lane wrote:
>
> Daniel Wood writes:
> > Hooks exist all over PG for extensions to cover various specific usages.
> > The hook I'd like to see would be in the PostgresMain() loop
> > for the API "firstchar" messages.
>
> What, to invent your own protocol? Where w
On Wed, Sep 23, 2020 at 06:11:06PM -0300, Fabrízio de Royes Mello wrote:
> Adding a TOAST can cause circular dependencies between those relations?? If
> you don't mind can you explain more about it?
The difficult task here is to make sure that we don't have any corner
cases that begin to break bec
2020-09-22 04:58 に Andres Freund さんは書きました:
Hi,
On 2020-09-18 17:55:12 +0900, btnakamichin wrote:
I’m thinking of adding adding a function called
pg_stat_statements_reset_time() that returns the last timestamp when
executed pg_stat_statements_reset(). pg_stat_statements can reset each
SQL
state
On Thu, Sep 24, 2020 at 04:25:24AM +0900, Etsuro Fujita wrote:
> Sorry, my thought was vague. To store xmin/xmax/cmin/cmax into a
> given slot, we need to extend the TupleTableSlot struct to contain
> these attributes as well? Or we need to introduce a new callback
> routine for that (say, setsys
On Tue, Aug 18, 2020 at 01:12:51PM +0300, Anna Akenteva wrote:
> I updated the most recent patch and removed the use of "master" from it,
> replacing it with "primary".
This is failing to apply lately, causing the CF bot to complain:
http://cfbot.cputube.org/patch_29_772.log
--
Michael
signature
On Wed, Sep 23, 2020 at 02:34:36PM +0200, Daniel Gustafsson wrote:
> While in the patch I realized that the relationlist saved the relkind but the
> code wasn't actually using it, so I've gone ahead and removed that with a lot
> fewer palloc calls as a result. The attached v22 fixes that and the ab
In v15:
(1)
+ for (cur_blk = firstDelBlock[j]; cur_blk <
nblocks; cur_blk++)
The right side of "cur_blk <" should not be nblocks, because nblocks is not the
number of the relation fork anymore.
(2)
+ BlockNumber nblocks;
+
Daniel Wood writes:
> Hooks exist all over PG for extensions to cover various specific usages.
> The hook I'd like to see would be in the PostgresMain() loop
> for the API "firstchar" messages.
What, to invent your own protocol? Where will you find client libraries
buying into that?
I'm not rea
On Tue, Sep 08, 2020 at 12:18:23PM -0700, Andres Freund wrote:
> A test verifying that a non-transactional message in later aborted
> transaction is handled correctly would be good.
On top of that, the patch needs a rebase as it visibly fails to apply,
per the CF bot.
--
Michael
signature.asc
De
On Thu, Sep 10, 2020 at 11:51:30AM +0200, Daniel Gustafsson wrote:
> Some comments on the patch:
Extra comment for this patch: regression tests are failing.
--
Michael
signature.asc
Description: PGP signature
Hooks exist all over PG for extensions to cover various specific usages.
The hook I'd like to see would be in the PostgresMain() loop
for the API "firstchar" messages.
While I started just wanting the hook for the absolute minimum overhead to
execute a function, even faster than fastpath, and in
On Thu, Sep 10, 2020 at 09:11:21PM +0900, Kasahara Tatsuhito wrote:
> I think it's fine to have an interface to delete in an emergency, but
> I agree that
> users shouldn't be made aware of the existence or deletion of dump
> files, basically.
Per the CF bot, the number of tests needs to be tweake
čt 24. 9. 2020 v 5:56 odesílatel Michael Paquier
napsal:
> On Sat, Jul 11, 2020 at 06:44:24AM +0200, Pavel Stehule wrote:
> > rebase
>
> Per the CF bot, this needs an extra rebase as it does not apply
> anymore. This has not attracted much the attention of committers as
> well.
>
I'll fix it to
On Mon, Aug 10, 2020 at 01:23:44PM +0300, Surafel Temesgen wrote:
> I also Implement PERCENT WITH TIES option. patch is attached
> i don't start a new tread because the patches share common code
This fails to apply per the CF bot. Could you send a rebase?
--
Michael
signature.asc
Description: P
On Sat, Jul 11, 2020 at 06:44:24AM +0200, Pavel Stehule wrote:
> rebase
Per the CF bot, this needs an extra rebase as it does not apply
anymore. This has not attracted much the attention of committers as
well.
--
Michael
signature.asc
Description: PGP signature
Hi Alvaro,
Sorry I totally failed to see the v2 you had posted and a couple of
other emails where you mentioned the issues I brought up.
On Thu, Sep 24, 2020 at 12:23 AM Alvaro Herrera
wrote:
> On 2020-Sep-23, Amit Langote wrote:
> I suspect that we don't really need this defensive constraint.
On Tue, Sep 01, 2020 at 10:27:03PM -0400, Bruce Momjian wrote:
> OK, good. Let's wait a few days and I will then apply it for PG 14.
It has been a few days, and nothing has happened here. I have not
looked at the patch in details, so I cannot say if that's fine or not,
but please note that the p
On Mon, Aug 31, 2020 at 03:13:06PM -0700, Melanie Plageman wrote:
> Attached is the current version of adaptive hash join with two
> significant changes as compared to v10:
The CF bot is complaining about a regression test failure:
@@ -2465,7 +2465,7 @@
Gather (actual rows=469 loops=1)
Worke
On Thu, Sep 10, 2020 at 04:06:17PM +0200, Drouvot, Bertrand wrote:
> Attaching a new version as the previous one was not passing the Patch Tester
> anymore.
Ditto, the CF bot is complaining again. Could you send a rebase?
--
Michael
signature.asc
Description: PGP signature
On Mon, Sep 14, 2020 at 02:38:56PM +0300, Anastasia Lubennikova wrote:
> Fixed. This was also caught by cfbot. This version should pass it clean.
Please note that regression tests are failing, because of 6b2c4e59.
--
Michael
signature.asc
Description: PGP signature
On Thu, Sep 24, 2020 at 12:38 PM Amit Kapila wrote:
>
> I have not checked the patch but I guess if we parallelise Inserts
> with Returning then isn't it better to have Gather node above Parallel
> Inserts?
>
This is indeed the case with the patch applied.
For example:
test=# explain insert int
On Wed, Sep 23, 2020 at 12:07:14PM +0200, Daniel Gustafsson wrote:
> TG_RELNAME was marked deprecated in commit 3a9ae3d2068 some 14 years ago, but
> we still use it in the triggers test suite (test added in 59b4cef1eb74a a year
> before deprecation). Seems about time to move over to TG_TABLE_NAME
Hi Bharath,
> Few things to follow before testing:
> 1. Is the table being dropped/truncated after the test with 0 workers and
> before running with 1 worker? If not, then the index insertion time would
> increase.[1](for me it is increasing by 10 sec). This is obvious because the
> 1st time in
Hi all,
Enabling FIPS with OpenSSL 1.0.2 causes direct calls to the SHAXXX
routines to fail:
"Low level API call to digest SHA256 forbidden in fips mode"
This got discussed back in 2018, but I never got back to it:
https://www.postgresql.org/message-id/20180911030250.ga27...@paquier.xyz
One thin
Hi,
On 2020-09-23 17:20:20 +0530, Bharath Rupireddy wrote:
> The idea of this patch is to allow the leader and each worker insert the
> tuples in parallel if the SELECT part of the CTAS is parallelizable.
Cool!
> The design:
I think it'd be good if you could explain a bit more why you think th
On Thu, Sep 24, 2020 at 7:57 AM Thomas Munro wrote:
>
> On Tue, Sep 22, 2020 at 4:56 PM Greg Nancarrow wrote:
> > Gather (cost=0.00..16.00 rows= width=12) (actual
> > time=69.870..70.310 rows=0 loops=1)
> >Workers Planned: 5
> >Workers Launched: 5
> >-> Parallel Insert on prima
On Tue, Sep 22, 2020 at 4:56 PM Greg Nancarrow wrote:
> Gather (cost=0.00..16.00 rows= width=12) (actual
> time=69.870..70.310 rows=0 loops=1)
>Workers Planned: 5
>Workers Launched: 5
>-> Parallel Insert on primary_tbl (cost=0.00..16.00 rows=500
> width=12) (actual time=59.948.
Hi,
On 2020-09-22 14:55:21 +1000, Greg Nancarrow wrote:
> Following on from Dilip Kumar's POC patch for allowing parallelism of
> the SELECT part of "INSERT INTO ... SELECT ...", I have attached a POC
> patch for allowing parallelism of both the INSERT and SELECT parts,
> where it can be allowed.
>
> [1] - For table_multi_insert() in CTAS, I used an in-progress patch available
> at
> https://www.postgresql.org/message-id/CAEET0ZG31mD5SWjTYsAt0JTLReOejPvusJorZ3kGZ1%3DN1AC-Fw%40mail.gmail.com
> [2] - Table with 2 integer columns, 100million tuples, with leader
> participation,with default
On Tue, Sep 22, 2020 at 10:26 AM Greg Nancarrow wrote:
>
> Hi Hackers,
>
> Following on from Dilip Kumar's POC patch for allowing parallelism of
> the SELECT part of "INSERT INTO ... SELECT ...", I have attached a POC
> patch for allowing parallelism of both the INSERT and SELECT parts,
> where it
On Sat, Sep 19, 2020 at 12:19 PM Robert Haas wrote:
> On Thu, Sep 17, 2020 at 10:40 AM Robert Haas wrote:
> > Yeah, I plan to push forward with 0001 through 0003 soon, but 0001
> > needs to be revised with a PGDLLIMPORT marking, I think, and 0002
> > needs documentation.
>
> So here's an updated
Daniel Gustafsson writes:
> On 23 Sep 2020, at 21:33, Tom Lane wrote:
>> 2. In the case where encoding conversion is performed, we still have
>> to pstrdup the result to have a safe copy for "curline". But I
>> realized that we're making a poor choice of which copy to return to
>> the caller. T
> On 23 Sep 2020, at 21:33, Tom Lane wrote:
>
> I wrote:
>> So the attached adds a pstrdup/pfree to ensure that "curline"
>> has its own storage, putting us right back at two palloc/pfree
>> cycles per line. I don't think there's a lot of choice though;
>> in fact, I'm leaning to the idea that w
On Wed, Sep 23, 2020 at 4:11 PM Thomas Munro wrote:
> On Wed, Sep 23, 2020 at 4:09 PM Michael Paquier wrote:
> > On Tue, Sep 22, 2020 at 07:05:36PM -0700, Andres Freund wrote:
> > > Good catch! Probably that should probably be backpatched...
> >
> > +1. Passing that down to the SLRU layer is a n
I looked this over and pushed it with some minor adjustments.
However, while I was looking at it I couldn't help noticing that
transformPartitionBoundValue's handling of collation concerns seems
less than sane. There are two things bugging me:
1. Why does it care about the expression's collation
On Tue, 22 Sep 2020 at 10:17, tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Masahiko Sawada
> > Yes, but it still seems hard to me that we require for all FDW
> > implementations to commit/rollback prepared transactions without the
> > possibility of ERROR.
>
> Of course we can't eliminate the pos
On Tue, Sep 22, 2020 at 10:57 PM Michael Paquier
wrote:
>
> On Tue, Sep 22, 2020 at 05:35:48PM -0400, Tom Lane wrote:
> > What exactly do you argue has changed since the previous decision
> > that should cause us to change it? In particular, where is the
> > additional data to change our minds ab
I wrote:
> So the attached adds a pstrdup/pfree to ensure that "curline"
> has its own storage, putting us right back at two palloc/pfree
> cycles per line. I don't think there's a lot of choice though;
> in fact, I'm leaning to the idea that we need to back-patch
> that part of this. The odds of
Hi,
On 2020-09-23 12:02:42 -0700, Peter Geoghegan wrote:
> On Wed, Sep 23, 2020 at 11:29 AM Andres Freund wrote:
> > Really should replace WAL compression with lz4 (or possibly zstd).
>
> Yeah. WAL compression is generally a good idea, and we should probably
> find a way to enable it by default
On Wed, Sep 23, 2020 at 10:12 PM Amit Langote wrote:
> On Sun, Sep 20, 2020 at 11:41 PM Etsuro Fujita
> wrote:
> > On Mon, Sep 14, 2020 at 10:45 PM Amit Langote
> > wrote:
> > > On Mon, Sep 14, 2020 at 5:56 PM Etsuro Fujita
> > > wrote:
> > > > IIUC, I think two issues are discussed in the t
On Wed, Sep 23, 2020 at 11:29 AM Andres Freund wrote:
> I wonder what the effect of logging WAL records as huge as this (~256kb)
> is on concurrent sessions. I think it's possible that logging 32 pages
> at once would cause latency increases for concurrent OLTP-ish
> writes. And that a smaller bat
Hi,
On 2020-09-23 11:19:18 -0700, Peter Geoghegan wrote:
> On Fri, Sep 18, 2020 at 8:39 AM Andrey M. Borodin
> wrote:
> > Here is PoC with porting that same routine to B-tree. It allows to build
> > B-trees ~10% faster on my machine.
I wonder what the effect of logging WAL records as huge as t
On Fri, Sep 18, 2020 at 8:39 AM Andrey M. Borodin wrote:
> Here is PoC with porting that same routine to B-tree. It allows to build
> B-trees ~10% faster on my machine.
It doesn't seem to make any difference on my machine, which has an
NVME SSD (a Samsung 970 Pro). This is quite a fast SSD, thou
Hello Gang,
Thank you for your report. I have not taken care of record size deeply yet,
so your report is very interesting. I will also have a test like yours then
post results here.
Regards,
Takashi
2020年9月21日(月) 14:14 Deng, Gang :
> Hi Takashi,
>
>
>
> Thank you for the patch and work on acc
On 2020-Sep-23, Amit Langote wrote:
Hi Amit, thanks for reviewing this patch!
> On Tue, Aug 4, 2020 at 8:49 AM Alvaro Herrera
> wrote:
> I suspect that we don't really need this defensive constraint. I mean
> even after committing the 1st transaction, the partition being
> detached still has
On Sat, Sep 19, 2020 at 12:55:58PM -0500, Justin Pryzby wrote:
> On Thu, Sep 10, 2020 at 12:19:55PM -0700, Yaroslav wrote:
> > Disclaimer: I'm not a native speaker, so not sure those are actually
> > incorrect, and can't offer non-trivial suggestions.
>
> https://www.postgresql.org/message-id/flat
On 2020/09/21 12:44, Bharath Rupireddy wrote:
On Thu, Sep 17, 2020 at 10:20 PM Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
>
> In 1st way, you may also need to call ReleaseExternalFD() when new
connection fails
> to be made, as connect_pg_server() does. Also we need to check th
On 2020/09/23 12:47, Thomas Munro wrote:
On Wed, Sep 23, 2020 at 2:27 PM David Rowley wrote:
I've gone as far as running the recovery tests on the v3-0001 patch
using a Windows machine. They pass:
Thanks! I pushed that one, because it was effectively a bug fix
(WaitLatch() without a latch
On Wed, Sep 23, 2020 at 1:41 AM Tom Lane wrote:
>
> Robert Haas writes:
> > On Mon, Sep 21, 2020 at 3:53 PM Andres Freund wrote:
> >> I think we mostly use it for the few places where we currently expose
> >> data as a signed integer on the SQL level, but internally actually treat
> >> it as a u
Greetings,
* Peter Geoghegan (p...@bowt.ie) wrote:
> On Tue, Sep 22, 2020 at 12:41 PM Robert Haas wrote:
> > But now I see that there's no secondary permission check in the
> > verify_nbtree.c code. Is that intentional? Peter, what's the
> > justification for that?
>
> As noted by comments in co
On Wed, Sep 23, 2020 at 10:22 PM Ashutosh Bapat
wrote:
> On Wed, 23 Sep 2020 at 14:41, Amit Langote wrote:
> Setting this CF entry as "RFC". Thanks.
Great, thanks for your time on this.
--
Amit Langote
EnterpriseDB: http://www.enterprisedb.com
On Wed, Sep 23, 2020 at 2:13 AM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Ashutosh Bapat
> > parallelism here has both pros and cons. If one of the servers errors
> > out while preparing for a transaction, there is no point in preparing
> > the transaction on other servers. In parallel executi
On Wed, 23 Sep 2020 at 14:41, Amit Langote wrote:
> Thanks Ashutosh.
>
> On Fri, Sep 18, 2020 at 7:33 PM Ashutosh Bapat
> wrote:
> > Thanks Amit for addressing comments.
> >
> > @@ -4256,5 +4256,8 @@ transformPartitionBoundValue(ParseState *pstate,
> Node *val,
> > if (!IsA(value, Const))
> >
Fujita-san,
On Sun, Sep 20, 2020 at 11:41 PM Etsuro Fujita wrote:
> On Mon, Sep 14, 2020 at 10:45 PM Amit Langote wrote:
> > On Mon, Sep 14, 2020 at 5:56 PM Etsuro Fujita
> > wrote:
> > > IIUC, I think two issues are discussed in the thread [1]: (a) there is
> > > currently no way to define th
On Wed, Sep 23, 2020 at 12:00 PM tsunakawa.ta...@fujitsu.com
wrote:
>
> From: Amit Kapila
> > The idea is that we can't use this optimization if the value is not
> > cached because we can't rely on lseek behavior. See all the discussion
> > between Horiguchi-San and me in the thread above. So, ho
Hi,
The idea of this patch is to allow the leader and each worker insert the
tuples in parallel if the SELECT part of the CTAS is parallelizable. Along
with the parallel inserts, if the CTAS code path is allowed to do
table_multi_insert()[1], then the gain we achieve is as follows:
For a table wi
TG_RELNAME was marked deprecated in commit 3a9ae3d2068 some 14 years ago, but
we still use it in the triggers test suite (test added in 59b4cef1eb74a a year
before deprecation). Seems about time to move over to TG_TABLE_NAME ourselves,
as TG_RELNAME is still covered by the test added in the deprec
Thanks Ashutosh.
On Fri, Sep 18, 2020 at 7:33 PM Ashutosh Bapat
wrote:
> Thanks Amit for addressing comments.
>
> @@ -4256,5 +4256,8 @@ transformPartitionBoundValue(ParseState *pstate, Node
> *val,
> if (!IsA(value, Const))
> elog(ERROR, "could not evaluate partition bound expression");
>
>
> - When INSERTs are made parallel, currently the reported row-count in
> the "INSERT 0 " status only reflects the rows that the
> leader has processed (not the workers) - so it is obviously less than
> the actual number of rows inserted.
Attached an updated patch which fixes this issue (for paral
> On 23 Sep 2020, at 10:19, Michael Paquier wrote:
>
> On Tue, Sep 22, 2020 at 02:01:18PM +0200, Daniel Gustafsson wrote:
>> Another option would be to follow OpenSSL's deprecations and mark these
>> ciphers
>> as deprecated such that we can remove them in case they indeed get removed
>> from
>
On Tue, Sep 22, 2020 at 02:01:18PM +0200, Daniel Gustafsson wrote:
> Another option would be to follow OpenSSL's deprecations and mark these
> ciphers
> as deprecated such that we can remove them in case they indeed get removed
> from
> libcypto. That would give users a heads-up that they should
On 2020-09-23 16:01, Julien Rouhaud wrote:
Not only providing a view but also logging evictions
along with the number of evicted entries might be a choice.
This idea is from legrand legrand [1].
+1. I'm wondering if logging each evicted entry, with its queryid,
would help to estimate the actua
On Mon, Sep 21, 2020 at 08:18:42PM +0200, Daniel Gustafsson wrote:
> I'm far from fluent in OpenSSL, but AFAICT it has to do with the new provider
> API. The default value for padding is unchanged, but it needs to be propaged
> into the provider to be set in the context where the old code picked i
On 2020-09-19 16:35, legrand legrand wrote:
+1 !
An other way is to log evictions, it provides informations about time
and
amount :
for (i = 0; i < nvictims; i++)
{
hash_search(pgssp_hash, &entries[i]->key, HASH_REMOVE, NULL);
}
pfree(entries);
On Fri, Sep 18, 2020 at 10:00:04PM +0200, Daniel Gustafsson wrote:
> The attached removes it in favor of using palloc() et.al directly. Is there
> any reason to keep it around still?
I doubt that anybody has been compiling with PX_OWN_ALLOC in the last
years, so let's remove this abstraction. An
On Wednesday, September 23, 2020 2:37 PM, Tsunakawa, Takayuki wrote:
> > I revised the patch based from my understanding of Horiguchi-san's
> > comment, but I could be wrong.
> > Quoting:
> >
> > "
> > + /* Get the number of blocks for the supplied
> relation's
> > fork */
> > +
Hi hackers,
I found a problem in logical replication.
It seems to have the same cause as the following problem.
Creating many tables gets logical replication stuck
https://www.postgresql.org/message-id/flat/20f3de7675f83176253f607b5e199b228406c21c.camel%40cybertec.at
Logical decoding CPU-
On Wed, Sep 23, 2020 at 2:48 PM Katsuragi Yuta
wrote:
>
> On 2020-09-18 18:49, Julien Rouhaud wrote:
> > Did you consider also adding the cumulated number of
> > evicted entries? This could be useful to know how to configure
> > pg_stat_statements.max.
>
> Thank you for your comments!
> I overloo
76 matches
Mail list logo
