Currently, tab-completing :variable names in psql does not work at the
beginning of the line. Fix this by moving the code block before the
"empty buffer" case.
(I have several "sql macros" in my .psqlrc like :relsize that prints
table sizes in a nicely formatted way, being able to type : would
be
A customer recently upgraded their jdbc driver from 8.4 to 9.2. This
enabled the binary wire protocol (effectively between 9.1 and 9.2).
They reported that single precision values inserted into a
numeric(10,2) column were suddenly rounded wrongly, i.e. 1.18 was
inserted as 1.20, while that
Re: Tom Lane 2014-01-07 <14979.1389112...@sss.pgh.pa.us>
> > But if extra_float_digits > 0 is set, I'd expect not only the float4
> > output to be affected by it, but also casts to other datatypes,
>
> This proposal scares me. extra_float_digits is strictly a matter of
> I/O representation, it do
n its own, and several people in the thread seem to
have agreed back then.
Patch attached, I'll add it to the next commit fest.
Mit freundlichen Grüßen,
Christoph Berg
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204566209
Trompeterall
people in the thread seem to
> have agreed back then.
I forgot to add the archive URL here:
https://www.postgresql.org/message-id/758d5e7f0804030023j659d72e6nd66a9d6b93b30886%40mail.gmail.com
Mit freundlichen Grüßen,
Christoph Berg
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB M
Re: Stephen Frost 2017-01-27 <20170127160544.gi9...@tamriel.snowman.net>
> > > Uh, I figured it was more like \g, which just re-runs the last query..
> > > As in, you'd do:
> > >
> > > table pg_proc; % blargh, I can't read it like this
> > > \G % ahh, much nicer
> >
> > Sure, that's exactly the s
Re: Daniel Verite 2017-01-28
<74e7fd23-f5a9-488d-a8c4-1e0da674b...@manitou-mail.org>
> > Mysql's CLI client is using \G for this purpose, and adding the very
> > same functionality to psql fits nicely into the set of existing
> > backslash commands: \g sends the query buffer, \G will do exactly th
es not support a filename argument. (It will
instead stuff the argument into the next query buffer.)
(The \G patch already supports the filename argument.)
Mit freundlichen Grüßen,
Christoph Berg
--
Senior Berater, Tel.: +49 2166 9901 187
credativ GmbH, HRB Mönchengladbach 12080, USt-ID-Nummer: DE204
The majority of voices here was in favor of using \gx, so here is
another version of the same patch which implements that.
Christoph
diff --git a/doc/src/sgml/ref/psql-ref.sgml b/doc/src/sgml/ref/psql-ref.sgml
new file mode 100644
index ae58708..e0302ea
*** a/doc/src/sgml/ref/psql-ref.sgml
--- b/d
Re: David Fetter 2017-02-07 <20170207051659.gc3...@fetter.org>
> On Mon, Feb 06, 2017 at 08:54:13PM +0100, Christoph Berg wrote:
> > The majority of voices here was in favor of using \gx, so here is
> > another version of the same patch which implements that.
>
> Pa
he \d version starts at line 398 in master.
I think that ship has sailed, given there's already \gset.
Supporting \g[optionset] next to it *now*, given no one knows how
"optionset" is going to evolve seems like premature optimization.
Mit freundlichen Grüßen,
Christoph Berg
--
Senio
Re: Heikki Linnakangas 2016-10-17 <07ebd878-ff09-72d5-7df7-f7fde7b83...@iki.fi>
> Committed this patch now.
Hi,
I've just taken up work again on PG 10 on Debian unstable.
With openssl 1.1.0c-2, pgcrypto errors out with:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statemen
Hi,
I'm not sure this is a bug, but before it bites back too late, I'm
reporting it now.
On pg_upgrading my catversion 201603111 9.6 cluster to 201603301, I
got the following error:
-
pg_upgrade run on Fri Apr 1 22:50:07 2016
---
Re: Alvaro Herrera 2016-04-09 <20160408232553.GA721890@alvherre.pgsql>
> It's useful, no doubt.
It's cool :)
> I pushed it.
Here's a small doc patch that removes the bogus space in "colH [:scolH]"
(otherwise psql complains that it is ignoring the 4th parameter.
It also adds an index entry and a
Re: To PostgreSQL Hackers 2016-04-13 <20160413092312.ga21...@msg.df7cb.de>
> Re: Alvaro Herrera 2016-04-09 <20160408232553.GA721890@alvherre.pgsql>
> > It's useful, no doubt.
>
> It's cool :)
>
> > I pushed it.
>
> Here's a small doc patch that removes the bogus space in "colH [:scolH]"
> (other
Re: Tom Lane 2016-04-13 <1854.1460562...@sss.pgh.pa.us>
> Hm, we do not have entries attached to any other psql
> meta-commands. Maybe they all should have one, or maybe not, but
> I'm unconvinced about adding one for just this command. What I did
> instead was to make a link target (which there
Re: Tom Lane 2016-04-14 <15673.1460592...@sss.pgh.pa.us>
> Here's a patch along those lines. Any objections?
> \crosstabview [
> colV
> ! [ colH
> ! [ colD
> ! [ scolH
> ! ] ] ] ]
Maybe use "sortcolH" to make it immediately
Re: Daniel Verite 2016-04-14
> I don't quite see how to work around that, short of simply
> removing the possibility of addressing columns by their
> numbers. Which maybe is a bit sad for the end user, I'm not
> sure, but ISTM that's a logical consequence of abandoning
> the dedicated parser for c
[Cc'ing -hackers]
I said:
> That said, there's a build failure on s390x:
>
> https://buildd.debian.org/status/fetch.php?pkg=citus&arch=s390x&ver=5.0.1-1&stamp=1461670278
>
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
> -Wendif-labels -Wmissing-format-attribute
Re: To Andres Freund 2016-04-28 <20160428080824.ga22...@msg.df7cb.de>
> I'm not an expert in compiler flags, but it seems to me CFLAGS_SL is
> wrong on s390(x) in Makefile.port, it should use -fPIC like sparc.
>
> (The m68k build has yet to happen, I'd guess it would exhibit the same
> problem.)
Re: Robert Haas 2016-05-02
> max_parallel_degree -> max_parallel_workers
> parallel_degree -> parallel_workers
>
> I would prefer to keep it as "degree". It's a reasonable term of art,
> and it also improves grep-ability. But I'm willing to go do the above
> renaming if there is a clear consen
Re: Álvaro Hernández Tortosa 2016-05-14 <5736f966.3040...@8kdata.com>
> Having said that, I believe having a single major number is a more
> effective marketing. Non major-major versions may make the release look like
> a "probably not worth" upgrade. People may hold their breath until a
> majo
Re: Michael Paquier 2016-05-24
> Yeah, that's really something that covers only a narrow case, though
> if we don't have it when we need it we're limited to some hacks.
> Perhaps people who have the advanced level to use such a thing have
> the level to use hacks anyway..
I'd think recovery_targ
Re: Murtuza Zabuawala 2016-05-26
> Hi,
>
> I have created a role using below sql, then I disconnected & try to login
> into postgres db with newly created user "test_role", It prompt for
> password and I pressed Enter key because I did not provided any password
> when I created role so it throw
Hi,
gcc5 is lurking in Debian experimental, and it's breaking initdb.
There's bug reports for 9.1 and 9.4:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778070 (9.1)
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778071 (9.4)
but I could reproduce it with 9.5devel (from last week) as well:
Re: Tom Lane 2015-02-15 <21030.1424022...@sss.pgh.pa.us>
> Christoph Berg writes:
> > gcc5 is lurking in Debian experimental, and it's breaking initdb.
>
> FYI, this is now fixed in Red Hat's rawhide version:
> https://bugzilla.redhat.com/show_bug.cgi?id=11909
Re: Robert Haas 2014-12-02
> I can't tell from this exactly what's going wrong. Questions:
>
> 1. Are there any background worker processes running at the same time?
> If so, how many? We'd expect to see 3.
> 2. Can we printout of the following variables in stack frame 3
> (test_shm_mq_pipeli
Re: Andres Freund 2014-12-12 <20141212152723.go31...@awork2.anarazel.de>
> On 2014-12-12 10:20:58 -0500, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > On 12/12/14 8:13 AM, Andres Freund wrote:
> > >> Wouldn't a make install-server/client targets or something similar
> > >> actually achieve th
Re: Alvaro Herrera 2014-12-12 <20141212203700.gb1...@alvh.no-ip.org>
> > Pardon me for not knowing much about Debian packages, but how would
> > that work exactly? Is it possible to do make install-client, then
> > package the installed files, then rm -rf the install tree, then
> > repeat for inst
Hi,
a fellow Debian Developer found a minor glitch in
src/timezone/localtime.c, where binary search is used. Now I don't
think there is an actual problem (unless there's > 2^30 timezones),
but it would at least make sense to mark the code as okayish so that
people running code scanners won't stumb
Re: Tom Lane 2014-12-15 <21813.1418655...@sss.pgh.pa.us>
> This is totally silly. The timecnt couldn't be anywhere near INT_MAX (in
> fact, it is not allowed to exceed TZ_MAX_TIMES, which is currently just
> 1200). And there are bunches of other instances of similar code in PG;
> shall we put equ
Re: Tom Lane 2014-12-16 <14615.1418694...@sss.pgh.pa.us>
> Jim Nasby writes:
> > On 12/15/14, 1:39 PM, Christoph Berg wrote:
> >> Well, if it's not interesting, let's just forget it. Sorry.
>
> > At the risk of sticking my head in the lions mouth... th
Re: Chris Butler 2014-12-19
<1155204201.65430.1418975376728.javamail.zim...@zedcore.com>
> One of our servers is currently running on postgres 9.2 using the
> 9.2.9-1.pgdg70+1 packages from pgdg.
>
> After an apt update this morning which brought in the libpq5 package version
> 9.4.0-1.pgdg70+1
Re: Alvaro Herrera 2014-12-22 <20141222165157.gd1...@alvh.no-ip.org>
> Multi-table CLUSTER uses multiple transactions, so this should not be an
> issue. That said, I don't think there's much point in CLUSTER SCHEMA,
> much less TRUNCATE SCHEMA. Do you normally organize your schemas so
> that ther
Re: Peter Eisentraut 2014-11-03 <5457f54e.4020...@gmx.net>
> On 11/2/14 2:00 PM, Noah Misch wrote:
> >> Ick; I concur with your judgment on those aspects of the IPC::Cmd design.
> >> Thanks for investigating. So, surviving options include:
> >>
> >> 1. Require IPC::Run.
> >> 2. Write our own run()
Hi,
I've played with trying to find out which minimal set of files I need
from the old version to make pg_upgrade work. Interestingly, this
includes the good old postmaster binary:
$ sudo -u postgres pgsql/bin/pg_upgrade -b /var/tmp/pgsql/bin/ -B
/usr/lib/postgresql/9.5/bin/ -d /etc/postgresql/9
Hi,
I've got several reports that postfix's pgsql lookup tables are broken
with 9.4's libpq5, while 9.3's libpq5 works just fine. The error
message looks like this:
Jan 10 00:11:40 lehmann postfix/trivial-rewrite[29960]: warning: connect to
pgsql server localhost:5432: out of memory?
Jan 10 00:1
Re: Tom Lane 2015-01-10 <22432.1420915...@sss.pgh.pa.us>
> So what I propose we do with this is patch HEAD and 9.4 only.
> We need to do *something* in 9.4 to address Christoph's complaint, and
> that branch is new enough that we can probably get away with changing
> officially-unsupported APIs. T
Re: Tom Lane 2015-01-11 <13609.1420998...@sss.pgh.pa.us>
> > The problem isn't present in 9.3 and earlier (at least with
> > postfix-pgsql), so there's no need to go back further.
>
> I've committed a fix for this in HEAD and 9.4.
I've just tested with the HEAD libpq and the issue is fixed. Thank
Hi,
the new fsync-pgdata-on-recovery code tries to open all files using
O_RDWR. At least on 9.1, this can make recovery fail:
* launch postgres, hit ^\ (or otherwise shut down uncleanly)
* touch foo; chmod 444 foo
* launch postgres
LOG: database system was interrupted; last known up at 2015-05-
Re: To PostgreSQL Hackers 2015-05-23 <20150523172627.ga24...@msg.df7cb.de>
> Hi,
>
> the new fsync-pgdata-on-recovery code tries to open all files using
> O_RDWR. At least on 9.1, this can make recovery fail:
>
> * launch postgres, hit ^\ (or otherwise shut down uncleanly)
> * touch foo; chmod 44
Re: Tom Lane 2015-05-23 <2284.1432413...@sss.pgh.pa.us>
> Christoph Berg writes:
> > the new fsync-pgdata-on-recovery code tries to open all files using
> > O_RDWR. At least on 9.1, this can make recovery fail:
>
> Hm. I wonder whether it would be all right to just sk
Re: Andres Freund 2015-05-24 <20150524005245.gd32...@alap3.anarazel.de>
> How about, to avoid masking actual problems, we have a more
> differentiated logic for the toplevel data directory? I think we could
> just skip all non-directory files in there data_directory itself. None
> of the files in t
Re: To Andres Freund 2015-05-24 <20150524075244.gb27...@msg.df7cb.de>
> Re: Andres Freund 2015-05-24 <20150524005245.gd32...@alap3.anarazel.de>
> > How about, to avoid masking actual problems, we have a more
> > differentiated logic for the toplevel data directory? I think we could
> > just skip al
Re: Tom Lane 2015-05-26 <14207.1432650...@sss.pgh.pa.us>
> Naoya Anzai writes:
> > I have a question about txid_current().
> > it is "Why does txid_current() assign new transaction-id?".
>
> Consider
>
> begin;
> select txid_current();
> insert into my_table ...;
> commit
Re: Tom Lane 2015-05-26 <18863.1432661...@sss.pgh.pa.us>
> Christoph Berg writes:
> > Still, exposing GetStableLatestTransactionId() on the SQL level would
> > make sense for monitoring transaction throughput.
>
> Perhaps, though I wonder why we should expose t
commit 4c5e060049a3714dd27b7f4732fe922090edea69
Author: Bruce Momjian
Date: Sat May 16 00:40:18 2015 -0400
pg_upgrade: force timeline 1 in the new cluster
Previously, this prevented promoted standby servers from being upgraded
because of a missing WAL history file. (Timeline 1 do
Re: Bruce Momjian 2015-05-27 <20150527174244.gb31...@momjian.us>
> > In fact, I'm wondering if pg_upgrade shouldn't rather *increase* the
> > timeline to make sure the archive_command doesn't clobber any files
> > from the old cluster when reused in the new cluster?
> >
> > https://bugs.debian.org
Re: Bruce Momjian 2015-05-28 <20150527221607.ga7...@momjian.us>
> Well, if you used pg_dump/pg_restore, you would have had even larger
> problems as the file names would have matched.
True, but even here it's possible that files get overwritten. If you
had a server running on TL 1 for files 000100
Re: Simon Riggs 2015-05-28
> Hmm, it looks like the change to TimeLine 1 is just a kludge anyway. The
> rule that TimeLine 1 doesn't need a history file is itself a hack.
>
> What we should be saying is that the last timeline doesn't need a history
> file. Then no change is needed here.
IMHO it
Re: Noah Misch 2015-05-28 <20150528072721.ga4102...@tornado.leadboat.com>
> > I've just had trouble getting barman to work again after a 9.1->9.4.2
> > upgrade, and I think part of the problem was that the WAL for this
> > cluster got reset from timeline 2 to 1, which made barman's incoming
> > WAL
Re: Noah Misch 2015-05-28 <20150528150234.ga4111...@tornado.leadboat.com>
> On Thu, May 28, 2015 at 10:20:58AM -0400, Bruce Momjian wrote:
> > On Thu, May 28, 2015 at 08:47:07AM +0100, Simon Riggs wrote:
> > > What we should be saying is that the last timeline doesn't need a history
> > > file.
>
Re: Tom Lane 2015-05-28 <5740.1432849...@sss.pgh.pa.us>
> Abhijit Menon-Sen writes:
> > Here's an updated patch for the fsync problem(s).
>
> I've committed this after some mostly-cosmetic rearrangements.
Fwiw, I can confirm that the problem is fixed for 9.5. The regression
tests I've added to p
Re: Robert Haas 2015-05-29
> > FTR: Robert, you have been a Samurai on this issue. Our many thanks.
>
> Thanks! I really appreciate the kind words.
I'm still watching with admiration. This list of steps-to-reproduce is
the longest and at the same time best I've ever seen.
If anyone ever asks
Re: Tom Lane 2015-05-29 <13871.1432921...@sss.pgh.pa.us>
> Why can't the user stop it? We won't be bleating about the case of a
> symlink to a non-writable file someplace else, which is the Debian use
> case. I don't see a very good excuse to have a non-writable file right
> in the data directory
Re: Michael Paquier 2015-05-28
> Attached is a doc patch among those lines.
> diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
> index 89a609f..6485b42 100644
> --- a/doc/src/sgml/func.sgml
> +++ b/doc/src/sgml/func.sgml
> @@ -16233,7 +16233,7 @@ SELECT collation for ('foo' COLLATE "
There was a stray "s" in "classes implement*s*". I've also added a
"the" to make the sentence more readable (at least for me).
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
diff --git a/doc/src/sgml/brin.sgml b/doc/src/sgml/brin.sgml
new file mode 100644
index e25f09c..894c269
*** a/doc/src/s
Hi,
as reported by Debian's OpenSSL maintainers, PostgreSQL is failing to
build against a snapshot of the upcoming 1.1.0 version. The report was
for 9.5.3, but I can reproduce it in HEAD as well:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828510
> OpenSSL 1.1.0 is about to released. Durin
Re: Andreas Karlsson 2016-06-27 <8a0a5959-0b83-3dc8-d9e7-66ce8c1c5...@proxel.se>
> > The errors you report make it sound like they broke API compatibility
> > wholesale. Was that really their intent? If so, where are the changes
> > documented?
>
> I do not see that they have documented the remo
Re: Tom Lane 2016-06-27 <31398.1467036...@sss.pgh.pa.us>
> Bjorn Munch reported off-list that this sequence:
>
> unpack tarball, cd into it
> ./configure ...
> cd src/test/regress
> make
>
> no longer works in 9.6beta2, where it did work in previous releases.
> I have confirmed both statements.
Re: Andreas Karlsson 2016-07-01 <688a438c-ccc2-0431-7100-26e418fc3...@proxel.se>
> Hi,
>
> Here is an initial set of patches related to OpenSSL 1.1. Everything should
> still build fine on older OpenSSL versions (and did when I tested with
> 1.0.2h).
Hi Andreas,
thanks for the patches. I applied
Re: Tom Lane 2016-07-01 <26357.1467400...@sss.pgh.pa.us>
> I made some mostly-cosmetic changes to this and pushed it.
I confirm that Debian's out-of-tree python3 build works now when
invoked directly in the relevant plpython/hstore_plpython
subdirectories. Thanks!
Christoph
--
Sent via pgsql-h
Re: Andreas Karlsson 2016-07-02
> On 07/01/2016 11:41 AM, Christoph Berg wrote:
> > thanks for the patches. I applied all there patches on top of HEAD
> > (10c0558f). The server builds and passes "make check", pgcrypto still
> > needs work, though:
>
> Thanks
Re: Stefan Huehner 2016-07-02 <20160702160042.ga11...@huehner.biz>
> No data at all needed in table.
> In fact just create database + create 3 those objects is enough to reproduce
> it.
Confirmed here on Debian unstable amd64, beta2.
FEHLER: XX000: cache lookup failed for type 0
ORT: get_typle
Re: Peter Eisentraut 2016-07-17
> On 7/15/16 3:07 PM, Andrew Dunstan wrote:
> > Do those packagers who install dummy certificates and turn SSL on also
> > change their pg_hba.conf.sample files to use hostssl?. That could go a
> > long way towards encouraging people.
>
> Debian, which I guess s
Makes sense. Is this something that should be implemented in postgresql, or via
pg_createcluster?
Am 19. Juli 2016 16:00:05 MESZ, schrieb Magnus Hagander :
>On Sun, Jul 17, 2016 at 10:07 PM, Christoph Berg
>wrote:
>
>> Re: Peter Eisentraut 2016-07-17 <
>> d6b22200-
Re: Bruce Momjian 2016-07-30 <20160730181643.gd22...@momjian.us>
> I also just applied a doc patch that increases case and spacing
> consistency in the use of kB/MB/GB/TB.
Hi,
PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses spaces:
# select pg_size_pretty((2^20)::bigint);
Re: Peter Eisentraut 2016-08-01
> > PostgreSQL uses the spaces inconsistently, though. pg_size_pretty uses
> > spaces:
> >
> > # select pg_size_pretty((2^20)::bigint);
> > pg_size_pretty
> >
> > 1024 kB
>
> because it's "pretty" :)
:)
> > SHOW does not:
> >
> > # show wor
Re: Craig Ringer 2016-08-12
> I think we should emit a HINT here, something like:
>
> ERROR: could not open file "D:\CBS_woningcijfers_2014.csv" for reading: No
> such file or directory'
> HINT: Paths for COPY are on the PostgreSQL server, not the client. You may
> want psql's \copy or a drive
Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us>
> In short, I think that the way to make something like this work is to
> figure out how to have "virtual" catalog rows describing a temp table.
> Or maybe to partition the catalogs so that vacuuming away temp-table
> rows is easier/cheaper th
Re: To Tom Lane 2016-08-15 <20160815111057.v2mqqjp4aabvw...@msg.df7cb.de>
> Re: Tom Lane 2016-07-30 <1184.1469890...@sss.pgh.pa.us>
> > In short, I think that the way to make something like this work is to
> > figure out how to have "virtual" catalog rows describing a temp table.
> > Or maybe to pa
> > I was surprised/annoyed to find out that there is no way to have
> > per-user pg_service.conf, something like ~/.pg_service.conf (well,
> > except by export PGSYSCONFDIR). That would be easy to add.
> > Comments?
>
> Here's a patch. Perhaps those who had said they would like that can
> valid
Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> The attached patch matches your suggestion. It is basically back to
> what the code originally had, except it skips system tables, and shows
> "???" for invalid values.
Fwiw, "make check-world" is currently broken:
build/c
Re: Bruce Momjian 2014-03-27 <20140327131048.ga11...@momjian.us>
> On Thu, Mar 27, 2014 at 10:02:20AM +0100, Christoph Berg wrote:
> > Re: Bruce Momjian 2014-03-26 <20140326161056.ga...@momjian.us>
> > > The attached patch matches your suggestion. It is basical
Why not "make check-world"? That should include everything, and
doesn't need updating the scripts when something new gets included in
PostgreSQL itself. The pg_upgrade test is included.
Mit freundlichen Grüßen,
Christoph Berg
--
Senior Berater, Tel.: +49 (0)21 61 / 46 43-187
cre
Re: Bruce Momjian 2013-12-04 <20131204151533.gb17...@momjian.us>
> On Mon, May 6, 2013 at 11:51:47PM -0700, Christoph Berg wrote:
> > "make check" supports EXTRA_REGRESS_OPTS to pass extra options to
> > pg_regress, but all the other places where pg_regress is
Re: Albe Laurenz 2014-03-28
> > ERROR: 42703: column ol.orderids does not exist
> > LINE 1: ...* from orders o join orderlines ol on o.orderid = ol.orderid...
> > ^
> > HINT: Perhaps you meant to reference the column "ol"."orderid".
>
Re: Noah Misch 2014-03-24 <20140323230420.ga4139...@tornado.leadboat.com>
> On Thu, Mar 06, 2014 at 11:52:22PM -0500, Noah Misch wrote:
> > On Thu, Mar 06, 2014 at 12:44:34PM -0500, Tom Lane wrote:
> > > I'm inclined to suggest that we should put the socket under $CWD by
> > > default, but provide
Re: Noah Misch 2014-03-30 <20140330014531.ge170...@tornado.leadboat.com>
> On Sat, Mar 29, 2014 at 10:04:55AM +0100, Christoph Berg wrote:
> > Fwiw, to relocate the pg_regress socket dir, there is already the
> > possibility to run make check EXTRA_REGRESS_OPTS="--host=/t
Re: Tom Lane 2014-03-31 <22183.1396293...@sss.pgh.pa.us>
> >> Enable pg_regress --host=/path/to/socket:
> >> https://alioth.debian.org/scm/loggerhead/pkg-postgresql/postgresql-9.4/trunk/view/head:/debian/patches/60-pg_regress_socketdir.patch
>
> > Wasn't this patch submitted for inclusion in Postg
Debian is shipping client headers in /usr/include/postgresql in the
libpq-dev package. The server headers go into
/usr/include/postgresql//server in postgresql-server-dev-,
so we can have the headers for several majors installed in parallel.
Historically, a few server headers were also included in
Re: Tom Lane 2014-04-26 <21449.1398524...@sss.pgh.pa.us>
> > internal/postgres_fe.h includes
> > common/fe_memutils.h which includes
> > utils/palloc.h
>
> Hm. It seems rather fundamentally broken to me that frontend code is
> including palloc.h --- that file was never intended to be fronte
Re: Heikki Linnakangas 2014-04-28 <535e09b7.3090...@vmware.com>
> >Comments? If there's anyone who has a really good use-case for using
> >relpath() from outside the backend, better speak up.
>
> I'm using it in the pg_rewind tool. It needs to know how to map relfilenodes
> to physical files.
>
Re: Tom Lane 2014-05-02 <9995.1398994...@sss.pgh.pa.us>
> >> The patch is certainly too invasive to consider back-patching into
> >> 9.3, though.
Understood.
> > I feel unsure about this. I agree the patch is quite invasive. Leaving
> > 9.3 in a broken state seems problematic. In particular I'
Hi,
if you split configuration and data by setting data_directory,
postgresql.auto.conf is writen to the data directory
(/var/lib/postgresql/9.4/main in Debian), but tried to be read from
the etc directory (/etc/postgresql/9.4/main).
One place to fix it would be in ProcessConfigFile in
src/backen
Re: Jeff Janes 2014-05-05
> I've personally never had a need to set the search_path to a system schema,
> and I guess I was implicitly modelling this on what is returned by \dn, not
> by \dnS. I wouldn't object much to including them; that would be better
> than not having any completion. I ju
Re: Amit Kapila 2014-05-07
> This problem occurs because we don't have the value of data_directory
> set in postgresql.conf by the time we want to parse .auto.conf file
> during server start. The value of data_directory is only available after
> processing of config files. To fix it, we need to
Re: Andres Freund 2014-05-08 <20140508145901.gb1...@awork2.anarazel.de>
> > Maybe this is nitpicking, but what happens when postgresql.auto.conf also
> > includes the setting of data_directory? This is possible because we can
> > set data_directory via ALTER SYSTEM now. Should we just ignore such
>
Hi,
the current tcl version is 8.6, and configure should recognize it. The
attached patch has been in the Debian/Ubuntu packages for a while, so
it's tested.
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
diff --git a/config/tcl.m4 b/config/tcl.m4
new file mode 100644
index e886057..a9fe7ba
*
Hi,
to support ppc64le, config.guess needs to be updated. The attached
patch is what was reported to work for Ubuntu.
Christoph
--
c...@df7cb.de | http://www.df7cb.de/
diff --git a/config/config.guess b/config/config.guess
new file mode 100755
index 2055429..b79252d
*** a/config/config.guess
---
Re: Tom Lane 2014-05-10 <27409.1399729...@sss.pgh.pa.us>
> Christoph Berg writes:
> > the current tcl version is 8.6, and configure should recognize it. The
> > attached patch has been in the Debian/Ubuntu packages for a while, so
> > it's tested.
>
> While
Re: Tom Lane 2014-05-10 <27476.1399729...@sss.pgh.pa.us>
> Christoph Berg writes:
> > to support ppc64le, config.guess needs to be updated. The attached
> > patch is what was reported to work for Ubuntu.
>
> Our normal procedure is
>
> o update config.gue
84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp
constructors. In the regression tests, various time zones are tested,
including America/Metlakatla. Now, if you configure using
--with-system-tzdata, you'll get an error if that zone isn't there.
Unfortunately, this is what I'm getting n
Re: To PostgreSQL Hackers 2014-05-12 <20140512214025.ga31...@msgid.df7cb.de>
> 84df54b22e8035addc7108abd9ff6995e8c49264 introduced timestamp
> constructors. In the regression tests, various time zones are tested,
> including America/Metlakatla. Now, if you configure using
> --with-system-tzdata, yo
Re: Robert Haas 2014-05-13
> On Mon, May 12, 2014 at 7:16 PM, Tom Lane wrote:
> > I'm quite unimpressed by the dependency on Mars/Mons_Olympus, too ... that
> > might not fail *today*, but considering it's a real location, assuming it
> > is not in the IANA database seems like a recipe for futur
Re: Tom Lane 2014-05-10 <27476.1399729...@sss.pgh.pa.us>
> Christoph Berg writes:
> > to support ppc64le, config.guess needs to be updated. The attached
> > patch is what was reported to work for Ubuntu.
>
> Our normal procedure is
>
> o update config.gue
Re: Alvaro Herrera 2014-05-13 <20140513135526.gr6...@eldon.alvh.no-ip.org>
> > I especially like MTC, Mars Time Coordinated. But whatever scheme gets
> > chosen, it won't be a standard 24h day, so PostgreSQL has a whole lot
> > of different problems to solve than to "fix" that little
> > Mars/Mons_
Re: Tom Lane 2014-05-13 <27525.1400012...@sss.pgh.pa.us>
> Heikki Linnakangas writes:
> > On 05/13/2014 09:58 PM, Tom Lane wrote:
> >> ... If so the issue is presumably
> >> that the environment variable(s) were set to incorrect values. While
> >> we *could* abort in that situation, I've never he
Building 9.4 beta1 on Debian sid/i386 fails during the regression
tests. amd64 works fine, as does i386 on the released distributions.
parallel group (11 tests): create_cast create_aggregate drop_if_exists
typed_table create_function_3 vacuum constraints create_table_like triggers
inherit updat
Re: Tom Lane 2014-05-17 <22961.1400343...@sss.pgh.pa.us>
> I think the key issue comes down to this comment in RenameDatabase:
>
> * XXX Client applications probably store the current database somewhere,
> * so renaming it could cause confusion. On the other hand, there may not
> *
201 - 300 of 312 matches
Mail list logo
