Re: [HACKERS] Proposal for changes to recovery.conf API

On Thu, Sep 1, 2016 at 1:15 AM, Simon Riggs wrote: > This is a summary of proposed changes to the recovery.conf API for > v10. These are based in part on earlier discussions, and represent a > minimal modification to current usage. > > Proposed changes (with reference to

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 1 September 2016 at 13:08, Craig Ringer wrote: > On 29 August 2016 at 15:53, Craig Ringer wrote: > >> Said better approach attached in revised series. Thanks. > > Here's another minor update to the txid_status() and > txid_convert_if_recent()

Re: [HACKERS] WAL consistency check facility

On Thu, Sep 1, 2016 at 9:43 AM, Peter Geoghegan wrote: > On Wed, Aug 31, 2016 at 8:26 PM, Amit Kapila wrote: >>> As far as I am understanding things, we are aiming at something that >>> could be used on production systems. >>> >> >> I don't think you can

Re: [HACKERS] Declarative partitioning - another take

On 2016/08/25 16:15, Ashutosh Bapat wrote: > On Thu, Aug 25, 2016 at 12:22 PM, Amit Langote wrote: >> b) >> when accumulating append subpaths, do not flatten a subpath that is itself >> an append when ((AppendPath *) subpath)->path.parent is a RelOptInfo with >> non-NULL partitioning info.Is the

Re: [HACKERS] [PATCH] Transaction traceability - txid_status(bigint)

On 29 August 2016 at 15:53, Craig Ringer wrote: > Said better approach attached in revised series. Thanks. Here's another minor update to the txid_status() and txid_convert_if_recent() patches. The only change is moving get_xid_in_recent_past from

[HACKERS] Re: [COMMITTERS] pgsql: Add putenv support for msvcrt from Visual Studio 2013

On Wed, Apr 27, 2016 at 2:39 AM, Christian Ullrich wrote: > * Christian Ullrich wrote: > >> wrong even without considering the debug/release split. If we load a >> compiled extension built with a CRT we have not seen yet, _after_ the >> first call to pgwin32_putenv(), that

[HACKERS] pg_recvlogical --endpos

Hi all Here's a rebased version of my pg_recvlogical --endpos patch from the 9.5 series, updated to incoroprate Álvaro's changes. This will be mainly useful for recovery tests as we start adding more logical decoding testing. See original post for more detail:

Re: [HACKERS] WAL consistency check facility

On Wed, Aug 31, 2016 at 8:26 PM, Amit Kapila wrote: >> As far as I am understanding things, we are aiming at something that >> could be used on production systems. >> > > I don't think you can enable it by default in production systems. > Enabling it will lead to

[HACKERS] [PATCH] Logical decoding timeline following take II

Hi all Attached is a rebased and updated logical decoding timeline following patch for 10.0. This is a pre-requisite for the pending work on logical decoding on standby servers and simplified failover of logical decoding. Restating the commit message: __ Follow timeline switches in

Re: [HACKERS] WAL consistency check facility

On Thu, Sep 1, 2016 at 8:02 AM, Amit Kapila wrote: > On Wed, Aug 31, 2016 at 7:02 PM, Simon Riggs wrote: >> On 27 August 2016 at 12:09, Kuntal Ghosh wrote: >> > * wal_consistency_mask = 511 /* Enable consistency

Re: [HACKERS] WAL consistency check facility

On Thu, Sep 1, 2016 at 8:30 AM, Michael Paquier wrote: > On Thu, Sep 1, 2016 at 11:32 AM, Amit Kapila wrote: >> On Wed, Aug 31, 2016 at 7:02 PM, Simon Riggs wrote: >>> On 27 August 2016 at 12:09, Kuntal Ghosh

Re: [HACKERS] WAL consistency check facility

On Thu, Sep 1, 2016 at 11:32 AM, Amit Kapila wrote: > On Wed, Aug 31, 2016 at 7:02 PM, Simon Riggs wrote: >> On 27 August 2016 at 12:09, Kuntal Ghosh wrote: >> > * wal_consistency_mask = 511 /* Enable consistency

Re: [HACKERS] Missing checks when malloc returns NULL...

On Thu, Sep 1, 2016 at 12:14 AM, Tom Lane wrote: > I still think it'd be better to fix that as attached, because it > represents a net reduction not net addition of code, and it provides > a defense against future repetitions of the same omission. If only > 4 out of 11

Re: [HACKERS] WAL consistency check facility

On Wed, Aug 31, 2016 at 7:02 PM, Simon Riggs wrote: > On 27 August 2016 at 12:09, Kuntal Ghosh wrote: > * wal_consistency_mask = 511 /* Enable consistency check mask bit*/ >>> >>> What does this mean? (No docs) >> >> I was using this

Re: [HACKERS] Replace use malloc() & friend by memory contexts for plperl and pltcl

On Thu, Sep 1, 2016 at 8:57 AM, Tom Lane wrote: > I wrote: >> Michael Paquier writes: >>> Attached are a set of patches to replace those memory system calls by >>> proper memory contexts: >>> - 0001 does the cleanup work for pltcl >>> - 0002 does

[HACKERS] restoration after crash slowness, any way to improve?

-hackers, So this is more of a spit balling thread than anything. As I understand it, if we have a long running transaction or a large number of wal logs and we crash, we then have to restore those logs on restart to the last known good transaction. No problem. I recently ran a very long

Re: [HACKERS] Replace use malloc() & friend by memory contexts for plperl and pltcl

I wrote: > Michael Paquier writes: >> Attached are a set of patches to replace those memory system calls by >> proper memory contexts: >> - 0001 does the cleanup work for pltcl >> - 0002 does this cleanup for plperl > Off to look at 0002 next. Pushed 0002 as well.

Re: [HACKERS] Logical Replication WIP

On 2016-08-31 22:51, 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. Clear, well-written docs, thanks. Here are some small changes to logical-replication.sgml

Re: [HACKERS] Notice lock waits

On Tue, Aug 9, 2016 at 5:17 PM, Jim Nasby wrote: > On 8/5/16 12:00 PM, Jeff Janes wrote: > >> So I created a new guc, notice_lock_waits, which acts like >> log_lock_waits but sends the message as NOTICE so it will show up on >> interactive connections like psql. >> > >

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Wed, Aug 31, 2016 at 6:07 PM, Andres Freund wrote: > > In my experience pg attribute is usually the worst affected. Many tech > takes won't even have stays entries... > > Mine too. One database currently has a 400GB pg_attribute table, because we chew through temp tables

Re: [HACKERS] _mdfd_getseg can be expensive

On Wed, Aug 31, 2016 at 3:08 PM, Andres Freund wrote: > On August 31, 2016 3:06:23 PM PDT, Peter Geoghegan wrote: > >>In other painfully pedantic news, I should point out that >>sizeof(size_t) isn't necessarily word size (the most generic >>definition of word

Re: [HACKERS] autonomous transactions

On 08/31/2016 03:09 PM, Joel Jacobson wrote: > On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova > wrote: >> >> On 30 August 2016 at 23:10, Joel Jacobson wrote: >>> >>> There should be a way to within the session and/or txn permanently >>> block

Re: [HACKERS] _mdfd_getseg can be expensive

On August 31, 2016 3:06:23 PM PDT, Peter Geoghegan wrote: >In other painfully pedantic news, I should point out that >sizeof(size_t) isn't necessarily word size (the most generic >definition of word size for the architecture), contrary to my reading >of the 0002-* patch

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On August 31, 2016 3:00:15 PM PDT, Tomas Vondra wrote: > > >On 08/31/2016 11:43 PM, Andres Freund wrote: >> On 2016-08-31 23:40:46 +0200, Tomas Vondra wrote: >>> It's an improvement (and it's pretty much exactly what I proposed >>> upthread). But it does not solve

Re: [HACKERS] _mdfd_getseg can be expensive

On Wed, Aug 31, 2016 at 2:37 PM, Andres Freund wrote: >> This looks good. > > Thanks for looking! No problem. In other painfully pedantic news, I should point out that sizeof(size_t) isn't necessarily word size (the most generic definition of word size for the architecture),

Re: [HACKERS] WAL consistency check facility

On Wed, Aug 31, 2016 at 10:32 PM, Simon Riggs wrote: > On 27 August 2016 at 12:09, Kuntal Ghosh wrote: > * wal_consistency_mask = 511 /* Enable consistency check mask bit*/ >>> >>> What does this mean? (No docs) >> >> I was using this

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 08/31/2016 11:43 PM, Andres Freund wrote: > On 2016-08-31 23:40:46 +0200, Tomas Vondra wrote: >> It's an improvement (and it's pretty much exactly what I proposed >> upthread). But it does not solve the problems with pg_statistic for >> example (each backend needs it's own statistics. So we'd

[HACKERS] pg_basebackup stream xlog to tar

Attached patch adds support for -X stream to work with .tar and .tar.gz file formats. If tar mode is specified, a separate pg_xlog.tar (or .tar.gz) file is created and the data is streamed into it. Regular mode is (should not) see any changes in how it works. The implementation creates a

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 2016-08-31 23:40:46 +0200, Tomas Vondra wrote: > It's an improvement (and it's pretty much exactly what I proposed > upthread). But it does not solve the problems with pg_statistic for > example (each backend needs it's own statistics. So we'd either bloat > the pg_statistic (if we manage to

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 08/31/2016 09:20 PM, Vik Fearing wrote: > On 08/24/2016 06:16 PM, Robert Haas wrote: >> On Tue, Aug 23, 2016 at 6:11 PM, Tomas Vondra >> wrote: >>> Could someone please explain how the unlogged tables are supposed to fix the >>> catalog bloat problem, as stated

Re: [HACKERS] _mdfd_getseg can be expensive

On 2016-08-31 14:09:47 -0700, Peter Geoghegan wrote: > On Thu, Aug 18, 2016 at 5:26 PM, Andres Freund wrote: > > Rebased version attached. A review would be welcome. Plan to push this > > forward otherwise in the not too far away future. > > This looks good. Thanks for

Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

On Sun, Nov 22, 2015 at 7:29 PM, Andreas Karlsson wrote: > Sorry for dropping this patch, but now I have started looking at it again. Any chance of picking this up again soon, Andreas? I think it's an important project. I would like to review it. -- Peter Geoghegan --

Re: [HACKERS] Replace use malloc() & friend by memory contexts for plperl and pltcl

Michael Paquier writes: > Cleanup $subject has been raised a couple of times, like one year ago here: > https://www.postgresql.org/message-id/cab7npqrxvq+q66ufzd9wa5uaftyn4wauadbjxkfrync96kf...@mail.gmail.com > And more recently here while working on the NULL checks for

Re: [HACKERS] _mdfd_getseg can be expensive

On Wed, Aug 31, 2016 at 2:09 PM, Peter Geoghegan wrote: > The only thing that stuck out to any degree is that we don't grow the > "reln->md_seg_fds[forknum]" array within the new _fdvec_resize() > function geometrically. That new function looks like this: > +static void >

Re: [HACKERS] _mdfd_getseg can be expensive

On Thu, Aug 18, 2016 at 5:26 PM, Andres Freund wrote: > Rebased version attached. A review would be welcome. Plan to push this > forward otherwise in the not too far away future. This looks good. The only thing that stuck out to any degree is that we don't grow the

Re: [HACKERS] delta relations in AFTER triggers

I have merged in the changes since v4 (a year and a half ago) and cured all bit-rot I found, to get the attached v5 which runs `make check world` without problem -- including the tests added for this feature. I did remove the contrib code that David Fetter wrote to demonstrate the correctness and

Re: [HACKERS] ICU integration

Hi all. I’m new to the PostgreSQL code and the mailing list, but I’ve had a lot of experience with using ICU in a different database product. So while I’m not up to speed on the code yet, I can offer some insights on using ICU. > On Aug 30, 2016, at 9:12 PM, Peter Eisentraut >

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Wed, Aug 31, 2016 at 04:03:29PM -0400, Bruce Momjian wrote: > Why not just remember the tid of chains converted from WARM to HOT, then > use "amrecheck" on an index entry matching that tid to see if the index > matches one of the entries in the chain. (It will match all of them or > none of

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Wed, Aug 31, 2016 at 10:15:33PM +0530, Pavan Deolasee wrote: > Instead, what I would like to propose and the patch currently implements is to > restrict WARM update to once per chain. So the first non-HOT update to a tuple > or a HOT chain can be a WARM update. The chain can further be HOT

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On 08/24/2016 06:16 PM, Robert Haas wrote: > On Tue, Aug 23, 2016 at 6:11 PM, Tomas Vondra > wrote: >> Could someone please explain how the unlogged tables are supposed to fix the >> catalog bloat problem, as stated in the initial patch submission? We'd still >> need

Re: [HACKERS] Proposal for changes to recovery.conf API

At 2016-08-31 17:15:59 +0100, si...@2ndquadrant.com wrote: > > * Recovery parameters would now be part of the main postgresql.conf > infrastructure > Any parameters set in $DATADIR/recovery.conf will be read after the > main parameter file, similar to the way that postgresql.conf.auto is > read. >

Re: [HACKERS] autonomous transactions

> On Aug 31, 2016, at 6:46 AM, Greg Stark wrote: > > Using a background worker mean that the autonomous transaction can't > access any state from the process memory. Parameters in plpgsql are a > symptom of this but I suspect there will be others. What happens if a > statement

Re: [HACKERS] pg_sequence catalog

On 2016-08-31 14:23:41 -0400, Tom Lane wrote: > Andres Freund writes: > > On 2016-08-31 13:59:48 -0400, Tom Lane wrote: > >> You are ignoring the performance costs associated with eating 100x more > >> shared buffer space than necessary. > > > I doubt that's measurable in any

Re: [HACKERS] pg_sequence catalog

Andres Freund writes: > On 2016-08-31 13:59:48 -0400, Tom Lane wrote: >> You are ignoring the performance costs associated with eating 100x more >> shared buffer space than necessary. > I doubt that's measurable in any real-world scenario. You seldomly have > hundreds of

Re: [HACKERS] [Patch] Temporary tables that do not bloat pg_catalog (a.k.a fast temp tables)

On Wed, Aug 24, 2016 at 12:39 PM, Andres Freund wrote: > > > On August 24, 2016 9:32:48 AM PDT, Tomas Vondra < > tomas.von...@2ndquadrant.com> wrote: > > > > > >On 08/24/2016 12:20 AM, Andres Freund wrote: > >> On 2016-08-23 19:18:04 -0300, Claudio Freire wrote: > >>> On Tue,

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Wed, Aug 31, 2016 at 10:38 PM, Claudio Freire wrote: > > On Wed, Aug 31, 2016 at 1:45 PM, Pavan Deolasee > wrote: > >> We discussed a few ideas to address the "Duplicate Scan" problem. For >> example, we can teach Index AMs to discard any

Re: [HACKERS] pg_sequence catalog

On 2016-08-31 13:59:48 -0400, Tom Lane wrote: > and...@anarazel.de (Andres Freund) writes: > > On 2016-08-31 14:25:43 -0300, Alvaro Herrera wrote: > >> Yes, sure, we're still improving even if we stick to one-seq-per-bufpage, > >> but while we're at it, we could as well find a way to make it as

Re: [HACKERS] pg_sequence catalog

and...@anarazel.de (Andres Freund) writes: > On 2016-08-31 14:25:43 -0300, Alvaro Herrera wrote: >> Yes, sure, we're still improving even if we stick to one-seq-per-bufpage, >> but while we're at it, we could as well find a way to make it as best as >> we can. And allowing multiple seqs per page

Re: [HACKERS] [COMMITTERS] pgsql: Use static inline functions for float <-> Datum conversions.

Heikki Linnakangas writes: > On 08/31/2016 08:27 PM, Tom Lane wrote: >> We had a bunch of similar problems in the recent work on exact degree trig >> functions, and eventually found that storing values into volatile float8 >> variables was the most reliable way to force rounding

Re: [HACKERS] ICU integration

On Tue, Aug 30, 2016 at 7:46 PM, Peter Eisentraut wrote: > In initdb, I initialize the default collation set as before from the > `locale -a` output, but also add all available ICU locales with a "%icu" > appended (so "fr_FR%icu"). I suppose one could create a

[HACKERS] Re: [COMMITTERS] pgsql: Use static inline functions for float <-> Datum conversions.

On 08/31/2016 08:27 PM, Tom Lane wrote: Heikki Linnakangas writes: Use static inline functions for float <-> Datum conversions. Hmm, it looks like narwhal for one is not happy with this:

Re: [HACKERS] ICU integration

On Tue, Aug 30, 2016 at 7:46 PM, Peter Eisentraut wrote: > Here is a patch I've been working on to allow the use of ICU for sorting > and other locale things. I'm really happy that you're working on this. This is more important than is widely appreciated, and

Re: [HACKERS] [COMMITTERS] pgsql: Use static inline functions for float <-> Datum conversions.

Heikki Linnakangas writes: > Use static inline functions for float <-> Datum conversions. Hmm, it looks like narwhal for one is not happy with this: http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=narwhal=2016-08-31%2016%3A00%3A03 I suspect the failure traces

Re: [HACKERS] pg_sequence catalog

On 2016-08-31 14:25:43 -0300, Alvaro Herrera wrote: > Andres Freund wrote: > > Hi, > > > > On 2016-08-31 12:53:30 -0400, Tom Lane wrote: > > > Improving on the space wastage is exactly the point IMO. If it's still > > > going to be 8k per sequence on disk (*and* in shared buffers, remember), > >

Re: [HACKERS] pg_sequence catalog

Andres Freund wrote: > Hi, > > On 2016-08-31 12:53:30 -0400, Tom Lane wrote: > > Improving on the space wastage is exactly the point IMO. If it's still > > going to be 8k per sequence on disk (*and* in shared buffers, remember), > > I'm not sure it's worth all the work to change things at all. >

Re: [HACKERS] pg_sequence catalog

Hi, On 2016-08-31 12:53:30 -0400, Tom Lane wrote: > Improving on the space wastage is exactly the point IMO. If it's still > going to be 8k per sequence on disk (*and* in shared buffers, remember), > I'm not sure it's worth all the work to change things at all. A separate file is a heck lot

Re: [HACKERS] Patch: Write Amplification Reduction Method (WARM)

On Wed, Aug 31, 2016 at 1:45 PM, Pavan Deolasee wrote: > We discussed a few ideas to address the "Duplicate Scan" problem. For > example, we can teach Index AMs to discard any duplicate (key, CTID) insert > requests. Or we could guarantee uniqueness by either only

Re: [HACKERS] autonomous transactions

On Wed, Aug 31, 2016 at 3:11 PM, Craig Ringer wrote: > > I suspect that there'll be way too much code that relies on stashing > xact-scoped stuff in globals for that to be viable. Caches alone. > Peter will be able to explain more, I'm sure. > > We'd probably need a new

Re: [HACKERS] pg_sequence catalog

Andres Freund writes: > On 2016-08-31 12:56:45 -0300, Alvaro Herrera wrote: >> I was thinking that nextval could grab a shared buffer lock and release >> immediately, just to ensure no one holds exclusive buffer lock >> concurrently (which would be used for things like

Re: [HACKERS] proposal: psql \setfileref

2016-08-31 18:24 GMT+02:00 Corey Huinker : > On Wed, Aug 31, 2016 at 11:32 AM, Pavel Stehule > wrote: > >> Hi >> >> I propose a new type of psql variables - file references. The content of >> file reference is specified by referenced file. It

Re: [HACKERS] autonomous transactions

On 31 August 2016 at 14:09, Joel Jacobson wrote: > On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova > wrote: >> >> On 30 August 2016 at 23:10, Joel Jacobson wrote: >> > >> > There should be a way to within the session and/or txn

Re: [HACKERS] proposal: psql \setfileref

On Wed, Aug 31, 2016 at 11:32 AM, Pavel Stehule wrote: > Hi > > I propose a new type of psql variables - file references. The content of > file reference is specified by referenced file. It allows simple inserting > large data without necessity of manual escaping or

Re: [HACKERS] pg_sequence catalog

On 2016-08-31 12:56:45 -0300, Alvaro Herrera wrote: > I was thinking that nextval could grab a shared buffer lock and release > immediately, just to ensure no one holds exclusive buffer lock > concurrently (which would be used for things like dropping one seq tuple > from the page, when a sequence

[HACKERS] Proposal for changes to recovery.conf API

This is a summary of proposed changes to the recovery.conf API for v10. These are based in part on earlier discussions, and represent a minimal modification to current usage. Proposed changes (with reference to patches from Abhijit Menon-Sen and myself) * pg_ctl start -M

Re: [HACKERS] Optimizing aggregates

On 2016-08-31 19:07:00 +0300, Heikki Linnakangas wrote: > On 08/31/2016 06:51 PM, Andres Freund wrote: > > I've first combined the projection for all the aggregates, ordered set, > > or not, into one projetion. That got rid of a fair amount of overhead > > when you have multiple aggregates. I

Re: [HACKERS] Optimizing aggregates

On 08/31/2016 06:51 PM, Andres Freund wrote: On 2016-08-31 17:47:18 +0300, Heikki Linnakangas wrote: We actually used to call ExecEvalExpr() directly for each argument, but that was changed by the patch that added support for ordered set aggregates. It looks like that was a bad idea, from a

Re: [HACKERS] pg_sequence catalog

Andres Freund wrote: > On 2016-08-31 11:23:27 -0400, Tom Lane wrote: > > Another issue is what is the low-level interlock between nextvals > > in different processes. Right now it's the buffer lock on the > > sequence's page. With a scheme like this, if we just kept doing > > that, we'd have a

Re: [HACKERS] Optimizing aggregates

Hi, On 2016-08-31 17:47:18 +0300, Heikki Linnakangas wrote: > # .. . > > # > 25.70% 0.00% postmaster [unknown] [k] > 14.23%13.75% postmaster postgres [.]

Re: [HACKERS] pg_sequence catalog

On 2016-08-31 11:23:27 -0400, Tom Lane wrote: > Another issue is what is the low-level interlock between nextvals > in different processes. Right now it's the buffer lock on the > sequence's page. With a scheme like this, if we just kept doing > that, we'd have a single lock covering probably

[HACKERS] proposal: psql \setfileref

Hi I propose a new type of psql variables - file references. The content of file reference is specified by referenced file. It allows simple inserting large data without necessity of manual escaping or using LO api. When I wrote the patch, I used parametrized queries for these data instead

Re: [HACKERS] pg_sequence catalog

Craig Ringer writes: > On 31 August 2016 at 22:01, Tom Lane wrote: >> Personally, my big beef with the current approach to sequences is that >> we eat a whole relation (including a whole relfilenode) per sequence. >> I wish that we could reduce a

Re: [HACKERS] Missing checks when malloc returns NULL...

Michael Paquier writes: > Which means that processes have an escape window when initializing > shared memory by cleaning up the index if an entry cannot be found and > then cannot be created properly. I don't think that it is a good idea > to change that by forcing

Re: [HACKERS] [GENERAL] C++ port of Postgres

[trimmed cc list because of big attachments] On 8/16/16 4:22 PM, Jim Nasby wrote: > Joy, do you have an idea what a *minimally invasive* patch for C++ > support would look like? That's certainly the first step here. I developed a minimally invasive patch for C++ support a few years ago shortly

[HACKERS] less expensive pg_buffercache on big shmem

Hi hackers, Recently I have finished my work on a patch for pg_buffercache contrib, I think it's time to share my results. Introduction I want to offer you the implementation that allows to decrease system workload by partially sacrificing (fully snapshot consistency) data

Re: [HACKERS] make async slave to wait for lsn to be replayed

On 31 August 2016 at 22:16, Ivan Kartyshov wrote: > Our clients who deal with 9.5 and use asynchronous master-slave replication, > asked to make the wait-mechanism on the slave side to prevent the situation > when slave handles query which needs data (LSN) that was

Re: [HACKERS] autonomous transactions

On 31/08/16 16:11, Craig Ringer wrote: On 31 August 2016 at 21:46, Greg Stark wrote: On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut wrote: - A API interface to open a "connection" to a background worker, run queries, get results:

[HACKERS] Optimizing aggregates

I've been profiling simple aggregate queries, looking for any low-hanging fruit. For this query: -- setup create table floats as select g::float8 as a, g::float8 as b, g::float8 as c from generate_series(1, 1000) g; vacuum freeze floats; -- query select sum(a), sum(b+c) from floats;

Re: [HACKERS] some requests on auditing

2016-08-31 16:00 GMT+02:00 David Steele : > On 8/31/16 9:39 AM, David Steele wrote: > >> On 8/30/16 10:12 AM, Pavel Stehule wrote: >> > > #3 is not likely without changes to logging in Postgres. However, there >> are plenty of tools for log analysis (e.g. ELK) that might

Re: [HACKERS] pg_sequence catalog

On 31/08/16 16:10, Tom Lane wrote: I wrote: Personally, my big beef with the current approach to sequences is that we eat a whole relation (including a whole relfilenode) per sequence. I wish that we could reduce a sequence to just a single row in a catalog, including the nontransactional

Re: [HACKERS] pg_sequence catalog

On 31 August 2016 at 22:01, Tom Lane wrote: > Personally, my big beef with the current approach to sequences is that > we eat a whole relation (including a whole relfilenode) per sequence. > I wish that we could reduce a sequence to just a single row in a > catalog, including

[HACKERS] make async slave to wait for lsn to be replayed

Hi hackers, Few days earlier I've finished my work on WAITLSN statement utility, so I’d like to share it. Introduction Our clients who deal with 9.5 and use asynchronous master-slave replication, asked to make the wait-mechanism on the slave side to prevent the situation when

Re: [HACKERS] INSERT .. SET syntax

Hello hello, Here's a rebased and updated patch for $SUBJECT for the September commit fest. .m *** a/doc/src/sgml/ref/insert.sgml --- b/doc/src/sgml/ref/insert.sgml *** *** 22,33 PostgreSQL documentation [ WITH [ RECURSIVE ] with_query [, ...] ] ! INSERT INTO

Re: [HACKERS] autonomous transactions

On 31 August 2016 at 21:46, Greg Stark wrote: > On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut > wrote: >> - A API interface to open a "connection" to a background worker, run >> queries, get results: AutonomousSessionStart(),

Re: [HACKERS] pg_sequence catalog

I wrote: > Personally, my big beef with the current approach to sequences is that > we eat a whole relation (including a whole relfilenode) per sequence. > I wish that we could reduce a sequence to just a single row in a > catalog, including the nontransactional state. Not sure how feasible >

Re: [HACKERS] Leftover member in openssl part of Port struct

> On 31 Aug 2016, at 15:12, Tom Lane wrote: > > Daniel Gustafsson writes: >> When SSL renegotiation was removed in 426746b9 the only consumer of the >> openssl >> specific count member in the Port struct was removed, but the member was left >> together

Re: [HACKERS] pg_sequence catalog

Craig Ringer writes: > On 31 August 2016 at 21:17, Peter Eisentraut > wrote: >> I don't know if this is a net improvement. Maybe this introduces as >> many new issues as it removes. But I figured I'll post this, so that at >> least we

Re: [HACKERS] some requests on auditing

On 8/31/16 9:39 AM, David Steele wrote: On 8/30/16 10:12 AM, Pavel Stehule wrote: #3 is not likely without changes to logging in Postgres. However, there are plenty of tools for log analysis (e.g. ELK) that might help and a Postgres extension that allows log messages to be directed elsewhere

Re: [HACKERS] autonomous transactions

On Wed, Aug 31, 2016 at 2:50 AM, Peter Eisentraut wrote: > - A API interface to open a "connection" to a background worker, run > queries, get results: AutonomousSessionStart(), AutonomousSessionEnd(), > AutonomousSessionExecute(), etc. The communication happens

Re: [HACKERS] Use static inline functions for Float <-> Datum conversions

Heikki Linnakangas writes: > On 08/31/2016 02:38 PM, Tom Lane wrote: >> I wonder whether there is a compiler-dependent way of avoiding the union >> trick ... or maybe gcc is already smart enough that it doesn't matter? > It seems to compile into a single instruction, so it can't

Re: [HACKERS] pg_sequence catalog

On 31 August 2016 at 21:17, Peter Eisentraut wrote: > While I was hacking around sequence stuff, I felt the urge to look into > an old peeve: That sequence metadata is not stored in a proper catalog. > Right now in order to find out some metadata about sequences

Re: [HACKERS] some requests on auditing

On 8/30/16 10:12 AM, Pavel Stehule wrote: I am working on pgaudit customization for one my customer. There are few requests: 1. flat format without complex types, without nesting - CSV is ideal. 2. all important attributes should be separated - is not possible to search in original queries:

Re: [HACKERS] WAL consistency check facility

On 27 August 2016 at 12:09, Kuntal Ghosh wrote: >>> * wal_consistency_mask = 511 /* Enable consistency check mask bit*/ >> >> What does this mean? (No docs) > > I was using this parameter as a masking integer to indicate the > operations(rmgr list) for which we need

Re: [HACKERS] autonomous transactions

2016-08-31 15:09 GMT+02:00 Joel Jacobson : > On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova > wrote: > > > > On 30 August 2016 at 23:10, Joel Jacobson wrote: > > > > > > There should be a way to within the session and/or txn

Re: [HACKERS] [COMMITTERS] pgsql: Fix pg_receivexlog --synchronous

On 29 August 2016 at 12:34, Tom Lane wrote: > Simon Riggs writes: >> Fix pg_receivexlog --synchronous > > The buildfarm says you broke the 9.5 branch. > > In general, pushing inessential patches just a few hours before a wrap > deadline is a dangerous

[HACKERS] pg_sequence catalog

While I was hacking around sequence stuff, I felt the urge to look into an old peeve: That sequence metadata is not stored in a proper catalog. Right now in order to find out some metadata about sequences (min, max, increment, etc.), you need to look into the sequence. That is like having to

Re: [HACKERS] Exclude schema during pg_restore

Hi, Am Mittwoch, den 31.08.2016, 07:59 -0300 schrieb Fabrízio de Royes Mello: > Please add it to the next open commitfest. I had done so already: https://commitfest.postgresql.org/10/762/ Regards, Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49

Re: [HACKERS] Leftover member in openssl part of Port struct

Daniel Gustafsson writes: > When SSL renegotiation was removed in 426746b9 the only consumer of the > openssl > specific count member in the Port struct was removed, but the member was left > together with a few updates to it which are unused. Attached patch removes > the >

Re: [HACKERS] autonomous transactions

On Wed, Aug 31, 2016 at 6:41 AM, Jaime Casanova wrote: > > On 30 August 2016 at 23:10, Joel Jacobson wrote: > > > > There should be a way to within the session and/or txn permanently > > block autonomous transactions. > > > > This will defeat one

Re: [HACKERS] [WIP] Patches to enable extraction state of query execution from external session

On 2016-08-30 11:22:43 +0300, Maksim Milyutin wrote: Hi, On 2016-08-29 18:22:56 +0300, maksim wrote: Now I complete extension that provides facility to see the current state of query execution working on external session in form of EXPLAIN ANALYZE output. This extension works on 9.5 version,

Re: [HACKERS] standalone backend PANICs during recovery

Michael Paquier writes: > On Tue, Aug 30, 2016 at 11:00 PM, Tom Lane wrote: >> Thinking about it some more ... what we actually need to prevent, AFAICS, >> is standby_mode becoming true in a standalone backend. > I have spent some time playing with

  1   2   >