Re: Peter Eisentraut
> Since some (legacy) code still uses the libc locale facilities
> directly, we still need to set the libc global locale settings even if
> ICU is otherwise selected. So pg_database now has three
> locale-related fields: the existing datcollate and datctype, which are
> always
Re: Peter Eisentraut
> > Since the intended usage seems to be that databases should either be
> > using libc, or the ICU locales, but probably not both at the same
> > time, does it make sense to clutter the already very wide `psql -l`
> > output with two new extra columns?
>
> Good point, let me
Re: Thomas Munro
> for all I know, "en" variants might change
> independently (I doubt it in practice, but in theory it's wrong).
Long before the glibc 2.28 incident, the same collation change
had already happened twice, namely between RedHat 5 -> 6 -> 7, for
de_DE.UTF-8 only. de_AT.UTF-8 and all
Re: Michael Paquier
> Refactor tar method of walmethods.c to rely on the compression method
Hi,
since about this commit, pg_wal.tar is no longer compressed at all:
$ pg_basebackup -D foo --format=tar
$ ls -l foo/
-rw--- 1 cbe cbe 137152 7. Jan 15:37 backup_manifest
-rw--- 1 cbe cbe
Re: Michael Paquier
> Move tablespace path re-creation from the makefiles to pg_regress
>
> Moving this logic into pg_regress fixes a potential failure with
> parallel tests when pg_upgrade and the main regression test suite both
> trigger the makefile rule that cleaned up testtablespace/ under
>
Re: Michael Paquier
> So you basically mimicked the makefile rule that this commit removed
> into your own test suite. Reverting the change does not really help,
> because we'd be back to square one where there would be problems in
> parallel runs for developers. Saying that, I would not mind add
I believe the "box" type description is slightly incorrect:
# \dT box
Liste der Datentypen
Schema │ Name │ Beschreibung
┼──┼──
pg_catalog │ box │ geometric box '(lower left,upper right)'
While the sy
Re: Kyotaro Horiguchi
> Returing to the description of pg_types, it should be changed like
> this following the discussion here.
>
> - pg_catalog | box | geometric box '(lower left,upper right)'
> + pg_catalog | box | geometric box 'lower left,upper right'
>
> But I find it hard to read. I fixe
Re: Michael Paquier
> http://commitfest.cputube.org/michael-paquier.html
>
> So it looks like this could be a different answer.
The mkdir() function looks like a sane and clean approach to me.
Christoph
I think this change neglected to add plpgsql to the extension
dependencies in the .control file:
12:53:51 # Failed test 'psql -qc 'CREATE EXTENSION "cube"''
12:53:51 # at t/TestLib.pm line 213.
12:53:51 not ok 68 - psql -qc 'CREATE EXTENSION "cube"'
12:53:51 # got: '1'
12:53:51 #
Re: To PostgreSQL Hackers
> I think this change neglected to add plpgsql to the extension
> dependencies in the .control file:
>
> 12:53:51 # Failed test 'psql -qc 'CREATE EXTENSION "cube"''
> 12:53:51 # at t/TestLib.pm line 213.
> 12:53:51 not ok 68 - psql -qc 'CREATE EXTENSION "cube"'
> 12:5
Re: Tom Lane
> > (The Debian regression tests remove plpgsql before testing all
> > extensions in turn.)
>
> Meh. I think that's testing a case that we don't guarantee to work.
> There was already a plpgsql dependency in hstore--1.1--1.2.sql,
> which I just cribbed from to make these fixes.
The
Re: Magnus Hagander
> > The confusion in my case is I wasn't sure why my distro was named,
> > tried the instructions and it...half worked.
> >
> > Maybe something like this?
> >
> > The PostgreSQL apt repository supports the currently supported stable
> > versions of Debian with the latest version
Re: Magnus Hagander
> Well, they are not supported. The packages may be there, but they are not
> supported. I think that's an important distinction. Maybe add something
> like "some packages may be available for older versions of Debian, but are
> not supported" or such?
I'm talking about https:/
Re: Julien Rouhaud
> Here's the rationale for this new flag, extracted from the patch's commit
> message:
>
> Add a new amnostablecollorder flag in IndexAmRoutine.
>
> This flag indicates if the access method does not rely on a stable collation
> ordering for deterministic collation, i.e. would n
Re: Devrim Gündüz 2018-04-10 <1523353963.8169.26.ca...@gunduz.org>
> I used to run
>
> "
> cd src/backend
> make submake-errcodes
> "
>
> in the RPM spec file, but looks like it was removed recently. Is that replaced
> with something else, or removed completely?
It is gone:
https://git.postgresq
Re: Tom Lane 2018-04-10 <24426.1523387...@sss.pgh.pa.us>
> The short-term solution seems to be to put that back, but that's sort
> of annoying because it means this isn't a bulletproof solution. It
> will only work for builds started in one of the directories that we
> take the trouble to put this
Re: Michael Paquier 2018-04-12 <20180411235843.gg32...@paquier.xyz>
> > You sure you're on 31f1f0bb4fd642643994d35c35ecb5b929711a99 or later?
> > Which gmake version is this?
GNU Make 4.2.1
> For what it's worth, all those combinations work for me when on
> d1e90792:
> ./configure blah
> cd src/p
Re: Tom Lane 2018-04-12 <10354.1523558...@sss.pgh.pa.us>
> ... or then again, maybe I do. Is it possible that your build
> recipe involves invoking our makefiles from an outer "make" run?
> If so, maybe you need to explicitly set MAKELEVEL=0 when invoking
> our build, to keep it from thinking it i
Re: Magnus Hagander 2018-04-09
> Revert "Allow on-line enabling and disabling of data checksums"
>
> Modified Files
> --
> doc/src/sgml/reference.sgml | 1 -
This removed "&pgVerifyChecksums;" which causes pg_verify_checksums.1
not to be built anymore.
The sec
Re: To Tom Lane 2018-04-12 <20180412202717.ga32...@msg.df7cb.de>
> > ... or then again, maybe I do. Is it possible that your build
> > recipe involves invoking our makefiles from an outer "make" run?
> > If so, maybe you need to explicitly set MAKELEVEL=0 when invoking
> > our build, to keep it fr
Building the 12rc1 package on Ubuntu eoan/amd64, I got this
regression diff:
12:06:27 diff -U3
/<>/build/../src/test/regress/expected/select_parallel.out
/<>/build/src/bin/pg_upgrade/tmp_check/regress/results/select_parallel.out
12:06:27 ---
/<>/build/../src/test/regress/expected/select_paralle
Re: Tom Lane 2019-09-26 <12685.1569510...@sss.pgh.pa.us>
> We haven't seen it in quite some time in HEAD, though I fear that's
> just due to bad luck or change of timing of unrelated tests.
The v13 package builds that are running every 6h here haven't seen a
problem yet either, so the probability
Re: Tom Lane 2019-09-28 <24917.1569692...@sss.pgh.pa.us>
> > (There's some extension modules
> > where the testsuite fails at a much higher rate, getting all targets
> > to pass at the same time is next to impossible there :(. )
>
> I feel your pain, believe me. Used to fight the same kind of pro
Re: Tom Lane 2018-09-28
> Remove pqsignal() from libpq's official exports list.
>
> Client applications should get this function, if they need it, from
> libpgport.
>
> The fact that it's exported from libpq is a hack left over from before
> we set up libpgport. It's never been documented, and
Re: Tom Lane 2019-10-08 <9333.1570566...@sss.pgh.pa.us>
> Having said all that, if we conclude we can't break compatibility
> with this legacy code quite yet, I'd be inclined to put a
> separate, clearly-marked-as-legacy-code version of pqsignal()
> back into libpq, using the pre-9.3 SA_RESTART sem
Re: Thomas Munro 2019-10-11
> While testing pg_upgrade scenarios I noticed that initdb-created
> collations' versions are not preserved, potentially losing track of
> information about corrupted indexes. That's a preexisting condition,
> and probably well understood, but it made me realise that
Re: Tom Lane 2019-10-10 <10247.1570731...@sss.pgh.pa.us>
> OK, done.
Thanks, that made quite a few QA pipeline jobs happy here.
Christoph
Re: Tom Lane 2019-10-22 <821.1571771...@sss.pgh.pa.us>
> Actually, I think we probably don't need any SQL representation of this
> at all, because if what you're going to do with it is omit logically
> necessary null-value checks, then a wrong setting would trivially crash
> the server. Therefore,
and the
usual reply is always something like what Pavel said recently:
"It is garbage. Usually it means nothing, but better to work live
without this garbage." [1]
[1]
https://www.postgresql.org/message-id/CAFj8pRDtwsxj63%3DLaWSwA8u7NrU9k9%2BdJtz2gB_0f4SxCM1sQA%40mail.gmail.com
Let
Re: Tom Lane 2019-01-31 <12792.1548965...@sss.pgh.pa.us>
> initdb hasn't depended on those libpq exports since 8.2, and it was
> a bug that it did so even then.
9.2 psql (and createuser, ...) is also broken:
/usr/lib/postgresql/9.2/bin/psql: symbol lookup error:
/usr/lib/postgresql/9.2/bin/psql:
Re: Andrew Dunstan 2019-03-04
<7cc6d2c1-bd87-9890-259d-36739c247...@2ndquadrant.com>
> Looks good to me.
+1.
Christoph
Re: Peter Eisentraut 2019-03-08
<3eb194cf-b878-1f63-8623-6d6add0ed...@2ndquadrant.com>
> On 2019-02-21 10:37, Christoph Berg wrote:
> > diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
> > index a18a6f6c45..8080626e94 100644
> > --- a/sr
(This seems to be the only occurrence of this error, after about 2
minutes of git-grep-ing.)
>From 42b2a82f8e06beb0de3b3b15ded85fc905fb9edd Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Wed, 13 Mar 2019 13:24:22 +0100
Subject: [PATCH] Remove stray comma from heap_page_item_attrs() d
Re: Magnus Hagander 2019-03-14
> Are you suggesting we should support running with a master with checksums
> on and a standby with checksums off in the same cluster? That seems.. Very
> fragile.
The case "shut down master and standby, run pg_checksums on both, and
start them again" should be sup
7;ll have a new version ready?
Here is a new revision that blank-pads "ok" to the length of "FAILED".
Christoph
>From cd2a5927b52473ca9c56e2e5142c257853429224 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Thu, 21 Feb 2019 10:35:19 +0100
Subject: [PATCH] Align timesta
Re: Peter Eisentraut 2019-03-22
<57769959-8960-a9ca-fc9c-4dbb12629...@2ndquadrant.com>
> I'm still in favor of defaulting --new-bindir appropriately. It seems
> silly not to. We know where the directory is, we don't have to ask anyone.
Fwiw I've been wondering why I have to pass that option eve
t also adds a new
option -k --no-data-checksums that wasn't present previously. Docs are
updated to say what the new default is, and the testsuite exercises
the -K option.
Christoph
>From cca069298f1cfc5c95e9e7dde08407a0c05f538a Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 22
Re: Fabien COELHO 2019-03-22
> Attached is a quick patch about "pg_rewind", so that the control file is
> updated after everything else is committed to disk.
> update_controlfile(datadir_target, progname, &ControlFile_new, do_sync);
>
> - pg_log(PG_PROGRESS, "syncing target data direc
Re: Tom Lane 2019-03-22 <4368.1553270...@sss.pgh.pa.us>
> Christoph Berg writes:
> > I think, the next step in that direction would be to enable data
> > checksums by default. They make sense in most setups,
>
> Well, that is exactly the point that needs some pro
Re: Daniel Gustafsson 2019-03-26
> 0003 - Make -B default to CWD and remove the exec_path check
>
> Defaulting to CWD for the new bindir has the side effect that the default
> sockdir is in the bin/ directory which may be less optimal.
Hmm, I would have thought that the default for the new bind
Re: To Tom Lane 2019-03-26 <20190326151446.gg3...@msg.df7cb.de>
> I run a benchmark with checksums disabled/enabled. shared_buffers is
> 512kB to make sure almost any read will fetch the page from the OS
> cache; scale factor is 50 (~750MB) to make sure the whole cluster fits
> into RAM.
[...]
> So
Re: Ants Aasma 2019-03-27
> Can you try with postgres compiled with CFLAGS="-O2 -march=native"? There's
> a bit of low hanging fruit there to use a runtime CPU check to pick a
> better optimized checksum function.
Frankly, no. This is with the apt.pg.o packages which are supposed to
be usable by
Re: Adrien NAYRAT 2019-03-28
> > > > Sorry, I changed that, someone suggest using either "0" and "1", or
> > > > "0.0" and "1.0" but not mixing both.
> >
> > Agreed with using "0.0" and "1.0".
> >
> > > > I will remove this change.
> +#log_transaction_sample_rate = 0 # Fraction of transacti
Re: Justin Pryzby 2019-03-28 <20190328135918.ga27...@telsasoft.com>
> + Determines the fraction of statements that exceed
> + to be logged.
> + The default is 1, meaning log all such
^ 1.0
Thanks for taking care of this!
Christoph
Re: Prabhat Sahu 2019-03-29
> While trying to explore on CHR() function in PG,
> I found that few of the ASCII values are returning hex number values(like
> '\x08', '\x0B')
> and few are executing within SQL (i.e. chr(9) => Horizontal tab, chr(10)
> => Line feed) as below example.
That's not a
Re: Tatsuo Ishii 2019-03-29
<20190329.100407.1159785913847835944.t-is...@sraoss.co.jp>
> If we were to invent new command names, what about doing similar to
> git? I mean something like:
>
> pgsql createdb
That is pretty close to "psql" and it will be utterly confusing for
new users. And ev
Re: Tom Lane 2019-03-29 <19517.1553876...@sss.pgh.pa.us>
> >> Or perhaps better, allow pg_ctl to grow new subcommands for those
> >> tasks?
>
> > We'd need to be careful to somehow delineate commands that need access
> > to the data directory / run locally on the server from the ones that
> > just
Re: Bernd Helmle 2019-03-29
<3586bb9345a59bfc8d13a50a7c729be1ee6759fd.ca...@oopsware.de>
> Am Freitag, den 29.03.2019, 23:10 +0900 schrieb Michael Paquier:
> >
> > I can't really believe that many people set up shared_buffers at
> > 128kB
> > which would cause such a large number of page eviction
Re: Pavel Stehule 2019-03-29
> > Other idea: If we don't want to reinvent a new tool, how about
> > supporting prepared statements in psql?
> >
> > psql -c 'create user %i' --args 'bob w. space'
> >
>
> Prepared statements cannot be DDL commands.
"Prepared" in the sense of what format() does.
Re: Joe Conway 2019-03-29 <48e5efaf-7ea2-ed70-a803-949bbfec8...@joeconway.com>
> echo "\password :\"role\"" | psql -v role='my role'
> Enter new password:
> Enter it again:
>
> That said, this is kind of off the topic of this thread.
It is on-topic because the reason we can't just tell people to
Re: Joe Conway 2019-03-29
> >> echo "\password :\"role\"" | psql -v role='my role'
> >
> > It is on-topic because the reason we can't just tell people to replace
> > createuser $foo
> > with
> > psql -c "create user $foo"
> > is because $foo might need escaping.
> >
> > IMHO if we find an wa
Re: Tomas Vondra 2019-03-30 <20190330192543.GH4719@development>
> I have not investigated the exact reasons, but my hypothesis it's about
> the amount of WAL generated during the initial CREATE INDEX (because it
> probably ends up setting the hint bits), which puts additional pressure
> on the stor
Open the config file in an editor. Unless $EDITOR is set, vi is
used.
SEE ALSO
user_clusters(5), postgresqlrc(5)
AUTHOR
Christoph Berg
Debian2019-07-15
PG_CONFTOOL(1)
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 break
> third-party tools, but (a) we would need more conc
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: 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
Re: Peter Eisentraut 2018-01-17
> 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 "
Re: Peter Eisentraut 2018-01-03
<99680dba-cf63-8151-1de2-46ca93897...@2ndquadrant.com>
> One scenario is that if GnuTLS goes in, it's quite plausible that the
> PG11 packages for Debian and Ubuntu will use it by default. But if it
> doesn't support tls-server-endpoint, then a JDBC client (assumin
The docs currently say
The language named plpythonu implements
PL/Python based on the default Python language variant, which is
currently Python 2. (This default is independent of what any
local Python installations might consider to be
their default, for example,
Re: Tom Lane 2019-11-07 <14186.1573147...@sss.pgh.pa.us>
> > And probably drop python2 support altogether.
>
> I think it'll be quite some time before that happens. People who
> are still using ancient versions of Postgres are not likely to be
> impressed by arguments about how python2 is out of
Re: Laurenz Albe 2019-11-08
<3c3b9ff84d21acf3188558928249d04db84ea2e9.ca...@cybertec.at>
> #3 is the best proposal, but there is still the need to run
> ALTER INDEX on all affected indexes to keep PostgreSQL from nagging.
> Perhaps the situation could be improved with a pg_upgrade option
> --i-kno
the statfs() names and should
certainly be improved
* which of these columns add to \db+ output?
* possibly extend this (and \db) to pg_wal
Christoph
>From bcd0c16e4ce12d406e41e1a77cbc2cf781accc93 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri, 8 Nov 2019 14:12:35 +0100
Subject
Re: Julien Rouhaud 2019-11-08
> Shouldn't we have something more generic, in hope that this eventually
> get implemented on Windows? I'm also wondering if getting the fs
> information is enough, as there might be quota.
The name is certainly not a good pick, it's not meant to be a raw
statfs()
Re: Julien Rouhaud 2019-11-08
> I'm also wondering if getting the fs
> information is enough, as there might be quota.
We could append the quotactl(Q_GETQUOTA) information as well, but I'm
not sure this has a sensible actual-users-to-noise ratio.
Christoph
Re: Julien Rouhaud 2019-11-08
> The related function on Windows is apparently GetDiskFreeSpaceA [1].
There's a link to GetDiskFreeSpaceExA() which seems much easier to use
because it accepts any directory on the drive in question:
https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fi
Re: Julien Rouhaud 2019-11-08
> > We could append the quotactl(Q_GETQUOTA) information as well, but I'm
> > not sure this has a sensible actual-users-to-noise ratio.
>
> Well, having a quota is one of the few real reason to create a
> tablespace so it's probably worth it, although I have to agr
Re: Tomas Vondra 2019-11-08 <20191108145025.d7pfcip6plufxiah@development>
> While I agree monitoring disk space is important, I think pretty much
> every deployment already does that using some other monitoring tool
> (which also monitors million other things).
There are plenty of deployments wher
Re: To Tomas Vondra 2019-11-08 <20191108150621.gl8...@msg.df7cb.de>
> I think this should be directly in core because it's useful to a wide
> range of users.
Also, I want to have it in \db+ in psql where users would actually be
looking for it.
Christoph
Re: Daniel Gustafsson 2019-11-12 <7a3b9bb6-bea0-466e-98a9-b4dd8f048...@yesql.se>
> I agree with Tomas upthread that it's unclear whether this needs to be in
> core.
> There are many system parameters a database admin is likely to be interested
> in, diskspace being just one of them (albeit a very
Re: Tom Lane 2020-01-02
> Add basic TAP tests for psql's tab-completion logic.
The \DRD test fails on Debian/unstable:
# check case-sensitive keyword replacement
# XXX the output here might vary across readline versions
check_completion(
"\\DRD\t",
"\\DRD\b\b\bdrds ",
"complete \\DRD
Re: Tom Lane 2020-01-03 <13708.1578059...@sss.pgh.pa.us>
> I found out while investigating this that the libedit version shipping
> with buster (3.1-20181209) is differently broken for the same case:
(Fwiw this wasn't spotted before because we have this LD_PRELOAD hack
that replaces libedit with r
Re: Tom Lane 2020-01-03 <26339.1578072...@sss.pgh.pa.us>
> Christoph Berg writes:
> > Re: Tom Lane 2020-01-03 <13708.1578059...@sss.pgh.pa.us>
> >> I found out while investigating this that the libedit version shipping
> >> with buster (3.1-20181209)
Re: Tom Lane 2020-01-05 <25771.1578249...@sss.pgh.pa.us>
> The current state of play on this is that I committed a hacky workaround
> [1], but there is now a fix for it in libedit upstream [2][3]. I gather
> from looking at Debian's package page that the fix could be expected to
> propagate to Deb
Re: Tom Lane 2020-01-06 <3764.1578323...@sss.pgh.pa.us>
> > Does not work on Ubuntu bionic, xenial. (Others not tested.)
>
> Hmm ... do we care? The test output seems to show that xenial's
> 3.1-20150325-1ubuntu2 libedit is completely broken. Maybe there's
> a way to work around that, but it's n
Re: Amit Kapila 2020-01-08
> It looks like this failure is more of what we are getting on
> "sidewinder" where it failed because of "insufficient file descriptors
> available to start server process". Can you check in the log
> (probably in 006_logical_decoding_master.log) if this is the same yo
Re: Andrew Dunstan 2019-11-01
> {"password_required", UserMappingRelationId, false},
> + /*
> + * Extra room for the user mapping copies of sslcert and
> sslkey. These
> + * are really libpq options but we repeat them here to allow
> them to
>
Re: To Andrew Dunstan 2020-01-09 <20200109103014.ga4...@msg.df7cb.de>
> sslcert/sslkey options can only be set/modified by superusers when
> "password_required" is set. But when password_required is not set, any
> user and create user mappings that reference arbitrary files on the
> server filesyst
Re: To Andrew Dunstan 2020-01-09 <20200109103014.ga4...@msg.df7cb.de>
> I believe the options are still used in that case
> for creating connections, even when that means the remote server isn't
> set up for cert auth, which needs password_required=false to succeed.
They are indeed:
stat("/var/li
Re: Robert Haas 2020-01-09
> Does this mean that a non-superuser can induce postgres_fdw to read an
> arbitrary file from the local filesystem?
Yes, see my comments in the "Allow 'sslkey' and 'sslcert' in
postgres_fdw user mappings" thread.
Christoph
Re: Robert Haas 2020-01-09
> > So that raises the question: why does xenial's version of libedit
> > not match either its documentation or the distributed source code?
> > Because it doesn't.
>
> The level of effort you've put into this is extremely impressive, but
> I can't shake the feeling th
Re: Tom Lane 2020-01-09 <16328.1578606...@sss.pgh.pa.us>
> build part.) I pushed a patch using SKIP_READLINE_TESTS.
> Christoph should be able to set that for the Ubuntu branches
> where the test is failing.
That "fixed" the problem on xenial, thanks.
Christoph
Re: Amit Kapila 2020-01-09
> The point is that we know what is going wrong on sidewinder on back
> branches. However, we still don't know what is going wrong with tern
> and mandrill on v10 [1][2] where the log is:
Fwiw, the problem on bionic disappeared yesterday with the build
triggered by "R
Debian reports that libxml2 is dropping the xml2-config binary:
Date: Mon, 20 Jan 2020 20:42:47 +0100
From: Mattia Rizzolo
Reply-To: Mattia Rizzolo , 949...@bugs.debian.org
Subject: Bug#949428: postgresql-12: FTBFS with libxml2 2.9.10 (uses xml2-config)
Source: postgresql-12
Version: 12.1-2
Seve
Re: To PostgreSQL Hackers 2020-01-20 <20200120204715.ga73...@msg.df7cb.de>
> Debian reports that libxml2 is dropping the xml2-config binary:
Please disregard that, I had assumed this was a change made by libxml2
upstream. I'm in contact with the libxml2 Debian maintainer to get
that change off the
Re: Tom Lane 2020-01-21 <6994.1579567...@sss.pgh.pa.us>
> > (Putting in support for pkg-config still makes sense, though.)
>
> Perhaps. Are there any platforms where libxml2 doesn't install a
> pkg-config file? What are we supposed to do if there's no pkg-config?
I can't comment on the libxml2
Re: Vik Fearing 2020-01-26
<09502c40-cfe1-bb29-10f9-4b3fa7b2b...@2ndquadrant.com>
> I cannot ever think of a time when I don't want to know if I'm in a
> transaction or not (and what its state is). Every new setup I do, I add
> %x to the psql prompt.
>
> I think it should be part of the default
Re: Raymond Martin 2019-04-01
> Thanks again Fabien. I am attaching the patch to this email in the hope of
> getting it approved during the next commit fest.
Raymond,
you sent the patch as UTF-16, could you re-send it as plain ascii?
Christoph
Re: Peter Eisentraut 2019-04-01
> - Some color in the messages, similar to gcc and clang. Set
> PG_COLOR=auto to try it out. Some colors are predefined, but can be
> customized by setting PG_COLORS.
Can we rename PG_COLOR to PGCOLOR? This is the only PG* environment
variable prefixed with t
Re: Peter Eisentraut 2019-04-01
> - There is support for setting a "log level". This is not meant to be
> user-facing, but can be used internally to implement debug or
> verbose modes.
I'm not entirely sure what happened here, but I think this made
pg_restore verbose by default (and there is
Re: Peter Eisentraut 2019-04-09
> I'm okay with changing it. As you indicate, I chose the name so that it
> doesn't look like a libpq variable. There are some other PG_ variables
> throughout the code, but those appear to be mostly for internal use.
> Also, there is GCC_COLORS, LS_COLORS, etc.
Re: Fred .Flintstone 2019-04-10
> It seems we do have a clear path forward on how to accomplish this and
> implement this change.
>
> 1. Rename executables to carry the pg_ prefix.
> 2. Create symlinks from the old names to the new names.
> 3. Modify the executables to read argv[0] and print a w
Re: Fred .Flintstone 2019-04-10
> Does anyone oppose the proposal?
I don't think part #3 has been discussed, and I'd oppose printing
these warnings.
Christoph
The 11rc1 build was failing on Debian mips:
cd /<>/build/../src/test/recovery &&
TESTDIR='/<>/build/src/test/recovery'
PATH="/<>/build/tmp_install/usr/lib/postgresql/11/bin:$PATH"
LD_LIBRARY_PATH="/<>/build/tmp_install/usr/lib/mips-linux-gnu"
PGPORT='65432'
PG_REGRESS='/<>/build/src/test/reco
Re: Tom Lane 2018-10-11 <28384.1539266...@sss.pgh.pa.us>
> Christoph Berg writes:
> > The 11rc1 build was failing on Debian mips:
> > ...
> > The diff is that "14|issued to london" was expected, but "|" was
> > received.
> > The bu
Re: Michael Paquier 2018-10-12 <20181012002520.gb26...@paquier.xyz>
> Do you still have the logs of the previous run for the standby?
Sorry, all I have is the (link to) the build log in the original
posting. I can run some tests on the mips porter box if you have any
ideas for things to try.
What
Re: Andres Freund 2018-10-12 <20181012170355.bhxi273skjt6s...@alap3.anarazel.de>
> Hi,
>
> Christoph Berg, on IRC, raised the issue that at least one extension
> failed compiling in v11. The extension currently does:
> https://github.com/pgq/pgq/blob/master/triggers/commo
mit personenbezogenen Daten unterliegt
folgenden Bestimmungen: https://www.credativ.de/datenschutz
>From 1c9a12d24169edb5343df28036adbf1d09a9ab2c Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Tue, 13 Nov 2018 11:35:26 +0100
Subject: [PATCH] Pass COPT and PROFILE to CXXFLAGS as well
Re: Tom Lane 2018-10-22 <80020.1540164...@sss.pgh.pa.us>
> * SIGQUIT is a fairly well-known way to get out of an application when all
> else fails. People who aren't familiar with psql's exit commands might
> find it pretty unfriendly of us to block this off.
Fwiw, pgadmin4 is one of those. ^C do
Re: Andres Freund 2018-11-21
> The biggest user of WITH OID columns was postgres' catalog. This
> commit changes all 'magic' oid columns to be columns that are normally
> declared and stored.
postgres=# \d+ pg_class
[...]
Indexe:
"pg_class_oid_index" UNIQUE, btree (oid)
Now that oid is a pro
1 - 100 of 478 matches
Mail list logo
