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
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 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 attachm
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,
> xml_
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 i
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 looks
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 th
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 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
around
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 c
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?
>
T
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 pe
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 = array[1,2,
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;
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 alloc
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 COMPRESSIO
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 exi
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", I
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 am
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 tha
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 "remx
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 extens
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 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.
> 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 bee
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 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 pa
> 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
> execution
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 c
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 (li
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
31 matches
Mail list logo
