On Mon, Mar 05, 2018 at 09:51:53AM -0800, Steve Atkins wrote:
> I've been running postgresql instances on ESXi VMs for years with no
> issues. I've not benchmarked them, but performance has been good
> enough despite their running on fairly wimpy hardware. Performance
> relative to bare metal is pr
On Tue, Mar 06, 2018 at 04:45:10AM +, Dylan Luong wrote:
> After a failover (promote) to the Slave1, is it easily resync the
> Slave2 to the new master (old slave1)? Do we need to do full rebuild
> of the Slave2 from new master everytime we failover to Slave1 from
> Master? Can we use pg_rewi
On Tue, Mar 06, 2018 at 06:00:40AM +, Dylan Luong wrote:
> So everytime after promoting Slave to become master (either manually
> or automatic), just stop Slave2 and run pg_rewind on slave2 against
> the new maser (old slave1). And when old master server is available
> again, use pg_rewind on t
On Thu, Mar 08, 2018 at 10:48:29AM +0300, Yavuz Selim Sertoğlu wrote:
> If not set, could you add recovery.conf file
> recovery_target_timeline='latest'
> parameter?
> https://www.postgresql.org/docs/devel/static/recovery-target-settings.html
Yes, that's visibly the issue here.
--
Michael
signat
On Wed, Mar 14, 2018 at 04:17:54PM +0100, Hans Schou wrote:
> I got the message
> ERROR: could not open relation with OID 0
> when running the "General Table Size Information" from
> https://wiki.postgresql.org/wiki/Disk_Usage
I cannot see this failure on latest HEAD on a database running the
re
On Sun, Mar 18, 2018 at 09:38:22AM -0400, Stephen Frost wrote:
> These days, each email from the mailing list includes a link which can
> be used to unsubscribe from that list without having any account.
Yes. Ron, if you take the time to look at a raw email, just look for the
field value of List-U
On Thu, Mar 22, 2018 at 06:55:12PM -0400, Tom Lane wrote:
> Anyway, it's clearly not very nice that postgres_fdw makes no attempt
> to do a graceful shutdown of its remote connection. I don't know that
> this rises to the level of a bug, exactly, but if somebody wanted to
> send in a patch it'd pr
On Sat, Mar 24, 2018 at 12:17:30PM +1300, David Rowley wrote:
> If it is, then it's not a bug in pg_stat_statements. log_statement =
> 'ddl' would have kept a record of the same thing.
>
> Perhaps the best fix would be a documentation improvement to mention
> the fact and that it's best not to use
On Mon, Mar 26, 2018 at 01:49:30PM -0700, David G. Johnston wrote:
> You should probably ask this question on the VMWare forums since its their
> software that would or would not have the performance improvements.
> PostgreSQL will benefit from any memory and disk-related virtualization
> enhanceme
On Mon, Mar 26, 2018 at 12:46:38PM -0300, Alvaro Herrera wrote:
> Was this ever fixed?
Ugh. I have added a reminder on the open item page for v11 as an older
bug:
https://wiki.postgresql.org/wiki/PostgreSQL_11_Open_Items#Older_Bugs
--
Michael
signature.asc
Description: PGP signature
On Mon, Mar 26, 2018 at 11:52:53AM +, Amee Sankhesara - Quipment India
wrote:
> Warning : The failed archive command was: copy
> "D:\PostgreSQL\9.6\data\pg_xlog\00010A8800F8.partial"
> "\\10.0.0.35\Archive_Replication\00010A8800F8.partial" |
> copy "D:\PostgreSQL\9.6\da
On Wed, Mar 28, 2018 at 09:36:11AM -0700, raj 1988 wrote:
> Are we hitting some bug? tried to look around but not able to confirm if we
> are hitting a bug or not. For us this is happening consistently on
> different servers whenever we do pg_ctl promote and then it block WRITE on
> that table.
T
On Sun, Apr 01, 2018 at 06:26:51PM +, Jakub Janeček wrote:
> What did i do wrong? I need stop comulating WAL files and remove old WAL
> files, which are processed and are only "waiting"..
Perhaps wal_keep_segments is set and you forgot about it or you used a
replication slot that you forgot to
On Tue, Apr 10, 2018 at 11:06:54PM +0530, Raghavendra Rao J S V wrote:
> I am not clear the difference between checkpoint_segments and
> wal_keep_segments .
>
> I would like to now below things. Please explain.Thanks in advance.
>
>- Difference between *checkpoint_segments *and *wal_keep_seg
On Sun, Apr 15, 2018 at 08:25:05AM +, A A wrote:
> I'm trying to restore a database from a broken data directory that
> have lost many of its files accidentally.
Let me guess, a wild set of rm commands?
> I have tried unsuccessfully to install new instance of the same
> Postgresql version and
On Tue, Apr 17, 2018 at 05:11:10PM -0700, David G. Johnston wrote:
> Long-lived non-idle statements would likely be waiting for a lock to be
> released.
Be very careful with transactions marked as "idle in transaction" for a
long time. Long-running transactions prevent VACUUM to do its work as
th
On Tue, Apr 17, 2018 at 02:57:03PM -0400, Tom Lane wrote:
> I think possibly the OP doesn't understand why it's designed that way.
> The point is not really to "recycle old WAL files", it's to avoid having
> disk space allocation occur during the critical section where we must
> PANIC on failure.
On Wed, Apr 25, 2018 at 09:52:47AM -0500, Scott Frazer wrote:
> I'm changing out a data center and I need to setup a new replicated server.
> The bandwidth speeds between the new data center and the master are slower
> than the speeds between the new data center and the current replica.
>
> Can I
On Thu, May 03, 2018 at 01:24:59PM -0500, Justin Pryzby wrote:
> Yes, I was surprised about the difference between ANALYZE relkind_p
> and relkind_r.
>
> But I see that's a documented behavior I'd missed until now:
>
> https://www.postgresql.org/docs/current/static/sql-analyze.html
> |If the spec
On Sun, May 13, 2018 at 01:39:48AM +0200, Hannes Erven wrote:
> what is Postgresql's strategy when to fetch WAL from the master while in
> streaming replication, and could it be tweaked?
>
> I'm using a physical streaming replication slave to have a database lagging
> behind about one month behind
On Sun, May 13, 2018 at 09:42:42AM +0200, Hannes Erven wrote:
> But when new WAL is needed, the standby will fetch /all/ WAL present on the
> master.
Fetching as much WAL as possible when recovery happens is wanted by
design, so as it recovers as much as possible. And that's documented.
> I'd sa
On Mon, May 14, 2018 at 05:22:39PM -0400, Tom Lane wrote:
> Maybe it'd be worth building some sort of infrastructure that would
> allow this to be done at a lower level. It's not hard to imagine
> an autovacuum-like or bgworker-based thingy that could run around
> and apply a given SQL script in e
On Tue, May 15, 2018 at 03:02:48PM +, ChatPristi wrote:
> I got the error with PG 10.3 and 10.4 on CentOS 7 up-to-date.The
> command works with a smaller size database.
> The command works with the same database with PG 9.3.19 on RHEL 6.9
> up-to-date.
>
> I attach the EXPLAIN SELECT command.
On Thu, May 17, 2018 at 08:31:48AM +0100, Paul Linehan wrote:
> I'm having problems compiling PostgreSQL.
On which platform and/or distribution are you trying the code
compilation?
--
Michael
signature.asc
Description: PGP signature
On Tue, May 22, 2018 at 10:35:46PM -0700, David G. Johnston wrote:
> I would conclude that pg-basebackup is placing its output in stderr instead
> of stdout then...
The output of pg_basebackup's verbose mode goes to stderr (look for
example at the verbose flags in pg_basebackup.c).
--
Michael
si
On Thu, May 24, 2018 at 10:21:33AM +0200, talk to ben wrote:
> - Doing Streaming Replication between different minor version of PG is
> possible but not recommended [2]
Standbys need to be updated first, hence be careful that the primary is
not updated before the standbys or WAL generated on the
On Mon, Jun 04, 2018 at 08:44:37PM +0200, Pavel Stehule wrote:
> I have few projects there - Orafce, plpgsql_check, and pspg. I hope so
> these projects are well protected by BSD licence - and distributed
> redundant nature of git. I hope so there is not reason for panic this
> moment. I have not a
On Thu, Jun 07, 2018 at 11:57:06AM +0200, Jehan-Guillaume (ioguix) de Rorthais
wrote:
> How do you backup your projects issues on github? Using the API with some
> loops?
I personally don't care much about this part. As long as the code
survives..
--
Michael
signature.asc
Description: PGP sign
On Tue, Jun 12, 2018 at 10:39:43AM -0700, Andres Freund wrote:
> On 2018-06-12 09:31:49 -0700, Scott Stroupe wrote:
>> According to the documentation[1], pg_lsn is a 64-bit integer that's
>> printed as two hex numbers separated by a slash, e.g. 68/1225BB70. Is
>> there a way to get the 64-bit integ
On Tue, Jun 19, 2018 at 02:32:10PM -0700, David G. Johnston wrote:
> You really need to describe what you consider to be a "real life
> scenario"; and probably give a better idea of creation and number of these
> csv files. In addition to describing the relevant behavior of the
> application you
Hi Pierre,
On Tue, Jun 19, 2018 at 12:03:58PM +, Pierre Timmermans wrote:
> Here is the doc, the sentence that I find misleading is "There are
> backups that cannot be used for point-in-time recovery", also
> mentioning that they are faster than pg_dumps add to confusion (since
> pg_dumps cann
Hi Pierre,
On Wed, Jun 20, 2018 at 08:06:31AM +, Pierre Timmermans wrote:
> Hi Michael
You should avoid top-posting on the Postgres lists, this is not the
usual style used by people around :)
> Thanks for the confirmation. Your rewording removes the confusion. I
> would maybe take the opport
On Thu, Jun 21, 2018 at 04:42:00PM -0400, Ravi Krishna wrote:
> Same here even though I use Mac mail. But it is not yahoo alone.
> Most of the web email clients have resorted to top posting. I miss
> the old days of Outlook Express which was so '>' friendly. I think
> Gmail allows '>' when you c
On Thu, Jun 21, 2018 at 04:50:38PM -0700, David G. Johnston wrote:
> Generally only actual bug fixes get back-patched; but I'd have to say
> this looks like it could easily be classified as one.
Everybody is against me here ;)
> Some comments on the patch itself:
>
> "recover up to the wanted re
On Mon, Jun 25, 2018 at 12:51:10PM -0400, Bruce Momjian wrote:
> FYI, in recent discussions on the docs list:
>
>
> https://www.postgresql.org/message-id/CABUevEyumGh3r05U3_mhRrEU=dfacdrr2hew140mvn7fsbm...@mail.gmail.com
I did not recall this one. Thanks for the reminder, Bruce.
> There
On Sun, Jul 08, 2018 at 09:51:47AM -0400, Matt Dee wrote:
> In the documentation for START_REPLICATION, a required argument is the WAL
> location to begin streaming at, and I'm not sure what to use here. I have
> been using 0, and it seems to work fine. Additionally, it seems that when
> --startp
On Mon, Jul 09, 2018 at 05:58:53PM -0700, Shawn Mulloney wrote:
> There are three PostgreSQL machines: A, B, and C. B and C are slaves off of
> the master, A. A fails, and B is promoted to being the new master. Can C
> just be pointed at A and have it "just work"?
In your question I am pretty sure
On Mon, Jul 23, 2018 at 04:41:59PM +, Nicola Contu wrote:
> we used to monitor waiting connections with postgres 9.6.6 via this
> query:
>
> select count (*) from pg_stat_activity where wait_event IS NOT NULL
Please note that a wait event becomes NULL once it is reset, so what
this query doe
On Wed, Aug 01, 2018 at 09:09:30PM +, Richard Schmidt wrote:
> Our procedure that runs on machine A and B is as follows:
>
> 1. Build new databases on A and B, and configure A as Primary and B
> as Standby databases.
> 2. Make some changes to the A (the primary) and check that they ar
On Fri, Aug 03, 2018 at 12:40:16PM +0200, Andreas Kretschmer wrote:
> On 3 August 2018 12:33:26 CEST, Andreas Joseph Krogh
> wrote:
>>Hm, a co-worker noticed that we have max_wal_size = 16GB, that might be
>>the
>>reason:-)
>
> Yes ;-)
Worth mentioning that this is a soft size, and not a hard
On Sat, Aug 04, 2018 at 07:44:59AM +0100, Simon Riggs wrote:
> I think the problem is that writing the online checkpoint is deferred
> after promotion, so this is a timing issue that probably doesn't show
> in our regression tests.
Somewhat. It is a performance improvement of 9.3 to let the start
On Sat, Aug 04, 2018 at 04:59:45AM -0700, Andres Freund wrote:
> On 2018-08-04 10:54:22 +0100, Simon Riggs wrote:
>> pg_rewind doesn't work correctly. Documenting a workaround doesn't change
>> that.
>
> Especially because most people will only understand this after they've
> been hit, as test sc
On Sat, Aug 04, 2018 at 07:54:36AM -0700, Christophe Pettus wrote:
> Would having pg_rewind do a checkpoint on the source actually cause
> anything to break, as opposed to a delay while the checkpoint
> completes?
Users relying only on streaming without archives would be impacted as
potentially tw
On Tue, Aug 14, 2018 at 04:15:12PM -0300, Martín Marqués wrote:
> I'd recommend testing with a clone of the server to verify that it works
> properly (not only pg_upgrade, but your application with the new version
> of postgres). Also to time the window you'll need and see if there are
> things to
On Tue, Aug 14, 2018 at 12:14:59PM -0400, Tom Lane wrote:
> That seems like a pretty expensive thing to do, if there are lots of
> files ... and you'd still end up failing, so it's not moving the ball
> very far.
Yeah, I would think that with many small relations it is going to have a
measurable p
On Tue, Aug 28, 2018 at 07:19:12AM +0530, Raghavendra Rao J S V wrote:
> pg_basebackup: could not get transaction log end position from server:
> FATAL: requested WAL segment 00010285008F has already been
> removed
>
> Please guide me why and how to handle this error. Do you want me t
On Mon, Aug 27, 2018 at 04:40:34PM -0700, Adrian Klaver wrote:
> Is there more then one copy of pg_basebackup on the machines?
Or this user has created a tablespace directly in the main data folder,
which can cause pg_basebackup to fail because of recursion issues. It
is no wonder that a WARNING
On Wed, Aug 29, 2018 at 08:31:50AM +0200, Alexander Kukushkin wrote:
> 2018-08-29 6:02 GMT+02:00 Dave Peticolas :
>> Hello, I'm seeing some issues with WAL replay on a test server running
>> 9.6.10 using WAL archived from a 9.6.8 primary server. It reliably PANICs
>> during replay with messages lik
On Wed, Aug 29, 2018 at 09:15:29AM -0700, Dave Peticolas wrote:
> Oh, perhaps I do, depending on what you mean by worker. There are a couple
> of periodic processes that connect to the server to obtain metrics. Is that
> what is triggering this issue? In my case I could probably suspend them
> unti
On Sun, Sep 02, 2018 at 04:31:18PM -0700, Andres Freund wrote:
> Please note that nobody has verified that postgres works correctly via
> the emulation stuff MS is doing. There is a native version of postgres
> for windows however, and that is tested (and exercised by a lot of
> installations).
I
On Wed, Sep 05, 2018 at 03:29:31AM +, Alessandro Gherardi wrote:
> It looks like scram-sha-256 doesn't work when postgres is linked
> against FIPS-enabled OpenSSL and FIPS mode is turned on.
>
> Specifically, all login attempts fail with an OpenSSL error saying
> something along the lines of "
On Wed, Sep 05, 2018 at 01:19:39PM +, Alessandro Gherardi wrote:
> Hi Michael,I'm actually running postgres on Windows.
First you may want to avoid top-posting. This is not the style of the
community lists and this breaks the logic of a thread.
> I added code to fe-secure-openssl.c and be-se
On Sun, Sep 09, 2018 at 10:29:08PM +0800, magodo wrote:
> So I want to know what is the correct way to do it. Thank you in
> advance!
There are pg_last_wal_receive_lsn() and pg_last_wal_replay_lsn() which
allow you to know what is the last LSN received and replayed on a
standby. Those can be used
On Mon, Sep 10, 2018 at 02:52:00PM +, Alessandro Gherardi wrote:
> I changed the implementation of the other SHA digests to use EVP
> also. I verified that, with these changes, scram-sha-256 works when
> FIPS is enabled.
Hm... I have spent a couple of hours setting up a CentOS 7 VM with FIPS
On Tue, Sep 11, 2018 at 12:02:50PM +0900, Michael Paquier wrote:
> Hence, intrinsically, we are in contradiction with the upstream docs. I
> have worked on the problem with the patch, which works down to OpenSSL
> 0.9.8, and should fix your issue. This is based on what you sent
>
On Tue, Sep 11, 2018 at 04:32:27PM +0200, Peter Eisentraut wrote:
> I recommend letting this bake in the master branch for a while. There
> are a lot weirdly patched and alternative OpenSSL versions out there
> that defy any documentation.
Good point. Such things have bitten in the past. Okay,
On Wed, Sep 12, 2018 at 07:24:24AM +0900, Michael Paquier wrote:
> Good point. Such things have bitten in the past. Okay, then let's do
> something about sha2_openssl.c only on HEAD for now then, which I am
> fine to finish wrapping.
I was looking at trying to commit this patch
On Mon, Sep 17, 2018 at 02:55:55PM +, Alessandro Gherardi wrote:
> Therefore, I believe the best option, at least for now, is calling
> FIPS_mode_set(1) in the application.
I am not so sure about that. As you rightly mention, CentOS and RedHat
patch OpenSSL to allow FIPS to work. Per my res
On Wed, Sep 19, 2018 at 10:29:44PM +, Dylan Luong wrote:
> After promoting slave to master, I completed a pg_rewind of the slave
> (old master) to the new master. But when I try to start the slave I am
> getting the following error.
>
> I tried to run pg_rewind again, but now it says I cannot d
On Fri, Sep 28, 2018 at 10:33:30AM +0530, Raghavendra Rao J S V wrote:
> Log file will be generated in *csv* format at *pg_log* directory in our
> PostgreSQL. Every day we are getting one log file. We would like to
> maintain only max 30 days. Which setting need to modify by us in
> “postgresql.con
On Fri, Sep 28, 2018 at 06:19:16AM -0700, Adrian Klaver wrote:
> If log_truncate_on_rotation = 'on', correct?
Yup, thanks for precising.
--
Michael
signature.asc
Description: PGP signature
On Mon, Oct 08, 2018 at 03:23:47PM +0800, magodo wrote:
> Is this as expected?
Yes.
> If so, in which case should I do backup on primary and in which case
> should I do it on standby?
This depends on your use cases, sometimes you don't want to make the
production server, the primary use more CPU
(Please do not forget to add the community mailing list in CC.)
On Tue, Oct 09, 2018 at 10:33:56AM +0800, magodo wrote:
> Since the backup history aims to aid administrator to identify the
> point from which wal archive should be kept and before which the
> archive could be cleaned. It is very hel
On Tue, Oct 09, 2018 at 11:45:50AM +0800, magodo wrote:
> Yet, I am still not so clear how does the bloat of pg_wal happen? Do
> you mean pg_wal will be filled up by many .backup(s)?
If your archive_command is for example a simple cp (which it should not
be by the way), and if you try to archive t
On Tue, Oct 09, 2018 at 03:26:35PM +0800, magodo wrote:
> Yes, but does this differ whether I'm archiving a general WAL or
> archiving the backup history? I mean if user doesn't handle duplicate
> archive, then pg_wal will still be filled up when archiving WAL.
A WAL segment has a unique name, and
On Fri, Oct 12, 2018 at 12:17:40PM -0400, Tom Lane wrote:
> So the immediate fix for building on Windows is you need to manually
> define all of those in pg_config.h. We probably ought to try to make
> that less painful, though. At the very least it'd be good if there
> were just one symbol you h
On Fri, Jul 05, 2019 at 10:03:16AM -0400, Tom Lane wrote:
> ayaho...@ibagroup.eu writes:
>> Do you have any thoughts regarding this issue?
>
> I do not think anybody thinks this is a bug. Setting wal_sender_timeout
> too small is a configuration mistake.
Yeah. I don't see any bug here. Please
On Fri, Jul 12, 2019 at 02:55:55AM +, Nanda Kumar wrote:
> Currently we are using postgres database 9.7 version.
You may be mistaken. There is a major release of PostgreSQL called
9.6, but after that we have jumped directly to 10, reducing the number
of digits to mark a given minor version fr
On Fri, Jul 12, 2019 at 05:57:10AM +, Nanda Kumar wrote:
> Its my bad. Yes, currently we are using 9.6 version. Now we are
> looking for 10.8 edb software for testing purpose . Kindly advise
> where we can download the 10.8 edb software ?
10.9 is the latest version in the 10.X series:
https:/
On Tue, Aug 13, 2019 at 12:45:35PM +1000, raf wrote:
> Since the backup itself was from a 9.5.12 server, it
> seems that the 9.6 parameter, idle_in_transaction_session_timeout,
> must have been set by the 9.6 client even though it was
> connected to a 9.5 server. Is that expected behaviour?
Yes, t
On Sun, Sep 29, 2019 at 04:52:15PM -0500, Ron wrote:
> On 9/29/19 4:42 PM, Colin 't Hart wrote:
> Redis is an in-memory key-value database. PostgreSQL... isn't.
Well, I think that you have never heard about the urban legend of
running Postgres on scissors then and this reminds me of this blog
post
On Thu, Oct 10, 2019 at 10:22:22AM +0530, Shankar Bhaskaran wrote:
> We are planning to use postgres 10.7 version as that is the latest
> version supported on Aurora DB. Since we have an on premise installation
> also , i was trying to download the same version of postgres for windows
> and linux.
On Sat, Oct 26, 2019 at 11:02:26AM -0700, Adrian Klaver wrote:
> Not sure how that can be answered without knowing what ComputeComputer is
> doing?
Yes, there is nothing of this kind in the PostgreSQL code. So you may
want to check your own extension code if a module is involved here, or
perhaps
On Mon, Oct 28, 2019 at 09:51:07AM -0700, ZhenHua Cai wrote:
> The following is the SQL statement of that function.
>
> DROP TABLE IF EXISTS "GenericReadList" ;
> CREATE TEMP TABLE "GenericReadList"(
> "ComputerProfileId" int NOT NULL,
> "Trustee" uuid NOT NULL,
> "AccessControlType" smallint NULL
On Thu, Nov 14, 2019 at 08:26:48AM +0100, Laurenz Albe wrote:
> If you have data corruption, you shouldn't use pg_upgrade to upgrade.
> pg_dumpall / psql is the way to go.
Please refer to this wiki page:
https://wiki.postgresql.org/wiki/Corruption
If you have a cluster in such a state, you have r
On Sun, Nov 17, 2019 at 04:41:59AM +0100, Pavel Stehule wrote:
> Documentation patch is good idea.
The documentation is rather clear about the need to of parenthesis
when using the VERBOSE option, and that it is not a mandatory option:
REINDEX [ ( VERBOSE ) ] { INDEX | TABLE | SCHEMA | DATABASE |
On Mon, Nov 18, 2019 at 10:27:24AM +0100, Josef Šimánek wrote:
> This is clear once you understand what does it mean. I was aware of VERBOSE
> option of EXPLAIN and tried to use it without needed parentheses (the same
> way EXPLAIN can understand it). In the parameter list of REINDEX, it is
> still
On Fri, Nov 15, 2019 at 03:17:17PM -0500, Dave Hughes wrote:
> Thanks for replying guys! You both led me down the right path. I didn't
> realize it, but looks like we had 2 directories where psql was installed.
> Once I gave the path specifically to PostgreSQL10, it worked like a charm.
>
> I'm
On Tue, Nov 19, 2019 at 11:37:04AM +, Geoff Winkless wrote:
> It's bad enough that you have the inconsistency that REINDEX VERBOSE
> requires parentheses while the more recent REINDEX CONCURRENTLY does
> not (presumably to match the syntax of CREATE INDEX CONCURRENTLY),
> without insisting that
On Thu, Nov 21, 2019 at 05:13:31PM +0100, Laurenz Albe wrote:
> How should that work for tables other than temporary tables?
> Should COMMIT lock if somebody else accesses the table?
Postgres does not support read uncommitted, so the table would not be
visible to other sessions until the transacti
On Fri, Nov 22, 2019 at 01:20:59PM +, Zwettler Markus (OIZ) wrote:
> I came up with the following query which should return any apply lag in
> seconds.
>
> select coalesce(replay_delay, 0) replication_delay_in_sec
> from (
>select datname,
> (
> select ca
On Fri, Nov 15, 2019 at 09:45:59PM +0100, Pavel Stehule wrote:
> Maybe ERRCODE_NULL_VALUE_NOT_ALLOWED, and "NULL is not allowed",
> errdetail - a exception due setting "null_value_treatment" =>
> raise_exception
> and maybe some errhint - "Maybe you would to use Jsonb NULL - "null"::jsonb"
>
> I d
On Fri, Nov 29, 2019 at 04:57:11PM -0300, Christopher Pereira wrote:
> Our stream replication slave server got out of sync so we need to base
> backup again.
>
> In case of big databases, can we do incremental backups with pg_basebackup?
I know of two ways to define such backups, one being actual
On Tue, Dec 03, 2019 at 10:32:22PM +, Julie Nishimura wrote:
> Hello, what is the best way to migrate from PostgreSQL 8.3.11 on
> x86_64-redhat-linux-gnu to PostgreSQL 9.6.16 on x86_64-pc-linux-gnu
> server, with minimal downtime?
> The caveat is the source has about 80 databases overall almost
On Wed, Dec 04, 2019 at 08:38:01AM +0100, Thomas Kellerer wrote:
> But pg_upgrade only supports 8.4+
Ditto. You're right here.
--
Michael
signature.asc
Description: PGP signature
On Thu, Dec 05, 2019 at 07:12:22PM -0600, Ron wrote:
> On 12/5/19 1:01 PM, Tom Lane wrote:
>> It's been considered, and rejected, many times. Aside from the overhead
>> involved, there are too many different ideas of what such dates ought to
>> mean (e.g., what should happen during dump/restore? d
On Thu, Dec 05, 2019 at 03:04:55PM +, Zwettler Markus (OIZ) wrote:
> What do you mean hear?
>
> Afaik, Postgres runs the archive_command per log, means log by log by log.
>
> How should we parallelize this?
You can, in theory, skip the archiving for a couple of segments and
then do the opera
On Tue, Jan 07, 2020 at 06:15:09AM +, Nagaraj Raj wrote:
> and this error is occurring in large tables only, and current table
> size which is running about 700GB
>
> /pg_repack --version
> pg_repack 1.4.3
>
> DB version: PostgreSQL 9.6.11 on x86_64-pc-linux-gnu, compiled by gcc (GCC)
> 4.9.
On Wed, Jan 08, 2020 at 11:06:28PM -0500, Rita wrote:
> I run a master and standby setup with Postgresql 11. The systems are
> identical from a hardware and software setup. If the master goes down I
> can do a pg_ctl promote on the standby and point my applications to use the
> standby (new master
On Wed, Jan 08, 2020 at 05:04:21AM +, Daulat Ram wrote:
> I have to implement the streaming replication for our prod environment.
> Can you please share the list of parameters to setup the PostgreSQL
> 11 streaming replication with continuous archiving and give clarity
> on the below.
>
> *
On Thu, Jan 09, 2020 at 03:14:59PM +0100, Jehan-Guillaume de Rorthais wrote:
> If you can afford that, this is the cleanest and easiest procedure you could
> find.
>
> Note that pg_basebackup need an empty PGDATA, so it will have to transfert the
> whole instance from new promoted primary to the or
On Mon, Jan 13, 2020 at 11:41:36AM -0800, Adrian Klaver wrote:
> How did the above get installed, from source, RPM. other?
Rushikesh, depending on your environment, the way to install
pg_stat_statements' libraries may change. On most Linux
distributions, any extension modules are shipped with a p
On Tue, Jan 14, 2020 at 02:34:04PM -0800, Adrian Klaver wrote:
> On 1/14/20 12:44 PM, Tulqin Navruzov wrote:
>> but can logged in with another user and trying to select from some
>> tables , showing this message :
>>
>> ERROR: catalog is missing 11 attribute(s) for relid 113971
>>
>> Could you h
On Tue, Jan 21, 2020 at 08:10:39AM +0100, Eric Veldhuyzen wrote:
> We are using pgbackrest (2.21) to backup out postgresql (11) clusters.
> Last night our nightly diff backup gave me the
> ERROR: unable to convert base 10 string '000B' to unsigned int.
> I tried if a full backup would fix this,
On Thu, Feb 06, 2020 at 03:54:48AM +0100, Vik Fearing wrote:
> I proposed a patch to add %x to PROMPT1 and PROMPT2 by default in psql.
>
> The effect of this is:
>
> - nothing at all when not in a transaction,
> - adding a '*' when in a transaction or a '!' when in an aborted
> transaction.
>
On Wed, Feb 12, 2020 at 12:05:11PM -0800, Andres Freund wrote:
> Yes, LLVM would work on windows. I'd not even be surprised if one could
> make it work on windows already when using a mingw based build, instead
> of msvc.
For MSVC, assuming that you have the proper dependencies for JIT
compilation
On Wed, Feb 12, 2020 at 07:32:08PM -0800, Andres Freund wrote:
> That's not really the hard part. That's integrating the generation of
> LLVM bitcode files into the buildsystem. As the absolute minimum
> llvmjit_types.bc needs to be generated, but to be meaningfully supported
> we'd need to generat
On Tue, Mar 10, 2020 at 12:23:49PM +0530, Sonam Sharma wrote:
> We have pg_read_all_stats role from v9.6. do we have a similar role for
> v9.5 and lower versions ?
No, and pg_read_all_stats has been introduced in Postgres 10, not 9.6:
https://www.postgresql.org/docs/10/release-10.html
--
Michael
On Tue, Mar 17, 2020 at 10:45:50AM -0400, Tom Lane wrote:
> Don Seiler writes:
>> What are the ramifications of changing collation like that? Should we
>> consider rebuilding indexes ASAP after that?
>
> Text indexes would definitely be at risk here. I'm not really certain
> how bad the problem
On Wed, Mar 18, 2020 at 10:57:22AM -0300, Norberto Dellê wrote:
> This setup worked very well for a long time, but since we upgraded
> PostgreSQL to newer versions (10.x), sometimes it just skips archiving some
> wal files. This seems to happen mainly when the server is shut down.
> There's no mess
1 - 100 of 309 matches
Mail list logo
