On 28-12-2020 13:48, Bharath Rupireddy wrote:
On Fri, Dec 25, 2020 at 8:10 AM Justin Pryzby wrote:
On Thu, Dec 24, 2020 at 05:48:42AM +0530, Bharath Rupireddy wrote:
I'm not posting the updated 0002 to 0004 patches, I plan to do so
after a couple of reviews happen on the design of the APIs in
On Mon, Jan 04, 2021 at 11:04:57AM +0500, Andrey Borodin wrote:
> > 4 янв. 2021 г., в 07:53, Justin Pryzby написал(а):
> > Note, there's currently several "compression" patches in CF app. This patch
> > seems to be independent of the others, but probably shouldn't be totally
> > uncoordinated
On Mon, Jan 4, 2021 at 6:52 AM Justin Pryzby wrote:
>
> The most recent patch doesn't compile --without-lz4:
>
> compress_lz4.c:191:17: error: ‘lz4_cmcheck’ undeclared here (not in a
> function)
> .datum_check = lz4_cmcheck,
> ...
>
> And fails pg_upgrade check, apparently losing track of the
> 4 янв. 2021 г., в 07:53, Justin Pryzby написал(а):
>
> Note, there's currently several "compression" patches in CF app. This patch
> seems to be independent of the others, but probably shouldn't be totally
> uncoordinated (like adding lz4 in one and ztsd in another might be poor
>
On 2021-01-02 06:49, Justin Pryzby wrote:
On Tue, Dec 15, 2020 at 11:47:23AM +0900, torikoshia wrote:
So I'm now thinking about adding a new column in pg_locks which
keeps the time at which locks started waiting.
Attached a patch.
This is failing make check-world, would you send an updated
Mark Dilger writes:
> Have you thought about whether If it weren't in test/modules, it might be
> nice to expose test_regex from SQL with a slightly different interface that
> doesn't throw on regex compilation error? Maybe something in contrib? It
> might be useful to some users to validate
> On Jan 3, 2021, at 7:49 PM, Tom Lane wrote:
>
> Over the holiday break I've been fooling with some regex performance
> improvements. I don't have anything ready to show yet in that line,
> but I was feeling the need for more-thorough test coverage, so I set
> to work on something that's
On Fri, Dec 25, 2020 at 6:08 PM Kasahara Tatsuhito
wrote:
Thanks for reviewing and kind suggestion!
Attached a rewritten patch.
Thanks for updating patch.
But when I had applyed the patch to the current HEAD and did make, I
got an error due to duplicate OIDs.
You need to rebase the patch.
At 2021-01-03 19:54:38 -0800, p...@bowt.ie wrote:
>
> It just seems worth removing gratuitous inconsistencies,
> such as this one.
Agreed.
-- Abhijit
On Sat, Jan 2, 2021 at 3:34 PM Luc Vlaming wrote:
>
> On 02-01-2021 08:36, Amit Kapila wrote:
> > On Fri, Jan 1, 2021 at 7:37 PM Luc Vlaming wrote:
> >>
> >> Hi,
> >>
> >> In an effort to speed up bulk data loading/transforming I noticed that
> >> considerable time is spent in the relation
On Mon, Jan 4, 2021 at 12:55 PM Peter Geoghegan wrote:
>
> I notice that heapdesc.c outputs the field latestRemovedXid as
> "remxid". But why? What sense is there in changing the name for output
> by tools like pg_waldump, which are intrinsically internals focussed?
Not sure but it has been
I notice that heapdesc.c outputs the field latestRemovedXid as
"remxid". But why? What sense is there in changing the name for output
by tools like pg_waldump, which are intrinsically internals focussed?
Does anyone have any objections to my changing the details within
heapdesc.c on master, so
Hi Amit,
Sorry for my late reply. Here are my answers for your earlier questions.
>BTW, it is not clear why the advantage for single table is not as big as
>multiple tables with the Truncate command
I guess it's the amount of table blocks caused this difference. For single
table I tested the
At Sat, 26 Dec 2020 02:15:06 +0900, Fujii Masao
wrote in
>
>
> On 2020/12/25 12:03, Kyotaro Horiguchi wrote:
> > Thank you for looking this.
> > At Thu, 24 Dec 2020 15:33:04 +0900, Fujii Masao
> > wrote in
> >> When I applied two patches in the master branch and
> >> ran "make check-world",
On Mon, Dec 21, 2020 at 01:49:24PM -0600, Justin Pryzby wrote:
> a big disadvantage of piping through zstd is that it's not identified as a
> PGDMP file, and, /usr/bin/file on centos7 fails to even identify zstd by its
> magic number..
Other reasons are that pg_dump |zstd >output.zst loses the
The most recent patch doesn't compile --without-lz4:
compress_lz4.c:191:17: error: ‘lz4_cmcheck’ undeclared here (not in a function)
.datum_check = lz4_cmcheck,
...
And fails pg_upgrade check, apparently losing track of the compression (?)
CREATE TABLE public.cmdata2 (
-f1 text
Hi
probably some is wrong still
create table foo(a jsonb);
update foo set a['a'] = '10';
update foo set a['b']['c'][1] = '10';
update foo set a['b']['c'][10] = '10'
WARNING: problem in alloc set ExprContext: req size > alloc size for chunk
0x256dd88 in block 0x256d160
WARNING: problem in
On Fri, Jan 01, 2021 at 01:21:10PM -0800, Zhihong Yu wrote:
> Krasiyan:
> Happy New Year.
>
> For WinGetFuncArgInPartition():
>
> + if (target > 0)
> + step = 1;
> + else if (target < 0)
> + step = -1;
> + else
> + step = 0;
ne 3. 1. 2021 v 19:07 odesílatel Tom Lane napsal:
> Pavel Stehule writes:
> > I found inconsistency in work with slicings (this is not directly related
> > to this patch, but can be interesting, because with new functionality the
> > array slicings can be edited more often).
>
> > a =
Pavel Stehule writes:
> I found inconsistency in work with slicings (this is not directly related
> to this patch, but can be interesting, because with new functionality the
> array slicings can be edited more often).
> a = array[1,2,3,4,5];
> a[1:5] = 10; -- correctly fails, although for some
On Sun, 3 Jan 2021 at 05:57, Simon Riggs
wrote:
> Exactly what's wrong with "REVOKE ALL ON ALL TABLES IN SCHEMA test" at
> the top of your script? You say there is a problem, but don't describe
> the precise problem. Can you give a fully worked example so we can
> understand how to resolve?
>
Hi
I continue in review.
I found inconsistency in work with slicings (this is not directly related
to this patch, but can be interesting, because with new functionality the
array slicings can be edited more often).
a = array[1,2,3,4,5];
a[1:5] = 10; -- correctly fails, although for some people
On 9/25/20 9:09 AM, Thomas Munro wrote:
On Fri, Sep 25, 2020 at 12:53 PM Thomas Munro wrote:
Here's a new version. The final thing I'm contemplating before
pushing this is whether there may be hidden magical dependencies in
the order of operations in CheckPointGuts(), which I've changed
Hi, all,
When using 'create index concurrently', we use a MVCC snaptshot, we should
not see tuples that are HEAPTUPLE_INSERT_IN_PROGRESS. I think we should
report an ERROR in this case. But, we report WARNING now.
In the early days, it indeed reports ERROR, but the behaviour is changed by
commit
On Sat, Jan 2, 2021 at 7:47 PM k.jami...@fujitsu.com
wrote:
>
> Happy new year. The V38 LGTM.
> Apologies for a bit of delay on posting the test results, but since it's the
> start of commitfest, here it goes and the results were interesting.
>
> I executed a VACUUM test using the same approach
Hi
ne 3. 1. 2021 v 13:13 odesílatel Joel Jacobson napsal:
> Hi hackers,
>
> I just learned about a feature called "LET clause".
>
> It's not part of the SQL standard, but it's supported by Oracle
> [1], Couchbase [2] and AsterixDB [3].
>
This is not SQL language - it uses EQL language
It
Hi hackers,
I just learned about a feature called "LET clause".
It's not part of the SQL standard, but it's supported by Oracle [1], Couchbase
[2] and AsterixDB [3].
I searched the pgsql-hackers archives and couldn't find any matches on "LET
clause",
so I thought I should share this with you
On Sun, Jan 03, 2021 at 12:33:54AM -0600, Justin Pryzby wrote:
>
> But actually, maybe we should just use the comment that exists everywhere else
> for that.
>
> /* Propagate context related error context to libxml2 */
> xmlSetStructuredErrorFunc((void *) xtCxt->xmlerrcxt,
>
On Thu, Jun 11, 2020 at 07:58:43PM +0300, Anastasia Lubennikova wrote:
> On 08.06.2020 19:31, Alvaro Herrera wrote:
> >I'm thinking what's a good way to have a test that's committable. Maybe
> >it would work to add a TAP test to pg_upgrade that runs initdb, does a
> >few GRANTS as per your
On Fri, Jan 1, 2021 at 7:35 PM Isaac Morland wrote:
> The use case is to ensure that after doing my GRANTs the permissions are in a
> known state, no matter what they were before. Typically, one would follow a
> reset command with some GRANTs. So maybe my permissions script contains:
>
> GRANT
On 30-12-2020 14:23, Luc Vlaming wrote:
On 30-12-2020 02:57, Andres Freund wrote:
Hi,
Great to see work in this area!
On 2020-12-28 09:44:26 +0100, Luc Vlaming wrote:
I would like to propose a small patch to the JIT machinery which
makes the
IR code generation lazy. The reason for postponing
31 matches
Mail list logo
