Re: [GENERAL] autovacuum worker running amok - and me too ;)

p. maybe that helps. Maybe you could reduce the statistics targets for that table. I think we've heard that the analyze functions for PostGIS data types are memory hogs, too --- maybe it's worth inquiring about that on the postgis mailing lists. regards, tom lane

Re: [GENERAL] autovacuum worker running amok - and me too ;)

wambacher writes: > Tom Lane-2 wrote >> Maybe you could reduce the statistics targets for that table. > don't understand what you mean. do you mean how often that table is > autovacuumed? at the moment about once a day or once in two days, i think. No, I mean the amount

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

at into pg_dumpall? I feel no compulsion whatsoever to preserve any user-initiated changes in template0 across an upgrade. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_upgrade failing from 9.3 to 9.4 because "template0" already exists

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Perhaps pg_upgrade should deliberately ignore template0 regardless of >> datallowconn? And/or we should hard-wire that into pg_dumpall? > My thinking would be that pg_dumpall should be hard-wired for template0

Re: [GENERAL] VACUUM FULL doesn't reduce table size

nup of known-dead rows. But we were just guessing at that over here.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] PostgreSQL-related legal question

ndard language for you. If not, maybe you don't want that job. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] regclass and format('%I')

quoting, it would get some cases wrong, potentially creating security holes. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] is there a relationship between indexes and temporary file creation?

be able to help much about that. If you'd like additional advice, I'd recommend reviewing https://wiki.postgresql.org/wiki/Slow_Query_Questions and then taking the discussion to the pgsql-performance list. regards, tom lane -- Sent via pgsql-general mailing li

Re: [GENERAL] is there a relationship between indexes and temporary file creation?

x27;t scan all the partitions. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] regclass and format('%I')

output. You can do format('... AS %I ...', ..., column_label, ...) and be confident that the label will be exactly what you've got in column_label. This proposed change would break that for labels that happen to already have double-quotes --- but who are we to say that

Re: [GENERAL] Preserving formatting and comments in a VIEW definition

SQL code in an SCM repo, somewhere outside the database. Postgres itself saves views as parse trees, so there's no way it will ever remember whitespace or comments. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To mak

Re: [GENERAL] Slow query with join

e that both plans we've been shown are going to produce output sorted by actor.id. Maybe that's happenstance, or maybe not. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Unexpected array_remove results

re nontrivial effort to change it --- for example, there are several early-exit cases that return the original array unmodified, and that would be wrong if we were to adopt some other definition such as "force the lower bound to 1". regards, tom lane -- Sent via pgs

Re: [GENERAL] xml

Pavel Stehule writes: > result of xmlagg is not valid xml. Really? Either that's a bug, or it's declared wrong. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.p

Re: [GENERAL] scope quirk in copy in function

ontain a regular DML command. I'm pretty sure there is a hack in there that allows parameters to be transmitted down through PREPARE or D.C. ... regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] inputs into query planner costing

7;s expectable that the data distribution stats would be a bit different on the two systems, but large differences that persist across multiple ANALYZE attempts are unlikely. (Although ... you do have the same default_statistics_target on both systems, no? Table-specific statistics targets could

Re: [GENERAL] Why does CREATE INDEX CONCURRENTLY need two scans?

storage that's local to the backend running CREATE INDEX, and isn't accessible to other processes at all. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Would like to know how analyze works technically

about what your data is, what PG version you're using, etc. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Creating a non-strict custom aggregate that initializes to the first value

27;re you gonna return when there were no input rows? You won't be able to distinguish "no input rows" from "first input row had a NULL". Maybe you should rethink whatever activity you were wanting it for. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] now() vs 'epoch'::timestamp

n int, in 2038), so you really don't want to be using it. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Would like to know how analyze works technically

free (6 chunks); 32 used > 2015-04-01 14:23:27 EDT ERROR: out of memory > 2015-04-01 14:23:27 EDT DETAIL: Failed on request of size 80. > 2015-04-01 14:23:27 EDT STATEMENT: analyze verbose; We need to see all of that memory map, not just the last six lines of it.

Re: [GENERAL] quick q re execute & scope of new

new.* or some variant of that. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Error handling in C API function calls in a way that doesn't close client connection

f what you've said here, though, I can only suggest that you're looking for the problem in the wrong place. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] "could not split GIN page; no new items fit"

Looks to me like a bug (ie, the code seems to think this is a can't-happen case). Don't suppose you could supply sample data that triggers this? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscr

Re: [GENERAL] Problems with casting

ou define for "variant" is going to be a loaded gun just waiting to shoot your foot off, if you make all those casts implicit. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Problems with casting

Jim Nasby writes: > On 4/7/15 4:17 PM, Tom Lane wrote: >> I suspect that that's only the tip of the iceberg. Remember the mess >> we had with implicit casts to text? And those only existed for a dozen >> or so types, not for everything. Every function or operator you

Re: [GENERAL] Problems with casting

Jim Nasby writes: > On 4/7/15 4:35 PM, Tom Lane wrote: >> Just out of curiosity, what's the point of this type at all, compared >> to "anyelement" and friends? > The two big differences are that you can store a variant in a table > (with reasonable protect

Re: [GENERAL] "could not split GIN page; no new items fit"

t to something like DropBox and posting the public link here. So far I've been unable to reproduce the failure from Chris' data :-( Don't know why not. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] ecpg rejects input parameters

re commonly filled from execution of previous commands. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Error Creating DBlink Extension in 9.4.1

ee from its initial location.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Invalid memory alloc

amounts of memory as a single chunk). regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] A question about plans and multi-key pks

d knowledge about cross-column correlations. The actual details of the plan (ie, that the pkey index can be used) are determined much later. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscri

Re: [GENERAL] delete is getting hung when there is a huge data in table

index on the referencing column. That would make the FK is-it-ok-to-delete checks very slow. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Hash function constant in the Hash join algorithm

ime, implying more buffer-access overhead, tuple visibility checking, etc. A closer comparison might be to a nestloop that has a Materialize node above its inner relation. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To ma

Re: [GENERAL] Why is there no object create date is the catalogs?

that it was not as simple as it seems at first glance, and that it would be difficult to satisfy all use-cases. Try searching the archives for previous threads. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to

Re: [GENERAL] Thousands of schemas and ANALYZE goes out of memory

Bruce Momjian writes: > Is there a reason the following patch wasn't applied? I don't think anybody ever did the legwork to verify it was a good idea. In particular, it'd be good to check if sending a tabstat message for each table adds noticeable overhead.

Re: [GENERAL] Thousands of schemas and ANALYZE goes out of memory

Bruce Momjian writes: > On Wed, May 13, 2015 at 06:10:26PM -0400, Tom Lane wrote: >> Bruce Momjian writes: >>> Is there a reason the following patch wasn't applied? >> I don't think anybody ever did the legwork to verify it was a good idea. >> In partic

Re: [GENERAL] SELECT INTO and ON COMMIT

command > --- yeah, confusing, so no, the pl/psql ability is not deprecated. Part of the argument for deprecating the SQL-level SELECT INTO is exactly that it's confusingly spelled the same as plpgsql's SELECT INTO, but it means something totally different. regards

Re: [GENERAL] Slaves show different results for query

guration if you recreate the database using C locale, but personally I wouldn't risk it. Masters and slaves in a WAL-shipping replication configuration should be on substantially identical platforms, else you're just asking for trouble. regards, tom lane -- S

Re: [GENERAL] Allowing postgresql to accept 0xff syntax for data types that it makes sense for?

do something that is also in Oracle or DB2 or one of the other big boys, then we can probably rely on the assumption that they'll block anything really incompatible from becoming standardized ;-). OTOH, if the actual meaning of "a lot" is "MySQL", I'd be pretty worried

Re: [GENERAL] Allowing postgresql to accept 0xff syntax for data types that it makes sense for?

r int8). And it'd likely behoove you to check how Microsoft answers those questions, if you want to point to SQL Server as what's going to keep you out of standards-compatibility problems. (IOW, if 0x ever did get standardized, the text might well match what SQL Server does.)

Re: [GENERAL] Allowing postgresql to accept 0xff syntax for data types that it makes sense for?

Bill Moran writes: > Tom Lane wrote: >> Other questions you'd have to think about: what is the data type of >> 0x; what do you do with 0x (too big >> even for int8). And it'd likely behoove you to check how Microsoft >> an

Re: [GENERAL] Server tries to read a different config file than it is supposed to

a bit out of date, or at least oversimplified. One possible theory is that you had an "include" directive in the config file in /etc, causing it to try to read the other one? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Re: Allowing postgresql to accept 0xff syntax for data types that it makes sense for?

the bit types under the bus and replaced them with "binary strings". I wonder how painful it would be to update that stuff to be compatible with more recent versions of the standard. Or whether anyone really cares --- people doing this in PG seem to be happy enough with bytea

Re: [GENERAL] Enum in foreign table: error and correct way to handle.

irably for WHERE conditions on the enum column; you'd need to test.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Server tries to read a different config file than it is supposed to

Adrian Klaver writes: > On 05/23/2015 08:06 AM, Tom Lane wrote: >> I can't explain that claim, but for me, -c config_file=something >> seems to work as you'd expect, and a look at the server source >> code confirms that it should honor that (cf SelectConfigFiles()

Re: [GENERAL] Re: Server tries to read a different config file than it is supposed to

ses though. Also, I thought the fsync-everything code would only run if the server had been shut down uncleanly. Which maybe it was, but that bit of info wasn't provided either. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org)

Re: [GENERAL] Trying to solve a SocketError [Errno 13] Permission with PL/Python in PostgreSQL 9.3

abling SELinux makes the problem go away then that's it. (I do *not* recommend that as a permanent solution, of course. You'll want to find some finer-grained change to the security policy. Don't remember enough about SELinux to know what the most likely bet is.)

Re: [GENERAL] PG and undo logging

better design in principle, because the necessary maintenance can be done in background processes rather than making clients wait for transactions to finish. In practice, it's still pretty annoying, just in different ways than Oracle's UNDO. regards, tom lane --

Re: [GENERAL] Re: Server tries to read a different config file than it is supposed to

* in the data directory unaccessible, even renamed it, > and everything worked fine. The only difference is that these are > streaming-replicated standby servers. They also had been restarted without > explicitly terminating Postgres. Hm. I wonder why we aren't fsync'ing on crash

Re: [GENERAL] duplicate key value violates unique constraint "pg_class_relname_nsp_index"

ABLE looks --- but in a concurrent-transactions situation, neither CREATE TABLE will see the other's table as already existing. In race conditions like this, it's the unique index on the catalog that is the duplicate-preventer of last resort, and it's going to throw this error.

Re: [GENERAL] Constraint exclusion not working - need different constraints?

n the current setting of TimeZone. So the planner will refuse to make any deductions at all with them. You'd be much better off using child-table constraints like "timestamp" >= '2015-01-01' AND "timestamp" < '2015-01-08' because the p

Re: [GENERAL] Constraint exclusion not working - need different constraints?

"=?utf-8?b?RG91ZyBHb3JsZXk=?=" writes: > On Wed, 27 May 2015 18:21:58 -0400, Tom Lane wrote: > You'd be much better off using child-table constraints like > "timestamp" >= '2015-01-01' AND "timestamp" < '2015-01-08

Re: [GENERAL] Partitioning and performance

;t cost anything much to scan. If it's significant relative to the child table access time then you probably didn't need partitioning in the first place. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To

Re: [GENERAL] Partitioning and performance

f magnitude either way, but it's just not worth the extra complexity for data volumes very much less than that. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Partitioning and performance

ercising either of those win scenarios, and all you're measuring is the overhead of partitioning, which as I said is substantial. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

places to contain similar logic. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Efficient sorting the results of a join, without denormalization

width=24) (actual time=0.008..0.811 rows=1228 loops=1) -> Seq Scan on c (cost=0.00..16370.00 rows=100 width=24) (actual time=0.007..0.310 rows=1228 loops=1) Planning time: 0.796 ms Execution time: 1.390 ms (15 rows) regards, tom lane

Re: [GENERAL] Curious case of huge simple btree indexes bloat.

all the indexes on a table to be used like that, though. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Find out what on what function depends an index

really be able to prevent with this approach. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] postgres db permissions

get rid of the database's public schema and/or restrict who has CREATE permissions on it. But I can't see us shipping a default configuration in which only superusers can create tables. That would just encourage people to operate as superusers, which overall would be much less secure.

Re: [GENERAL] pg_relation_size performance issue

Getting rid of the useless join to pg_stat_all_tables would probably help; there's a lot of computation in that view. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Row visibility issue with consecutive triggers, one being DEFERRED

nother one because of the fresh UPDATE. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] cannot connect to database through ECPG but can through psql

correct. > What else should I look for to try to determine the cause of this error? Postmaster's log might offer some insight, especially if you turn on log_connections. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

sues remain to be looked at? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

Robert Haas writes: > On Fri, Jun 5, 2015 at 12:00 PM, Andres Freund wrote: >> On 2015-06-05 11:43:45 -0400, Tom Lane wrote: >>> So where are we on this? Are we ready to schedule a new set of >>> back-branch releases? If not, what issues remain to be looked at? >

Re: [GENERAL] alter column type

ntially throw off offsets for other values? Yes. This *will* break your table, spectacularly. The other person who was opining that it would work has no understanding of the actual storage layout. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgr

Re: [HACKERS] [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1

re saying is that you don't trust the already-committed patch very much, then maybe we'd better hold off another couple weeks for more review and testing. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] select count(*);

u can omit FROM. If you suppose that that's the underlying model then the result of "select count(*)" is completely natural. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] database-level lockdown

an't all forcibly win. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] GCC error and libmpfr.so.4 not found

your real problem is you have a broken gcc installation. Basic tools like that should not need a custom LD_LIBRARY_PATH to work. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.

Re: [GENERAL] Alter column from text[] to uuid[]

n there's a USING it needs to be worded more like ERROR: result of USING clause cannot be cast automatically to type uuid[] regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] localtime ?

as to where "localtime" is coming from: select * from pg_settings where name = 'TimeZone'; regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] support for ltree

be in core. (Even if there were a credible argument for putting ltree in core, I doubt it would win out over backwards-compatibility concerns. We've found in the past that moving things into core is not exactly transparent.) regards, tom lane -- Sent via pgsql-gen

Re: [GENERAL] double precision[] storage space questions

rialization before storing the data). TBH, that seems like a pretty silly decision. It guarantees that you cannot do any useful manipulations of the array on the database side. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To m

Re: [GENERAL] Row count estimation bug in BETWEEN?

y, because it usually doesn't make enough of a difference to matter. Currently we don't even bother to distinguish say ">" from ">=" for estimation purposes, though certainly we would need to in order to deal with zero-width ranges with any great amount of precisi

Re: [GENERAL] Row count estimation bug in BETWEEN?

Yaroslav writes: > Tom Lane-2 wrote >> PG doesn't try to estimate inequalities exactly, because it usually >> doesn't make enough of a difference to matter. Currently we don't >> even bother to distinguish say ">" from ">=" for esti

Re: [GENERAL] pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux

an PG 8.4.9. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] pg_class.reltuples VS pg_stat_all_tables.n_live_tup for estimation of table

e and dead)? I would guess it's live only but that is a >guess Hm. I'm pretty sure the planner takes it as counting live tuples only, but it looks like VACUUM thinks it includes recently-dead-but-not-yet- removable tuples. We might need to do some adjustment there.

Re: [GENERAL] PL/pgSQL: How to return two columns and multiple rows

#x27;s later examples, the best way is with LATERAL: select f.*, 'baz' as baz from foobartable, lateral myfunc(foo, bar) as f; regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] writable cte triggers reverse order

uld probably get the behavior you want if you make all the triggers DEFERRED so that they all fire at end-of-transaction, rather than at end of the statement that queued them. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To mak

Re: [GENERAL] pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux

Douglas Stetner writes: > On 18 Jun 2015, at 02:06 , Tom Lane wrote: >> Douglas Stetner writes: >>> Looking for confirmation there is an issue with pg_dump failing after >>> upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux. >> Quick thought --- did

Re: [GENERAL] Postgres SIGALRM timer

e've not heard similar reports elsewhere. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Trying to avoid a simple temporary variable declaration in a pl/pgsql function

#x27;t just use "RETURN expression" if this is all that will be in the function. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Less is More

to text, much less do any network I/O. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux

Ticket/Display.html?id=3712&user=guest&pass=guest That link doesn't work for me :-( I'm going to file this as a bug with Red Hat. In the meantime it looks like we can suggest ssl_renegotiation_limit = 0 as a temporary workaround. regards, tom lane --

Re: [GENERAL] Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux

I wrote: > I'm going to file this as a bug with Red Hat. In the meantime it looks > like we can suggest ssl_renegotiation_limit = 0 as a temporary workaround. Done at https://bugzilla.redhat.com/show_bug.cgi?id=1234487 regards, tom lane -- Sent via pg

Re: [GENERAL] foreign keys to foreign tables

cks for existance of the > ids in the foreign table, and then put a CHECK constraint on using that > function, but I thought I'd as first if there was a better way. What's going to happen when the foreign server decides to delete some rows from its table? regards,

Re: [GENERAL] Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux

seems this same update has also broken sendmail, mysql, and probably other services. Not for the same reason, but still ... Red Hat fell down badly on QA'ing this. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make change

Re: [GENERAL] Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux

sl library on the same host, of course. Red Hat have confirmed that this was caused by a faulty openssl security patch in RHEL6 and RHEL7. They apparently have a fix already, which I'd expect will ship in a day or two. Keep an eye on the bugzilla entry I posted upthread for status.

Re: [GENERAL] Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux

ails. The precise number of previous renegotiations does not matter. If the above is reproducible for you, there may be more than one bug :-( regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Re: pg_dump 8.4.9 failing after upgrade to openssl-1.0.1e-30.el6_6.11.x86_64 on redhat linux

fault SSL settings? Because I can't reproduce > the failure you show. Oh, scratch that: I do reproduce that in PG <= 9.3, just not in 9.4 or HEAD. Apparently our renegotiation rewrite in 9.4 affects this. regards, tom lane -- Sent via pgsql-general mailing l

Re: [GENERAL] Include.d and warnings

s did not change before the reload. It is just > overruled in an included configuration file. This is fixed in 9.4 and up. Since it's just cosmetic, we did not back-patch the change. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Counting the occurences of a substring within a very large text

so forth. I'd be a bit worried about the performance implications of throwing such large strings around, anyway. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Correct place for feature requests

=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JHQtdGA0LXQttC90Y/Qug==?= writes: > Is there any correct place for feature requests? Starting a thread here is a reasonable way. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes

Re: [GENERAL] Foreign data wrappers and indexes on remote side

f tds_fdw. It's mostly on the head of each individual FDW how smart plans for it will be. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] Need for re-index after pg_upgrade

Bruce, doesn't that doc need improvement? regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general

Re: [GENERAL] plpgsql question: select into multiple variables ?

using results. To make this noticeably better, we'd probably have to insist that INTO come at the end of the SELECT list, which would break lots and lots of existing client code ... so I'm not holding my breath. Moral of the story: being user-friendly by accepting sloppy syntax is not an

Re: [GENERAL] plpgsql question: select into multiple variables ?

"David G. Johnston" writes: > On Mon, Jun 29, 2015 at 4:27 PM, Tom Lane wrote: >> ... So what you wrote here is equivalent to >> >> SELECT MIN(CAL_DATE),MAX(CAL_DATE) ::date, last_weekend::date INTO >> first_weekend FROM sys.calendar ... > â€

Re: [GENERAL] Feature request: fsync and commit_delay options per database

vailable for other "real" > databases. > Is this feature or something similar planned? No. Neither of them make any sense per-database. regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make change

  1   2   3   4   5   6   7   8   9   10   >