On Wed, Aug 24, 2016 at 2:03 AM, Robert Haas wrote:
> ISTR that you were going to try to look at this patch set. It seems
> from the discussion that it's not really ready for serious
> consideration for commit yet, but also that some high-level design
> comments from you at this stage could go a
On Wed, Aug 24, 2016 at 5:07 PM, Bernd Helmle wrote:
> That said, i'm okay if --single is not intended to bring up a hot standby.
> There are many other ways to debug such problems.
This patch is still on the CF app:
https://commitfest.postgresql.org/10/610/
Even after thinking about it, my opini
On 08/30/2016 03:26 AM, Andreas Karlsson wrote:
On 08/26/2016 11:31 AM, Heikki Linnakangas wrote:
On 07/05/2016 04:46 PM, Andreas Karlsson wrote:
@@ -280,8 +287,9 @@ px_find_digest(const char *name, PX_MD **res)
digest = px_alloc(sizeof(*digest));
digest->algo = md;
-EVP_MD_CTX_i
On Tue, Aug 30, 2016 at 2:57 PM, Michael Paquier
wrote:
> The funny part here is that ProcGlobal->allProcs is actually handled,
> but not the two others. Well yes, you are right, we really need to
> fail on FATAL for all of them if ShmemAlloc returns NULL as they
> involve the shmem initialization
On Mon, Aug 29, 2016 at 11:26 PM, Tom Lane wrote:
> Aleksander Alekseev writes:
>>> if (prodesc->user_proname == NULL || prodesc->internal_proname == NULL)
>>> + {
>>> +free(prodesc);
>
>> I think that prodesc->user_proname and prodesc->internal_proname should
>> also be freed if they are not
On Tue, Aug 30, 2016 at 3:39 AM, Tom Lane wrote:
> Fujii Masao writes:
>> ISTM that the cause of this issue is that gin_desc() uses XLogRecGetData() to
>> extract ginxlogVacuumDataLeafPage data from XLOG_GIN_VACUUM_DATA_LEAF_PAGE
>> record. Since it's registered by XLogRegisterBufData() in
>> gin
On Mon, Aug 29, 2016 at 11:13 PM, Aleksander Alekseev
wrote:
>> Hello, Michael
>>
>> > I don't know how you did it, but this email has visibly broken the
>> > original thread. Did you change the topic name?
>>
>> I'm very sorry for this. I had no local copy of this thread. So I wrote a
>> new emai
On Tue, Aug 30, 2016 at 5:43 AM, Martín Marqués wrote:
> This is v4 of the patch, which is actually a cleaner version from the
> v2 one Michael sent.
>
> I stripped off the external index created from the tests as that index
> shouldn't be dumped (table it belongs to isn't dumped, so neither
> sho
On Tue, Aug 30, 2016 at 1:44 PM, Fujii Masao wrote:
> On Tue, Aug 30, 2016 at 1:32 PM, Michael Paquier
> wrote:
>> On Mon, Aug 29, 2016 at 11:16 PM, Fujii Masao wrote:
>>> You seem to add another entry for this patch into CommitFest.
>>> Either of them needs to be removed.
>>> https://commitfest
On 30 August 2016 at 00:37, Robert Haas wrote:
> Long story short, I kind of agree that it might have been better to
> expose server_version_num rather than server_version in the beginning,
> but I'm not sure that it really helps anybody now, especially given
> our decision to simplify the versio
On Tue, Aug 30, 2016 at 1:32 PM, Michael Paquier
wrote:
> On Mon, Aug 29, 2016 at 11:16 PM, Fujii Masao wrote:
>> You seem to add another entry for this patch into CommitFest.
>> Either of them needs to be removed.
>> https://commitfest.postgresql.org/10/698/
>
> Indeed. I just removed this one.
On Mon, Aug 29, 2016 at 11:16 PM, Fujii Masao wrote:
> You seem to add another entry for this patch into CommitFest.
> Either of them needs to be removed.
> https://commitfest.postgresql.org/10/698/
Indeed. I just removed this one.
> This patch prevents pg_stop_backup from starting while pg_star
Hello.
The comment on GatherPath.single_copy is the following.
===
/*
* GatherPath runs several copies of a plan in parallel and collects the
* results. The parallel leader may also execute the plan, unless the
* single_copy flag is set.
*/
typedef struct GatherPath
{
Path
On 30 Aug 2016 9:07 AM, "Dave Cramer" wrote:
>
>
> On 29 August 2016 at 15:42, Tom Lane wrote:
>>
>> Kevin Grittner writes:
>> > Regarding Java, for anything above the driver itself the
>> > JDBC API says the DatabaseMetaData class must implement these
>> > methods:
>> > ...
>> > That *should* m
No, it was wrong.
At Mon, 29 Aug 2016 17:08:36 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI
wrote in
<20160829.170836.161449399.horiguchi.kyot...@lab.ntt.co.jp>
> Hello,
>
> I considered applying the async infrastructure onto nodeGather,
> but since parallel workers hardly make Gather (or th
On 2016-08-30 07:57:19 +0530, Amit Kapila wrote:
> I will write such a test case either in this week or early next week.
Great.
> I hope this is not super urgent, let me know if you think otherwise.
It's not urgent, no.
Thanks!
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@po
On Mon, Aug 29, 2016 at 10:09 PM, Robert Haas wrote:
> On Sat, Aug 27, 2016 at 3:30 AM, Andres Freund wrote:
>> Hi,
>>
>> On 2016-02-04 21:43:14 +, Robert Haas wrote:
>>> Change the way that LWLocks for extensions are allocated.
>>>
>>> The previous RequestAddinLWLocks() method had several di
On Tue, Aug 30, 2016 at 3:40 AM, Alvaro Herrera
wrote:
> Amit Kapila wrote:
>
>> How about attached?
>
> That works; pushed.
Thanks.
> (I removed a few #includes from the new file.)
>
oops, copied from hash.h and forgot to remove those.
>> If you want, I think we can one step further and move
On Mon, Aug 29, 2016 at 9:39 PM, Craig Ringer
wrote:
> Cool. I'll mark as waiting on author pending that.
>
> It'll be good to get this footgun put away.
OK, so done. I have put the renaming of pg_xlog to pg_wal on top patch
stack as that's the one making no discussion it seems: a lot of people
l
On 2016/08/26 22:35, Heikki Linnakangas wrote:
On 04/05/2016 11:15 AM, Etsuro Fujita wrote:
On 2016/03/16 16:25, Etsuro Fujita wrote:
PG9.5 allows us to add an oid system column to foreign tables, using
ALTER FOREIGN TABLE SET WITH OIDS, but currently, that column reads as
zeroes in postgres_fd
On 29 August 2016 at 15:42, Tom Lane wrote:
> Kevin Grittner writes:
> > Regarding Java, for anything above the driver itself the
> > JDBC API says the DatabaseMetaData class must implement these
> > methods:
> > ...
> > That *should* make it just a problem for the driver itself. That
> > seems
On 8/28/16 8:45 PM, Jim Nasby wrote:
> People accidentally blowing away pg_clog or pg_xlog is a pretty common
> occurrence, and I don't think there's all that many tools that reference
> them. I think it's well worth renaming them.
I think a related problem is that the default log directory is c
On 8/29/16 12:54 PM, Robert Haas wrote:
> As for the new names, how about pg_wal and
> pg_xact? I don't think "pg_trans" is as good; is it transactional or
> transient or transport or transitive or what?
pg_transaction_status? (or pg_xact_status if you want to keep it short)
--
Peter Eisentraut
On 2016-08-29 19:27:29 -0500, Jim Nasby wrote:
> On 8/27/16 1:11 PM, Tom Lane wrote:
> > Alvaro Herrera writes:
> > > I'm for renaming too, but I'd go with Peter E's suggestion: move pg_xlog
> > > to something like $PGDATA/var/wal or $PGDATA/srv/wal or something like
> > > that.
> >
> > I think
On 8/27/16 1:11 PM, Tom Lane wrote:
Alvaro Herrera writes:
I'm for renaming too, but I'd go with Peter E's suggestion: move pg_xlog
to something like $PGDATA/var/wal or $PGDATA/srv/wal or something like that.
I think that would make sense if we were to relocate *everything* under
PGDATA into
On 08/26/2016 11:31 AM, Heikki Linnakangas wrote:
On 07/05/2016 04:46 PM, Andreas Karlsson wrote:
@@ -280,8 +287,9 @@ px_find_digest(const char *name, PX_MD **res)
digest = px_alloc(sizeof(*digest));
digest->algo = md;
-EVP_MD_CTX_init(&digest->ctx);
-if (EVP_DigestInit_ex(&di
Robert Haas wrote:
> That would also have the advantage of improving the test coverage for
> pg_stat_statements, which is at the moment quite a bit thinner than
> the coverage for lwlock.c.
Hmm, the coverage-html report is not currently covering contrib ... I
suppose that's an easily fixable over
Amit Kapila wrote:
> How about attached?
That works; pushed. (I removed a few #includes from the new file.)
> If you want, I think we can one step further and move hash_redo to a
> new file hash_xlog.c which is required for main patch, but we can
> leave it for later as well.
I think that can
On 08/29/2016 07:22 PM, Heikki Linnakangas wrote:
Pushed with some small doc fixes, thanks Andreas! I'll continue
reviewing the rest of the patches.
Thanks!
Andreas
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgre
Hi,
This is v4 of the patch, which is actually a cleaner version from the
v2 one Michael sent.
I stripped off the external index created from the tests as that index
shouldn't be dumped (table it belongs to isn't dumped, so neither
should the index). I also took off a test which was duplicated.
Greg Stark writes:
> On Mon, Aug 29, 2016 at 7:19 PM, Tom Lane wrote:
>> To deal with the infinity/NaN issues, I made cube_in and cube_out rely
>> on float8in_internal and float8out_internal, as we recently did for the
>> core geometric types. That causes the response to "1e-700" to be an
>> out
On Mon, Aug 29, 2016 at 7:19 PM, Tom Lane wrote:
> To deal with the infinity/NaN issues, I made cube_in and cube_out rely
> on float8in_internal and float8out_internal, as we recently did for the
> core geometric types. That causes the response to "1e-700" to be an
> out-of-range error rather tha
2016-08-29 4:51 GMT-03:00 Michael Paquier :
>
>> I see the current behavior is documented, and I do understand why global
>> objects can't be part of the extension, but for indexes it seems to violate
>> POLA a bit.
>>
>> Is there a reason why we don't want the extension/index dependencies?
>
> I t
Kevin Grittner writes:
> Regarding Java, for anything above the driver itself the
> JDBC API says the DatabaseMetaData class must implement these
> methods:
> ...
> That *should* make it just a problem for the driver itself. That
> seems simple enough until you check what those methods have been
On Mon, Aug 29, 2016 at 11:37 AM, Robert Haas wrote:
> Note that these are all one-liners, and I bet the same is true in
> mostly other languages. Even in notoriously verbose languages like
> Java or Cobol or ADA it can't be very hard.
Regarding Java, for anything above the driver itself the
JD
> Le 29 août 2016 à 19:46, Heikki Linnakangas a écrit :
>
>
> Tom, Rémi, can you fix locust and prairiedog, please, by updating OpenSSL or
> removing --with-openssl?
>
Hi,
Should be OK for locust on next build.
Rémi
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
Fujii Masao writes:
> ISTM that the cause of this issue is that gin_desc() uses XLogRecGetData() to
> extract ginxlogVacuumDataLeafPage data from XLOG_GIN_VACUUM_DATA_LEAF_PAGE
> record. Since it's registered by XLogRegisterBufData() in
> ginVacuumPostingTreeLeaf(),
> XLogRecGetBlockData() should
Heikki Linnakangas writes:
> Buildfarm animals "locust" and "prairiedog" are not happy with this.
> They seem to be using OpenSSL 0.9.7, as they failed with errors related
> to those ECDH calls:
prairiedog definitely is, and since locust is also an ancient OS X
version, that's not too surprisin
In bug #14300 it's pointed out that cube_in rejects zero-element
cubes, as well as infinity and NaN coordinate values. Since it's
easy to make such cube values via the cube-from-float-array
constructors, this is a dump/reload hazard. The attached proposed
patch attempts to fix it up.
To deal wit
On Fri, Aug 26, 2016 at 05:14:36PM +0200, Magnus Hagander wrote:
> On Aug 26, 2016 5:13 PM, "Joshua D. Drake" wrote:
> >
> > On 08/25/2016 07:39 PM, Michael Paquier wrote:
> >>
> >> Hi all,
> >>
> >> I am relaunching $subject as 10 development will begin soon. As far as
> >> I know, there is agree
On 08/29/2016 08:22 PM, Heikki Linnakangas wrote:
On 08/27/2016 05:15 PM, Peter Eisentraut wrote:
On 8/26/16 9:26 PM, Andreas Karlsson wrote:
I have attached a patch which removes the < 0.9.8 compatibility code.
Should we also add a version check to configure? We do not have any such
check curr
On 08/27/2016 05:15 PM, Peter Eisentraut wrote:
On 8/26/16 9:26 PM, Andreas Karlsson wrote:
I have attached a patch which removes the < 0.9.8 compatibility code.
Should we also add a version check to configure? We do not have any such
check currently.
I think that is not necessary.
I was goi
On 08/29/2016 10:00 AM, Daniel Verite wrote:
Let's imagine that pg_xlog is named wal instead.
How does that help our user with the disk space problem?
Does that point to a path of resolution? I don't see it.
What do we think that user's next move will be?
After all, WAL means Write Ahead *Log*.
Joshua D. Drake wrote:
> You log in, see that all the space and you find that you are using a
> ton of disk space. You look around for anything you can delete. You
> find a directory called pg_xlog, it says log, junior ignorant, don't
> want to be a sysadmin 101 says, "delete logs".
Yes,
On Sat, Aug 27, 2016 at 2:03 PM, Michael Paquier
wrote:
> - Rename them, hard break is OK: Michael P, Bruce, Stephen (depends on
> David's input), Magnus
I'm in favor of this. But I don't like Peter's proposal to use a more
complicated structure. As for the new names, how about pg_wal and
pg_x
On Sat, Aug 27, 2016 at 5:33 PM, Michael Paquier
wrote:
> On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote:
>> On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
>>> I agree with all that. But the subject line is specifically about
>>> moving pg_xlog. So if your opinion is that we should
On Mon, Aug 29, 2016 at 6:37 PM, Robert Haas wrote:
> On Mon, Aug 29, 2016 at 7:12 PM, Tom Lane wrote:
> > Craig Ringer writes:
> >> The same sort of problems apply to network clients, but network
> >> clients don't currently get that option because we only send
> >> server_version on the wire
On Sat, Aug 27, 2016 at 3:30 AM, Andres Freund wrote:
> Hi,
>
> On 2016-02-04 21:43:14 +, Robert Haas wrote:
>> Change the way that LWLocks for extensions are allocated.
>>
>> The previous RequestAddinLWLocks() method had several disadvantages.
>> First, the locks would be in the main tranche;
On 08/29/2016 08:07 AM, Tom Lane wrote:
"Joshua D. Drake" writes:
Also as a note to the idea that we make break things for external user
space; the next version being v10 is the exact time to do that.
Let's please drop this meme that "v10 is a great time to break things".
We don't want this t
On Mon, Aug 29, 2016 at 7:12 PM, Tom Lane wrote:
> Craig Ringer writes:
>> The same sort of problems apply to network clients, but network
>> clients don't currently get that option because we only send
>> server_version on the wire in the startup packet. We don't send
>> server_version_num.
>
>>
On Mon, Aug 29, 2016 at 07:34:52AM -0400, 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 business. Pushing them witho
On 2016-08-29 12:07:51 -0400, David Steele wrote:
> >> pg_replslot -> pg_tmp/pg_repslot
> >
> > That's most certainly not ephemeral. Just because something isn't
> > generally appropriate on a standby, doesn't, by far, mean it's ephemeral.
>
> Yes, ephemeral was a poor choice of words. I really
On 8/29/16 11:35 AM, Andres Freund wrote:
> On 2016-08-29 11:18:38 -0400, David Steele wrote:
>> pg_logical -> pg_replgcl
>
> That seems considerably worse.
Fair enough. I was just trying to throw something out there to get rid
of the "log" in logical.
>> pg_replslot -> pg_tmp/pg_repslot
>
> T
On Mon, Aug 29, 2016 at 5:22 PM, maksim wrote:
> Hi, hackers!
>
> 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, for 9.6 and later it doesn't
> supp
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, for 9.6 and later it doesn't
> support detailed stat
Andres Freund writes:
> Do we want to revert this until the release, or does somebody want to
> push the fix?
If this had broken the 9.6 branch I would have already summarily
reverted it. Since it didn't, my only real concern vis-a-vis today's
release is that the build failure in 9.5 calls into
On 2016-08-29 12:56:25 +0300, Heikki Linnakangas wrote:
> On 08/28/2016 12:48 AM, Andres Freund wrote:
> > Attached is a significantly updated patch series (see the mail one up
> > for details about what this is, I don't want to quote it in its
> > entirety).
> >
> > There's still some corner case
Andres Freund writes:
> On 2016-08-29 11:18:38 -0400, David Steele wrote:
>> pg_replslot -> pg_tmp/pg_repslot
> That's most certainly not ephemeral. Just because something isn't
> generally appropriate on a standby, doesn't, by far, mean it's ephemeral.
Do we need to account for both of those co
On 2016-08-29 07:34:52 -0400, 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 business. Pushing them without any testi
Hi,
On 2016-08-29 11:18:38 -0400, David Steele wrote:
> pg_logical -> pg_replgcl
That seems considerably worse.
> pg_replslot -> pg_tmp/pg_repslot
That's most certainly not ephemeral. Just because something isn't
generally appropriate on a standby, doesn't, by far, mean it's ephemeral.
Greetin
On 8/27/16 4:33 AM, Michael Paquier wrote:
> On Sat, Aug 27, 2016 at 6:34 AM, Andres Freund wrote:
>> On 2016-08-26 17:31:14 -0400, Peter Eisentraut wrote:
>>> I agree with all that. But the subject line is specifically about
>>> moving pg_xlog. So if your opinion is that we shouldn't move pg_xl
Hi, hackers!
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, for 9.6 and later
it doesn't support detailed statistics for parallel nodes yet.
I want
"Joshua D. Drake" writes:
> Also as a note to the idea that we make break things for external user
> space; the next version being v10 is the exact time to do that.
Let's please drop this meme that "v10 is a great time to break things".
We don't want this to be any worse than any other major-ver
On 08/29/2016 06:42 AM, Daniel Verite wrote:
Aside from that, we might also question how much of the excuse
"pg_xlog looked like it was just deletable logs" is a lie made up
after the fact, because anybody wrecking a database is not against
deflecting a bit of the blame to the software, that's h
On 08/29/2016 12:04 AM, Magnus Hagander wrote:
On Mon, Aug 29, 2016 at 2:45 AM, Jim Nasby mailto:jim.na...@bluetreble.com>> wrote:
On 8/26/16 4:08 PM, Andres Freund wrote:
Splitting of ephemeral data seems to have a benefit, the rest
seems more
like rather noisy busy
On 08/27/2016 11:11 AM, Tom Lane wrote:
Alvaro Herrera writes:
I'm for renaming too, but I'd go with Peter E's suggestion: move pg_xlog
to something like $PGDATA/var/wal or $PGDATA/srv/wal or something like that.
I think that would make sense if we were to relocate *everything* under
PGDATA i
Aleksander Alekseev writes:
>> if (prodesc->user_proname == NULL || prodesc->internal_proname == NULL)
>> + {
>> +free(prodesc);
> I think that prodesc->user_proname and prodesc->internal_proname should
> also be freed if they are not NULL's.
Hmm, this is kind of putting lipstick on a pig, i
On Mon, Aug 22, 2016 at 10:43 AM, Michael Paquier
wrote:
> On Sat, Aug 6, 2016 at 6:35 PM, Andreas Seltenreich
> wrote:
>> Michael Paquier writes:
>>
>>> Andreas, with the patch attached is the assertion still triggered?
>>> [2. text/x-diff; base-backup-crash-v2.patch]
>>
>> I didn't observe the
> Hello, Michael
>
> > I don't know how you did it, but this email has visibly broken the
> > original thread. Did you change the topic name?
>
> I'm very sorry for this. I had no local copy of this thread. So I wrote a
> new email with the same subject hoping it will be OK. Apparently right
> In
On Sat, Aug 6, 2016 at 6:36 PM, Petr Jelinek wrote:
> On 04/08/16 06:40, Masahiko Sawada wrote:
>>
>> On Wed, Aug 3, 2016 at 3:05 PM, Michael Paquier
>> wrote:
>>>
>>> On Wed, Aug 3, 2016 at 2:52 PM, Masahiko Sawada
>>> wrote:
I was thinking that the syntax for quorum method would use
Craig Ringer writes:
> The same sort of problems apply to network clients, but network
> clients don't currently get that option because we only send
> server_version on the wire in the startup packet. We don't send
> server_version_num.
> It'll be immediately useful to have this since clients ca
Craig Ringer wrote:
> People won't see a README in amongst 5000 xlog segments while
> freaking out about the sever being down.
Maybe they're more likely to google "pg_xlog".
BTW, renaming it will not help with respect to that, as
there's a pretty good corpus on knowledge linked to that
pa
Hello, Michael
> I don't know how you did it, but this email has visibly broken the
> original thread. Did you change the topic name?
I'm very sorry for this. I had no local copy of this thread. So I wrote a
new email with the same subject hoping it will be OK. Apparently right
In-Reply-To header
On 29 August 2016 at 20:28, Michael Paquier wrote:
> On Mon, Aug 29, 2016 at 5:28 PM, Craig Ringer
> wrote:
>> On 29 August 2016 at 14:30, Michael Paquier
>> wrote:
>>> On Mon, Aug 29, 2016 at 2:36 PM, Craig Ringer
>>> wrote:
I don't care if it comes as part of some greater reorg or not b
On Mon, Aug 29, 2016 at 5:28 PM, Craig Ringer
wrote:
> On 29 August 2016 at 14:30, Michael Paquier wrote:
>> On Mon, Aug 29, 2016 at 2:36 PM, Craig Ringer
>> wrote:
>>> I don't care if it comes as part of some greater reorg or not but I'll be
>>> really annoyed if scope creep lands up killing th
On Mon, Aug 29, 2016 at 8:34 PM, 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 business. Pushing them without any test
On Fri, Aug 26, 2016 at 1:33 PM, Amit Langote
wrote:
> We do take a lock on the parent because we would be changing its partition
> descriptor (relcache). I changed MergeAttributes() such that an
> AccessExclusiveLock instead of ShareUpdateExclusiveLock is taken if the
> parent is a partitioned t
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 business. Pushing them without any testing
is close to irresponsible.
regar
On 23 August 2016 at 14:57, Michael Paquier wrote:
> On Tue, Aug 23, 2016 at 9:48 PM, Gabriele Bartolini
> wrote:
>> Hi Simon and Michael,
>>
>> 2016-08-23 10:39 GMT+02:00 Simon Riggs :
>>>
>>> Agreed, but I'd move all the comments above the block.
>>
>>
>> That's fine with me.
>
> +1.
Committed
Hi all
It's recently been observed[1] that the 10.0 version scheme change has
affected PostGIS, which relies on parsing the server version string
and broke when faced with a string like "10.0devel" since it expected
a minor version.
In that thread Tom points out [2] that they should be using
PG_V
On Mon, Aug 29, 2016 at 7:04 AM, Vik Fearing wrote:
> We have sample configuration files for postgresql.conf and
> recovery.conf, but we do not have them for contrib modules. This patch
> attempts to add them.
>
> Although the patch puts the sample configuration files in the tree, it
> doesn't tr
On 08/28/2016 12:48 AM, Andres Freund wrote:
Attached is a significantly updated patch series (see the mail one up
for details about what this is, I don't want to quote it in its
entirety).
There's still some corner cases (DISTINCT + SRF, UNION/INTERSECT with
SRF) to test / implement and a good
On 27/08/16 18:50, Tom Lane wrote:
Michael Paquier writes:
OK, so let's focus only on the renaming mentioned in $subject. So far
as I can see on this thread, here are the opinions of people who
clearly gave one:
- Rename them, hard break is OK: Michael P, Bruce, Stephen (depends on
David's inpu
On Fri, Aug 26, 2016 at 11:35 PM, Fujii Masao wrote:
> On Tue, May 10, 2016 at 9:57 PM, Alexander Korotkov
> wrote:
>> Hi!
>>
>> On Mon, May 9, 2016 at 10:46 PM, Andres Freund wrote:
>>>
>>> trying to debug something I saw the following in pg_xlogdump output:
>>>
>>> rmgr: Gin len (rec/t
On 29 August 2016 at 11:46, Andres Freund wrote:
> On 2016-08-29 11:41:00 +0800, Craig Ringer wrote:
>> On 29 August 2016 at 02:52, Tom Lane wrote:
>> > "Regina Obe" writes:
>> >> The routine in PostGIS to parse out the version number from pg_config is
>> >> breaking in the 10 cycle
>> >
>> > TB
On 29 August 2016 at 14:30, Michael Paquier wrote:
> On Mon, Aug 29, 2016 at 2:36 PM, Craig Ringer
> wrote:
>> I don't care if it comes as part of some greater reorg or not but I'll be
>> really annoyed if scope creep lands up killing the original proposal to just
>> rename these dirs. I think th
Jim Nasby wrote:
Yeah, especially since you mentioned this being for backups. I
suspect you *want* those WAL records marked with 0, because that
tells you that you can't rely on WAL when you back that data up.
Thanks, you right if you doing incremental backup you try compare every
page LSN wi
On 29 August 2016 at 11:45, Andres Freund wrote:
> Hi,
>
> On 2016-08-29 11:25:39 +0800, Craig Ringer wrote:
>> ERROR: could not access status of transaction 778793573
>> DETAIL: could not open file "pg_clog/02E6": No such file or directory
>>
>> What I'd really like is to be able to ask tra
On Sat, Aug 27, 2016 at 8:15 AM, Tomas Vondra
wrote:
> On 08/27/2016 12:37 AM, Tom Lane wrote:
>> =?UTF-8?B?TWFydMOtbiBNYXJxdcOpcw==?= writes:
>>> Looking at this issue today, I found that we are not setting a
>>> dependency for an index created inside an extension.
>>
>> Surely the index has a d
On Sat, Aug 27, 2016 at 10:24 PM, Michael Paquier
wrote:
> ./src/backend/postmaster/postmaster.c: userDoption =
> strdup(optarg);
> [...]
> ./src/backend/bootstrap/bootstrap.c:userDoption =
> strdup(optarg);
> [...]
> ./src/backend/tcop/postgres.c: use
On Mon, Aug 29, 2016 at 2:45 AM, Jim Nasby wrote:
> On 8/26/16 4:08 PM, Andres Freund wrote:
>
>> Splitting of ephemeral data seems to have a benefit, the rest seems more
>> like rather noisy busywork to me.
>>
>
> People accidentally blowing away pg_clog or pg_xlog is a pretty common
> occurrenc
91 matches
Mail list logo
