Added a fix for src/backend/storage/ipc/shm_mq.c:shm_mq_receive.
commit 936c7268b61460deb201b9e6bbfb60ab5258ec87
Author: Piotr Stefaniak
Date: Thu Apr 28 18:35:43 2016 +0200
Don't pass null pointers to functions that require the pointers to be non null.
diff --git a/contrib/pgcrypto/px.c
On Sun, May 1, 2016 at 10:24 AM, Yury Zhuravlev
wrote:
> zeray87 wrote:
>>
>> Hello guys,
>> This is my first ever post and here goes my apology for being newbie.
>>
>> I have been able to build PgAdmin3 after several days of hassle on
>> building
>> PgAdmin3 using build-wxmsw.bat.
>
>
> If I rem
On Sat, Apr 30, 2016 at 8:11 AM, zeray87 wrote:
> Hello guys,
> This is my first ever post and here goes my apology for being newbie.
>
> I have been able to build PgAdmin3 after several days of hassle on building
> PgAdmin3 using build-wxmsw.bat.
>
> Now i am trying to build PgAdmin3 using Visua
With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
bitmap
to represent what to include. With this commit if non-super user is unable
to perform the dump.
Consider the below testcase:
postgres=# select version();
version
--
Hi all,
How postgresql handles full table delete in terms of loading the full
table in these scenarios
consider one big table(tablename: bigtable)
and the query will be >> delete from bigtable;
1)which doesn't have any foreign table reference with any other tables
2)And when this
On 05/02/2016 10:56 PM, Robert Haas wrote:
I spent some time going through the output of a trial pgindent run
today. Some questions/problems:
1. Is pgindent supposed to touch DATA() lines? Because it does.
Apart from being detabbed/entabbed, no. pgindent protects (or tries to
protect) DA
On Mon, May 2, 2016 at 7:36 AM, Robert Haas wrote:
> On Wed, Apr 27, 2016 at 7:07 AM, Anastasia Lubennikova
> wrote:
>> Hi, hackers.
>> There's a couple of questions about processes.
>>
>> I found EXEC_BACKEND flag, while reading the code.
>> As I understood, it exists because we have to emulate
Robert Haas writes:
> 1. Is pgindent supposed to touch DATA() lines? Because it does.
It always has.
> 2. CustomPathMethods is not in the buildfarm's typedefs.list. Why not?
Probably because there are no variables, parameters, or fields declared
with that typedef, so it doesn't get into the d
Does anyone else have a Windows 7 installation we can test this on ?
This
https://github.com/postgres-plr/plr/files/191013/plr-8.3.0.16-pg9.5-win32.zip
is actually a 64 bit version built on windows 10. I've had one confirmation
that it works.
Dave
Dave Cramer
da...@postgresintl.com
www.postgres
Hi all
There's a bug (mine) in logical decoding timeline following where reading
the first page from the segment containing a timeline switch fails to read
from the most recent timeline in that segment. This is harmless if the old
timeline's copy of the segment is present - but if it's been rename
On Tue, May 3, 2016 at 6:48 AM, Andres Freund wrote:
> Hi,
>
> The freeze map changes, besides being very important, seem to be one of
> the patches with a high risk profile in 9.6. Robert had asked whether
> I'd take a look. I thought it'd be a good idea to review that while
> running tests for
Hi,
On 04/30/2016 07:35 PM, Tom Lane wrote:
Julien Rouhaud writes:
On 29/04/2016 18:05, Tom Lane wrote:
Julien Rouhaud writes:
The segfault is caused by quals_match_foreign_key() calling get_leftop()
and get_rightop() on a ScalarArrayOpExpr node.
I'm not sure that assuming this compatibili
Hi,
On 05/02/2016 09:18 PM, Robert Haas wrote:
On Sat, Apr 30, 2016 at 1:35 PM, Tom Lane wrote:
Julien Rouhaud writes:
On 29/04/2016 18:05, Tom Lane wrote:
Julien Rouhaud writes:
The segfault is caused by quals_match_foreign_key() calling get_leftop()
and get_rightop() on a ScalarArrayOpE
On 3 May 2016 at 22:03, Craig Ringer wrote:
> A corrected and handily much, much simpler patch is attached. The logic
> for finding the last timeline on a segment was massively more complex than
> it needed to be, and that wasn't the only thing.
>
I'm aware that this is late in the piece, btw,
On Tue, May 3, 2016 at 5:51 AM, hari.prasath
wrote:
> Hi all,
> How postgresql handles full table delete in terms of loading the
> full table in these scenarios
>
> consider one big table(tablename: bigtable)
> and the query will be >> delete from bigtable;
>
> 1)which doesn't have any fore
On 3 May 2016 at 21:37, Merlin Moncure wrote:
>
> There is library out there, unfortunately GPL licensed, that attempts
> to fully implement posix including fork(): http://midipix.org/. One
> of these days I'd like to have a go at porting postgres to it.
... and here I thought you'd be keen t
On 3 May 2016 at 19:04, Rushabh Lathia wrote:
> With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> bitmap
> to represent what to include. With this commit if non-super user is unable
> to perform the dump.
>
Hm. I think we need a src/bin/pg_dump/t/ test for the TAP suite
Windows 7 vs 10 makes no odds here. What matters is whether your Postgres or R
installations are x64 or x86.
Any x64 Windows can run x64 or x86 software perfectly happily, but you can’t
mix a DLL with an EXE of a different flavour. They have to match.
Regards
David M Bennett FACS
On Mon, May 2, 2016 at 2:46 PM, Julien Rouhaud
wrote:
> I noticed that postgresql.conf.sample doesn't say that changing
> max_worker_processes requires a restart.
>
> Patch attached.
Good catch. Committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Compa
On Sun, May 1, 2016 at 10:39 PM, McCoy, Shawn wrote:
> I have been debugging a problem on a 9.3.10 Postgres database cluster with
> over 1200 databases. 10 workers, increased maintenance_work_mem, auto
> vacuum settings to run more frequently than default. What I will notice is
> that autovacuu
* Craig Ringer (cr...@2ndquadrant.com) wrote:
> On 3 May 2016 at 19:04, Rushabh Lathia wrote:
>
> > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> > bitmap
> > to represent what to include. With this commit if non-super user is unable
> > to perform the dump.
> >
>
>
On Tue, May 3, 2016 at 9:40 AM, Tom Lane wrote:
> Robert Haas writes:
>> 1. Is pgindent supposed to touch DATA() lines? Because it does.
>
> It always has.
>
>> 2. CustomPathMethods is not in the buildfarm's typedefs.list. Why not?
>
> Probably because there are no variables, parameters, or fie
* Rushabh Lathia (rushabh.lat...@gmail.com) wrote:
> With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> bitmap
> to represent what to include. With this commit if non-super user is unable
> to perform the dump.
[...]
> pg_dump: [archiver (db)] query was: LOCK TABLE pg_catalo
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, May 3, 2016 at 10:57 AM, Stephen Frost wrote:
> > * Craig Ringer (cr...@2ndquadrant.com) wrote:
> >> On 3 May 2016 at 19:04, Rushabh Lathia wrote:
> >>
> >> > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
> >> > bit
On Tue, Apr 26, 2016 at 7:39 PM, Robert Haas wrote:
> On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
>> Based on our discussion at PGConf.US and the comments up-thread from
>> Tom, I'll work up a patch to remove those checks around SET ROLE and
>> friends which were trying to prevent defau
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Apr 26, 2016 at 7:39 PM, Robert Haas wrote:
> > On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost wrote:
> >> Based on our discussion at PGConf.US and the comments up-thread from
> >> Tom, I'll work up a patch to remove those checks around SET R
On Tue, May 3, 2016 at 10:57 AM, Stephen Frost wrote:
> * Craig Ringer (cr...@2ndquadrant.com) wrote:
>> On 3 May 2016 at 19:04, Rushabh Lathia wrote:
>>
>> > With commit a9f0e8e5a2e779a888988cb64479a6723f668c84, now pg_dump, use a
>> > bitmap
>> > to represent what to include. With this commit i
On Mon, May 2, 2016 at 3:03 PM, Rodrigo Cavalcante
wrote:
> On alternate days my backup is failing, by the pg_stop_backup process ()
> does not perform or quit.
>
> Version PostgreSQL: 9.1.6
>
> The following backup script:
>
> PGDATA=/dados
> SAVE_BASE_DIR=/backup/diario
> backup="'bkpfull'"
> da
Robert Haas writes:
> OK, I committed this. Barring objections, I'll go ahead and pgindent
> the whole tree tomorrow. If we're going to revert anything big then
> we might want to hold off, but otherwise I think its better to get
> this done sooner rather than later.
Well, there are at least tw
On Tue, May 3, 2016 at 11:23 AM, Tom Lane wrote:
> Robert Haas writes:
>> OK, I committed this. Barring objections, I'll go ahead and pgindent
>> the whole tree tomorrow. If we're going to revert anything big then
>> we might want to hold off, but otherwise I think its better to get
>> this don
Robert Haas writes:
> On Tue, May 3, 2016 at 11:23 AM, Tom Lane wrote:
>> Well, there are at least two patchsets we're actively discussing
>> reverting, so I think this should wait till those decisions are resolved.
> OK, but that may well mean we don't get this done before beta1, which
> I thin
On 2016-05-02 10:32:28 -0400, Robert Haas wrote:
> You are certainly welcome to add a new open item to cover those
> complaints.
Done that.
> But I do not want to blur together the discussion of
> whether the feature is well-designed with the question of whether it
> regresses performance when it
On Mon, May 2, 2016 at 04:02:35PM -0500, Kevin Grittner wrote:
> On Sun, May 1, 2016 at 1:43 AM, Amit Kapila wrote:
> > On Sun, May 1, 2016 at 12:05 PM, Amit Kapila
> > wrote:
> >>
> >> Currently we do the test for old snapshot (TestForOldSnapshot) for hash
> >> indexes while scanning them. Do
On Tue, May 3, 2016 at 10:45 AM, Bruce Momjian wrote:
> On Mon, May 2, 2016 at 04:02:35PM -0500, Kevin Grittner wrote:
>> On Sun, May 1, 2016 at 1:43 AM, Amit Kapila wrote:
>> > On Sun, May 1, 2016 at 12:05 PM, Amit Kapila
>> > wrote:
>> >>
>> >> Currently we do the test for old snapshot (Test
On 5/2/16 8:53 AM, Dean Rasheed wrote:
Here are updated patches doing that --- the first moves
fmtReloptionsArray() from pg_dump.c to fe_utils/string_utils.c so that
it can be shared by pg_dump and psql, and renames it to
appendReloptionsArray(). The second patch fixes the actual psql bug.
This
On Tue, May 3, 2016 at 11:36 AM, Tom Lane wrote:
>> There are a lot more than 2 patchsets that are busted at the moment,
>> unfortunately, but I assume you are referring to "snapshot too old"
>> and "Use Foreign Key relationships to infer multi-column join
>> selectivity".
>
> Yeah, those are the
There is logic in pg_upgrade plus the backend, mostly added by commit
4c6780fd1, to cope with the corner cases that sometimes arise where the
old and new versions have different ideas about whether a given table
needs a TOAST table. The more common case is where there's a TOAST table
in the old DB
On Tue, May 3, 2016 at 11:46 AM, Kevin Grittner wrote:
>> Uh, I have no idea how this would be fixed if the PageLSN is zero. Do
>> you?
>
> Yes, I see three ways, the most obvious of which is what Amit
> suggested -- don't do early vacuum on a table which has a hash index.
What do you mean by "e
On Tue, May 3, 2016 at 10:58 AM, Robert Haas wrote:
> - Snapshot Too Old. Tom, Andres, and Bruce want this reverted.
> It regresses performance significantly when turned on.
When turned on, it improves performance in some cases and regresses
performance in others. Don't forget it is currently
On 2016-05-03 11:58:34 -0400, Robert Haas wrote:
> - Atomic Pin/Unpin. There are two different open items related to
> this, both apparently relating to testing done by Jeff Janes. I am
> not sure whether they are really independent reports of different
> problems or just two reports of the same
On 03/05/16 16:35, Craig Ringer wrote:
On 3 May 2016 at 21:37, Merlin Moncure mailto:mmonc...@gmail.com>> wrote:
There is library out there, unfortunately GPL licensed, that attempts
to fully implement posix including fork(): http://midipix.org/. One
of these days I'd like to have
On Tue, May 3, 2016 at 11:09 AM, Robert Haas wrote:
> On Tue, May 3, 2016 at 11:46 AM, Kevin Grittner wrote:
>>> Uh, I have no idea how this would be fixed if the PageLSN is zero. Do
>>> you?
>>
>> Yes, I see three ways, the most obvious of which is what Amit
>> suggested -- don't do early vacuu
On 2016-05-03 11:12:03 -0500, Kevin Grittner wrote:
> On Tue, May 3, 2016 at 10:58 AM, Robert Haas wrote:
>
> > - Snapshot Too Old. Tom, Andres, and Bruce want this reverted.
> > It regresses performance significantly when turned on.
>
> When turned on, it improves performance in some cases and
On Tue, May 3, 2016 at 12:22 PM, Andres Freund wrote:
>> > but that might be fixed now.
>>
>> Certainly all evidence suggests that, FUD to the contrary.
>
> So it's now FUD to report issues with a patch that obviously hasn't
> received sufficient benchmarking? Give me break.
Yeah, I don't think t
On Tue, May 3, 2016 at 11:22 AM, Andres Freund wrote:
> The issue with 0 v. -1 (and 0 vs. > 0 makes a big performance
> difference, so it's not that surprising to interpret numbers that way)
... if you fail to read the documentation of the feature or the
code implementing it before testing.
> w
On Tue, May 3, 2016 at 12:17 PM, Kevin Grittner wrote:
> On Tue, May 3, 2016 at 11:09 AM, Robert Haas wrote:
>> On Tue, May 3, 2016 at 11:46 AM, Kevin Grittner wrote:
Uh, I have no idea how this would be fixed if the PageLSN is zero. Do
you?
>>>
>>> Yes, I see three ways, the most obv
On Tue, May 3, 2016 at 11:48 AM, Robert Haas wrote:
> OK, I see now: the basic idea here is that we can't prune based on the
> newer XID unless the page LSN is guaranteed to advance whenever data
> is removed. Currently, we attempt to limit bloat in non-unlogged,
> non-catalog tables. You're sa
Andres Freund wrote:
> I'm *really* doubtful about the logical timeline following patches. I
> think they're, as committed, over-complicated and pretty much unusable.
As its committer, I tend to agree about reverting that feature. Craig
was just posting some more patches, and I have the pg_recvl
Tom Lane wrote:
> More generally, though, I wonder how we can have some test coverage
> on such cases going forward. Is the patch below too ugly to commit
> permanently, and if so, what other idea can you suggest?
I suggest a buildfarm animal running a custom buildfarm module that
exercises the
On Tue, May 3, 2016 at 9:58 AM, Alvaro Herrera wrote:
> As its committer, I tend to agree about reverting that feature. Craig
> was just posting some more patches, and I have the pg_recvlogical
> changes here (--endpos) which after some testing are not quite looking
> ready to go -- plus we still
* Robert Haas (robertmh...@gmail.com) wrote:
> Here's a list of what I think is currently broken in 9.6 that we might
> conceivably fix by reverting patches:
[...]
> - Predefined Roles. Neither you nor I liked Stephen's design. It
> slowed down pg_dump. It also broke pg_dump for non-superusers a
Stephen Frost wrote:
> * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > Tom Lane wrote:
> >
> > > More generally, though, I wonder how we can have some test coverage
> > > on such cases going forward. Is the patch below too ugly to commit
> > > permanently, and if so, what other idea can yo
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Tom Lane wrote:
>
> > More generally, though, I wonder how we can have some test coverage
> > on such cases going forward. Is the patch below too ugly to commit
> > permanently, and if so, what other idea can you suggest?
>
> I suggest a build
On 05/03/2016 01:21 PM, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Tom Lane wrote:
More generally, though, I wonder how we can have some test coverage
on such cases going forward. Is the patch below too ugly to commit
permanently, and if so, what other idea can
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> Stephen Frost wrote:
> > * Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
> > > Tom Lane wrote:
> > >
> > > > More generally, though, I wonder how we can have some test coverage
> > > > on such cases going forward. Is the patch below too ugly
On 05/03/2016 01:28 PM, Andrew Dunstan wrote:
On 05/03/2016 01:21 PM, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Tom Lane wrote:
More generally, though, I wonder how we can have some test coverage
on such cases going forward. Is the patch below too ugly to co
I wrote:
> Alvaro Herrera writes:
>> I'm happy with the solution that pg_upgrade has a step in the check
>> stage that says "catalog XYZ has a toast table but shouldn't, aborting
>> the upgrade". (Well, not _happy_, but at least it's a lot easier to
>> diagnose).
> I think though that you're def
On 05/03/2016 01:33 PM, Andrew Dunstan wrote:
On 05/03/2016 01:28 PM, Andrew Dunstan wrote:
On 05/03/2016 01:21 PM, Stephen Frost wrote:
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote:
Tom Lane wrote:
More generally, though, I wonder how we can have some test coverage
on such cases
On 2016-05-03 11:46:23 -0500, Kevin Grittner wrote:
> > was immediately addressed by another round of benchmarks after you
> > pointed it out.
>
> Which showed a 4% maximum hit before moving the test for whether it
> was "off" inline.
> (I'm not clear from the posted results whether that was befo
Stephen Frost wrote:
> One other point is that pg_dump goes quite a bit farther back than just
> what we currently support (or at least, it tries to). I think that,
> generally, that's a good thing, but it does mean we have a lot of cases
> that don't get tested nearly as much...
>
> I was able
Hi,
On 2016-05-03 12:07:51 -0400, Tom Lane wrote:
> I think possibly the easiest fix for this is to have pg_upgrade,
> instead of RESETting a nonexistent option, RESET something that's
> still considered to require AccessExclusiveLock. "user_catalog_table"
> would work, looks like; though I'd wan
On 2016-05-03 10:12:51 -0700, Peter Geoghegan wrote:
> On Tue, May 3, 2016 at 9:58 AM, Alvaro Herrera
> wrote:
> > As its committer, I tend to agree about reverting that feature. Craig
> > was just posting some more patches, and I have the pg_recvlogical
> > changes here (--endpos) which after s
Stephen Frost writes:
> One other point is that pg_dump goes quite a bit farther back than just
> what we currently support (or at least, it tries to). I think that,
> generally, that's a good thing, but it does mean we have a lot of cases
> that don't get tested nearly as much...
Yeah. I do pe
* Andres Freund (and...@anarazel.de) wrote:
> On 2016-05-03 12:07:51 -0400, Tom Lane wrote:
> > I think possibly the easiest fix for this is to have pg_upgrade,
> > instead of RESETting a nonexistent option, RESET something that's
> > still considered to require AccessExclusiveLock. "user_catalog_
Andrew Dunstan wrote:
> And if this is of any use, here are the dump differences from every live
> version to git tip, as of this morning.
Interesting, thanks. I wonder if some of these diffs could be reduced
further by using pg_dump -Fd instead of a single text dump -- then
internal ordering wo
On 2016-05-03 13:47:14 -0400, Tom Lane wrote:
> I've been thinking of proposing that it's time (not now, at this point,
> but for 9.7) to rip out libpq's support for V2 protocol as well as
> pg_dump's support for pre-7.4 backends.
+1
> There might be an argument for moving pg_dump's cutoff furth
Andres Freund writes:
> On 2016-05-03 12:07:51 -0400, Tom Lane wrote:
>> I think possibly the easiest fix for this is to have pg_upgrade,
>> instead of RESETting a nonexistent option, RESET something that's
>> still considered to require AccessExclusiveLock. "user_catalog_table"
>> would work, lo
On Tue, May 3, 2016 at 1:38 PM, Tom Lane wrote:
> Any thoughts what to do with this? We could decide that it's a bug fix
> and backpatch, or decide that it's a new feature and delay till 9.7,
> or decide that it's a minor bug fix and add it to 9.6 only. I kinda lean
> towards the last alternativ
Craig Ringer wrote:
> With this patch pg_recvlogical takes a new --endpos LSN argument, and will
> exit if either:
>
> * it receives an XLogData message with dataStart >= endpos; or
> * it receives a keepalive with walEnd >= endpos
>
> The latter allows it to work without needing a dummy transa
Tom Lane wrote:
> Any thoughts what to do with this? We could decide that it's a bug fix
> and backpatch, or decide that it's a new feature and delay till 9.7,
> or decide that it's a minor bug fix and add it to 9.6 only. I kinda lean
> towards the last alternative.
How about backpatching patch
On Fri, Apr 29, 2016 at 6:06 PM, Andreas Karlsson wrote:
> I am currently looking into adding the correct parallel options to all
> functions in the extensions and I noticed that some built-in functions seems
> to have been marked as unsafe by accident. The main culprit is
> system_views.sql which
On 05/03/2016 01:58 PM, Alvaro Herrera wrote:
Andrew Dunstan wrote:
And if this is of any use, here are the dump differences from every live
version to git tip, as of this morning.
Interesting, thanks. I wonder if some of these diffs could be reduced
further by using pg_dump -Fd instead of
On Tue, May 3, 2016 at 2:09 PM, Alvaro Herrera wrote:
> Tom Lane wrote:
>> Any thoughts what to do with this? We could decide that it's a bug fix
>> and backpatch, or decide that it's a new feature and delay till 9.7,
>> or decide that it's a minor bug fix and add it to 9.6 only. I kinda lean
>>
On 05/03/2016 07:12 PM, Peter Geoghegan wrote:
On Tue, May 3, 2016 at 9:58 AM, Alvaro Herrera wrote:
As its committer, I tend to agree about reverting that feature. Craig
was just posting some more patches, and I have the pg_recvlogical
changes here (--endpos) which after some testing are not
On 05/03/2016 07:41 PM, Andres Freund wrote:
On 2016-05-03 11:46:23 -0500, Kevin Grittner wrote:
was immediately addressed by another round of benchmarks after you
pointed it out.
Which showed a 4% maximum hit before moving the test for whether it
was "off" inline.
(I'm not clear from the p
On 3 May 2016 at 16:52, Peter Eisentraut
wrote:
> I would change appendReloptionsArrayAH() to a function and keep AH as the
> first argument (similar to other functions that take such a handle).
I can understand changing it to a function, but I don't think AH
should be the first argument. All oth
Robert Haas wrote:
> On Tue, May 3, 2016 at 2:09 PM, Alvaro Herrera
> wrote:
> > Tom Lane wrote:
> >> Any thoughts what to do with this? We could decide that it's a bug fix
> >> and backpatch, or decide that it's a new feature and delay till 9.7,
> >> or decide that it's a minor bug fix and add
Alvaro Herrera writes:
> Robert Haas wrote:
>> On Tue, May 3, 2016 at 2:09 PM, Alvaro Herrera
>> wrote:
>>> How about backpatching patch 1 all the way back, and putting the others
>>> in 9.6?
>> Why would we do that? It seems very odd to back-patch a pure
>> refactoring - isn't that taking a r
Hello Robert,
Thanks for the feedback.
The my script works, but after a few days it stops working because the
process does not end pg_stop_backup.
The pg_basebackup already does this substitution?
--
View this message in context:
http://postgresql.nabble.com/Pg-stop-backup-process-does-not-r
On Tue, May 3, 2016 at 4:21 PM, Rodrigo Cavalcante
wrote:
> The my script works, but after a few days it stops working because the
> process does not end pg_stop_backup.
Well, that shouldn't happen, but without any logs or debugging
information, it's hard to guess why.
> The pg_basebackup alread
On Mon, May 2, 2016 at 12:03 PM, Rodrigo Cavalcante
wrote:
> Hi,
>
> On alternate days my backup is failing, by the pg_stop_backup process ()
> does not perform or quit.
>
> Version PostgreSQL: 9.1.6
>
Reporting unusual behavior while running a years-old point release is
unlikely to be producti
On Tue, May 3, 2016 at 9:57 PM, Tomas Vondra
wrote:
> If you tell me how to best test it, I do have a 4-socket server sitting idly
> in the corner (well, a corner reachable by SSH). I can get us some numbers,
> but I haven't been following the snapshot_too_old so I'll need some guidance
> on what
On 4 May 2016 at 02:10, Tomas Vondra wrote:
> There are probably a few reasonably simple things we could do - e.g. ignore
> foreign keys with just a single column, as the primary goal of the patch is
> improving estimates with multi-column foreign keys. I believe that covers a
> vast majority of f
I don't like reverting patches, but this patch is making me more and
more uncomfortable. We have two open items, one of which requires
writing new test code that doesn't exist yet; and we have the
pg_recvlogical changes that were approved post-feature freeze, but that
I now have second thoughts ab
On 2016-05-04 00:01:20 +0300, Ants Aasma wrote:
> On Tue, May 3, 2016 at 9:57 PM, Tomas Vondra
> wrote:
> > If you tell me how to best test it, I do have a 4-socket server sitting idly
> > in the corner (well, a corner reachable by SSH). I can get us some numbers,
> > but I haven't been following
On 2016-05-03 20:57:13 +0200, Tomas Vondra wrote:
> On 05/03/2016 07:41 PM, Andres Freund wrote:
> >On 2016-05-03 11:46:23 -0500, Kevin Grittner wrote:
> >>>was immediately addressed by another round of benchmarks after you
> >>>pointed it out.
> >>
> >>Which showed a 4% maximum hit before moving t
Hi Jeff,
On 2016-04-29 10:38:55 -0700, Jeff Janes wrote:
> I've bisected the errors I was seeing, discussed in
> http://www.postgresql.org/message-id/CAMkU=1xqehc0ok4d+tkjfq1nvuho37pyrkhjp6q8oxifmx7...@mail.gmail.com
>
> It look like they first appear in:
>
> commit 48354581a49c30f5757c203415aa8
On 4 May 2016 at 01:12, Peter Geoghegan wrote:
> On Tue, May 3, 2016 at 9:58 AM, Alvaro Herrera
> wrote:
> > As its committer, I tend to agree about reverting that feature. Craig
> > was just posting some more patches, and I have the pg_recvlogical
> > changes here (--endpos) which after some t
Hi,
On 2016-05-03 07:24:46 +0200, Fabien COELHO wrote:
> >>I'm unsure about switching enum to #define, could be an enum still with
> >>explicit values set, something like:
> >
> >An enum doesn't have a benefit for a bitmask imo - you can't "legally"
> >use it as a type for functions accepting the
On 4 May 2016 at 09:18, David Rowley wrote:
> On 4 May 2016 at 02:10, Tomas Vondra wrote:
>> There are probably a few reasonably simple things we could do - e.g. ignore
>> foreign keys with just a single column, as the primary goal of the patch is
>> improving estimates with multi-column foreign
On 5/3/16 3:10 PM, Dean Rasheed wrote:
On 3 May 2016 at 16:52, Peter Eisentraut
wrote:
I would change appendReloptionsArrayAH() to a function and keep AH as the
first argument (similar to other functions that take such a handle).
I can understand changing it to a function, but I don't think
On Mon, May 2, 2016 at 10:29 PM, Robert Haas wrote:
> On Thu, Apr 28, 2016 at 11:46 PM, Craig Ringer wrote:
>> I just helped another person yesterday who deleted their pg_xlog.
>
> The biggest reason I've seen pg_xlog get deleted is not because it's
> called pg_xlog, but because it's located some
On 05/03/2016 06:38 PM, Michael Paquier wrote:
On Mon, May 2, 2016 at 10:29 PM, Robert Haas wrote:
On Thu, Apr 28, 2016 at 11:46 PM, Craig Ringer wrote:
I just helped another person yesterday who deleted their pg_xlog.
The biggest reason I've seen pg_xlog get deleted is not because it's
cal
Commit bb14050 said:
- change order for tsquery, so, users, who has a btree index over tsquery,
should reindex it
The last change of this sort also modified pg_upgrade to issue REINDEX
guidance. See old_8_3_invalidate_hash_gin_indexes() in the PostgreSQL 9.4
source. PostgreSQL 9.6 pg_
On Sun, Mar 20, 2016 at 8:31 AM, Thomas Munro
wrote:
> One thing that I want to do but can't with this interface is remove an
> fd from the set. I can AddWaitEventToSet returning a position, and I
> can ModifyWait to provide new event mask by position including zero
> mask, I can't actually remov
On Mon, May 2, 2016 at 11:47 PM, Robert Haas wrote:
>
> On Tue, Apr 26, 2016 at 11:49 AM, Robert Haas
wrote:
> > On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane wrote:
> >> Robert Haas writes:
>
> To summarize the positions as I understand them:
>
> Magnus seems OK with the way things are.
> Peter w
Noah Misch writes:
> Commit bb14050 said:
> - change order for tsquery, so, users, who has a btree index over tsquery,
> should reindex it
We undid that in 1ec4c7c05, no? (Even if we didn't, the usefulness
of a btree index on tsquery seems negligibly small.)
> Commit 61d66c4 may or ma
On 4 May 2016 at 15:12, Amit Kapila wrote:
> On Mon, May 2, 2016 at 11:47 PM, Robert Haas wrote:
>>
>> On Tue, Apr 26, 2016 at 11:49 AM, Robert Haas
>> wrote:
>> > On Tue, Apr 26, 2016 at 11:44 AM, Tom Lane wrote:
>> >> Robert Haas writes:
>>
>> To summarize the positions as I understand them:
On Tue, May 3, 2016 at 9:47 PM, Kevin Grittner wrote:
>
> On Tue, May 3, 2016 at 11:09 AM, Robert Haas
wrote:
> > On Tue, May 3, 2016 at 11:46 AM, Kevin Grittner
wrote:
> >>> Uh, I have no idea how this would be fixed if the PageLSN is zero. Do
> >>> you?
> >>
> >> Yes, I see three ways, the mo
On Tue, May 3, 2016 at 9:28 PM, Robert Haas wrote:
>
> On Tue, May 3, 2016 at 11:36 AM, Tom Lane wrote:
> >> There are a lot more than 2 patchsets that are busted at the moment,
> >> unfortunately, but I assume you are referring to "snapshot too old"
> >> and "Use Foreign Key relationships to inf
1 - 100 of 111 matches
Mail list logo
