Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

> "Tom" == Tom Lane writes: Tom> TBH, I find this borderline insane: it's taking a problem we did Tom> not have and moving the goalposts to the next county. Not just any Tom> old county, either, but one where there's a shooting war going on. Tom> As soon as you do something like putting

RE: Global shared meta cache

Hi, everyone. >From: Ideriha, Takeshi [mailto:ideriha.take...@jp.fujitsu.com] >My current thoughts: >- Each catcache has (maybe partial) HeapTupleHeader >- put every catcache on shared memory and no local catcache >- but catcache for aborted tuple is not put on shared memory >- Hash table exists p

Re: [patch]socket_timeout in interfaces/libpq

On Wed, Jun 26, 2019 at 04:13:36AM +, nagaura.ryo...@fujitsu.com wrote: > I don't think that the rest one of my proposals has been rejected > completely, so I want to restart discussion. I recall on the matter that there was consensus that nobody really liked this option because it enforced a

Re: fsync error handling in pg_receivewal, pg_recvlogical

On Tue, Jun 25, 2019 at 02:23:05PM +0200, Peter Eisentraut wrote: > Yeah, there is more to do. The reason I'm focusing on these two right > now is that they would typically run as a background service, and a > clean exit is most important there. In the other cases, the program > runs more often i

mcvstats serialization code is still shy of a load

I'm seeing a reproducible bus error here: #0 0x00417420 in statext_mcv_serialize (mcvlist=0x62223450, stats=Variable "stats" is not available. ) at mcv.c:785 785 memcpy(ITEM_BASE_FREQUENCY(item, ndims), &mcvitem->base_frequency, sizeof(double)); What appears to be happe

Re: [HACKERS] Regression tests vs existing users in an installation

[ blast from the past department ] So, this thread about ensuring the regression tests don't create random globally-visible names seems to have got lost in the weeds. I'm going to resurrect it after noticing that two different places have grown violations of the rule since I fixed things in 18555

Re: GiST VACUUM

On Wed, Jun 26, 2019 at 2:33 PM Michael Paquier wrote: > On Tue, Jun 25, 2019 at 02:38:43PM +0500, Andrey Borodin wrote: > > I feel a little uncomfortable with number 0x7fff right in code. > > PG_INT32_MAX... MaxTransactionId / 2? -- Thomas Munro https://enterprisedb.com

Re: GiST VACUUM

On Tue, Jun 25, 2019 at 02:38:43PM +0500, Andrey Borodin wrote: > I feel a little uncomfortable with number 0x7fff right in code. PG_INT32_MAX... -- Michael signature.asc Description: PGP signature

Re: GiST "choose subtree" support function to inline penalty

On Mon, Jun 24, 2019 at 2:31 PM Andrey Borodin wrote: > > 24 июня 2019 г., в 15:08, Darafei Komяpa Praliaskouski > написал(а): > > > > I'm looking at PostGIS geometry GiST index build times and try to > optimize withing the current GiST framework. The function that shows a lot > on my flame grap

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

Andrew Gierth writes: > I was planning on submitting a follow-up myself (for pg13+) for > discussion of further improvements. My suggestion would be that we > should have the following order of preference, from highest to lowest: > - UTC (justified by being an international standard) > - Etc/U

Re: UCT (Re: pgsql: Update time zone data files to tzdata release 2019a.)

[ starting to come up for air again after a truly nasty sinus infection... fortunately, once I stopped thinking it was "a cold" and went to the doctor, antibiotics seem to be working ] Andrew Gierth writes: > "Tom" == Tom Lane writes: > Tom> 1 Europe/Isle_of_Man > Is this from HEAD a

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jun 25, 2019 at 04:53:40PM -0400, James Coleman wrote: Unrelated: if you or someone else you know that's more familiar with the parallel code, I'd be interested in their looking at the patch at some point, because I have a suspicion it might not be operating in parallel ever (either that

Re: Don't allocate IndexAmRoutine dynamically?

Hi, On June 25, 2019 5:53:47 PM EDT, Tom Lane wrote: >Andres Freund writes: >> On 2019-06-25 17:25:12 -0400, Tom Lane wrote: >>> Yeah, I think trying to make such pointer fields "const", within >>> structures that are otherwise not const, is just more trouble than >it's >>> worth. To start with

Re: Don't allocate IndexAmRoutine dynamically?

Andres Freund writes: > On 2019-06-25 17:25:12 -0400, Tom Lane wrote: >> Yeah, I think trying to make such pointer fields "const", within >> structures that are otherwise not const, is just more trouble than it's >> worth. To start with, how will you assign the handler's output pointer >> to such

Re: Don't allocate IndexAmRoutine dynamically?

Hi, On 2019-06-25 17:25:12 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2019-06-25 16:15:17 -0400, Tom Lane wrote: > >> One too many "consts" there. Pointer to const object seems fine. > >> The other part is either meaningless or will cause problems. > > > Yea - I was thinking of the po

Re: Don't allocate IndexAmRoutine dynamically?

Andres Freund writes: > On 2019-06-25 16:15:17 -0400, Tom Lane wrote: >> One too many "consts" there. Pointer to const object seems fine. >> The other part is either meaningless or will cause problems. > Yea - I was thinking of the pointer in RelationData, where having it as > const *Routine con

Re: Don't allocate IndexAmRoutine dynamically?

Hi, On 2019-06-25 16:15:17 -0400, Tom Lane wrote: > Andres Freund writes: > > I think it might be worthwhile require that IndexAmRoutine returned by > > amhandler are allocated statically. > > +1. Could only be an issue if somebody were tempted to have time-varying > entries in them, but it's h

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jun 25, 2019 at 4:32 PM Tomas Vondra wrote: > > On Tue, Jun 25, 2019 at 12:13:01PM -0700, Peter Geoghegan wrote: > >On Tue, Jun 25, 2019 at 11:03 AM James Coleman wrote: > >> No, I haven't confirmed that it's called less frequently, and I'd be > >> extremely surprised if it were given the

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jun 25, 2019 at 12:13:01PM -0700, Peter Geoghegan wrote: On Tue, Jun 25, 2019 at 11:03 AM James Coleman wrote: No, I haven't confirmed that it's called less frequently, and I'd be extremely surprised if it were given the diff doesn't suggest any changes to that at all. I must have mis

Re: Don't allocate IndexAmRoutine dynamically?

Andres Freund writes: > I think it might be worthwhile require that IndexAmRoutine returned by > amhandler are allocated statically. +1. Could only be an issue if somebody were tempted to have time-varying entries in them, but it's hard to see why that could be a good idea. Should we enforce th

sigmod article about ANSI SQL 2016 features

Hi if somebody has a interest about topic, then can look to article https://sigmodrecord.org/publications/sigmodRecord/1806/pdfs/full-issue.pdf The New and Improved SQL:2016 Standard Regards Pavel

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jun 25, 2019 at 11:03 AM James Coleman wrote: > No, I haven't confirmed that it's called less frequently, and I'd be > extremely surprised if it were given the diff doesn't suggest any > changes to that at all. I must have misunderstood, then. I thought that you were suggesting that that

Don't allocate IndexAmRoutine dynamically?

Hi, I think it might be worthwhile require that IndexAmRoutine returned by amhandler are allocated statically. Right now we copy them into local/cache memory contexts. That's not free and reduces branch/jump target prediction rates. For tableam we did the same, and that was actually measurable.

Re: errbacktrace

On Tue, Jun 25, 2019 at 4:08 AM Peter Eisentraut < peter.eisentr...@2ndquadrant.com> wrote: > New thread continuing from > < > https://www.postgresql.org/message-id/d4903af2-e7b7-b551-71f8-3e4a6bdc2...@2ndquadrant.com > >. > > Here is a extended version of Álvaro's patch that adds an errbacktrace(

Re: unlogged sequences

Hi, On 2019-06-20 09:30:34 +0200, Peter Eisentraut wrote: > I'm looking for feedback from those who have worked on tableam and > storage manager to see what the right interfaces are or whether some new > interfaces might perhaps be appropriate. Hm, it's not clear to me that tableam design matters

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jun 25, 2019 at 1:13 PM Peter Geoghegan wrote: > > On Tue, Jun 25, 2019 at 9:53 AM James Coleman wrote: > > Given the patch contents I don't see any obviously reason why either > > of those possibilities (calling comparetup_heap less often, or it's > > cheaper) are likely. Is that somethi

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jun 25, 2019 at 9:53 AM James Coleman wrote: > Given the patch contents I don't see any obviously reason why either > of those possibilities (calling comparetup_heap less often, or it's > cheaper) are likely. Is that something we should investigate further? > Or is it just a nice happy acc

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Tue, Jun 25, 2019 at 12:02 PM Tomas Vondra wrote: > > On Mon, Jun 24, 2019 at 07:34:19PM -0400, James Coleman wrote: > >On Mon, Jun 24, 2019 at 4:16 PM Tomas Vondra > > wrote: > >> > >> On Mon, Jun 24, 2019 at 01:00:50PM -0400, James Coleman wrote: > >> >On Mon, Jun 24, 2019 at 12:56 PM Simon R

Re: [PATCH] Incremental sort (was: PoC: Partial sort)

On Mon, Jun 24, 2019 at 07:34:19PM -0400, James Coleman wrote: On Mon, Jun 24, 2019 at 4:16 PM Tomas Vondra wrote: On Mon, Jun 24, 2019 at 01:00:50PM -0400, James Coleman wrote: >On Mon, Jun 24, 2019 at 12:56 PM Simon Riggs wrote: >> >> On Mon, 24 Jun 2019 at 16:10, James Coleman wrote: >>>

Re: psql UPDATE field [tab] expands to DEFAULT?

I wrote: > I took a closer look and realized that this isn't some magic behavior of > arcane parts of libreadline; it's more like self-inflicted damage. It > happens because tab-complete.c's complete_from_const() is doing exactly > what its comment says it does: > /* > * This function returns on

Re: SQL/JSON path issues/questions

On 6/21/19 8:04 PM, Alexander Korotkov wrote: On Wed, Jun 19, 2019 at 10:14 PM Alexander Korotkov wrote: While I have no objections to the proposed fixes, I think we can further improve patch 0003 and the text it refers to. In attempt to clarify jsonpath docs and address the concern that ? is h

Weird index ordering in psql's \d (was Re: BUG #15865: ALTER TABLE statements causing "relation already exists" errors when some indexes exist)

I wrote: >> BTW, has anyone got an explanation for the order in which psql is >> listing the indexes of "anothertab" in this test case? > Ah, here's the explanation: describe.c is sorting the indexes > with this: > "ORDER BY i.indisprimary DESC, i.indisunique DESC, c2.relname;" > I can see t

Duplicated LSN in ReorderBuffer

Hi hackers, I believe we found a bug in logical decoding. It only occures with casserts enabled. It was originally discovered and reproduced by Murat Kabilov and Ildus Kurbangaliev. Here is the stacktrace we've got: #0 0x7facc66ef82f in raise () from /usr/lib/libc.so.6 #1 0x7facc66da672

Re: errbacktrace

On 2019-Jun-25, Peter Eisentraut wrote: > Here is a extended version of Álvaro's patch that adds an errbacktrace() > function. Great stuff, thanks for working on it. > You can do two things with this: > > - Manually attach it to an ereport() call site that you want to debug. > > - Set a config

Re: Minimal logical decoding on standbys

On Fri, Jun 21, 2019 at 11:50 AM Amit Khandekar wrote: > > This definitely needs to be expanded, and follow the message style > > guideline. > > This message , with the v8 patch, looks like this : > ereport(LOG, > (errmsg("Dropping conflicting slot %s", NameStr(slotname)), > errdetail("%s", reason

Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3

On Tue, Jun 25, 2019 at 8:28 AM Peter Eisentraut wrote: > How are the requirements here different from ssl_passphrase_command? > Why do we need a new mechanism? I don't think that the requirements are different, and I don't think we need a new mechanism. I am curious exactly how you would set up

[GSoC] artbufmgr

Hello everyone, I am participating in gsoc and would like to share the current working status of my project, devoted to an alternative data structure for buffer management. To get things going, I started with the basic implementation of the art tree for the single backend process, using the ope

Re: Dead encoding conversion functions

On 2019-05-29 21:03, Tom Lane wrote: > If we do delete them as useless, it might also be advisable to change > CreateConversionCommand() to refuse creation of conversions to/from > SQL_ASCII, to prevent future confusion. It seems nonsensical by definition to allow that. -- Peter Eisentraut

Re: "WIP: Data at rest encryption" patch and, PostgreSQL 11-beta3

On 2019-06-17 11:23, Antonin Houska wrote: > I'm thinking how to teach postmaster to accept FEBE protocol connections > temporarily, just to receive the key. The user applications like pg_ctl, > initdb or pg_upgrade would retrieve the key / password from the DBA, then > start postmaster and send it

Re: fsync error handling in pg_receivewal, pg_recvlogical

On 2019-03-29 14:05, Michael Paquier wrote: > Yes, I think that we are going to need an equivalent of that for all > frontend tools. At various degrees, making sure that a fsync happens > is also important for pg_dump, pg_basebackup, pg_rewind and > pg_checksums so it is not only a problem of the

errbacktrace

New thread continuing from . Here is a extended version of Álvaro's patch that adds an errbacktrace() function. You can do two things with this: - Manually attach it to an ereport() call site that you wan

Re: Minimal logical decoding on standbys

On Mon, 24 Jun 2019 at 23:58, Amit Khandekar wrote: > > On Thu, 20 Jun 2019 at 00:31, Andres Freund wrote: > > > > > > Or else, do you think we can just increment the record pointer by > > > > doing something like (lastReplayedEndRecPtr % XLOG_BLCKSZ) + > > > > SizeOfXLogShortPHD() ? > > > > > >

Re: GiST VACUUM

Hi! Thanks for clarification, now I understand these patches better. > 25 июня 2019 г., в 13:10, Heikki Linnakangas написал(а): > >> Also, I did not understand this optimization: >> +/* >> + * We can skip this if the page was deleted so long ago, that no scan >> can possibly >> + *

Re: Choosing values for multivariate MCV lists

On Mon, Jun 24, 2019 at 02:54:01PM +0100, Dean Rasheed wrote: On Mon, 24 Jun 2019 at 00:42, Tomas Vondra wrote: On Sun, Jun 23, 2019 at 10:23:19PM +0200, Tomas Vondra wrote: >On Sun, Jun 23, 2019 at 08:48:26PM +0100, Dean Rasheed wrote: >>On Sat, 22 Jun 2019 at 15:10, Tomas Vondra wrote: >>>

Re: [PATCH] Stop ALTER SYSTEM from making bad assumptions

Hello > But we already have ALTER SYSTEM, so why do we need to write it again? > You just need to check whether the system is running: if it is, connect > and do "ALTER SYSTEM". If it isn't, do `echo ALTER SYSTEM | postgres > --single`. Is this approach still possible for pg_basebackup --format=t

Re: GiST VACUUM

(Thanks for the reminder on this, Michael!) On 05/04/2019 08:39, Andrey Borodin wrote: 4 апр. 2019 г., в 20:15, Heikki Linnakangas написал(а): I suggest that we do the attached. It fixes this for GiST. The patch changes expands the "deletion XID" to 64-bits, and changes where it's stored. Inst