Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

Thank you for the new patch. At Fri, 11 Nov 2016 16:42:43 +0900, Michael Paquier wrote in > On Fri, Nov 11, 2016 at 12:28 AM, Stephen Frost wrote: > > We should probably include in here that we may skip a checkpoint if no > > activity has happened, meaning that this is a safe setting to set fo

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Fri, Nov 11, 2016 at 12:28 AM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> Thanks for the review! Waiting for a couple of days more is fine for >> me. This won't change much. Attached is v15 with the fixes you >> mentioned. > > I figured I'd go ahead and start

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, > Aside from that, I'd like to comment this patch on other points > later. The start of this patch is that the fact that most of but not all geometric operators use fuzzy comparson. But Tom pointed out that the fixed fuzz factor is not reasonable but hard to find how to modify it. We can

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On Thu, Nov 10, 2016 at 6:41 PM, Tom Lane wrote: > I think you've fundamentally missed the point here. A data dump from a > table would be semantically indistinguishable from the lots-o-DATA-lines > representation we have now. What we want is something that isn't that. > In particular I don't s

Re: [HACKERS] postgres_fdw : altering foreign table not invalidating prepare statement execution plan.

> > That leaves the question of whether it's worth detecting table-level > option changes this way, or whether we should just handle those by forcing > a relcache inval in ATExecGenericOptions, as in Amit's original patch in > <5702298d.4090...@lab.ntt.co.jp>. I kind of like that approach; that >

Re: [HACKERS] Patch: Implement failover on libpq connect level.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Robert Haas > Great, committed. There's still potentially more work to be done here, > because my patch omits some features that were present in Victor's original > submission, like setting the fail

Re: [HACKERS] Calculation of param_source_rels in add_paths_to_joinrel

On Sat, Nov 5, 2016 at 2:16 AM, Tom Lane wrote: > Ashutosh Bapat writes: >> There's code in add_paths_to_joinrel() which computes the set of >> target relations that should overlap parameterization of any proposed >> join path. >> ... >> The calculations that follow are based on joinrel->relids (

Re: [HACKERS] Transactions involving multiple postgres foreign servers

On Wed, Nov 2, 2016 at 9:22 PM, Ashutosh Bapat wrote: > On Mon, Oct 31, 2016 at 6:17 AM, Masahiko Sawada > wrote: >> On Fri, Oct 28, 2016 at 3:19 AM, Robert Haas wrote: >>> On Wed, Oct 26, 2016 at 2:00 AM, Masahiko Sawada >>> wrote: I think we can consider the atomic commit and the atomi

Re: [HACKERS] Patch: Implement failover on libpq connect level.

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Mithun Cy > Yes this patch will only address failover to new master, values "master" > and "any" appeared sufficient for that case. Do you mean that unlike pgJDBC "standby" and "prefer_standby" are

Re: [HACKERS] [PATCH] Send catalog_xmin separately in hot standby feedback

On 25 October 2016 at 00:19, Petr Jelinek wrote: >> Now formatted a series: >> >> 1. Send catalog_xmin in hot standby feedback protocol > >> + xmin_epoch = nextEpoch; >> if (nextXid < xmin) >> - nextEpoch--; >> + xmin_epoch --; >> + catalog_xmin_epoch =

Re: [HACKERS] Microvacuum support for Hash Index

Hi Jesper, > Some initial comments. > > _hash_vacuum_one_page: > > + END_CRIT_SECTION(); > + _hash_chgbufaccess(rel, metabuf, HASH_READ, HASH_NOLOCK); > > The _hash_chgbufaccess() needs a comment. > > You also need a place where you call pfree for so->killedItems - mayb

Re: [HACKERS] Shared memory estimation for postgres

Hi Michael, Thanks for all the help and time. I have already developed a code where I can exactly calculate the to be allocated shared memory value based on the Postgres 9.5.4 code (i went through the code, found out the sizes and offset of all the structures used in the memory calculation process

Re: [HACKERS] Re: [BUGS] BUG #14350: VIEW with INSTEAD OF INSERT TRIGGER and COPY. Missing feature or working as designed.

On Fri, Nov 11, 2016 at 6:15 AM, Tom Lane wrote: > Haribabu Kommi writes: > > [ copy_to_view_3.patch ] > > Pushed with cosmetic adjustments. > Thank you. Regards, Hari Babu Fujitsu Australia

Re: [HACKERS] Shared memory estimation for postgres

On Fri, Nov 11, 2016 at 1:26 PM, leoaaryan wrote: > I think the method "pg_get_shmem_allocations" mentioned in the patch will > give the allocated shared memory when the postgres db server is running. I'm > trying to get the same without running the server if possible. That's up to "read the code

Re: [HACKERS] Danger of automatic connection reset in psql

2016-11-11 5:14 GMT+01:00 Ashutosh Bapat : > > > > How about, instead of all this, adding an option to psql to suppress > > the automatic reconnect behavior? When enabled, psql just exits > > instead of trying to reconnect. > > > +1. But, existing users may not notice addition of the new option a

Re: [HACKERS] Shared memory estimation for postgres

Hi Craig, Sorry for the multiple point of contact for the same question. I'll keep in mind to attach similar corresponding links in future if any. http://stackoverflow.com/questions/39607940/is-it-possible-to-know-the-memory-being-allocated-by-the-method-createsharedmem and http://stackoverflow.c

Re: [HACKERS] Shared memory estimation for postgres

Hi Michael, I think the method "pg_get_shmem_allocations" mentioned in the patch will give the allocated shared memory when the postgres db server is running. I'm trying to get the same without running the server if possible. Please correct me if I have failed to understand the discussion thread

Re: [HACKERS] Danger of automatic connection reset in psql

> > How about, instead of all this, adding an option to psql to suppress > the automatic reconnect behavior? When enabled, psql just exits > instead of trying to reconnect. > +1. But, existing users may not notice addition of the new option and still continue to face problem. If we add the option

Re: [HACKERS] Shared memory estimation for postgres

On 11 November 2016 at 06:57, leoaaryan wrote: > I am a newbie to databases and Postgres and I am trying to analyze the shared > memory being calculated and allocated by Postgres in the method > "CreateSharedMemoryAndSemaphores" for different major versions for different > postgres.conf file Note

Re: [HACKERS] Unlogged tables cleanup

On Thu, Nov 10, 2016 at 10:52 PM, Kuntal Ghosh wrote: > On Thu, Nov 10, 2016 at 3:42 PM, Michael Paquier > wrote: >> Nah. Looking at the code the fix is quite obvious. >> heap_create_init_fork() is checking for XLogIsNeeded() to decide if >> the INIT forknum should be logged or not. But this is w

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, > > Returning to the issue, the following query should give you the > > expected result. > > > > SELECT name, #thepath FROM iexit ORDER BY name COLLATE "C", 2; > > Yes, I have worked around it like this. What I couldn't understand is > how my patch can cause this regression. How is it p

Re: [HACKERS] Shared memory estimation for postgres

On Fri, Nov 11, 2016 at 8:40 AM, leoaaryan wrote: > The easiest way to find the value for the shared memory computation is to > change the logging level to DEBUG3 and start postgres DB engine and it will > give the calculated value in the log file. > > I believe postgres as a DB needs to be runnin

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Magnus Hagander Okay and I think partially it might be because we don't have > writeback > optimization (done in 9.6) for Windows. However, still the broader > question stands th

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On 2016-11-09 10:47 AM, Tom Lane wrote: Amit Langote writes: On Wed, Nov 9, 2016 at 11:47 PM, Tom Lane wrote: Hmm, that's from 2009. I thought I remembered something much more recent, like last year or so. This perhaps: * Re: Bootstrap DATA is a pita * https://www.postgresql.org/message-id

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

Corey Huinker writes: > On Wed, Nov 9, 2016 at 10:47 AM, Tom Lane wrote: >> Yeah, that's the thread I remembered. I think the basic conclusion was >> that we needed a Perl script that would suck up a bunch of data from some >> representation that's more edit-friendly than the DATA lines, expand

Re: [HACKERS] Shared memory estimation for postgres

Hi Jay, If you are talking about http://evol-monkey.blogspot.com/2013/08/setting-sharedbuffers-hard-way.html and the "pg_buffercache" extensions then yes I have gone through it. The easiest way to find the value for the shared memory computation is to change the logging level to DEBUG3 and start

Re: [HACKERS] Do we need use more meaningful variables to replace 0 in catalog head files?

On Wed, Nov 9, 2016 at 10:47 AM, Tom Lane wrote: > Yeah, that's the thread I remembered. I think the basic conclusion was > that we needed a Perl script that would suck up a bunch of data from some > representation that's more edit-friendly than the DATA lines, expand > symbolic representations

Re: [HACKERS] Shared memory estimation for postgres

Do a web search on setting shared memory the hard way, and I think you'll see what you really need to do. -- Jay Sent from my iPad > On Nov 10, 2016, at 5:57 PM, leoaaryan wrote: > > I am a newbie to databases and Postgres and I am trying to analyze the shared > memory being calculated and all

Re: [HACKERS] Something is broken about connection startup

I wrote: > A quick look through the sources confirms that this error implies that > SearchSysCache on the RELOID cache must have failed to find a tuple for > pg_proc --- there are many occurrences of this text, but they all are > reporting that. Which absolutely should not be happening now that we

[HACKERS] Shared memory estimation for postgres

I am a newbie to databases and Postgres and I am trying to analyze the shared memory being calculated and allocated by Postgres in the method "CreateSharedMemoryAndSemaphores" for different major versions for different postgres.conf file My idea was to create a utility in Postgres and calll out th

[HACKERS] Something is broken about connection startup

I noticed that buildfarm member piculet fell over this afternoon: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=piculet&dt=2016-11-10%2020%3A10%3A02 with this interesting failure during startup of the "collate" test: psql: FATAL: cache lookup failed for relation 1255 1255 is pg_proc, and

Re: [HACKERS] Logical Replication WIP

On 04/11/16 13:15, Andres Freund wrote: > > /* Prototypes for private functions */ > -static bool libpq_select(int timeout_ms); > +static bool libpq_select(PGconn *streamConn, > + int timeout_ms); > > If we're starting to use this more widely, we real

Re: [HACKERS] WAL consistency check facility

On Fri, Nov 11, 2016 at 1:36 AM, Robert Haas wrote: > So, who are all of the people involved in the effort to produce this > patch, and what's the right way to attribute credit? The original idea was from Heikki as he has introduced the idea of doing such checks if you look at the original thread

Re: [HACKERS] Declarative partitioning - another take

On Wed, Nov 9, 2016 at 9:58 PM, Amit Langote wrote: >> With all patches applied, "make check" fails with a bunch of diffs >> that look like this: >> >> Check constraints: >> - "pt1chk2" CHECK (c2 <> ''::text) >> "pt1chk3" CHECK (c2 <> ''::text) > > Hm, I can't seem to reproduce this on

Re: [HACKERS] Improvements in psql hooks for variables

Rahila Syed wrote: > I have applied this patch on latest HEAD and have done basic testing which > works fine. Thanks for reviewing this patch! > >if (current->assign_hook) > >- (*current->assign_hook) (current->value); > >- return true; > >+

Re: [HACKERS] checkpoint_flush_after and friends

On Thu, Nov 10, 2016 at 12:17 PM, Andres Freund wrote: > On 2016-11-10 12:13:05 -0800, Jeff Janes wrote: > > configuration parameters *_flush_after were added in 9.6. They are not > in > > postgresql.conf.sample, but are also not marked GUC_NOT_IN_SAMPLE. Is > this > > intentional and/or desira

Re: [HACKERS] checkpoint_flush_after and friends

On 2016-11-10 12:13:05 -0800, Jeff Janes wrote: > configuration parameters *_flush_after were added in 9.6. They are not in > postgresql.conf.sample, but are also not marked GUC_NOT_IN_SAMPLE. Is this > intentional and/or desirable? Hm? $ grep flush_after src/backend/utils/misc/postgresql.conf.

[HACKERS] checkpoint_flush_after and friends

configuration parameters *_flush_after were added in 9.6. They are not in postgresql.conf.sample, but are also not marked GUC_NOT_IN_SAMPLE. Is this intentional and/or desirable? Cheers, Jeff

Re: [HACKERS] WIP: About CMake v2

Mark Kirkwood writes: > I would recommend making it behave as Tom suggested. *Then* add an > --autodetect or similar option that makes > behave in the 'finding and using what it could' manner as a 2nd patch. An "--autodetect" switch would be fine with me. I just don't want it to behave that way

Re: [HACKERS] WIP: About CMake v2

On 11/11/16 08:15, Yury Zhuravlev wrote: Craig Ringer wrote: So personally I think it'd be fine if a cmake build defaulted to finding and using what it could, but offered a --minimal mode or whatever that gets us just core postgres + whatever we enable explicitly. But our current behaviour is O

Re: [HACKERS] WIP: About CMake v2

Craig Ringer wrote: So personally I think it'd be fine if a cmake build defaulted to finding and using what it could, but offered a --minimal mode or whatever that gets us just core postgres + whatever we enable explicitly. But our current behaviour is OK too. To me it's best way. But I'm not s

Re: [HACKERS] Re: [BUGS] BUG #14350: VIEW with INSTEAD OF INSERT TRIGGER and COPY. Missing feature or working as designed.

Haribabu Kommi writes: > [ copy_to_view_3.patch ] Pushed with cosmetic adjustments. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Improving RLS planning

On 10 November 2016 at 17:12, Tom Lane wrote: > Yeah, I think we'd be best off to avoid the bare term "security". > It's probably too late to change the RTE field name "securityQuals", > but maybe we could uniformly call those "security barrier quals" in > the comments. Then the basic terminology

Re: [HACKERS] Declarative partitioning - another take

On Thu, Nov 10, 2016 at 7:40 AM, Amit Langote wrote: >> I think "partitioning key" is a bit awkward and actually prefer >> "partiton key". But "partition method" sounds funny so I would go >> with "partitioning method". > > OK, "partition key" and "partitioning method" it is then. Source code >

Re: [HACKERS] proposal: psql \setfileref

2016-11-10 18:56 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > 2016-11-09 22:47 GMT+01:00 Tom Lane : > >> * I really dislike the notion of keying the behavior to a special type > of > >> psql variable. > > > still I am thinking so some differencing can be nice, because we can use > > psql file

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On 11/10/16 1:03 PM, Stephen Frost wrote: > On Thursday, November 10, 2016, Joshua D. Drake > wrote: > > On 11/10/2016 09:33 AM, David Steele wrote: > > On 11/10/16 10:28 AM, Stephen Frost wrote: > > diff --git a/src/backend/access/tran

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On Thursday, November 10, 2016, Joshua D. Drake wrote: > On 11/10/2016 09:33 AM, David Steele wrote: > >> On 11/10/16 10:28 AM, Stephen Frost wrote: >> >> diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c >>> [...] >>> + if (lo

Re: [HACKERS] proposal: psql \setfileref

Pavel Stehule writes: > 2016-11-09 22:47 GMT+01:00 Tom Lane : >> * I really dislike the notion of keying the behavior to a special type of >> psql variable. > still I am thinking so some differencing can be nice, because we can use > psql file path tab autocomplete. > Maybe \setfileref can stay -

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On 11/10/2016 07:16 AM, Michael Paquier wrote: On Wed, Nov 9, 2016 at 7:46 PM, Andreas Karlsson wrote: Those tests fail due to that listen_addresses cannot be changed on reload so none of the test cases can even connect to the database. When I hacked ServerSetup.pm to set the correct listen_add

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On 11/10/2016 09:33 AM, David Steele wrote: On 11/10/16 10:28 AM, Stephen Frost wrote: diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c [...] + if (log_checkpoints) + ereport(LOG, (errmsg("checkpoint skippe

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

On 11/10/16 10:28 AM, Stephen Frost wrote: >> diff --git a/src/backend/access/transam/xlog.c >> b/src/backend/access/transam/xlog.c > [...] >> +if (log_checkpoints) >> +ereport(LOG, (errmsg("checkpoint skipped"))); > > Do we really need to log that

Re: [HACKERS] Improving RLS planning

Stephen Frost writes: > * Dean Rasheed (dean.a.rash...@gmail.com) wrote: >> On 8 November 2016 at 14:45, Tom Lane wrote: >>> ... I'm still suspicious that the three places I found may >>> represent bugs in the management of Query.hasRowSecurity. >> I don't believe that there are any existing bug

Re: [HACKERS] WAL consistency check facility

On Thu, Nov 10, 2016 at 10:02 AM, Kuntal Ghosh wrote: >> With the patch for BRIN applied, I am able to get installcheck-world >> working with wal_consistency = all and a standby doing the consistency >> checks behind. Adding wal_consistency = all in PostgresNode.pm, the >> recovery tests are passi

Re: [HACKERS] Fix checkpoint skip logic on idle systems by tracking LSN progress

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > Thanks for the review! Waiting for a couple of days more is fine for > me. This won't change much. Attached is v15 with the fixes you > mentioned. I figured I'd go ahead and start looking into this (and it's pretty easy for me to dis

Re: [HACKERS] WAL consistency check facility

On Thu, Nov 10, 2016 at 10:25 AM, Michael Paquier wrote: > On Wed, Nov 9, 2016 at 11:32 PM, Kuntal Ghosh >> Thanks a lot for reviewing the patch. Based on your review, I've attached the >> I've done a fair amount of testing which includes regression tests >> and manual creation of inconsistencies

Re: [HACKERS] Patch: Implement failover on libpq connect level.

On Thu, Nov 10, 2016 at 1:11 PM, Tsunakawa, Takayuki < tsunakawa.ta...@jp.fujitsu.com> wrote: > Why don't you add "standby" and "prefer_standby" as the target_server_type value? Are you thinking that those values are useful with load balancing > feature? Yes this patch will only address failover t

Re: [HACKERS] Copying Permissions

Corey, * Corey Huinker (corey.huin...@gmail.com) wrote: > I think allowing users to receive and send serialized relacl values (which > is what I *think* you're asking about here) is only slightly less icky, and That isn't actually what I was suggesting. > presents a backward compatibility issue.

Re: [HACKERS] Bug in comparison of empty jsonb arrays to scalars

Michael Paquier writes: > On Thu, Nov 10, 2016 at 7:37 AM, Tom Lane wrote: >> Given that nobody actually cares what that sort order is, I think that >> having to jump through hoops in pg_upgrade in order to fix it is not a >> great tradeoff. I suggest changing the documentation to match the code

Re: [HACKERS] proposal: psql \setfileref

Hi 2016-11-09 22:47 GMT+01:00 Tom Lane : > Pavel Stehule writes: > > [ psql-setfileref-2016-10-11.patch ] > > I haven't been paying any attention to this thread, but I got around to > looking at it finally. I follow the idea of wanting to be able to shove > the contents of a file into a query l

Re: [HACKERS] Copying Permissions

Robert, * Robert Haas (robertmh...@gmail.com) wrote: > On Wed, Nov 9, 2016 at 2:54 PM, Corey Huinker wrote: > > 3. The operation is judged to have succeeded if at least one permission is > > granted, or NO grants failed (i.e. there was nothing to grant). > > Allow me to be skeptical. If a user

Re: [HACKERS] Is user_catalog_table sensible for matviews?

Andres Freund writes: > On 2016-11-09 12:55:51 -0500, Robert Haas wrote: >> On Wed, Nov 9, 2016 at 12:17 PM, Tom Lane wrote: >>> The system will let you set the "user_catalog_table" reloption to "true" >>> on a materialized view. Is this sensible, or is it a bug caused by the >>> fact that relop

Re: [HACKERS] Improving RLS planning

Dean, * Dean Rasheed (dean.a.rash...@gmail.com) wrote: > On 8 November 2016 at 14:45, Tom Lane wrote: > > OK. In that case I'll need to adjust the patch so that the planner keeps > > its own flag about whether the query contains any securityQuals; that's > > easy enough. But I'm still suspiciou

Re: [HACKERS] Unlogged tables cleanup

On Thu, Nov 10, 2016 at 3:42 PM, Michael Paquier wrote: > On Thu, Nov 10, 2016 at 5:15 PM, Michael Paquier > wrote: >> Okay, so what happens is that the CREATE TABLESPACE record removes the >> tablespace directory and recreates a fresh one, but as no CREATE >> records are created for unlogged tab

[HACKERS] switching documentation build to XSLT

Some work has been going on recently to be able to update our documentation build tool chain. After discussion on pgsql-docs, the people involved agree that it is time to move forward. We are now proposing that we change the way the HTML documentation is built from jade/openjade+docbook-dsssl to

Re: [HACKERS] Bug in comparison of empty jsonb arrays to scalars

On 10.11.2016 09:54, Michael Paquier wrote: Yes, definitely. =# create table json_data (a jsonb); CREATE TABLE =# INSERT INTO json_data values ('{}'::jsonb), ('[]'::jsonb), ('null'::jsonb), ('true'::jsonb), ('1'::jsonb), ('""'::jsonb); INSERT 0 6 =# SELECT * FROM json_data ORDER BY 1 DESC; a

Re: [HACKERS] Fwd: Re: [CORE] temporal tables (SQL2011)

Hi, thanks for elaborating. yes, of course, I can implement it with 3 triggers, adding a couple of columns. It doesn't affect design and testing which stay the same. As we are developing a product that must support a couple of databases and as I am not really happy with Maria e.a., I want to sw

Re: [HACKERS] Adding in docs the meaning of pg_stat_replication.sync_state

On Wed, Nov 9, 2016 at 2:33 PM, Michael Paquier wrote: > Hi all, > > The documentation does not explain at all what means "sync" or "async" > on pg_stat_replication. "potential" state also should be explained? > The paragraph "Planning for high availability" > mentions "catchup" and "streaming",

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

> Returning to the issue, the following query should give you the > expected result. > > SELECT name, #thepath FROM iexit ORDER BY name COLLATE "C", 2; Yes, I have worked around it like this. What I couldn't understand is how my patch can cause this regression. How is it passes on master withou

Re: [HACKERS] Improving RLS planning

On 8 November 2016 at 16:46, Robert Haas wrote: > On Thu, Nov 3, 2016 at 6:23 PM, Tom Lane wrote: >>> I think that ordering might be sub-optimal if you had a mix of >>> leakproof quals and security quals and the cost of some security quals >>> were significantly higher than the cost of some other

Re: [HACKERS] Improving RLS planning

On 8 November 2016 at 14:45, Tom Lane wrote: > Stephen Frost writes: >> * Tom Lane (t...@sss.pgh.pa.us) wrote: >>> * Since the planner is now depending on Query.hasRowSecurity to be set >>> whenever there are any securityQuals, I put in an Assert about that, >>> and promptly found three places in

Re: [HACKERS] Is user_catalog_table sensible for matviews?

On 2016-11-09 12:55:51 -0500, Robert Haas wrote: > On Wed, Nov 9, 2016 at 12:17 PM, Tom Lane wrote: > > The system will let you set the "user_catalog_table" reloption to "true" > > on a materialized view. Is this sensible, or is it a bug caused by the > > fact that reloptions.c fails to distingui

Re: [HACKERS] Floating point comparison inconsistencies of the geometric types

Hello, At Thu, 29 Sep 2016 10:37:30 +0200, Emre Hasegeli wrote in > > regression=# select 'I- 580Ramp' < 'I- 580/I-680 > > Ramp'; > > ?column? > > -- > > t > > (1 row) > > on the Linux server I am testing, it is not: > > > regression=# selec

Re: [HACKERS] Unlogged tables cleanup

On Thu, Nov 10, 2016 at 5:15 PM, Michael Paquier wrote: > Okay, so what happens is that the CREATE TABLESPACE record removes the > tablespace directory and recreates a fresh one, but as no CREATE > records are created for unlogged tables the init fork is not > re-created. It seems to me that we sh

Re: [HACKERS] Remove the comment on the countereffectiveness of large shared_buffers on Windows

On Tue, Nov 8, 2016 at 5:03 AM, Amit Kapila wrote: > On Tue, Nov 8, 2016 at 5:12 AM, Jeff Janes wrote: > > On Mon, Nov 7, 2016 at 5:55 AM, Amit Kapila > wrote: > >> > >> On Tue, Sep 20, 2016 at 8:15 AM, Tsunakawa, Takayuki > >> wrote: > >> > I ran read-only and read-write modes of pgbench, and

Re: [HACKERS] Unlogged tables cleanup

On Thu, Nov 10, 2016 at 4:33 PM, Michael Paquier wrote: > On Thu, Nov 10, 2016 at 4:23 PM, konstantin knizhnik > wrote: >> No, it is latest sources from Postgres repository. >> Please notice that you should create new database and tablespace to >> reproduce this issue. >> So actually the whole s