Re: [HACKERS] pgbench regression test failure

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: not tested Spec compliant: not tested Documentation:not tested This causes the pgbench tests to fail (consistently) with not ok 194 - p

Re: [HACKERS] 10 beta docs: different replication solutions

On Mon, 31 Jul 2017, Merlin Moncure wrote: On Sun, Jul 30, 2017 at 8:34 PM, Steve Singer wrote: We don't seem to describe logical replication on https://www.postgresql.org/docs/10/static/different-replication-solutions.html The attached patch adds a section. This is a good catch.

[HACKERS] 10 beta docs: different replication solutions

We don't seem to describe logical replication on https://www.postgresql.org/docs/10/static/different-replication-solutions.html The attached patch adds a section. Steve diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 138bdf2..1329d1f 100644

Re: [HACKERS] tablesync patch broke the assumption that logical rep depends on?

On 04/10/2017 01:28 PM, Fujii Masao wrote: Hi, src/backend/replication/logical/launcher.c * Worker started and attached to our shmem. This check is safe * because only launcher ever starts the workers, so nobody can steal * the worker slot. The tablesync

Re: [HACKERS] Retiring from the Core Team

Thanks, Josh, for everything. I especially enjoyed your monthly updates at SFPUG. Cheers, Steve On Thu, Jan 12, 2017 at 1:59 PM, Merlin Moncure wrote: > On Wed, Jan 11, 2017 at 6:29 PM, Josh Berkus wrote: > > Hackers: > > > > You will have noticed that I haven't bee

Re: [HACKERS] sequence data type

On 12/31/2016 01:27 AM, Peter Eisentraut wrote: Another updated patch, with quite a bit of rebasing and some minor code polishing. Patch applies cleanly and the tests pass The feature seems to work as expected. I've tried this out and it behaves as expected and desired. I also tested the PG

Re: [HACKERS] Logical Replication WIP

On 12/30/2016 05:53 AM, Petr Jelinek wrote: Hi, I rebased this for the changes made to inheritance and merged in the fixes that I previously sent separately. I'm not sure if the following is expected or not I have 1 publisher and 1 subscriber. I then do pg_dump on my subscriber ./pg_dump

Re: [HACKERS] Logical Replication WIP

On 12/18/2016 09:04 PM, Petr Jelinek wrote: On 18/12/16 19:02, Steve Singer wrote: pg_dump is also generating warnings pg_dump: [archiver] WARNING: don't know how to set owner for object type SUBSCRIPTION I know that the plan is to add proper ACL's for publications and subscription

Re: [HACKERS] Logical Replication WIP

On 12/18/2016 05:28 AM, Petr Jelinek wrote: On 17/12/16 18:34, Steve Singer wrote: On 12/16/2016 07:49 AM, Petr Jelinek wrote: Yeah subscriptions are per database. I don't want to make v14 just for these 2 changes as that would make life harder for anybody code-reviewing the v13 so att

Re: [HACKERS] Logical Replication WIP

On 12/16/2016 07:49 AM, Petr Jelinek wrote: Hi, attached is version 13 of the patch. I merged in changes from PeterE. And did following changes: - fixed the ownership error messages for both provider and subscriber - added ability to send invalidation message to invalidate whole relcache and us

Re: [HACKERS] Logical Replication WIP

On Sun, 20 Nov 2016, Petr Jelinek wrote: On 13/11/16 23:02, Steve Singer wrote: There is one exception though: *** 195,214 A conflict will produce an error and will stop the replication; it ! must be resolved manually by the user. ! The resolution can

Re: [HACKERS] Logical Replication WIP

On 10/31/2016 06:38 AM, Petr Jelinek wrote: On 31/10/16 00:52, Steve Singer wrote: There are some fundamental issues with initial sync that need to be discussed on list but this one is not known. I'll try to convert this to test case (seems like useful one) and fix it, thanks for the r

Re: [HACKERS] Logical Replication WIP

On 10/31/2016 06:38 AM, Petr Jelinek wrote: There are some fundamental issues with initial sync that need to be discussed on list but this one is not known. I'll try to convert this to test case (seems like useful one) and fix it, thanks for the report. In meantime I realized I broke the last p

Re: [HACKERS] Logical Replication WIP

On 10/24/2016 09:22 AM, Petr Jelinek wrote: Hi, attached is updated version of the patch. There are quite a few improvements and restructuring, I fixed all the bugs and basically everything that came up from the reviews and was agreed on. There are still couple of things missing, ie column type

Re: [HACKERS] Is it time to kill support for very old servers?

. This is effectively a 5-year upgrade "grace period" *after* the EOL date of a given version which seems plenty generous. Defining the term of backward compatibility support might be useful in the future when these types of questions arise. Cheers, Steve On Fri, Oct 7, 2016 at 9:06

Re: [HACKERS] Logical Replication WIP

On Tue, 20 Sep 2016, Peter Eisentraut wrote: On 9/18/16 4:17 PM, Steve Singer wrote: I think if we want to prevent the creation of subscriptions that point to self, then we need to create a magic token when the postmaster starts and check for that when we connect. So more of a running

Re: [HACKERS] Logical Replication WIP

if the specified connection connects back to same db (although that check is somewhat imperfect) and if it gets stuck on create slot it should be normally cancelable (that should solve the issue Steve Singer had) - fixed the tests to work in any timezone - added DDL regress tests for subscription

Re: [HACKERS] Logical Replication WIP

On 09/08/2016 06:59 PM, Petr Jelinek wrote: - the CREATE SUBSCRIPTION also tries to check if the specified connection connects back to same db (although that check is somewhat imperfect) and if it gets stuck on create slot it should be normally cancelable (that should solve the issue Steve

Re: [HACKERS] Logical Replication WIP

On 09/05/2016 03:58 PM, Steve Singer wrote: On 08/31/2016 04:51 PM, Petr Jelinek wrote: Hi, and one more version with bug fixes, improved code docs and couple more tests, some general cleanup and also rebased on current master for the start of CF. A few more things I noticed when

Re: [HACKERS] Logical Replication WIP

On 08/31/2016 04:51 PM, Petr Jelinek wrote: Hi, and one more version with bug fixes, improved code docs and couple more tests, some general cleanup and also rebased on current master for the start of CF. To get the 'subscription' TAP tests to pass I need to set export PGTZ=+02 Shouldn'

Re: [HACKERS] Logical Replication WIP

On 08/05/2016 11:00 AM, Petr Jelinek wrote: Hi, as promised here is WIP version of logical replication patch. Thanks for keeping on this. This is important work Feedback is welcome. + + Publication + +A Publication object can be defined on any master node, owned by one +user.

Re: [HACKERS] Bug in to_timestamp().

On Fri, Jun 24, 2016 at 3:43 PM, Joshua D. Drake wrote: > On 06/24/2016 02:16 PM, Tom Lane wrote: > >> Robert Haas writes: >> >>> On Fri, Jun 24, 2016 at 12:26 PM, Steve Crawford >>> wrote: >>> >>>> To me, 2016-02-30 is an invali

Re: [HACKERS] Bug in to_timestamp().

. Automatically and silently changing it to be 2016-03-01 strikes me as a behavior I'd expect from a certain other open-source database, not PostgreSQL. Cheers, Steve On Fri, Jun 24, 2016 at 8:52 AM, Alex Ignatov wrote: > > Alex Ignatov > Postgres Professional: http://www.postgrespro.com

Re: [HACKERS] Feature request: make cluster_name GUC useful for psql prompts

connections? You can use variables to approximate the behavior of aliases so you can hack an alias that includes the reconnect and re-read. Or just \i ~/.psqlrc as you deem necessary. Cheers, Steve On Fri, May 6, 2016 at 12:50 PM, Jerry Sievers wrote: > Steve Crawford writes: > >

Re: [HACKERS] Feature request: make cluster_name GUC useful for psql prompts

d. Cheers, Steve On Fri, May 6, 2016 at 11:42 AM, Jerry Sievers wrote: > Peter Eisentraut writes: > > > On 5/5/16 9:21 PM, Steve Crawford wrote: > > > >> Adding an escape sequence that references cluster_name would enable > >> prompts to identify the c

[HACKERS] Feature request: make cluster_name GUC useful for psql prompts

re-9.5 version. %M? %m? In future server versions should there be a default for cluster_name if it is not set? If so, what should it be? Would the server canonical hostname + listen-port be reasonable? Cheers, Steve

Re: [HACKERS] pglogical - logical replication contrib module

On 01/26/2016 10:43 AM, Craig Ringer wrote: On 23 January 2016 at 11:17, Steve Singer <mailto:st...@ssinger.info>> wrote: ** Schema changes involving rewriting big tables Sometimes you have a DDL change on a large table that will involve a table rewrite and the be

Re: [HACKERS] pglogical - logical replication contrib module

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: not tested Documentation:tested, failed Here is some more review +- `pglogical.replication_set_add_table

Re: [HACKERS] pglogical - logical replication contrib module

The following review has been posted through the commitfest application: make installcheck-world: not tested Implements feature: not tested Spec compliant: not tested Documentation:not tested This reply will covers a 10,000 foot level review of the feature (some of my

Re: [HACKERS] pglogical - logical replication contrib module

On 01/15/2016 12:07 PM, Petr Jelinek wrote: That's bug, fixed. Can you posted an updated patch with whatever fixes you have so far made? There are several statuses the table goes through, during the COPY it's in synchronizing status, so next logical step seemed to be synchronized. Maybe it

Re: [HACKERS] pglogical - logical replication contrib module

On 01/09/2016 01:30 PM, Steve Singer wrote: On 12/31/2015 06:34 PM, Petr Jelinek wrote: I'm not really sure what to do to 'recover' my cluster at this point so I'll send this off and rebuild my cluster and start over. I had a setup test1--->test2 (with 2 tables

Re: [HACKERS] pglogical - logical replication contrib module

On 12/31/2015 06:34 PM, Petr Jelinek wrote: Hi, I'd like to submit the replication solution which is based on the pglogical_output [1] module (which is obviously needed for this to compile). The pglogical contrib module provides extension which does the master-slave logical replication base

Re: [HACKERS] pglogical - logical replication contrib module

On 12/31/2015 06:34 PM, Petr Jelinek wrote: Hi, I'd like to submit the replication solution which is based on the pglogical_output [1] module (which is obviously needed for this to compile). Hi, make check gives me for extra in ../../contrib/pglogical_output contrib/pglogical; do make

Re: [HACKERS] Extracting fields from 'infinity'::TIMESTAMP[TZ]

-week will have no value for a date of infinity I'd be OK with returning null. I suppose the real question is what return value will cause the smallest amount of breakage and surprising results. Throwing an error will definitely break legit queries. Cheers, Steve On Mon, Nov 9, 2015 at

Re: [HACKERS] snapshot too old, configured by time

On 10/15/2015 05:47 PM, Kevin Grittner wrote: All other issues raised by Álvaro and Steve have been addressed, except for this one, which I will argue against: I've been looking through the updated patch In snapmgr.c + * XXX: If we can trust a read of an int64 value to be atomic, w

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

nterprise version. Cheers, Steve

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

munity" and an "enterprise" version so for comparison purposes we should only look at the features in the open-source community version: https://about.gitlab.com/features/#compare Cheers, Steve

Re: [HACKERS] snapshot too old, configured by time

On 08/31/2015 10:07 AM, Kevin Grittner wrote: Kevin, I've started to do a review on this patch but I am a bit confused with some of what I am seeing. The attached testcase fails I replace the cursor in your test case with direct selects from the table. I would have expected this to generat

Re: [HACKERS] What does RIR as in fireRIRrules stand for?

Candidate for Appendix K? Cheers, Steve On Thu, Aug 27, 2015 at 6:52 AM, Tom Lane wrote: > Andres Freund writes: > > On 2015-08-27 09:43:09 -0400, Tom Lane wrote: > >> http://www.postgresql.org/message-id/3e887762.5b68f...@yahoo.com > > > Oops. I saw that messag

Re: [HACKERS] pg_dump and search_path

Thank you gentlemen for clarifying this. I found this problem when my database modeling tool saw a change in the database (the nextval() parameters) after a database restore. I guess the tool must be reading adsrc for this information. Cheers, Steve Thames -Original Message- From: Tom

[HACKERS] pg_dump and search_path

I earliest reference I found to this issue is here and refers to the search_path being arbitrarily set in the file created by pg_dump. This is apparently still the case in 9.4. I found this issue b

Re: [HACKERS] [PATCH] libpq: Allow specifying multiple host names to try to connect to

On 04/19/2015 11:18 AM, Mikko Tiihonen wrote: Hi, I would like allow specifying multiple host names for libpq to try to connecting to. This is currently only supported if the host name resolves to multiple addresses. Having the support for it without complex dns setup would be much easier.

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

Just wanted to report that I rolled back my VM to where it was with 9.4.2 installed and it wouldn't start. I installed 9.4.4 and now it starts up just fine: > 2015-06-12 16:05:58 PDT [6453]: [1-1] LOG: database system was shut down at 2015-05-27 13:12:55 PDT > 2015-06-12 16:05:58 PDT [6453]: [2-1

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

On Fri, Jun 5, 2015 at 11:47 AM Andres Freund wrote: > But I'd definitely like some > independent testing for it, and I'm not sure if that's doable in time > for the wrap. > I'd be happy to test on my database that was broken, for however much that helps. It's a VM so I can easily revert back as

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

On Fri, May 29, 2015 at 12:08 PM Robert Haas wrote: > OK, here's a patch. > I grabbed branch REL9_4_STABLE from git, and Robert got me a 9.4-specific patch. I rebuilt, installed, and postgres started up successfully! I did a bunch of checks, had our app run several thousand SQL queries against

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

On Wed, May 27, 2015 at 3:21 PM Alvaro Herrera wrote: > I think a patch like this should be able to fix it ... not tested yet. > Thanks Alvaro. I got a compile error, so looked for other uses of SimpleLruDoesPhysicalPageExist and added MultiXactOffsetCtl, does this look right? + (!InRecovery |

Re: [HACKERS] Unable to build pg_rewind

Thanks all. I opened an issue in GitHub (https://github.com/vmware/pg_rewind/issues/43). Sorry for posting to the wrong spot. I found some discussions on pg_rewind on this list, so I thought it was the appropriate place to send my questions. Thanks, Steve From: Michael Paquier

[HACKERS] Unable to build pg_rewind

I have checked out the pg_rewind code from https://github.com/vmware/pg_rewind.git on the master branch and am using PostgreSQL 9.4.1 source code to build against. When I try to compile pg_rewind, I am getting the following errors. How can I resolve these problems? gcc -Wall -Wmissing-protot

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

On 12/19/2014 10:41 AM, Alex Shulgin wrote: I don't think so. The scenario this patch relies on assumes that the DBA will remember to look in the log if something goes wrong, and in your case there would be a message like the following: WARNING: pg_hba.conf not reloaded So an extra hint about

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

On 12/15/2014 11:38 AM, Alex Shulgin wrote: These are all valid concerns IMHO. Attached is the modified version of the original patch by Craig, addressing the handling of the new hint_log error data field and removing the client-side HINT. I'm also moving this to the current CF. -- Alex

Re: [HACKERS] tracking commit timestamps

On 11/19/2014 08:22 AM, Alvaro Herrera wrote: I think we're overblowing the pg_upgrade issue. Surely we don't need to preserve commit_ts data when upgrading across major versions; and pg_upgrade is perfectly prepared to remove old data when upgrading (actually it just doesn't copy it; consider

Re: [HACKERS] logical decoding - reading a user catalog table

On 11/17/2014 11:34 AM, Andres Freund wrote: Hi, Kevin: CCed you, because it doesn't really look like a logical decoding related issue. On 2014-11-17 11:25:40 -0500, Steve Singer wrote: On 11/17/2014 10:37 AM, Andres Freund wrote: On 2014-11-13 22:23:02 -0500, Steve Singer wrote:

Re: [HACKERS] logical decoding - reading a user catalog table

On 11/17/2014 10:37 AM, Andres Freund wrote: On 2014-11-13 22:23:02 -0500, Steve Singer wrote: Also since updating (to 2c267e47afa4f9a7c) I've seen a assertion failure in a normal client connection, not the walsender #3 0x006b4978 in GetSerializableTransactionSnapsh

Re: [HACKERS] logical decoding - reading a user catalog table

On 11/16/2014 04:49 PM, Steve Singer wrote: I installed things following the above steps on a different system than my usual development laptop and I have been unable to reproduce the error so for (on that system). But I am still able to reproduce it on occasion on my normal development

Re: [HACKERS] logical decoding - reading a user catalog table

On 11/13/2014 02:44 PM, Andres Freund wrote: Hi Steve, If it still happens, could you send me instructions of how to reproduce the problem after cloning the necessary source repositories? It's quite hard to validate a possible fix otherwise. 1. Install PG 9.4 2. Perform an i

Re: [HACKERS] tracking commit timestamps

mber of different systems at a number of different companies. I've generally seen it dealt with by either selecting rows behind the last now() timestamp seen and then filtering out already processed rows or by tracking the 'processed' state of each row individually (ie perfor

Re: [HACKERS] logical decoding - reading a user catalog table

On 11/13/2014 02:44 PM, Andres Freund wrote: H I've pushed a fix for a bug that could possibly also cause this. Although it'd be odd that it always hits the user catalog table. Except if your tests mostly modify the slony tables, but do not do much DDL otherwise? The test I was running doesn

Re: [HACKERS] tracking commit timestamps

On 11/10/2014 08:39 AM, Petr Jelinek wrote: On 09/11/14 17:57, Steve Singer wrote: On 11/07/2014 07:07 PM, Petr Jelinek wrote: The list of what is useful might be long, but we can't have everything there as there are space constraints, and LSN is another 8 bytes and I still want to have

Re: [HACKERS] tracking commit timestamps

On 11/07/2014 07:07 PM, Petr Jelinek wrote: The list of what is useful might be long, but we can't have everything there as there are space constraints, and LSN is another 8 bytes and I still want to have some bytes for storing the "origin" or whatever you want to call it there, as that's the

Re: [HACKERS] tracking commit timestamps

On 11/05/2014 05:43 PM, Andres Freund wrote: On 2014-11-05 17:17:05 -0500, Steve Singer wrote: Imo that's essentially a different feature. What you essentially would need here is a 'commit sequence number' - but no timestamps. And probably to be useful that number has to be 8

Re: [HACKERS] tracking commit timestamps

On 11/05/2014 11:23 AM, Jim Nasby wrote: Except that commit time is not guaranteed unique *even on a single system*. That's my whole point. If we're going to bother with all the commit time machinery it seems really silly to provide a way to uniquely order every commit. Clearly trying to u

Re: [HACKERS] "snapshot too large" error when initializing logical replication (9.4)

On 10/28/2014 01:27 PM, Andres Freund wrote: Hi, On 2014-10-25 18:09:36 -0400, Steve Singer wrote: I sometimes get the error "snapshot too large" from my logical replication walsender process when in response to a CREATE_REPLICATION_SLOT. Yes. That's possible if 'too much

Re: [HACKERS] logical decoding - reading a user catalog table

On 10/28/2014 01:31 PM, Andres Freund wrote: On 2014-10-25 18:18:07 -0400, Steve Singer wrote: My logical decoding plugin is occasionally getting this error "could not resolve cmin/cmax of catalog tuple" I get this when my output plugin is trying to read one of the user defin

[HACKERS] logical decoding - reading a user catalog table

My logical decoding plugin is occasionally getting this error "could not resolve cmin/cmax of catalog tuple" I get this when my output plugin is trying to read one of the user defined catalog tables (user_catalog_table=true) I am not sure if this is a bug in the time-travel support in the l

[HACKERS] "snapshot too large" error when initializing logical replication (9.4)

I sometimes get the error "snapshot too large" from my logical replication walsender process when in response to a CREATE_REPLICATION_SLOT. This is in SnapBuildExportSnapshot in snapbuild.c newxcnt is 212 at that point I have max_connections = 200 procArray->maxProcs=212 Should we be testing

Re: [HACKERS] Moving of INT64_FORMAT to c.h

On 10/22/2014 04:17 PM, Robert Haas wrote: Slonik used to include postgre_fe.h but back in 2011 or so we stopped doing so because it was causing issues (I think on win32 builds) That seems like something we ought to consider fixing, but obviously we'd need more details. When I'll try to find

Re: [HACKERS] Moving of INT64_FORMAT to c.h

y projects that have been including pg_config.h will hit similar issues. if there was good reason for the change then fine (Postgres isn't intended to be a general purpose C portability layer). Steve Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers

Re: [HACKERS] [PATCH] HINT: pg_hba.conf changed since last config reload

fected changes were applied set_config_option is comparing the relative path with the absolute path. Steve (Even if DETAIL was appropriate for this info, which it isn't, I can't use errdetail_log because it's already used for other information in some of the same error sites.) The

Re: [HACKERS] Replication identifiers, take 3

On 09/26/2014 10:21 AM, Andres Freund wrote: On 2014-09-26 09:53:09 -0400, Robert Haas wrote: On Fri, Sep 26, 2014 at 5:05 AM, Andres Freund wrote: Let me try to summarize the information requirements for each of these things. For #1, you need to know, after crash recovery, for each standby,

Re: [HACKERS] Replication identifiers, take 3

ds the space we'll redo this feature to use the method Robert describes is unrealistic. If we think that the replication identifier isn't general/important/necessary to justify 2 bytes of WAL header space then we should start out with something that doesn't use the WAL header,

Re: [HACKERS] Why data of timestamptz does not store value of timezone passed to it?

t;interesting." Is the interval 1-day shorthand for 24-hours or the same time of day the following day (i.e. when crossing DST boundaries). What is the appropriate value of March 31 minus one month? February 29 plus one year? Read and experiment to understand the quirks and the design-decisions implemented in PostgreSQL (or other program). Cheers, Steve

Re: [HACKERS] 9.4 logical decoding assertion

On 08/15/2014 09:42 AM, Andres Freund wrote: On 2014-08-14 16:03:08 -0400, Steve Singer wrote: I hit the following on 9.4 testing logical decoding. TRAP: FailedAssertion("!(prev_first_lsn < cur_txn->first_lsn)", File: "reorderbuffer.c", Line: 618) LOG: ser

[HACKERS] 9.4 logical decoding assertion

I hit the following on 9.4 testing logical decoding. TRAP: FailedAssertion("!(prev_first_lsn < cur_txn->first_lsn)", File: "reorderbuffer.c", Line: 618) LOG: server process (PID 3801) was terminated by signal 6: Aborted Unfortunately I don't have a core file and I haven't been able to repro

Re: [HACKERS] Hokey wrong versions of libpq in apt.postgresql.org

proper packaging on this? +1 Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] 9.4 logical replication - walsender keepalive replies

On 07/14/2014 01:19 PM, Steve Singer wrote: On 07/06/2014 10:11 AM, Andres Freund wrote: Hi Steve, Right. I thought about this for a while, and I think we should change two things. For one, don't request replies here. It's simply not needed, as this isn't dealing with timeou

Re: [HACKERS] 9.4 logical replication - walsender keepalive replies

On 07/06/2014 10:11 AM, Andres Freund wrote: Hi Steve, Right. I thought about this for a while, and I think we should change two things. For one, don't request replies here. It's simply not needed, as this isn't dealing with timeouts. For another don't just check ->f

Re: [HACKERS] 9.4 pg_control corruption

On 07/08/2014 10:14 PM, Tom Lane wrote: Steve Singer writes: I've encountered a corrupt pg_control file on my 9.4 development cluster. I've mostly been using the cluster for changeset extraction / slony testing. This is a 9.4 (currently commit 6ad903d70a440e + a walsender change

[HACKERS] 9.4 pg_control corruption

I've encountered a corrupt pg_control file on my 9.4 development cluster. I've mostly been using the cluster for changeset extraction / slony testing. This is a 9.4 (currently commit 6ad903d70a440e + a walsender change discussed in another thread) but would have had the initdb done with an

[HACKERS] 9.4 logical replication - walsender keepalive replies

thing like Server Sends LSN 0/1000 Server Sends LSN 0/2000 Server Sends LSN 0/3000 Client confirms LSN 0/2000 I don't see why all these keep alive replies are needed in this case (the timeout value is bumped way up, it's the above block that is triggering the reply request not som

Re: [HACKERS] CREATE REPLICATION SLOT fails on a timeout

On 05/28/2014 06:41 PM, Andres Freund wrote: Hi, Pushed a fix for it. I am pretty sure it will, but could you still test that it fixes your problem? Thanks! The fix seems to work (I am no longer getting the timeout on slot creation) Thanks Andres Freund -- Sent via pgsql-hackers ma

Re: [HACKERS] I thought we were changing the name of recvlogical?

...@awork2.anarazel.de Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] CREATE REPLICATION SLOT fails on a timeout

out checking is more robust. Greetings, Andres Freund That makes sense. A patch that does that is attached. Steve diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c new file mode 100644 index 5c11d68..d23f06b *** a/src/backend/replication/walsender.c --

[HACKERS] CREATE REPLICATION SLOT fails on a timeout

p to now() it starts processing a command. Since receiving a command is hearing something from the client. Steve diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c new file mode 100644 index 5c11d68..56a2f10 *** a/src/backend/repli

Re: [HACKERS] assertion in 9.4 with wal_level=logical

On 04/17/2014 04:33 PM, Andres Freund wrote: Hi, On 2014-04-17 16:23:54 -0400, Steve Singer wrote: With master/9.4 from today (52e757420fa98a76015c2c88432db94269f3e8f4) I am getting an assertion when doing a truncate via SPI when I have wal_level=logical. Stack trace is below. I am just

[HACKERS] assertion in 9.4 with wal_level=logical

With master/9.4 from today (52e757420fa98a76015c2c88432db94269f3e8f4) I am getting an assertion when doing a truncate via SPI when I have wal_level=logical. Stack trace is below. I am just replicating a table with normal slony (2.2) I don't need to establish any replication slots to get this

Re: [HACKERS] Patch: iff -> if

disuse the news has failed to reach me: http://en.wikipedia.org/wiki/If_and_only_if http://www.mathwords.com/i/if_and_only_if.htm http://mathworld.wolfram.com/Iff.html ... Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] PQputCopyData dont signal error

ead, find out that discussion thread really has nothing to do with your topic of interest, repeat, finally try something different, repeat? Again, my apologies for lighting a fire under everyone. Regards, Steve K. -- View this message in context: http://postgresql.1045698.n5.nabble.com

Re: [HACKERS] PQputCopyData dont signal error

a or not. Effectively these were silent failures. Sorry I can't provide more information but I do appreciate your time. If you can't get any further with it I understand and don't expect another reply. Regards, Steve K. -- View this message in context: http://postgresq

Re: [HACKERS] PQputCopyData dont signal error

te public embarassment. Maybe others will get something too. It's how we all get ahead. At any rate, thanks for your time and I look forward to what you find. Steve K. -- View this message in context: http://postgresql.1045698.n5.nabble.com/PQputCopyData-dont-signal-error-tp4302

Re: [HACKERS] PQputCopyData dont signal error

. Thanks again for the suggestion and I'll definitely keep PGLoader in mind as things unfold here on this project. Best Regards, Steve K. -- View this message in context: http://postgresql.1045698.n5.nabble.com/PQputCopyData-dont-signal-error-tp4302340p5798038.html Sent from th

Re: [HACKERS] PQputCopyData dont signal error

allow for notification if some of the data contained within for some reason fails to copy/insert so that the cause of the bad data can be examined and remedied as soon as it occurs as well as writing the offending data to a log so that not all of it is lost. Regards, Steve K. -- View this

Re: [HACKERS] PQputCopyData dont signal error

gards to everyone and thank you all for your time, Steve K. -- View this message in context: http://postgresql.1045698.n5.nabble.com/PQputCopyData-dont-signal-error-tp4302340p5798002.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers

Re: [HACKERS] PQputCopyData dont signal error

shutdowns etc...) I haven't tried using inserts yet with multiple "values" clauses but have read this is possible. However, once the planner gets involved, speed drops noticeably. Thanks to everyone for their time or any feedback. Regards, Steve K. -- View this message in

Re: [HACKERS] QSoC proposal: date_trunc supporting intervals

data when you convert to an interval that you can’t get back)? Subtracting to get an interval, then converting that interval to seconds or minutes could give you a value that’s wildly different from the right answer. Cheers, Steve -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Documentation patch for to_date and to_timestamp

27;) returns 2014-01-17 rather than generating an error. Cheers, Steve diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml index c76d357..19197ce 100644 --- a/doc/src/sgml/func.sgml +++ b/doc/src/sgml/func.sgml @@ -5426,7 +5426,7 @@ SELECT SUBSTRING('XY1234Z', 'Y*

Re: [HACKERS] In-core regression tests for replication, cascading, archiving, PITR, etc. Michael Paquier

On 01/05/2014 09:13 PM, Michael Paquier wrote: On Mon, Jan 6, 2014 at 4:51 AM, Mark Dilger > wrote: > I am building a regression test system for replication and came across > this email thread. I have gotten pretty far into my implementation, but > would be happy

Re: [HACKERS] plpgsql_check_function - rebase for 9.3

I don't think that I will have a lot more time in the next week to do a more thorough review or follow-up review If we aren't happy with the overal approach of this patch then we need to tell Pavel. My vote would be to try to get the patch (documentation, error messages, &

Re: [HACKERS] Replication Node Identifiers and crashsafe Apply Progress

On 11/14/2013 12:26 PM, Andres Freund wrote: Hello, As you know, the reason we are working changeset extraction is that we want to build logical unidirection and bidirectional replication ontop. To use changeset extraction effectively, I think one set of related features ontop is very useful: W

Re: [HACKERS] logical changeset generation v6.5

On 11/11/2013 02:06 PM, Andres Freund wrote: On 2013-11-10 14:45:17 -0500, Steve Singer wrote: Not really keen - that'd be a noticeable overhead. Note that in the cases where DEFAULT|INDEX is used, you can just use the new tuple to extract what you need for the pkey lookup since they now

Re: [HACKERS] logical changeset generation v6.5

On 11/10/2013 09:41 AM, Andres Freund wrote: Still give me the following: update disorder.do_inventory set ii_in_stock=2 where ii_id=251; UPDATE 1 test1=# LOG: tuple in table with oid: 35122 without primary key Hm. Could it be that you still have an older "test_decoding" plugin lying around? Th

  1   2   3   4   5   6   >