Re: master make check fails on Solaris 10

On Wed, 17 Jan 2018 18:02:26 +0300 Marina Polyakova wrote: > > Attached is a possible test program. I can confirm it passes on a > > machine with working __int128, but I have no idea whether it will > > detect the problem on yours. If not, maybe you can tweak it? >

Re: master make check fails on Solaris 10

Marina Polyakova writes: > On 17-01-2018 18:07, Tom Lane wrote: >> Yeah, I can work with this. What I propose to do is use a somewhat >> stripped-down version of this test as an AC_RUN_IFELSE test normally, >> but if cross-compiling, fall back to just seeing if we can

Re: Package version in PG_VERSION and version()

Christoph Berg writes: > Re: Tom Lane 2018-01-17 <15537.1516200...@sss.pgh.pa.us> >> IMO there's not really any evidence that we need an additional mechanism >> in this space. I don't see any way to get that evidence unless some >> packager tries to use the existing

Re: master make check fails on Solaris 10

BTW, now that you've demonstrated that the bug exists in a current gcc release, you should definitely file a bug at https://gcc.gnu.org/bugzilla/ I think you can just give them int128test2.c as-is as a test case. Please do that and let me know the PR number --- I think it would be good to cite

Re: Is there a "right" way to test if a database is empty?

I always do:\l+and then you can compare the size:new_one | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | | *7869 kB* | pg_default | template0 | postgres | UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +| *7869 kB* | pg_default | |

Re: proposal: alternative psql commands quit and exit

On 01/17/18 06:50, Geoff Winkless wrote: > Having said all that, has anyone suggested grabbing and writing out > using the "stty quit" value? That appears to work whatever level > you're at, readline-or-not, mid-line or not. It wasn't even something > I was aware of. Well, the usual use of

Re: Package version in PG_VERSION and version()

Re: Tom Lane 2018-01-17 <15537.1516200...@sss.pgh.pa.us> > IMO there's not really any evidence that we need an additional mechanism > in this space. I don't see any way to get that evidence unless some > packager tries to use the existing mechanism and hits insurmountable > problems. The problem

Re: master make check fails on Solaris 10

Marina Polyakova writes: > investigating the regression diffs, we found out that the error occurs > when we pass int128 as not the first argument to the function (perhaps > its value is replaced by the value of some address): > ... > Based on this, we modified the

Re: master make check fails on Solaris 10

Sorry, diff.patch is attached now. On 17-01-2018 18:02, Marina Polyakova wrote: [I added Victor Wagner as co-researcher of this problem] On 13-01-2018 21:10, Tom Lane wrote: In the end this might just be an instance of the old saw about avoiding dot-zero releases. Have you tried a newer gcc?

Re: pg_(total_)relation_size and partitioned tables

I'm setting this patch to Returned with feedback. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: [PATCH] session_replication_role = replica with TRUNCATE

Hi, On 02/01/18 17:16, Marco Nenciarini wrote: > Hi, > > I've tried to amend the documentation to be more clear. Feel free to > suggest further editing. Patch v2 attached. > I think the patch as is now looks okay. So marking as ready for committer. This is noteworthy for the release notes

Re: master make check fails on Solaris 10

Attached is a draft patch to incorporate Victor's slimmed-down test into configure. If you have a chance, could you confirm it does the right thing on your Sparc machine? BTW, it would be a good idea to set up a buildfarm member on that machine, if you care about whether that configuration

Re: [HACKERS] Proposal: Local indexes for partitioned table

On Tue, Jan 16, 2018 at 6:08 PM, David Rowley wrote: > On 17 January 2018 at 03:58, Alvaro Herrera wrote: >>> 9. Error details claim that p2_a_idx is not a partition of p. >>> Shouldn't it say table "p2" is not a partition of "p"? >> >> You

Re: Package version in PG_VERSION and version()

On 1/3/18 10:25, Robert Haas wrote: > On Tue, Jan 2, 2018 at 9:20 PM, Craig Ringer wrote: >> Last time I tried to actually deploy packages that used --with-extra-version >> a variety of tools that talk to postgres broke because they choked when >> parsing the version.

Re: master make check fails on Solaris 10

[I added Victor Wagner as co-researcher of this problem] On 13-01-2018 21:10, Tom Lane wrote: In the end this might just be an instance of the old saw about avoiding dot-zero releases. Have you tried a newer gcc? (Digging in their bugzilla finds quite a number of __int128 bugs fixed in 5.4.x,

Re: Package version in PG_VERSION and version()

I wrote: > Yeah, but the same argument could be made against the variant > you're proposing. In theory, people could have written arbitrarily > brittle checks of version numbers/strings. I'm not exactly convinced > that it's your (or our) problem if they did. BTW, as concrete evidence in this

Re: Is there a "right" way to test if a database is empty?

On 17 Jan 2018, at 6:34 PM, David G. Johnston wrote: > ​That was my original thought - though comparing the size of template1 to the > target database should be reasonably safe... > > If you do go for object detection you will want to ensure that no schemas >

Re: proposal: alternative psql commands quit and exit

On 17 January 2018 at 14:50, Tom Lane wrote: > (I'm still not very sure which of ^C and ^D have Windows equivalents.) Ctrl-C quits immediately for me no matter what input stage I'm at in Windows' psql. Ctrl-Z (DOS EOF) only quits after enter is pressed and only at

Re: Is there a "right" way to test if a database is empty?

On 17 Jan 2018, at 6:01 PM, pinker wrote: > I always do: \l+ and then you can compare the size: new_one | postgres | UTF8 > | en_US.UTF-8 | en_US.UTF-8 | | 7869 kB | pg_default | template0 | postgres | > UTF8 | en_US.UTF-8 | en_US.UTF-8 | =c/postgres +| 7869 kB | pg_default | |

Re: Is there a "right" way to test if a database is empty?

On 17 Jan 2018, at 5:47 PM, Graham Leggett wrote: > I need to test whether a database is empty, in other words “createdb” has > been executed but no data of any kind appears in that database. > > What is the correct postgresql way to do this? > > Is there a pg_isempty

Re: CREATE ROUTINE MAPPING

> > CREATE ROUTINE MAPPING local_routine_name > > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [ > argname ] > > > argtype [ { DEFAULT | = } default_expr ] [, ...] ] ) > > >[ RETURNS rettype > > > | RETURNS TABLE ( column_name column_type [, ...] ) ] > > > SERVER

Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

On 17 October 2017 at 14:16, Robert Haas wrote: > On Sat, Oct 14, 2017 at 2:14 PM, Tomas Vondra > wrote: >> I propose is to add a new cursor option (PARALLEL), which would allow >> parallel plans for that particular user-defined cursor.

Re: Package version in PG_VERSION and version()

Christoph Berg writes: > Re: Peter Eisentraut 2018-01-17 > >> So what is the next action this thread? I think --with-extra-version is >> the right solution for packagers, so I'm tempted to close this commit >>

Re: proposal: alternative psql commands quit and exit

Chapman Flack writes: > On 01/17/18 06:50, Geoff Winkless wrote: >> Having said all that, has anyone suggested grabbing and writing out >> using the "stty quit" value? That appears to work whatever level >> you're at, readline-or-not, mid-line or not. It wasn't even

Re: Package version in PG_VERSION and version()

Re: Tom Lane 2018-01-17 <16522.1516201...@sss.pgh.pa.us> > I wrote: > > Yeah, but the same argument could be made against the variant > > you're proposing. In theory, people could have written arbitrarily > > brittle checks of version numbers/strings. I'm not exactly convinced > > that it's your

Is there a "right" way to test if a database is empty?

Hi all, I need to test whether a database is empty, in other words “createdb” has been executed but no data of any kind appears in that database. What is the correct postgresql way to do this? Is there a pg_isempty command or equivalent somewhere? Regards, Graham — smime.p7s Description:

Builtin connection polling

Hi hackers, My recent experiments with pthread version of Postgres show that although pthread offers some performance advantages comparing with processes for large number of connections, them still can not eliminate need in connection pooling. Large number even of inactive connections cause

Re: [HACKERS] [Patch] Log SSL certificate verification errors

Graham, will you be able to respond to my questions or provide an updated patch within the next week or so? On 1/2/18 09:17, Peter Eisentraut wrote: > The server-side changes look pretty reasonable. > > On the client side, I'd like to see some comments explaining the > business around

Re: Package version in PG_VERSION and version()

Re: Peter Eisentraut 2018-01-17 > So what is the next action this thread? I think --with-extra-version is > the right solution for packagers, so I'm tempted to close this commit > fest item. There is some speculation that using it could

Re: proposal: alternative psql commands quit and exit

On 17 January 2018 at 14:17, Chapman Flack wrote: > Well, the usual use of SIGQUIT is to abort a process while generating > a core dump so it can be post-mortem debugged, and the abort is immediate > without any exit hooks in the process having a chance to execute, so >

Re: master make check fails on Solaris 10

On 17-01-2018 18:28, Tom Lane wrote: BTW, now that you've demonstrated that the bug exists in a current gcc release, you should definitely file a bug at https://gcc.gnu.org/bugzilla/ I think you can just give them int128test2.c as-is as a test case. Please do that and let me know the PR number

Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

On 2 November 2017 at 01:55, Robert Haas wrote: > On Wed, Nov 1, 2017 at 7:49 AM, Craig Ringer wrote: >> If the client wants to fetch in chunks it can use a portal and limited >> size fetches. That shouldn't (?) be parallel-unsafe, since nothing >>

Re: master make check fails on Solaris 10

On Wed, 17 Jan 2018 10:07:37 -0500 Tom Lane wrote: > Marina Polyakova writes: > Yeah, I can work with this. What I propose to do is use a somewhat > stripped-down version of this test as an AC_RUN_IFELSE test normally, > but if cross-compiling,

Re: Is there a "right" way to test if a database is empty?

On Wed, Jan 17, 2018 at 9:10 AM, Graham Leggett wrote: > > db=# select count(s.nspname) from pg_class c join pg_namespace s on s.oid > = c.relnamespace where s.nspname in ('public'); > count > --- > 0 > (1 row) > > It is based on the idea that the database is not

Re: [PATCH] Logical decoding of TRUNCATE

Hi, I reviewed 0001 in its own thread. So I think that we generally want this patch and I think the design decisions are right. Namely: TRUNCATE being treated as DELETE in terms of DML filtering makes sense to me as it is basically bulk delete, needs to be mentioned in release notes though.

Re: [HACKERS] GnuTLS support

On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane wrote: > Peter Eisentraut writes: > > On 1/17/18 12:39, Tom Lane wrote: > >> I don't know too much about the internals here, so looking at your > >> list, I wonder whether "ssl_dh_params_file" ought

Re: [HACKERS] postgres_fdw bug in 9.6

Etsuro Fujita writes: > (2018/01/16 6:38), Tom Lane wrote: >> I'm also still pretty unhappy with the amount of useless planning work >> caused by doing GetExistingLocalJoinPath during path creation. It strikes >> me that we could likely replace the entire thing with

Re: [HACKERS] GnuTLS support

Magnus Hagander writes: > On Wed, Jan 17, 2018 at 8:18 PM, Tom Lane wrote: >> What I don't want to end up with is an unholy mixture of both approaches. >> Therefore, if we are going to use method #2, we must be certain that >> the basic "ssl_" parameters

Re: Is there a "right" way to test if a database is empty?

On Wed, Jan 17, 2018 at 9:39 AM, Graham Leggett wrote: > Would it be true to say that if this query returned more than zero rows > the database is not empty? > > db=# select distinct s.nspname from pg_class c join pg_namespace s on > s.oid = c.relnamespace where s.nspname not

Re: Unnecessary static variable?

Antonin Houska writes: > While reading XLogPageRead() I was surprised that readLen variable is set but > not used in the read() call. Then I realized that it's declared static > although no other function uses it. Maybe it was used earlier to exit early if > sufficient amount of

Re: [HACKERS] GnuTLS support

Peter Eisentraut writes: > Question for the group: We currently have a number of config settings > named ssl_*. Some of these are specific to OpenSSL, some are not, namely: > # general > ssl > ssl_dh_params_file > ssl_cert_file > ssl_key_file > ssl_ca_file >

Re: [HACKERS] GnuTLS support

On 1/17/18 12:39, Tom Lane wrote: > I don't know too much about the internals here, so looking at your > list, I wonder whether "ssl_dh_params_file" ought to be treated as > implementation-specific too. The other four files seem essential > to any feature-complete implementation, but is that one?

Re: Test-cases for exclusion constraints is missing in alter_table.sql file

Ashutosh Sharma writes: > While working on exclusion constraints for one of our internal > project, I noticed that there is no test-case for exclusion > constraints in alter_table.sql file. However, for other constraints i > could see lots of test-cases in alter_table.sql.

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Jan 17, 2018 at 5:47 AM, Amit Kapila wrote: > I could still reproduce it. I think the way you have fixed it has a > race condition. In _bt_parallel_scan_and_sort(), the value of > brokenhotchain is set after you signal the leader that the worker is > done (by

Re: Unnecessary static variable?

Tom Lane wrote: > Antonin Houska writes: > but your patch also does this: Yes, that should have been a separate diff. > > *** retry: > > *** 11648,11654 > > } > > > > pgstat_report_wait_start(WAIT_EVENT_WAL_READ); > > ! if

Re: PostgreSQL crashes with SIGSEGV

Aleksandr Parfenov writes: > The new status of this patch is: Ready for Committer I don't feel particularly comfortable committing a patch that was clearly labeled as a rushed draft by its author. Peter, where do you stand on this work? In a quick look at the patches,

Re: [HACKERS] PATCH: enabling parallel execution for cursors explicitly (experimental)

On Wed, Jan 17, 2018 at 8:53 AM, Simon Riggs wrote: > At present, one major use of Cursors is in postgres_fdw. > > In that usage, the query executes and returns all the rows. No other > side execution is possible. True, although foreign tables using postgres_fdw can't be

Re: CREATE ROUTINE MAPPING

On Wed, Jan 17, 2018 at 11:09:19AM -0500, Corey Huinker wrote: > > > CREATE ROUTINE MAPPING local_routine_name > > > > FOR (FUNCTION | PROCEDURE) remote_routine_name ( [ [ argmode ] [ > > argname ] > > > > argtype [ { DEFAULT | = } default_expr ] [, ...] ] ) > > > >[ RETURNS rettype > > > >

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Mon, Jan 15, 2018 at 7:54 PM, Peter Geoghegan wrote: >> BufFileView() looks fairly pointless. It basically creates a copy of >> the input and, in so doing, destroys the input, which is a lot like >> returning the input parameter except that it uses more cycles. It >> does do a

Re: [HACKERS] GnuTLS support

On 1/2/18 10:35, Peter Eisentraut wrote: > On 11/26/17 20:05, Andreas Karlsson wrote: >> I have now implemented this in the attached patch (plus added support >> for channel binding and rebased it) but I ran into one issue which I >> have not yet solved. The script for the windows version takes

Re: Package version in PG_VERSION and version()

On 1/17/18 10:14, Christoph Berg wrote: > The difference is that when parsing version() (which is all my variant > is changing), people already have to deal with extra stuff at the end > (gcc version), while that would be new for "psql --version". For me, having the package identifier in "psql

Re: [HACKERS] [PATCH] Improve geometric types

> I'm not sure what you mean by the "basic comparison ops" but I'm > fine with the policy, handling each component values in the same > way with float. So point_eq_point() is right and other functions > should follow the same policy. I mean <, >, <= and >= by basic comparison operators.

Re: Unnecessary static variable?

Antonin Houska writes: > Tom Lane wrote: >> At one time, I think, readLen told how much data in readBuf was >> actually valid. It seems not to be used for that anymore, but >> I don't much like the idea that readBuf is only partially filled >> but there is

Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently

On Sat, Jan 6, 2018 at 7:33 PM, Stephen Frost wrote: > Greetings Claudio, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > > On Mon, Nov 27, 2017 at 2:39 PM, Jing Wang > wrote: > > > A few general comments. > > > > > > +

Re: [HACKERS] postgres_fdw bug in 9.6

On Mon, Jan 15, 2018 at 4:38 PM, Tom Lane wrote: > There *is* a problem with GetExistingLocalJoinPath not honoring its > API spec: it will sometimes return join nests that include remote > joins at levels below the top, as I'd speculated to begin with. > This turns out not to

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Sat, Jan 6, 2018 at 7:35 PM, Stephen Frost wrote: > Greetings, > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire > wrote: > > > They did apply at the time, but I think major work on vacuum

Re: General purpose hashing func in pgbench

Hello Fabien, 17/01/2018 10:52, Fabien COELHO пишет: >> Here is a new version of patch. I've splitted it into two parts. The >> first one is almost the same as v4 from [1] with some refactoring. >> The second part introduces random_seed variable as you proposed. > > Patch 1 applies.

Re: PostgreSQL crashes with SIGSEGV

On Wed, Jan 17, 2018 at 12:31 PM, Tom Lane wrote: > Probably not very. It'd be nice to have it done by the next minor > releases, ie before 5-Feb ... but given that these bugs are years > old, missing that deadline would not be catastrophic. Got it. >> I'm not sure whether

Re: [HACKERS] Useless code in ExecInitModifyTable

Etsuro Fujita writes: > (2018/01/15 11:35), Amit Langote wrote: >> On 2018/01/15 11:28, Stephen Frost wrote: >>> Seems like this has gotten a review (and quite a bit of down-stream >>> discussion that seemed pretty positive), and the latest patch still >>> applies

Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem

On Wed, Jan 17, 2018 at 5:02 PM, Claudio Freire wrote: > > > On Sat, Jan 6, 2018 at 7:35 PM, Stephen Frost wrote: > >> Greetings, >> >> * Michael Paquier (michael.paqu...@gmail.com) wrote: >> > On Mon, Dec 4, 2017 at 2:38 PM, Claudio Freire

[PATCH][PROPOSAL] Refuse setting toast.* reloptions when TOAST table does not exist

Hi! This patch is part of a bigger patch I've offered before https://www.postgresql.org/message-id/flat/2146419.veIEZdk4E4@x200m#2146419.veIEZdk4E4@x200m as we agreed I am trying to commit it by smaller bits This patch raises error if user tries o set or change toast.* option for a table that

Re: jsonpath

On 01/15/2018 07:24 PM, Andrew Dunstan wrote: > > On 01/10/2018 05:42 PM, Nikita Glukhov wrote: >> Attached new 8th version of jsonpath related patches. Complete >> documentation is still missing. >> >> The first 4 small patches are necessary datetime handling in jsonpath: >> 1. simple

Re: [HACKERS] postgres_fdw bug in 9.6

Robert Haas writes: > On Wed, Jan 17, 2018 at 3:37 PM, Tom Lane wrote: >> Looks OK to me. Would it be worth annotating the added regression test >> case with a comment that this once caused EPQ-related planning problems? > I tend to think somebody who

Re: proposal: alternative psql commands quit and exit

On 17 Jan 2018 20:12, "Robert Haas" wrote: On Wed, Jan 17, 2018 at 10:00 AM, Geoff Winkless wrote: > On 17 January 2018 at 14:50, Tom Lane wrote: >> (I'm still not very sure which of ^C and ^D have Windows equivalents.) > > Ctrl-C

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Tue, Jan 16, 2018 at 2:00 AM, Yoshimi Ichiyanagi wrote: > C-5. Running the 2 benchmarks(1. pgbench, 2. my insert benchmark) > C-5-1. pgbench > # numactl -N 1 pgbech -c 32 -j 8 -T 120 -M prepared [DB_NAME] > > The averages of running pgbench three times are: >

Re: PostgreSQL crashes with SIGSEGV

Peter Geoghegan writes: > On Wed, Jan 17, 2018 at 12:31 PM, Tom Lane wrote: >> +1. If the problem isn't known to be reproducible in those branches, >> the risk of adding new bugs seems to outweigh any benefit. > You could make the same objection to changing

Re: proposal: alternative psql commands quit and exit

On 17 January 2018 at 15:00, I wrote: > Ctrl-C quits immediately for me no matter what input stage I'm at in > Windows' psql. Ctrl-Z (DOS EOF) only quits after enter is pressed and > only at beginning-of-line, so I'd say suggesting the user uses Ctrl-C > in windows makes sense. ^D doesn't appear

Re: [HACKERS][PATCH] Applying PMDK to WAL operations for persistent memory

On Tue, Jan 16, 2018 at 2:00 AM, Yoshimi Ichiyanagi wrote: > Using pgbench which is a PostgreSQL general benchmark, the postgres server > to which the patches is applied is about 5% faster than original server. > And using my insert benchmark, it is up to 90%

Re: PostgreSQL crashes with SIGSEGV

Peter Geoghegan writes: > On Wed, Jan 17, 2018 at 11:23 AM, Tom Lane wrote: >> I don't feel particularly comfortable committing a patch that >> was clearly labeled as a rushed draft by its author. >> Peter, where do you stand on this work? > I would like to

Re: proposal: alternative psql commands quit and exit

On Wed, Jan 17, 2018 at 10:00 AM, Geoff Winkless wrote: > On 17 January 2018 at 14:50, Tom Lane wrote: >> (I'm still not very sure which of ^C and ^D have Windows equivalents.) > > Ctrl-C quits immediately for me no matter what input stage I'm at in >

Re: PostgreSQL crashes with SIGSEGV

On Wed, Jan 17, 2018 at 11:23 AM, Tom Lane wrote: > Aleksandr Parfenov writes: >> The new status of this patch is: Ready for Committer > > I don't feel particularly comfortable committing a patch that > was clearly labeled as a rushed draft by its

Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Jan 17, 2018 at 3:37 PM, Tom Lane wrote: > Robert Haas writes: >> Thanks for the review. Updated patch attached. > > Looks OK to me. Would it be worth annotating the added regression test > case with a comment that this once caused EPQ-related

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Haribabu Kommi writes: > [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ] I started to look through this, and almost immediately found that the diff in t/002_pg_dump.pl doesn't seem necessary --- the test passes for me without applying that hunk. Is

Re: [HACKERS] postgres_fdw bug in 9.6

(2018/01/16 6:38), Tom Lane wrote: Robert Haas writes: On Mon, Jan 15, 2018 at 12:31 PM, Tom Lane wrote: Hm. Simple is certainly good, but if there's multiple rows coming back during an EPQ recheck then I think we have a performance problem. You

Re: [HACKERS] postgres_fdw bug in 9.6

(2018/01/16 12:00), Etsuro Fujita wrote: (2018/01/16 11:17), Tom Lane wrote: Etsuro Fujita writes: (2018/01/16 1:47), Robert Haas wrote: Hmm, I was thinking that bar and baz wouldn't be constrained to return just one tuple in that case, but I'm wrong: there would

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

On 17 January 2018 at 17:05, David Rowley wrote: > 6. Which brings me to; why do we need match_clauses_to_partkey at all? > classify_partition_bounding_keys seems to do all the work > match_clauses_to_partkey does, plus more. Item #3 above is caused by > an

Re: [Sender Address Forgery]Re: [Sender Address Forgery]Re: [HACKERS] path toward faster partition pruning

Hi David. On Wed, Jan 17, 2018 at 6:19 PM, David Rowley wrote: > On 17 January 2018 at 17:05, David Rowley > wrote: >> 6. Which brings me to; why do we need match_clauses_to_partkey at all? >> classify_partition_bounding_keys seems to

Re: [HACKERS] Deadlock in XLogInsert at AIX

On Tue, Jan 16, 2018 at 08:50:24AM -0800, Andres Freund wrote: > On 2018-01-16 16:12:11 +0900, Michael Paquier wrote: > > On Fri, Feb 03, 2017 at 12:26:50AM +, Noah Misch wrote: > > > Since this emits double syncs with older xlc, I recommend instead > > > replacing > > > the whole thing with

Re: [HACKERS] WIP: Covering + unique indexes.

Hi! > 16 янв. 2018 г., в 21:50, Anastasia Lubennikova > написал(а): > > Updated patches are attached. > Cool, thanks! I've looked into the code, but haven't found anything broken. Since I've tried to rebase patch myself and failed on parse utils, I've spend some

Re: WIP Patch: Precalculate stable functions, infrastructure v1

Thank you so much for your comments!! I'll answer a bit later because now I'm trying to find a test for int128 on Solaris 10.. [1] On 17-01-2018 1:05, Tom Lane wrote: [ I'm sending this comment separately because I think it's an issue Andres might take an interest in. ] Marina Polyakova

Re: PATCH: psql tab completion for SELECT

On 15 January 2018 at 15:45, Andres Freund wrote: > On January 14, 2018 5:44:01 PM PST, Edmund Horner wrote: >>In psql if you have readline support and press TAB, psql will often >>run a DB query to get a list of possible completions to type on your

Re: [HACKERS] postgres_fdw bug in 9.6

On Wed, Jan 17, 2018 at 4:08 PM, Tom Lane wrote: > It's debatable perhaps -- I tend to err in the other direction. > But likewise, I don't care deeply. Just push it ... Done. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

On Thu, Jan 18, 2018 at 8:25 AM, Tom Lane wrote: > Haribabu Kommi writes: > > [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ] > > I started to look through this, and almost immediately found that the > diff in t/002_pg_dump.pl

Re: [HACKERS] GnuTLS support

On 01/17/2018 11:14 PM, Peter Eisentraut wrote: > On 1/17/18 14:05, Tom Lane wrote: >> Although these corner cases are starting to make me feel like >> changing my original vote. Maybe we should forget the prefixes, in >> particular renaming gnutls_priorities to ssl_priorities, and just >>

Re: [HACKERS] replace GrantObjectType with ObjectType

On 1/16/18 23:38, Michael Paquier wrote: > It seems to me that you could just use rel->rd_rel->relkind instead of > get_rel_relkind(RelationGetRelid(rel)). right > 0004 alone fails to compile as OBJECT_RELATION is still listed in > objectaddress.c. This is corrected in 0005. Yeah, the ordering

Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall

Haribabu Kommi writes: > [ pg_dump-and-pg_dumpall-database-handling-refactoring_v12.patch ] I've gone through this in a once-over-lightly fashion. Since there was quite a bit of debate upthread about how things should work, I'd like to start by summarizing the

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Wed, Jan 17, 2018 at 10:27 AM, Robert Haas wrote: > On Wed, Jan 17, 2018 at 12:27 PM, Peter Geoghegan wrote: >> I think that both problems (the live _bt_parallel_scan_and_sort() bug, >> as well as the general issue with needing to account for parallel >>

Re: PostgreSQL crashes with SIGSEGV

On Wed, Jan 17, 2018 at 1:00 PM, Tom Lane wrote: >> You could make the same objection to changing tuplesort_getdatum() >> outside of the master branch, though. I think that going back further >> than that for the (arguably independent) tuplesort_getdatum() subset >> fix might

Re: PATCH: psql tab completion for SELECT

Edmund Horner writes: > On 15 January 2018 at 15:45, Andres Freund wrote: >> All worries like this are supposed to check the server version. > In psql there are around 200 such tab completion queries, none of > which checks the server version. Many would

Re: Setting BLCKSZ 4kB

On 01/16/2018 11:17 AM, Giuseppe Broccolo wrote: > Hi Sanyam, > > Interesting topic! > > 2018-01-16 7:50 GMT+01:00 sanyam jain >: > > Hi, > > I am trying to solve WAL flooding due to FPWs. > > > What are the cons of setting

Re: [HACKERS] [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM

В письме от 3 сентября 2017 11:45:43 пользователь Alvaro Herrera написал: > The new checks around toast table creation look like they belong to a > completely independent patch also ... the error message there goes > against message style guidelines also. Offered toast relation checks as a

Re: [HACKERS] GnuTLS support

On 1/17/18 13:18, Tom Lane wrote: >> The proposed GnuTLS patch does make use of ssl_dh_params_file. > > Right, but what happens if say macTLS doesn't? The previously proposed patch for that also makes use of ssl_dh_params_file. So while we can't guarantee that this will be the case for all TLS

Re: [HACKERS] GnuTLS support

On 1/17/18 14:05, Tom Lane wrote: > Although these corner cases are starting to make me feel like changing > my original vote. Maybe we should forget the prefixes, in particular > renaming gnutls_priorities to ssl_priorities, and just accept the need > to document some parameters as only relevant

Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)

On Tue, Jan 16, 2018 at 6:24 AM, Peter Geoghegan wrote: > On Fri, Jan 12, 2018 at 10:28 AM, Robert Haas wrote: >> More comments: > > Attached patch has all open issues worked through, including those > that I respond to or comment on below, as well as the

Re: master make check fails on Solaris 10

On Wed, 17 Jan 2018 11:33:09 -0500 Tom Lane wrote: > Attached is a draft patch to incorporate Victor's slimmed-down test > into configure. If you have a chance, could you confirm it does > the right thing on your Sparc machine? It seems that what it does is not exactly a

Re: [HACKERS] postgres_fdw bug in 9.6

(2018/01/18 7:09), Robert Haas wrote: On Wed, Jan 17, 2018 at 4:08 PM, Tom Lane wrote: It's debatable perhaps -- I tend to err in the other direction. But likewise, I don't care deeply. Just push it ... Done. Thanks for taking the time to work on this issue, Robert and

Re: master make check fails on Solaris 10

Victor Wagner writes: > Tom Lane wrote: >> Attached is a draft patch to incorporate Victor's slimmed-down test >> into configure. If you have a chance, could you confirm it does >> the right thing on your Sparc machine? > It seems that what it does is

Re: [HACKERS] Useless code in ExecInitModifyTable

(2018/01/18 4:46), Tom Lane wrote: Pushed. I think the long delay on this is really my fault for having raised an incorrect objection initially --- apologies for that. Thanks for committing! Best regards, Etsuro Fujita

Re: [HACKERS] Reorder header files in alphabetical order

(2018/01/18 8:10), Bruce Momjian wrote: Applied, thanks. Thanks for picking this up! Best regards, Etsuro Fujita

Re: Index-only scan returns incorrect results when using a composite GIST index with a gist_trgm_ops column.

Hello! > 18 янв. 2018 г., в 10:48, Kyotaro HORIGUCHI > написал(а): > > Gist imposes the ninth strategy to perform index only scan but > planner is not considering that > > Please find the attached patch. I agree with you that current behavior is a bug and

  1   2   >