On 2016-06-30 23:51:18 -0400, Noah Misch wrote:
> On Thu, Jun 16, 2016 at 01:56:44PM -0500, Kevin Grittner wrote:
> > On Thu, Jun 16, 2016 at 1:32 PM, Andres Freund wrote:
> >
> > > With old_snapshot_threshold=1 I indeed can reproduce the issue. I
> > > disabled autovacuum, to make the scheduling
On 1 July 2016 at 08:33, Tsunakawa, Takayuki wrote:
> Hello,
>
> While I was thinking of application binary compatibility between
> PostgreSQL releases, some questions arose about C language user-defined
> functions (UDFs) and extensions that depend on them.
>
> [Q1]
> Can the same UDF binary be
Amit Kapila writes:
> On Fri, Jul 1, 2016 at 9:38 AM, Thomas Munro
> wrote:
>> Or maybe just like this?
>>
>> - snapshot->subxip = snapshot->xip + serialized_snapshot->xcnt;
>> + snapshot->subxip = ((TransactionId *) (snapshot + 1)) +
>> + seriali
Hi
2016-06-29 1:51 GMT+02:00 Stefan Keller :
> Hi,
>
> FYI: I'd just like to point you to following two forthcoming standard
> parts from "ISO/IEC JTS 1/SC 32" comittee: one on JSON, and one on
> "Multi-Dimensional Arrays" (SQL/MDA).
>
> They define there some things different as already in PG. S
On Fri, Jul 1, 2016 at 9:38 AM, Thomas Munro
wrote:
> On Fri, Jul 1, 2016 at 3:25 PM, Amit Kapila wrote:
>> On Fri, Jul 1, 2016 at 8:48 AM, Thomas Munro
>> wrote:
>>> If serialized_snapshot->xcnt == 0, then snapshot->xip never gets
>>> initialized to a non-NULL value. Then if serialized_snapsho
On Tue, Jun 28, 2016 at 12:26:00PM +0900, Michael Paquier wrote:
> On Tue, Jun 28, 2016 at 3:22 AM, Christoph Berg wrote:
> > Re: Tom Lane 2016-06-27 <31398.1467036...@sss.pgh.pa.us>
> >> Bjorn Munch reported off-list that this sequence:
> >>
> >> unpack tarball, cd into it
> >> ./configure ...
>
On Fri, Jul 1, 2016 at 3:25 PM, Amit Kapila wrote:
> On Fri, Jul 1, 2016 at 8:48 AM, Thomas Munro
> wrote:
>> If serialized_snapshot->xcnt == 0, then snapshot->xip never gets
>> initialized to a non-NULL value. Then if serialized_snapshot->subxcnt
>> > 0, we set snapshot->subxip = snapshot->xip
On Sun, Jun 26, 2016 at 09:14:05PM -0700, Peter Geoghegan wrote:
> In general, moving tuplesort.c batch memory caller tuples around
> happens when batch memory needs to be recycled, or freed outright with
> pfree().
>
> I failed to take into account that CLUSTER tuplesorts need an extra
> step whe
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> So perhaps the best answer, is not 1 nor 2. Just saying that the routines
> are carefully maintained with a best effort, though sometimes you may need
> to rebuild depending on un
On Thu, Jun 16, 2016 at 01:56:44PM -0500, Kevin Grittner wrote:
> On Thu, Jun 16, 2016 at 1:32 PM, Andres Freund wrote:
>
> > With old_snapshot_threshold=1 I indeed can reproduce the issue. I
> > disabled autovacuum, to make the scheduling more predictable. But it
> > should "work" just as well w
On Fri, Jul 1, 2016 at 8:48 AM, Thomas Munro
wrote:
>
> On Fri, Jul 1, 2016 at 2:17 PM, Michael Paquier
> wrote:
> > On Fri, Jul 1, 2016 at 6:26 AM, Andreas Seltenreich
wrote:
> >> #1 0x00822032 in RestoreSnapshot
(start_address=start_address@entry=0x7f2701d5a110 ) at snapmgr.c:2020
> >
On Fri, Jul 1, 2016 at 12:19 PM, Tsunakawa, Takayuki
wrote:
>> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
>> To make this situation better, what we'd really need is a bunch of work
>> to identify and document the specific APIs that we would promise won't change
>> within a release branch. That id
> From: Tom Lane [mailto:t...@sss.pgh.pa.us]
> "Tsunakawa, Takayuki" writes:
> > Option 2:
> > Rebuild UDFs with the target PostgreSQL distribution.
> > You do not have to rebuild UDFs when you upgrade or downgrade the
> > minor release. (If your UDF doesn't work after changing the minor
> > rele
On Fri, Jul 1, 2016 at 2:17 PM, Michael Paquier
wrote:
> On Fri, Jul 1, 2016 at 6:26 AM, Andreas Seltenreich
> wrote:
>> #1 0x00822032 in RestoreSnapshot
>> (start_address=start_address@entry=0x7f2701d5a110 > memory at address 0x7f2701d5a110>) at snapmgr.c:2020
>
> memcpy(snaps
On Fri, Jul 1, 2016 at 11:33 AM, Tsunakawa, Takayuki
wrote:
> OK, I understood that your choice is option 2. And the UDF developer should
> report the problem and ask for its reason on pgsql-bugs, possibly end up
> haveing to rebuild the UDF. But if so, it sounds like option 1. That is,
> "F
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> On Fri, Jul 1, 2016 at 10:35 AM, Tsunakawa, Takayuki
> wrote:
> > I'd like to document the policy clearly in the upgrade section of
> PostgreSQL manual, eliminating any ambiguity
"Tsunakawa, Takayuki" writes:
> I'd like to document the policy clearly in the upgrade section of PostgreSQL
> manual, eliminating any ambiguity, so that users can determine what they
> should do without fear like "may or may not work". Which of the following
> policies should I base on?
> Op
On Fri, Jul 1, 2016 at 6:26 AM, Andreas Seltenreich wrote:
> #1 0x00822032 in RestoreSnapshot
> (start_address=start_address@entry=0x7f2701d5a110 memory at address 0x7f2701d5a110>) at snapmgr.c:2020
memcpy(snapshot->subxip, serialized_xids + serialized_snapshot->xcnt,
On Thu, Jun 30, 2016 at 8:10 PM, Masahiko Sawada wrote:
> On Thu, Jun 30, 2016 at 3:12 PM, Amit Kapila wrote:
>> On Thu, Jun 30, 2016 at 9:13 AM, Andres Freund wrote:
>>> On 2016-06-30 08:59:16 +0530, Amit Kapila wrote:
On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund wrote:
> On 2016-
On Fri, Jul 1, 2016 at 9:27 AM, Andreas Karlsson wrote:
> Hi,
>
> Here is an initial set of patches related to OpenSSL 1.1. Everything should
> still build fine on older OpenSSL versions (and did when I tested with
> 1.0.2h).
>
> 0001-Fixes-for-compiling-with-OpenSSL-1.1.patch
>
> This patch fixes
On 2016-06-30 18:34:20 -0700, Peter Geoghegan wrote:
> On Thu, Jun 30, 2016 at 6:23 PM, Andres Freund wrote:
> > I plan to, once the tree opens again. Likely needs some considerable
> > updates for recent changes.
>
> Offhand, do you think that CREATE INDEX calls to smgrextend() could be
> apprec
On Fri, Jul 1, 2016 at 10:35 AM, Tsunakawa, Takayuki
wrote:
> I'd like to document the policy clearly in the upgrade section of PostgreSQL
> manual, eliminating any ambiguity, so that users can determine what they
> should do without fear like "may or may not work". Which of the following
> po
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Michael Paquier
> On Fri, Jul 1, 2016 at 9:33 AM, Tsunakawa, Takayuki
> wrote:
> > [Q1]
> > Can the same UDF binary be used with different PostgreSQL minor releases?
> If it is, is it a defined po
On Thu, Jun 30, 2016 at 6:23 PM, Andres Freund wrote:
> I plan to, once the tree opens again. Likely needs some considerable
> updates for recent changes.
Offhand, do you think that CREATE INDEX calls to smgrextend() could be
appreciably affected by this bottleneck? If that's a very involved or
d
On 1 July 2016 at 09:02, Michael Paquier wrote:
> On Fri, Jul 1, 2016 at 9:57 AM, Alvaro Herrera
> wrote:
> > Craig Ringer wrote:
> >> On 30 June 2016 at 20:19, Alvaro Herrera
> wrote:
> >>
> >> > Hmm, so what about a pure 32bit build, if such a thing still exists?
> If
> >> > so and it causes
CREATE FUNCTION pg_temp.bad() RETURNS text[] LANGUAGE plpythonu AS
$$return []$$;
SELECT pg_temp.bad();
bad
-
{}
(1 row)
SELECT pg_temp.bad() = '{}'::text[];
?column?
--
f
(1 row)
Erm?? Turns out this is because
SELECT array_dims(pg_temp.bad()), array_dims('{}'::text[]);
array
On 2016-06-30 18:14:15 -0700, Peter Geoghegan wrote:
> On Tue, Dec 15, 2015 at 10:04 AM, Andres Freund wrote:
> > Took a while. But here we go. The attached version is a significantly
> > revised version of my earlier patch. Notably I've pretty much entirely
> > revised the code in _mdfd_getseg()
On Tue, Dec 15, 2015 at 10:04 AM, Andres Freund wrote:
> Took a while. But here we go. The attached version is a significantly
> revised version of my earlier patch. Notably I've pretty much entirely
> revised the code in _mdfd_getseg() to be more similar to the state in
> master. Also some commen
On Fri, Jul 1, 2016 at 9:57 AM, Alvaro Herrera wrote:
> Craig Ringer wrote:
>> On 30 June 2016 at 20:19, Alvaro Herrera wrote:
>>
>> > Hmm, so what about a pure 32bit build, if such a thing still exists? If
>> > so and it causes the same crash, perhaps we should have one member for
>> > each VS
On Fri, Jul 1, 2016 at 9:33 AM, Tsunakawa, Takayuki
wrote:
> [Q1]
> Can the same UDF binary be used with different PostgreSQL minor releases? If
> it is, is it a defined policy (e.g. written somewhere in the manual, wiki,
> documentation in the source code)?
>
> For example, suppose you build a
Craig Ringer wrote:
> On 30 June 2016 at 20:19, Alvaro Herrera wrote:
>
> > Hmm, so what about a pure 32bit build, if such a thing still exists? If
> > so and it causes the same crash, perhaps we should have one member for
> > each VS version running on 32bit x86.
>
> It's fine for a pure 32-bi
On 30 June 2016 at 20:19, Alvaro Herrera wrote:
> Craig Ringer wrote:
> > On 30 June 2016 at 07:21, Tom Lane wrote:
> >
> > > Alvaro Herrera writes:
> > > > Tom Lane wrote:
> > > >> Thanks for investigating! I'll go commit that change. I wish
> someone
> > > >> would put up a buildfarm critte
On Fri, Jul 1, 2016 at 8:50 AM, Michael Paquier
wrote:
> On Fri, Jul 1, 2016 at 8:48 AM, Alvaro Herrera
> wrote:
>> Michael Paquier wrote:
>>> Yeah, I know. Now my opinion regarding this view is that we should
>>> show information about a currently-working WAL receiver, and that it
>>> has nothi
Hello,
While I was thinking of application binary compatibility between PostgreSQL
releases, some questions arose about C language user-defined functions (UDFs)
and extensions that depend on them.
[Q1]
Can the same UDF binary be used with different PostgreSQL minor releases? If
it is, is it a
Hi,
Here is an initial set of patches related to OpenSSL 1.1. Everything
should still build fine on older OpenSSL versions (and did when I tested
with 1.0.2h).
0001-Fixes-for-compiling-with-OpenSSL-1.1.patch
This patch fixes the code so it builds with OpenSSL 1.1 (except the
CRYPTO_LOCK iss
Hi,
Currently the tuple returned by INSTEAD OF triggers on DELETEs is only
used to determine whether to pretend that the DELETE happened or not,
which is often not helpful enough; for example, the actual tuple might
have been concurrently UPDATEd by another transaction and one or more of
the
On Fri, Jul 1, 2016 at 8:48 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> Yeah, I know. Now my opinion regarding this view is that we should
>> show information about a currently-working WAL receiver, and that it
>> has nothing to do with reporting information of its previous startup state
Michael Paquier wrote:
> On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera
> wrote:
> > Michael Paquier wrote:
> >> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
> >> wrote:
> >> > Also, actually, I see no reason for the conninfo to be shown differently
> >> > regardless of a connection being al
On Fri, Jul 1, 2016 at 8:35 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
>> wrote:
>> > Also, actually, I see no reason for the conninfo to be shown differently
>> > regardless of a connection being already established. If we show the
>>
Michael Paquier wrote:
> On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
> wrote:
> > Also, actually, I see no reason for the conninfo to be shown differently
> > regardless of a connection being already established. If we show the
> > conninfo that the server is trying to use, it might be easie
On Thu, Jun 30, 2016 at 11:24 PM, Alvaro Herrera
wrote:
> Also, actually, I see no reason for the conninfo to be shown differently
> regardless of a connection being already established. If we show the
> conninfo that the server is trying to use, it might be easier to
> diagnose a problem. In sh
On Fri, Jul 1, 2016 at 5:19 AM, Andrew Dunstan wrote:
> On 06/30/2016 03:13 AM, Yury Zhuravlev wrote:
>> Only one extra phase (mkdir build). I think it's not so important. For
>> windows and macosx I used cmake GUI it's so easy.
>
> We need this to be scriptable, not using a GUI.
Definitely agree
On Mon, Jun 27, 2016 at 4:12 PM, Robert Haas wrote:
>>> Tom, do you want to commit this, or do you want me to handle it, or
>>> something else?
>>
>> I was not sure if you'd agreed that the patch was correct, and in any
>> case I thought you wanted to fold it into the upperrel consider_parallel
>>
On Wed, Jun 29, 2016 at 10:52 PM, Peter Eisentraut
wrote:
> I'm happy with this patch.
Great. I have committed it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
On Thu, Jun 30, 2016 at 5:54 PM, Tom Lane wrote:
>> That's pretty much right, but there are two conceptually separate
>> things. The first is whether or not we actually attempt to spawn
>> workers, and the second is whether or not we enter parallel mode.
>> Entering parallel mode enables various
On Thu, Jun 30, 2016 at 1:13 PM, Tom Lane wrote:
> BTW, I just had another thought about reducing the cost of
> has_parallel_hazard checks, to wit: you already made one pass over the
> entire query to verify that there's no PARALLEL UNSAFE functions anywhere.
> If that pass were to also track whet
Robert Haas writes:
> On Thu, Jun 30, 2016 at 12:04 PM, Tom Lane wrote:
>> * It seems like the initialization of root->parallelModeNeeded is still
>> overcomplicated and/or underexplained.
> That's pretty much right, but there are two conceptually separate
> things. The first is whether or not
On Thu, Jun 30, 2016 at 12:04 PM, Tom Lane wrote:
> Robert Haas writes:
>> Here is a new patch addressing (I hope) the above comments and a few
>> other things.
>
> Some more comments:
>
> * It seems like the initialization of root->parallelModeNeeded is still
> overcomplicated and/or underexplai
Running sqlsmith on a streaming slave (master as of f8c5855) is
inconspicuous as long as the master is idle. As soon as I start it on
the master as well, the standby frequently crashes in RestoreSnapshot.
It doesn't seem to be specific to the queries, as they don't trigger a
crash when re-run.
Ba
On 06/30/2016 03:13 AM, Yury Zhuravlev wrote:
Michael Paquier wrote:
You have not tested with macOS, and so did I.
Thanks! I fixed this typo. But for XCode I see more corrections. I
will can fix it today or maybe tomorrow.
It would be nice to come as well with simpler steps than all this
On 06/30/2016 06:26 AM, Oleg Bartunov wrote:
On Wed, Jun 29, 2016 at 7:23 PM, Yury Zhuravlev
wrote:
Hello Hackers.
I decided to talk about the current state of the project:
1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql all
work correctly (all tests pass).
3. Works d
BTW, I just had another thought about reducing the cost of
has_parallel_hazard checks, to wit: you already made one pass over the
entire query to verify that there's no PARALLEL UNSAFE functions anywhere.
If that pass were to also track whether there are any PARALLEL RESTRICTED
functions anywhere,
Robert Haas writes:
> Here is a new patch addressing (I hope) the above comments and a few
> other things.
Some more comments:
* It seems like the initialization of root->parallelModeNeeded is still
overcomplicated and/or underexplained. Why do you not merely set it false
to start with, and all
On Thu, Jun 30, 2016 at 3:12 PM, Amit Kapila wrote:
> On Thu, Jun 30, 2016 at 9:13 AM, Andres Freund wrote:
>> On 2016-06-30 08:59:16 +0530, Amit Kapila wrote:
>>> On Wed, Jun 29, 2016 at 10:30 PM, Andres Freund wrote:
>>> > On 2016-06-29 19:04:31 +0530, Amit Kapila wrote:
>>> >> There is nothin
Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 10:12 PM, Michael Paquier
> wrote:
> > On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera
> > wrote:
> >> Fujii Masao wrote:
> >>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
> >>> wrote:
> >>> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao
> >>>
Fujii Masao writes:
> The document explains that pg_replication_origin_xact_reset() doesn't have
> any argument variables. But it's been actually defined so as to have two
> argument variables with pg_lsn and timestamptz data types, as follows.
> =# \df pg_replication_origin_xact_reset
>
On Thu, Jun 30, 2016 at 10:12 PM, Michael Paquier
wrote:
> On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera
> wrote:
>> Fujii Masao wrote:
>>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
>>> wrote:
>>> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao
>>> > wrote:
>>
>>> >> ISTM that we will
Hi,
The document explains that pg_replication_origin_xact_reset() doesn't have
any argument variables. But it's been actually defined so as to have two
argument variables with pg_lsn and timestamptz data types, as follows.
=# \df pg_replication_origin_xact_reset
On Thu, Jun 30, 2016 at 9:41 PM, Alvaro Herrera
wrote:
> Fujii Masao wrote:
>> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
>> wrote:
>> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
>
>> >> ISTM that we will never be able to get out of this loop if walreceiver
>> >> fails to connect
Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
> wrote:
> > On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
> >> ISTM that we will never be able to get out of this loop if walreceiver
> >> fails to connect to the master (e.g., password is wrong) after we enter
> >> thi
On Thu, Jun 30, 2016 at 9:35 PM, Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
> wrote:
>> On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
>>> (2)
>>> +retry:
>>> +SpinLockAcquire(&walrcv->mutex);
>>> +if (!walrcv->ready_to_display)
>>> +{
>>> +Spi
On Thu, Jun 30, 2016 at 9:30 PM, Michael Paquier
wrote:
> On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
>> (2)
>> +retry:
>> +SpinLockAcquire(&walrcv->mutex);
>> +if (!walrcv->ready_to_display)
>> +{
>> +SpinLockRelease(&walrcv->mutex);
>> +CHECK_FOR_INTERRUPTS()
Fujii Masao wrote:
> On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
> wrote:
> > Alvaro Herrera wrote:
> >
> >> I propose to push this patch, closing the open item, and you can rework
> >> on top -- I suppose you would completely remove the original conninfo
> >> from shared memory and instead on
On Thu, Jun 30, 2016 at 8:59 PM, Fujii Masao wrote:
> (2)
> +retry:
> +SpinLockAcquire(&walrcv->mutex);
> +if (!walrcv->ready_to_display)
> +{
> +SpinLockRelease(&walrcv->mutex);
> +CHECK_FOR_INTERRUPTS();
> +pg_usleep(1000);
> +goto retry;
> +}
> +
Robert Haas wrote:
> It might be better to document this in bgworker.sgml instead. That
> already documents some facts about exiting:
>
>
>If bgw_restart_time for a background worker is
>configured as BGW_NEVER_RESTART, or if it exits with an exit
>code of 0 or is terminated by Te
Craig Ringer wrote:
> On 30 June 2016 at 07:21, Tom Lane wrote:
>
> > Alvaro Herrera writes:
> > > Tom Lane wrote:
> > >> Thanks for investigating! I'll go commit that change. I wish someone
> > >> would put up a buildfarm critter using VS2013, though.
> >
> > > Uh, isn't that what woodlouse i
Gavin Flower wrote:
> I hate the rampant inflation associated with numbering schemes like FireFox
> - the numbers of no meaning at all, other than something non-trivial has
> been changed, with no indication at all about how non-trivial!
I thought this horse had already been beaten to death -- ap
On Thu, Jun 30, 2016 at 6:01 AM, Alvaro Herrera
wrote:
> Alvaro Herrera wrote:
>
>> I propose to push this patch, closing the open item, and you can rework
>> on top -- I suppose you would completely remove the original conninfo
>> from shared memory and instead only copy the obfuscated version th
That didn't cover all the places that needed to be fixed, but I have
re-read the docs and believe I've made things good now.
I have reviewed this thread and verified that all the cases raised in it
now work as desired, so I have marked the open item closed.
Thank you very much!
--
Teodor Sigaev
On Tue, Jun 28, 2016 at 5:22 PM, Amit Kapila wrote:
> On Tue, Jun 28, 2016 at 8:25 AM, Tom Lane wrote:
>
>> In the appendrel case, I tend to agree that the easiest solution is to
>> scan all the children of the appendrel and just mark the whole thing as
>> not consider_parallel if any of them hav
On Wed, Jun 29, 2016 at 7:23 PM, Yury Zhuravlev
wrote:
> Hello Hackers.
>
> I decided to talk about the current state of the project:
> 1. Merge with 9.6 master. 2. plpython2, plpython3, plperl, pltcl, plsql all
> work correctly (all tests pass).
> 3. Works done for all contrib modules. 4. You can
Michael Paquier wrote:
You have not tested with macOS, and so did I.
Thanks! I fixed this typo. But for XCode I see more corrections.
I will can fix it today or maybe tomorrow.
It would be nice to come as well with simpler steps than all this
mkdir build, etc stanza. Perhaps with a wrapper
Hi All,
Sorry for trouble you with small environment setup for testing.
I should to test this with large machine.
What I was testing were involved multiple things same time so quite
confusing .
possible reason for this testing failure is :
1. small hardware
2. haproxy not able to balance connecti
73 matches
Mail list logo
