comment regarding double timestamps; and, infinite timestamps and NaN

2019-12-29 Thread Justin Pryzby
selfuncs.c convert_to_scalar() says: |* The several datatypes representing absolute times are all converted |* to Timestamp, which is actually a double, and then we just use that |* double value. Note this will give correct results even for the "special" |* values of Timestamp, since those are

Re: Yet another fast GiST build

2019-12-29 Thread Andrey Borodin
> 1 дек. 2019 г., в 7:06, Michael Paquier написал(а): > > On Sun, Sep 08, 2019 at 01:54:35PM +0500, Andrey Borodin wrote: >> Here's V3 of the patch set. >> Changes: >> 1. Added some documentation of new sort support routines >> 2. Fixed bug with dirty pages >> >> I did not add sort support

Re: Reorderbuffer crash during recovery

2019-12-29 Thread Amit Kapila
On Fri, Dec 27, 2019 at 8:37 PM Alvaro Herrera wrote: > > On 2019-Dec-27, vignesh C wrote: > > > I felt amit solution also solves the problem. Attached patch has the > > fix based on the solution proposed. > > Thoughts? > > This seems a sensible fix to me, though I didn't try to reproduce the >

Re: [HACKERS] Block level parallel vacuum

2019-12-29 Thread Amit Kapila
On Mon, Dec 30, 2019 at 2:53 AM Tomas Vondra wrote: > > On Sun, Dec 29, 2019 at 10:06:23PM +0900, Masahiko Sawada wrote: > >> > >> v40-0003-Add-FAST-option-to-vacuum-command.patch > >> > >> > >> I do have a bit of an issue with this part - I'm not

Re: [HACKERS] Block level parallel vacuum

2019-12-29 Thread Amit Kapila
On Mon, Dec 30, 2019 at 2:53 AM Tomas Vondra wrote: > > On Sun, Dec 29, 2019 at 10:06:23PM +0900, Masahiko Sawada wrote: > >> v40-0001-Introduce-IndexAM-fields-for-parallel-vacuum.patch > >> --- > >> > >> I wonder if

Re: Recognizing superuser in pg_hba.conf

2019-12-29 Thread Vik Fearing
On 29/12/2019 17:31, Tom Lane wrote: > Robert Haas writes: >> On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing >> wrote: >>> I'm all for this (and even suggested it during the IRC conversation that >>> prompted this patch). It's rife with bikeshedding, though. My original >>> proposal was to use

Re: [HACKERS] Block level parallel vacuum

2019-12-29 Thread Tomas Vondra
On Sun, Dec 29, 2019 at 10:06:23PM +0900, Masahiko Sawada wrote: On Fri, 27 Dec 2019 at 11:24, Tomas Vondra wrote: Hi, On Wed, Dec 25, 2019 at 09:17:16PM +0900, Masahiko Sawada wrote: >On Tue, 24 Dec 2019 at 15:46, Masahiko Sawada > wrote: >> >> On Tue, 24 Dec 2019 at 15:44, Amit Kapila

Re: error context for vacuum to include block number (atomic progress update)

2019-12-29 Thread Justin Pryzby
On Sat, Dec 28, 2019 at 07:21:31PM -0500, Robert Haas wrote: > On Thu, Dec 26, 2019 at 10:57 AM Justin Pryzby wrote: > > I agree that's better. > > I don't see any reason why the progress params need to be updated > > atomically. > > So rebasified against your patch. > > I am not sure whether

Re: TAP testing for psql's tab completion code

2019-12-29 Thread Tom Lane
Fabien COELHO writes: >> No, I disagree with that. If configure thinks it built with readline, >> and then the actual binary acts like it doesn't have readline, that's >> a bug that we'd like the tests to detect. > Hmmm. Sure, that's a point. > What about running some tests on an installed

Re: TAP testing for psql's tab completion code

2019-12-29 Thread Fabien COELHO
I'm not fan of relying on the configure stuff ("with_readline"), in my Expect version I tested if history capabilities are available from psql itself. No, I disagree with that. If configure thinks it built with readline, and then the actual binary acts like it doesn't have readline, that's a

Re: vacuum verbose detail logs are unclear (show debug lines at *start* of each stage?)

2019-12-29 Thread Jeff Janes
On Fri, Dec 20, 2019 at 12:11 PM Justin Pryzby wrote: > This is a usability complaint. If one knows enough about vacuum and/or > logging, I'm sure there's no issue. > > | 11 DEBUG: "t": found 999 removable, 999 nonremovable row versions in 9 > out of 9 pages > I agree the mixture of

Re: TAP testing for psql's tab completion code

2019-12-29 Thread Tom Lane
Fabien COELHO writes: > I've looked at your PoC implementation: > I'm not fan of relying on the configure stuff ("with_readline"), in my > Expect version I tested if history capabilities are available from psql > itself. No, I disagree with that. If configure thinks it built with readline,

Re: [PATCH] Increase the maximum value track_activity_query_size

2019-12-29 Thread Jeff Janes
On Tue, Dec 24, 2019 at 12:11 AM Robert Haas wrote: > On Sat, Dec 21, 2019 at 1:25 PM Tom Lane wrote: > > > What is the overhead here except the memory consumption? > > > > The time to copy those strings out of shared storage, any time > > you query pg_stat_activity. > > It seems like you're

Re: TAP testing for psql's tab completion code

2019-12-29 Thread Fabien COELHO
Hello Tom, If you have to install IO::Pty anyway, ISTM you can also install Expect. My point is precisely that buildfarm owners *won't* have to install IO::Pty; it comes in a default Perl install almost everywhere. I'm afraid that's not true of Expect. Hmmm. That is a good argument. Now

Re: Incremental View Maintenance: ERROR: out of shared memory

2019-12-29 Thread Tom Lane
Tatsuo Ishii writes: >> here is an unexpected error found while testing IVM v11 patches >> ... >> ERROR: out of shared memory > I think we could avoid such an error in IVM by reusing a temp table in > a session or a transaction. I'm more than a little bit astonished that this proposed patch is

Re: Greatest Common Divisor

2019-12-29 Thread Fabien COELHO
Hello, Because I do not trust C modulo as I had a lot of problems with it?:-) If I recall correctly (and I'm traveling and away from those notes), the exact semantics of C's % with negative operands was left implementation-defined until, was it, C99 ? Indeed, my woes with C % started

Re: TAP testing for psql's tab completion code

2019-12-29 Thread Tom Lane
Fabien COELHO writes: >> on the machines I have handy, the only one in which [Expect] appears in the >> default Perl installation is macOS. (Huh, what's Apple doing out ahead >> of the pack?) I'm pretty sure that Expect also relies on IO::Pty, > Indeed, it does. >> so it's a strictly worse

Re: Greatest Common Divisor

2019-12-29 Thread Chapman Flack
On 12/29/19 02:30, Fabien COELHO wrote: >>> C modulo operator (%) is a pain because it is not positive remainder >>> (2 % -3 == -1 vs 2 % 3 == 2, AFAICR). >> >> This does not seem to be the case... > ... > Because I do not trust C modulo as I had a lot of problems with it? :-) If I recall

Re: Recognizing superuser in pg_hba.conf

2019-12-29 Thread Robert Haas
On Sun, Dec 29, 2019 at 11:31 AM Tom Lane wrote: > I don't have any particular objection to '&' if people prefer that. > But ':' seems like it would introduce confusion with the > variable-substitution notation used in psql and some other places. > > It's not that hard to imagine that somebody

Re: Recognizing superuser in pg_hba.conf

2019-12-29 Thread Tom Lane
Robert Haas writes: > On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing > wrote: >> I'm all for this (and even suggested it during the IRC conversation that >> prompted this patch). It's rife with bikeshedding, though. My original >> proposal was to use '&' and Andrew Gierth would have used ':'. >

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

2019-12-29 Thread Robert Haas
On Sun, Dec 29, 2019 at 8:35 AM Dave Cramer wrote: > So where are we on this patch ? AFAICT using _pq is a protocol level option. It is, but it only lets you set the initial value, not change things later. Fixing that is probably going to require introducing a new protocol message with careful

Re: Recognizing superuser in pg_hba.conf

2019-12-29 Thread Robert Haas
On Sat, Dec 28, 2019 at 2:02 PM Vik Fearing wrote: > > these keywords are syntactically distinct from ordinary names. Given > > the precedent that "+" and "@" prefixes change what an identifier means, > > maybe we could use "*" or some other punctuation character as a keyword > > prefix? We'd

Re: Greatest Common Divisor

2019-12-29 Thread Vik Fearing
On 29/12/2019 08:30, Fabien COELHO wrote: > >>> I'm wondering what it should do on N, 0 and 0, 0. Raise an error? >>> Return 0? Return 1? return N? There should be some logic and comments >>> explaining it. >> >> Well, gcd(N, 0) is N, and gcd(0, 0) is 0, so I don't see an issue here? > > I think

Re: let's make the list of reportable GUCs configurable (was Re: Add %r substitution for psql prompts to show recovery status)

2019-12-29 Thread Dave Cramer
On Wed, 6 Nov 2019 at 11:09, Robert Haas wrote: > On Tue, Nov 5, 2019 at 10:02 AM Alvaro Herrera > wrote: > > There's a reason the SQL standard defines SET SESSION AUTHORIZATION but > > no RESET SESSION AUTHORIZATION: once you enter a security context, you > > cannot escape it. ISTM that

Re: ALTER INDEX fails on partitioned index

2019-12-29 Thread Robert Haas
On Thu, Dec 26, 2019 at 10:52 PM Justin Pryzby wrote: > Possibly attached should be backpatched through v11 ? > > This allows SET on the parent index, which is used for newly created child > indexes, but doesn't itself recurse to children. > > I noticed recursive "*" doesn't seem to be allowed

Re: Assert failure due to "drop schema pg_temp_3 cascade" for temporary tables and \d+ is not showing any info after drooping temp table schema

2019-12-29 Thread Robert Haas
On Fri, Dec 27, 2019 at 4:06 AM Michael Paquier wrote: > And committed down to 9.4. We use much more "temporary schema" in > error messages actually, so I have switched to that. I think this was a bad idea and that it should be reverted. It seems to me that the problem here is that you

Re: [PATCH] fix a performance issue with multiple logical-decoding walsenders

2019-12-29 Thread Julien Rouhaud
On Sat, Dec 28, 2019 at 1:56 PM Pierre Ducroquet wrote: > > Thank you for your comments. > Attached to this email is a patch with better comments regarding the > XLogSendLogical change. Arguably the first test to compare to InvalidXLogRecPtr is unneeded, as any value of EndRecPtr is greater or

Re: Physical replication slot advance is not persistent

2019-12-29 Thread Alexey Kondratov
On 2019-12-26 16:35, Alexey Kondratov wrote: Another concern is that ReplicationSlotIsDirty is added with the only one user. It also cannot be used by SaveSlotToPath due to the simultaneous usage of both flags dirty and just_dirtied there. In that way, I hope that we should call

Re: Incremental View Maintenance: ERROR: out of shared memory

2019-12-29 Thread Tatsuo Ishii
> Hello > here is an unexpected error found while testing IVM v11 patches > > create table b1 (id integer, x numeric(10,3)); > create incremental materialized view mv1 > as select id, count(*),sum(x) from b1 group by id; > > do $$ > declare > i integer; > begin > for i in

Re: pgbench - use pg logging capabilities

2019-12-29 Thread Michael Paquier
On Tue, Dec 24, 2019 at 11:17:31AM +0100, Fabien COELHO wrote: > Some printing to stderr remain for some pgbench specific output. Hmm. Wouldn't it make sense to output the log generated as information from the test using pg_log_info() instead of using fprintf(stderr) (the logs of the initial

remove some STATUS_* symbols

2019-12-29 Thread Peter Eisentraut
I have found the collection of STATUS_* defines in c.h a bit curious. There used to be a lot more even that have been removed over time. Currently, STATUS_FOUND and STATUS_WAITING are only used in one group of functions each, so perhaps it would make more sense to remove these from the global

Re: Disallow cancellation of waiting for synchronous replication

2019-12-29 Thread Andrey Borodin
> 29 дек. 2019 г., в 4:54, Robert Haas написал(а): > > On Sat, Dec 28, 2019 at 6:19 PM Maksim Milyutin wrote: >> The stuckness of backend is not deadlock here. To cancel waiting of >> backend fluently, client is enough to turn off synchronous replication >> (change synchronous_standby_names

Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions

2019-12-29 Thread Dilip Kumar
On Sat, Dec 28, 2019 at 9:33 PM Tomas Vondra wrote: > > On Tue, Dec 10, 2019 at 10:23:19AM +0530, Dilip Kumar wrote: > >On Tue, Dec 10, 2019 at 9:52 AM Amit Kapila wrote: > >> > >> On Mon, Dec 2, 2019 at 2:02 PM Dilip Kumar wrote: > >> > > >> > On Sun, Dec 1, 2019 at 7:58 AM Michael Paquier >