On Monday, August 19, 2019 10:39 AM (GMT+9), Masahiko Sawada wrote:
> Fixed.
>
> Attached the updated version patch.
Hi Sawada-san,
I haven't tested it with heavily updated large tables, but I think the patch
is reasonable as it helps to shorten the execution time of vacuum by removing
the
On Tue, Aug 27, 2019 at 1:54 PM Tom Lane wrote:
> Thomas Munro writes:
> > OK I started writing a patch and realised there were a few ugly
> > problems that I was about to report here... but now I wonder if, based
> > on the comment for RelationHasUnloggedIndex(), we shouldn't just nuke
> > all
On Mon, Aug 26, 2019 at 11:05:55AM +0200, Fabien COELHO wrote:
> I have started to do something, and I can spend some time on that this week,
> but I'm pretty unclear about what exactly should be done.
Thanks.
> The error returning stuff is simple enough, but I'm unclear about what to do
> with
On Tue, Aug 20, 2019 at 10:52 PM Alex wrote:
>
>
> On Tue, Aug 20, 2019 at 4:59 PM Heikki Linnakangas
> wrote:
>
>> On 20/08/2019 10:23, Alex wrote:
>> > I have troubles to understand the pg lock in the following simple
>> > situation.
>> >
>> >
>> > Session 1:
>> >
>> >
>> > begin; update
On Tue, Aug 27, 2019 at 1:48 PM Tom Lane wrote:
> A stack trace would likely be really useful right about now.
Yeah. Looking into how to get that.
--
Thomas Munro
https://enterprisedb.com
Greetings,
(Apologies for any naïve thoughts below. Please correct my misunderstandings)
I am trying to understand the background for the ideas proposed and/or already
decided, but it is increasingly difficult to follow.
I’ve been watching the TDE list for several months and over that time
Thomas Munro writes:
> OK I started writing a patch and realised there were a few ugly
> problems that I was about to report here... but now I wonder if, based
> on the comment for RelationHasUnloggedIndex(), we shouldn't just nuke
> all this code. We don't actually support unlogged indexes on
>
Thomas Munro writes:
> This is apparently an EDB-owned machine but I have no access to it
> currently (I could ask if necessary). For some reason it's been
> failing for a week, but only on REL_12_STABLE, with this in the log:
Yeah, I've been puzzling over that to little avail.
> It's hard to
On Mon, Aug 26, 2019 at 4:29 PM Arcadiy Ivanov wrote:
> This problem is not limited to IoT but to RT financial transaction
> ingestion as well.
Not surprising, since the TPC-E benchmark models a financial trading
application. Perhaps it exhibits this behavior because it is actually
Hi Richard,
On Mon, Aug 26, 2019 at 6:33 PM Richard Guo wrote:
>
> Hi All,
>
> To generate partitionwise join, we need to make sure there exists an
> equi-join condition for each pair of partition keys, which is performed
> by have_partkey_equi_join(). This makes sense and works well.
>
> But
Hi,
This is apparently an EDB-owned machine but I have no access to it
currently (I could ask if necessary). For some reason it's been
failing for a week, but only on REL_12_STABLE, with this in the log:
2019-08-20 04:31:48.886 MDT [13421:4] LOG: server process (PID 13871)
was terminated by
On Mon, Aug 26, 2019 at 5:36 AM Ashutosh Sharma
wrote:
> Thanks Ashwin and Heikki for your responses. I've one more query here,
>
> If BTree index is created on a zedstore table, the t_tid field of
> Index tuple contains the physical tid that is not actually pointing to
> the data block instead
On Tue, Aug 27, 2019 at 10:59 AM Tom Lane wrote:
> > At first glance it seems
> > like we need to capture PageGetLSN(page) while we have the lock, and
> > then later pass that into TestForOldSnapshot() instead of the page.
> > I'll look into that and write a patch, probably in a day or two.
>
>
On Mon, Aug 26, 2019 at 4:59 PM Arcadiy Ivanov wrote:
> But apart from TPC-E and having to perform to it, is there any practical
> real world usefulness in trying to have a B-tree index on TS-based data
> just to have a PK on it, as opposed to having a BRIN on a TS field and
> calling it a day?
On 8/26/19 6:48 PM, Peter Geoghegan wrote:
Such data often consists of timestamps from a large number
of low cost devices -- event data that arrives *approximately* in
order. This is more or less the problem that the TimescaleDB extension
targets, so it seems likely that a fair number of users
On 8/26/19 7:49 PM, Peter Geoghegan wrote:
Not surprising, since the TPC-E benchmark models a financial trading
application.
The good news there is that that will almost certainly be a lot better
in Postgres 12. TPC-E also has a number of very low cardinality
indexes, despite being an OLTP
The well known rightmost page split optimization (where we apply leaf
page fill factor) usually does a great job of maximizing space
utilization with indexes on a single auto-incrementing column or
timestamp column, by packing the left half of the rightmost page full.
Splitting the rightmost page
Thomas Munro writes:
> On Tue, Aug 27, 2019 at 9:28 AM Tom Lane wrote:
>> It is hard to express what a bad idea it is to be asking for complex
>> catalog searches while holding a buffer lock. We could easily get
>> into undetectable deadlocks that way, for example. We need to refactor
>> these
On Tue, Aug 27, 2019 at 9:28 AM Tom Lane wrote:
> I agree that this code is absolutely horrid as it stands. However,
> it doesn't look to me like caching RelationHasUnloggedIndex is quite
> enough to fix it. The other problem is that the calls in question
> seem to be mostly in
James Coleman writes:
> While digging into the incremental sort patch, I noticed in
> tuplesort.c at the beginning of the function in $SUBJECT we have this
> comment and assertion:
> tuplesort_set_bound(Tuplesortstate *state, int64 bound)
> {
> /* Assert we're called before loading any
Thomas Munro writes:
> On my laptop, all prewarmed, no concurrency, the mere existence of 10
> brin indexes causes a sequential scan to take ~5% longer and an
> uncorrelated index scan to take ~45% longer (correlated index scans
> don't suffer). Here's a draft patch for v13 that fixes that
"=?gb18030?B?1cXOxL3c?=" <757634...@qq.com> writes:
> When the number of potential synchronous standbys is smaller than num_sync,
> such as 'FIRST 3 (1,2)', 'ANY 4 (1,2,3)' in the synchronous_standby_names,
> the processes will wait for synchronous replication forever.
> Obviously, it's not
On Mon, Aug 26, 2019 at 11:01:20AM -0400, Tom Lane wrote:
Tomas Vondra writes:
I'm willing to take a stab at it, but to do that I need a way to
reproduce it. Tom, you mentioned you've managed to reproduce it in a
qemu instance, but that it took some fiddling with qemu parmeters or
something.
> It seems that it contradicts the very idea of your patch, so probably we
> should look for other ways to optimize this use-case.
> Maybe this restriction can be relaxed for write only tables, that never
> have to reread the page because of visibility, or something like that.
> Also we probably
I wrote:
> I propose the attached. I'm inclined to think that the risk/benefit
> of back-patching this is not very good, so I just want to stick it in
> HEAD, unless somebody can explain why dead_end children are likely to
> crash in the field.
Pushed at ee3278239.
I'm still curious as to the
On 2019-06-19 04:51, Michael Paquier wrote:
> On Tue, Jun 18, 2019 at 09:13:19AM -0700, Shawn Debnath wrote:
>>> case SLRU_WRITE_FAILED:
>>> ereport(ERROR,
>>> (errcode_for_file_access(),
>>>
On 8/26/19 2:55 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 8/21/19 4:16 PM, Tom Lane wrote:
>>> Andrew Dunstan writes:
Still, if we simply added the skew to the snapshot time that might be
enough to achieve what you want. That would be a one line change, I think.
>>> +1
>>
OK, let's try this again :)
This is work mainly based in the first version of the online checksums
patch, but based on top of Andres WIP patchset for global barriers (
https://www.postgresql.org/message-id/20181030051643.elbxjww5jjgnjaxg%40alap3.anarazel.de
)
Andres patch has been enhanced with
Andrew Dunstan writes:
> On 8/21/19 4:16 PM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> Still, if we simply added the skew to the snapshot time that might be
>>> enough to achieve what you want. That would be a one line change, I think.
>> +1
> Done. It's only happening prospectively, so
On Mon, Aug 26, 2019 at 9:46 AM Michael Paquier wrote:
> On Sun, Aug 25, 2019 at 05:10:47PM +0200, Julien Rouhaud wrote:
> > I did some searching, and oid2name.c is also missing this.
>
> And pgbench, no?
>
Yes, the patch is slightly different.
> --
> Michael
>
--
Ibrar Ahmed
Hi,
On 2019-08-26 14:09:45 -0400, Robert Haas wrote:
> On Fri, Aug 23, 2019 at 10:22 PM Thomas Munro wrote:
> > Couldn't resist trying this, and it seems to work. Based on the
> > comment "the buffer size is a multiple of MAXIMUM_ALIGNOF, and each
> > read and write is as well", it should
On Wed, 2019-08-21 at 21:54 -0700, Paul A Jungwirth wrote:
> Sometimes I think about having a maybe type instead of null/not
> null. SQL nulls are already very "monadic" I think but nullability
> doesn't travel.
Yeah, that would be a great direction, but there is some additional
complexity that
On Mon, 26 Aug 2019 at 14:14, Tom Lane wrote:
> Laurenz Albe writes:
> > Dave Cramer wrote:
> > test=> BEGIN;
> > BEGIN
> > test=> CALL testproc();
> > ERROR: invalid transaction termination
> > CONTEXT: PL/pgSQL function testproc() line 1 at COMMIT
>
> > What is the rationale for this?
>
> A
On Fri, Aug 23, 2019 at 10:22 PM Thomas Munro wrote:
> Couldn't resist trying this, and it seems to work. Based on the
> comment "the buffer size is a multiple of MAXIMUM_ALIGNOF, and each
> read and write is as well", it should always work (though I wish
> shm_mq_receive_bytes()'s documentation
Laurenz Albe writes:
> Dave Cramer wrote:
> test=> BEGIN;
> BEGIN
> test=> CALL testproc();
> ERROR: invalid transaction termination
> CONTEXT: PL/pgSQL function testproc() line 1 at COMMIT
> What is the rationale for this?
A procedure shouldn't be able to force commit of the surrounding
[CC to -hackers]
Dave Cramer wrote:
> On Mon, 26 Aug 2019 at 13:43,
Laurenz Albe
> wrote:
> > Dave Cramer wrote:
>
> > As I said, I'd entertain a connection parameter that switched the
>
> > CALL to call procedures but ideally you'd complain to the server
> >
> folks to make Procedures useful.
>
I wrote:
>> I'm very hesitant to apply a volatile-qualification approach to
>> eliminate those issues, for fear of pessimizing performance-critical
>> code on more modern platforms. I wonder whether there is a reasonable
>> way to tell at compile time if we have a platform with 80-bit math.
>
On 8/25/19 4:23 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 8/20/19 8:59 AM, Peter Eisentraut wrote:
>>> Running the regression tests on mingw32, I get the following diff in
>>> circle.out:
>>> - | <(3,5),0> | <(1,2),3> | 0.60555127546399
>>> + | <(3,5),0> |
Peter Eisentraut writes:
> On 2019-08-26 13:28, Daniel Migowski wrote:
>> I would like to implement a fallback solution
>> that detects such errors and automatically updates the nextvalue of the
>> sequence when the nextvalue is already used on insert.
> ISTM that such a system would likely
Hello Rafia,
CREATE TABLE Stuff (...)
PARTITION BY [HASH | RANGE | LIST] (…)
DO NONE -- this is the default
DO [IMMEDIATE|DEFERRED] USING (…)
Where the USING part would be generic keword value pairs, eg:
For HASH: (MODULUS 8) and/or (NPARTS 10)
For RANGE: (START
Just one suggestion --partition-method option should be made dependent
on --partitions, because it has no use unless used with --partitions.
What do you think?
Why not. V4 attached.
--
Fabien.diff --git a/doc/src/sgml/ref/pgbench.sgml b/doc/src/sgml/ref/pgbench.sgml
index
On 2019-08-26 13:28, Daniel Migowski wrote:
> I would like to implement a fallback solution
> that detects such errors and automatically updates the nextvalue of the
> sequence when the nextvalue is already used on insert.
ISTM that such a system would likely have many of the same problems as
Justin Pryzby writes:
> On Mon, Aug 26, 2019 at 12:45:24PM -0400, Tom Lane wrote:
>> However ... there is some pretty interesting info at
>> https://bugzilla.redhat.com/show_bug.cgi?id=1338673
>> suggesting that compiling with a late-model gcc against older RHEL6
>> headers could result in bad
On Mon, Aug 26, 2019 at 12:45:24PM -0400, Tom Lane wrote:
> However ... there is some pretty interesting info at
> https://bugzilla.redhat.com/show_bug.cgi?id=1338673
> suggesting that compiling with a late-model gcc against older RHEL6
> headers could result in bad code. I wonder whether the
Thomas Munro writes:
> Of course it's entirely possible that we have a bug here and I'm very
> keen to find it, but I can't help noticing the common factor here is
> that they're all running ancient RHEL 6.x releases, except Merlin who
> didn't say. Merlin?
Hm, Justin said he had
25.08.2019 0:59, Floris Van Nee wrote:
Though, I got interested in the comment inconsistency you have found.
I added debug message into this code branch of the patch and was able to
see it in regression.diffs after 'make check':
Speaking of your patch, it seems that the buffer was unpinned and
On Fri, Aug 16, 2019 at 8:39 PM Greg Stark wrote:
> Everywhere I've worked I've seen people struggle with table bloat. It's
> hard to even measure how much of it you have or where, let alone actually
> fix it.
>
> If you search online you'll find dozens of different queries estimating
> how much
Tomas Vondra writes:
> I'm willing to take a stab at it, but to do that I need a way to
> reproduce it. Tom, you mentioned you've managed to reproduce it in a
> qemu instance, but that it took some fiddling with qemu parmeters or
> something. Can you share what exactly was necessary?
I don't
On 8/26/19 10:10 AM, ROS Didier wrote:
> Hi
>
> I would like to check that postgresql is compatible with TLS 1.2.
> what test could I do to check this compatibility?
Hi,
I just now pointed this command at our PG 9.5 server at $work:
openssl s_client -connect dbhost:5432 -starttls postgres
and
Hi
I would like to check that postgresql is compatible with TLS 1.2.
what test could I do to check this compatibility?
Thanks in advance
Best Regards
Didier ROS
EDF
Ce message et toutes les pièces jointes (ci-après le 'Message') sont établis à
l'intention exclusive des destinataires et
Hi,
On Mon, 26 Aug 2019 at 06:28, Michael Paquier wrote:
> Alexander, it seems to me that we should also consider lock_timeout
> and idle_in_transaction_session_timeout (new as of 9.6), no? We could
Well, I was thinking about it and came to the conclusion that we are
neither taking heavy
On Tue, Aug 13, 2019 at 05:04:35PM +0900, Michael Paquier wrote:
On Wed, Feb 13, 2019 at 01:51:47PM -0800, Andres Freund wrote:
I'm not yet sure that that's actually something that's supposed to
happen, I got to spend some time analysing how this actually
happens. Normally the contents of the
Thanks Ashwin and Heikki for your responses. I've one more query here,
If BTree index is created on a zedstore table, the t_tid field of
Index tuple contains the physical tid that is not actually pointing to
the data block instead it contains something from which the logical
tid can be derived.
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
Hi,
The patch looks good to me, Just one suggestion
On Sun, 18 Aug 2019 at 11:33, Fabien COELHO wrote:
>
> Hello Robert & Robert,
>
> > - no partitions are created immediately (current case)
> > but will have to be created manually later
> >
> > - static partitions are created automatically, based on provided
> > parameters
> >
> > - dynamic
Hello,
one of the most frustating things when I started with PostgreSQL was
that IDENTITY columns are based on sequences that are completly
disconnected from the table contents and manually imported data will
lead to errors like 'duplicate key value violates unique constraint
"xyz_pkey"'.
On 8/26/19 2:53 AM, Masahiko Sawada wrote:
> I guess that this depends on the number of encryption keys we use. If
> we have encryption keys per tablespace or database the number of keys
> would be at most several dozen or several hundred. It's enough to have
> them in flat-file format on the disk
On Mon, Aug 26, 2019 at 7:49 PM Joe Conway wrote:
>
> On 8/26/19 2:53 AM, Masahiko Sawada wrote:
> > I guess that this depends on the number of encryption keys we use. If
> > we have encryption keys per tablespace or database the number of keys
> > would be at most several dozen or several
Peter Geoghegan wrote:
> Consumers of this new infrastructure probably won't be limited to the
> deduplication feature;
It'd also solve an open problem of the aggregate push-down patch [1], in
particular see the mention of pg_opclass in [2]: the partial aggregate
node below the final join must
On 26/08/2019 10:59, Andrey Borodin wrote:
Hi!
In many cases GiST index can be build fast using z-order sorting.
I've looked into proof of concept by Nikita Glukhov [0] and it looks very
interesting.
So, I've implemented yet another version of B-tree-like GiST build.
Cool!
My biggest
Hello,
This is very interesting. In my pipeline currently GiST index rebuild is
the biggest time consuming step.
I believe introducing optional concept of order in the GiST opclass will be
beneficial not only for fast build, but for other tasks later:
- CLUSTER can order the table using that
Hi All,
To generate partitionwise join, we need to make sure there exists an
equi-join condition for each pair of partition keys, which is performed
by have_partkey_equi_join(). This makes sense and works well.
But if, let's say, one certain pair of partition keys (foo.k = bar.k)
has formed an
On Mon, 26 Aug 2019 12:48:40 +0800 mich...@paquier.xyz wrote
>Your patch has forgotten to update the alternate output in
>float4-misrounded-input.out.
Thanks for your remind, I have modified the patch and now it is
'regression_20190826.patch' in attachment, and I have done a successful
test on
Bonjour Michaël,
So I'll set out to write and use "pg_strtou?int64", i.e. 2 functions, and
then possibly generalize to lower sizes, 32, 16, depending on what is
actually needed.
I am interested in this patch, and the next commit fest is close by.
Are you working on an updated version? If
On Mon, Aug 26, 2019 at 02:34:31PM +1200, Thomas Munro wrote:
On Mon, Aug 26, 2019 at 1:44 PM Justin Pryzby wrote:
On Mon, Aug 26, 2019 at 01:09:19PM +1200, Thomas Munro wrote:
> On Sun, Aug 25, 2019 at 3:15 PM Peter Geoghegan wrote:
> > I was reminded of this issue from last year, which also
Hi!
In many cases GiST index can be build fast using z-order sorting.
I've looked into proof of concept by Nikita Glukhov [0] and it looks very
interesting.
So, I've implemented yet another version of B-tree-like GiST build.
It's main use case and benefits can be summarized with small example:
On Sat, Aug 17, 2019 at 9:59 AM Andres Freund wrote:
>
> Hi,
>
> On 2019-08-16 20:39:21 -0400, Greg Stark wrote:
> > But isn't this all just silliiness these days? We could actually sum up the
> > space recorded in the fsm and get a much more trustworthy number in
> > milliseconds.
>
> You mean
Hi Fabien,
On Thu, Aug 01, 2019 at 04:48:35PM +0200, Fabien COELHO wrote:
> Ok, so there is an agreement on reworking the unsigned function. I missed
> this bit.
>
> So I'll set out to write and use "pg_strtou?int64", i.e. 2 functions, and
> then possibly generalize to lower sizes, 32, 16,
On Fri, Aug 23, 2019 at 11:35 PM Stephen Frost wrote:
>
> Greetings,
>
> * Bruce Momjian (br...@momjian.us) wrote:
> > On Fri, Aug 23, 2019 at 07:45:22AM -0400, Stephen Frost wrote:
> > > Having listed out the feature set of each of the other major databases
> > > when it comes to TDE is exactly
On Fri, Aug 23, 2019 at 8:44 PM Michael Paquier wrote:
>
> On Fri, Aug 23, 2019 at 03:35:01PM +0900, Masahiko Sawada wrote:
> > Good idea. I've updated the doc update patch.
>
> Thanks. I have removed the output part as I am not sure that it is
> that helpful for the reader, and applied it down
70 matches
Mail list logo
