Re: [HACKERS] Setting pd_lower in GIN metapage

On Mon, Sep 25, 2017 at 2:26 PM, Amit Kapila wrote: > I understand that and I think there are always multiple ways to write > same information. It might be better to pass this patch series to > committer if you don't see any mistake because he might anyway change > some

Re: [HACKERS] [Proposal] Allow users to specify multiple tables in VACUUM commands

On Sat, Sep 23, 2017 at 12:56 AM, Bossart, Nathan wrote: > On 9/21/17, 9:55 PM, "Michael Paquier" wrote: >> I still think that ExecVacuum() should pass a list of VacuumRelation >> objects to vacuum(), and get_rel_oids() should take in input a list,

Re: [HACKERS] Setting pd_lower in GIN metapage

On Mon, Sep 25, 2017 at 10:13 AM, Michael Paquier wrote: > On Sun, Sep 24, 2017 at 2:25 PM, Amit Kapila wrote: >> Added and updated the comments for both btree and hash index patches. > > I don't have real complaints about this patch, this

Re: [HACKERS] Rethinking autovacuum.c memory handling

On Sun, Sep 24, 2017 at 2:28 AM, Tom Lane wrote: > Michael Paquier writes: >> I have spent some time looking at your patch and testing it. This >> looks sane. A small comment that I have would be to add an assertion >> at the top of

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

On Mon, Sep 25, 2017 at 4:39 AM, Tomas Vondra wrote: > > > On 09/06/2017 09:45 AM, Haribabu Kommi wrote: > > > > > > On Tue, Jul 25, 2017 at 9:33 PM, Tomas Vondra > > > > wrote: > > > > On

Re: [HACKERS] Setting pd_lower in GIN metapage

On Sun, Sep 24, 2017 at 2:25 PM, Amit Kapila wrote: > Added and updated the comments for both btree and hash index patches. I don't have real complaints about this patch, this looks fine to me. +* Currently, the advantage of setting pd_lower is in limited cases like

Re: [HACKERS] visual studio 2017 build support

On Fri, Sep 22, 2017 at 10:40 PM, Andrew Dunstan < andrew.duns...@2ndquadrant.com> wrote: > > > On 09/21/2017 08:16 PM, Haribabu Kommi wrote: > > > > > > I was about to commit this after a good bit of testing when I > > noticed this: > > > > + Building with Visual Studio 2017 >

Re: [HACKERS] Page Scan Mode in Hash Index

On Fri, Sep 22, 2017 at 11:56 PM, Robert Haas wrote: > On Thu, Sep 21, 2017 at 3:08 AM, Ashutosh Sharma > wrote: >> I have added a note for handling of logged and unlogged tables in >> README file and also corrected the header comment for >>

[HACKERS] Patch to address concerns about ICU collcollate stability in v10 (Was: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it?)

On Fri, Sep 22, 2017 at 11:34 AM, Peter Eisentraut wrote: > After reviewing this thread and testing around a bit, I think the code > is mostly fine as it is, but the documentation is lacking. Hence, > attached is a patch to expand the documentation quite a bit,

Re: [HACKERS] What's with all the fflush(stderr) calls in pg_standby.c?

On 2017-09-25 10:01:35 +0900, Michael Paquier wrote: > On Mon, Sep 25, 2017 at 9:45 AM, Robert Haas wrote: > > On a related note, the idea of removing pg_standby altogether has been > > proposed a few times. Including recently by me

Re: [HACKERS] Shaky coding for vacuuming partitioned relations

On Sat, Sep 23, 2017 at 4:13 AM, Tom Lane wrote: > Somebody inserted this into vacuum.c's get_rel_oids(): > > tuple = SearchSysCache1(RELOID, ObjectIdGetDatum(relid)); > if (!HeapTupleIsValid(tuple)) > elog(ERROR, "cache lookup failed for relation

Re: [HACKERS] What's with all the fflush(stderr) calls in pg_standby.c?

On Mon, Sep 25, 2017 at 9:45 AM, Robert Haas wrote: > On a related note, the idea of removing pg_standby altogether has been > proposed a few times. Apparently there are a few things that it still > does better than standby_mode, but nobody seems in a hurry to do >

Re: [HACKERS] Fix number skipping in to_number

On Thu, Aug 17, 2017 at 12:33:02PM +0100, Oliver Ford wrote: > Ok I've made that change in the attached v3. I'm not sure as I'm on > en_US.UTF-8 locale too. Maybe something Windows specific? This patch applies against master (8485a25a), compiles, and passes a make check. I tested both on my

Re: [HACKERS] What's with all the fflush(stderr) calls in pg_standby.c?

On Sun, Sep 24, 2017 at 11:51 AM, Tom Lane wrote: > This looks like cargo-cult programming to me. stderr is almost > always line-buffered, making these fflush'es pointless. If it's > not line-buffered, that's probably because it's going to a > noninteractive destination for

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/24/2017 07:06 PM, Tom Lane wrote: > > So I think we should just stop with the blacklist test for v10, > and then see if we still get complaints (and exactly what they're > about) so that we can judge how much more work the problem deserves. > It's still ahead of where we were in previous

Re: [HACKERS] DROP SUBSCRIPTION hangs if sub is disabled in the same transaction

On Sat, Sep 23, 2017 at 4:06 AM, Peter Eisentraut wrote: > On 9/21/17 04:43, Masahiko Sawada wrote: >>> Once we got this patch, DROP SUBSCRIPTION is not transactional either >>> if dropping a replication slot or if the subscription got disabled in >>> a

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > On 09/24/2017 04:37 PM, Tom Lane wrote: >> What we still need to debate is whether to remove the heuristic >> type-is-from-same-transaction test, making the user-visible behavior >> simply "you must commit an ALTER TYPE ADD VALUE before you

Re: [HACKERS] Server crash due to SIGBUS(Bus Error) when trying to access the memory created using dsm_create().

On Thu, Aug 17, 2017 at 11:39 AM, Thomas Munro wrote: > On Thu, Jun 29, 2017 at 12:24 PM, Thomas Munro > wrote: >> fallocate-v5.patch > > Added to commitfest so we don't lose track of this. Rebased due to collision with recent

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/24/2017 04:37 PM, Tom Lane wrote: > Andrew Dunstan writes: >> OK, here's the finished patch. It has a pretty small footprint all >> things considered, and I think it guarantees that nothing that could be >> done in this area in 9.6 will be forbidden. That's

Re: [HACKERS] PATCH : Generational memory allocator (was PATCH: two slab-like memory allocators)

On 24 September 2017 at 21:32, Tomas Vondra wrote: > Attached is an updated version of the patch, tweaking the comments. That looks good, thanks. Marking Ready for Committer to give notice before commit. -- Simon Riggshttp://www.2ndQuadrant.com/

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

Andrew Dunstan writes: > OK, here's the finished patch. It has a pretty small footprint all > things considered, and I think it guarantees that nothing that could be > done in this area in 9.6 will be forbidden. That's probably enough to > get us to 10 without

[HACKERS] comments improvements

comments improvements--- src/backend/optimizer/prep/prepunion.c.orig 2017-09-24 17:40:34.888790877 +0200 +++ src/backend/optimizer/prep/prepunion.c 2017-09-24 17:41:39.796748743 +0200 @@ -2413,7 +2413,7 @@ * Find AppendRelInfo structures for all relations specified by relids. * * The

Re: [HACKERS] PATCH : Generational memory allocator (was PATCH: two slab-like memory allocators)

Hi, Attached is an updated version of the patch, tweaking the comments. 1) I've added a section at the end of src/backend/utils/mmgr/README, briefly explaining the alternative memory allocators we have. I don't think we should get into too much low-level detail here, that's more appropriate for

Re: [HACKERS] [BUGS] BUG #14825: enum type: unsafe use?

On 09/23/2017 06:06 PM, Tom Lane wrote: > Andrew Dunstan writes: >> OK, I think I'm convinced. Here's is the WIP code I put together for the >> blacklist. I'm was looking for a place to put the init call, but since >> it's possibly not going anywhere I stopped

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

Hi, Apologies, I forgot to respond to the second part of your message. On 09/06/2017 09:45 AM, Haribabu Kommi wrote: > > While testing this patch, I found another problem that is not related to > this patch. When the vacuum command is executed mutiple times on > a table with no dead rows, the

Re: [HACKERS] VACUUM and ANALYZE disagreeing on what reltuples means

On 09/06/2017 09:45 AM, Haribabu Kommi wrote: > > > On Tue, Jul 25, 2017 at 9:33 PM, Tomas Vondra > > wrote: > > On 7/25/17 12:55 AM, Tom Lane wrote: > > Tomas Vondra

Re: [HACKERS] ICU locales and text/char(n) SortSupport on Windows

On Sun, Sep 24, 2017 at 5:04 AM, Peter Eisentraut wrote: > On 9/22/17 12:25, Peter Geoghegan wrote: >> On Fri, Sep 22, 2017 at 7:25 AM, Peter Eisentraut >> wrote: >>> I agree. The attached patch should do it. >> >> I see one

[HACKERS] logical replication and statistics

Hi I did trivial example of logical replication (one table, one publication, one subscription) I am little bit surprised so after some work - the replication is working, the statistics are empty #master postgres=# select * from pg_stat_replication ; (0 rows) #slave postgres=# select * from

[HACKERS] What's with all the fflush(stderr) calls in pg_standby.c?

This looks like cargo-cult programming to me. stderr is almost always line-buffered, making these fflush'es pointless. If it's not line-buffered, that's probably because it's going to a noninteractive destination for which this wouldn't matter. Moreover, none of our other programs do this.

Re: [HACKERS] Built-in plugin for logical decoding output

On 24 September 2017 at 15:15, Craig Ringer wrote: > On 23 September 2017 at 06:28, Gregory Brail wrote: > >> >> Would the community support the development of another plugin that is >> distributed as part of "contrib" that addresses these issues? > >

[HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)

Hello Tom, Well, I think it's mostly about valgrind making everything really slow. Since we have seen some passes from skink recently, perhaps there was also a component of more-load-on-the-machine-than-usual. But in the end this is just evidence for my point that regression tests have to

Re: [HACKERS] Built-in plugin for logical decoding output

On 24 September 2017 at 07:41, Euler Taveira wrote: > It is difficult to > coordinate a change like that having only one-way communication). > > I really think we need to fix that at some point, such that: * Downstream

Re: [HACKERS] Built-in plugin for logical decoding output

On 23 September 2017 at 06:28, Gregory Brail wrote: > Would the community support the development of another plugin that is > distributed as part of "contrib" that addresses these issues? > Petr Jelinek and I tried just that with pglogical. Our submission was knocked back

Re: [HACKERS] OpenFile() Permissions Refactor

On 9/23/17 10:22 AM, Peter Eisentraut wrote: > On 9/13/17 10:26, David Steele wrote: >> Here's a new patch based on your review. Where I had a question I made >> a choice as described below: > > I have committed the changes to the file APIs and a fix for the umask > save/restore issue. Thank

Re: [HACKERS] ICU locales and text/char(n) SortSupport on Windows

On 9/22/17 12:25, Peter Geoghegan wrote: > On Fri, Sep 22, 2017 at 7:25 AM, Peter Eisentraut > wrote: >> I agree. The attached patch should do it. > > I see one small issue here: You'll now need to set ssup->comparator > back to NULL before you return early in

Re: [HACKERS] Log LDAP "diagnostic messages"?

On Wed, Sep 20, 2017 at 7:57 AM, Peter Eisentraut wrote: > In the 0001 patch, I would move the ldap_unbind() calls after the > ereport(LOG) calls. We do all the other resource cleanup (pfree() etc.) > after the ereport() calls, so it would be weird to do this

Re: [HACKERS] Built-in plugin for logical decoding output

On 24/09/17 02:41, Euler Taveira wrote: 2017-09-23 14:01 GMT-03:00 Alvaro Hernandez : However, AFAIK, AWS's DMS uses it for production purposes (see http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_PostgreSQL.html). It seems a bad idea. AFAICS test_decoding

Re: [HACKERS] pgbench regression test failure

Hello Tom, # progress: 2.6 s, 6.9 tps, lat 0.000 ms stddev 0.000, lag 0.000 ms, 18 skipped # progress: 3.0 s, 0.0 tps, lat -nan ms stddev -nan, lag -nan ms, 0 skipped # progress: 4.0 s, 1.0 tps, lat 2682.730 ms stddev 0.000, lag 985.509 ms, 0 skipped (BTW, the "-nan" bits suggest an actual