Hi
2016-11-25 15:32 GMT+01:00 Pavel Stehule :
> Hi
>
> 2016-10-14 9:56 GMT+02:00 Craig Ringer :
>
>> On 14 October 2016 at 13:30, Pavel Stehule
>> wrote:
>> > Hi,
>> >
>> > long time I working on this topic. Session server side variables are one
>> > major missing feature in PLpgSQL. Now I hope,
On 11/27/16 10:15 AM, Tom Lane wrote:
Jim Nasby writes:
I suspect this is unrelated, but I've run into another oddity with
extension dependency: if an extension creates any temporary objects the
extension will install and function correctly... until the backend that
created the extension quits.
On 11/24/16 8:18 AM, Bruce Momjian wrote:
What if we used BRIN to find heap pages where the new row was in the
page BRIN min/max range, and the heap page had free space. Only if that
fails do we put is somewhere else in the heap.
That would certainly be useful. You'd have to figure
On Thu, Nov 3, 2016 at 10:46 PM, Robert Haas wrote:
> libpq: Allow connection strings and URIs to specify multiple hosts.
>
> It's also possible to specify a separate port for each host.
>
> Previously, we'd loop over every address returned by looking up the
> host name; now, we'll try every addre
Hi hackers,
HASH_CHUNK_SIZE is defined as 1024 * 32 = 0x8000. The size of the
chunks that nodeHash.c passes to palloc is that +
offsetof(HashJoinMemoryChunkData, data), which is 0x20 here. So we
ask aset.c for 0x8020 bytes. Sizes in that range are sent directly to
malloc, after adding ALLOC_BLO
On Thu, Nov 24, 2016 at 11:15 PM, Andreas Karlsson wrote:
> Never mind, I had not fetched the latest master. Once I had done so these
> tests were both broken in my rebased branch and in the master branch without
> any modifications. I guess I will have to bisect this once I get home.
>
> Inof for
On Wed, Nov 23, 2016 at 2:03 PM, Andres Freund wrote:
> Here's my WIP series addressing this and related problems. With this
> we're again noticeably faster than the dynahash implementation, in both
> the case here, and the query you brought up over IM.
>
> This definitely needs some more TLC, but
On Sun, Nov 27, 2016 at 10:30 PM, Tom Lane wrote:
> Robert Haas writes:
>> I think you made this considerably more fragile with those changes.
>
> This code will only ever run at all in corner cases --- cases that
> almost by definition will go untested in the standard regression tests.
> The pro
On Mon, Nov 28, 2016 at 9:20 AM, Thomas Munro
wrote:
> It would work, but I suppose you might call it overkill. If they were
> cooperating to build the bitmap in parallel then a barrier might look
> more tempting, because then they'd all be waiting for each other to
> agree that they've all finis
On Mon, Nov 28, 2016 at 3:49 PM, Amit Kapila wrote:
> Do you think that using barrier's will simplify the patch as compared
> to using condition variables because in that case, it will make sense
> to use barriers?
It would work, but I suppose you might call it overkill. If they were
cooperating
On Mon, Nov 28, 2016 at 4:50 AM, Robert Haas wrote:
>
> Well, my original email did contain a discussion of the need for
> delete-marking. I said that you couldn't do in-place updates when
> indexed columns were modified unless the index AMs had support for
> delete-marking, which is the same poi
Robert Haas writes:
> I think you made this considerably more fragile with those changes.
This code will only ever run at all in corner cases --- cases that
almost by definition will go untested in the standard regression tests.
The problems you suggest it has are corner-squared or corner-cubed c
On Mon, Nov 28, 2016 at 12:14 PM, Robert Haas wrote:
> I think you made this considerably more fragile with those changes.
> Now, if we fail to drop a temporary table, we won't do any actual
> vacuuming, either. I'd be willing to bet someone will get hosed
> because of that who would have been mu
>> --- a/contrib/pgstattuple/pgstatapprox.c
>> +++ b/contrib/pgstattuple/pgstatapprox.c
>> @@ -70,7 +70,7 @@ statapprox_heap(Relation rel, output_type *stat)
>> TransactionId OldestXmin;
>> uint64 misc_count = 0;
>>
>> - OldestXmin = GetOldestXmin(rel, true);
>> + Oldes
On Sun, Nov 27, 2016 at 9:33 PM, Tom Lane wrote:
> I pushed a patch to deal with this. I ended up simplifying the previous
> commit considerably by getting rid of the commit-multiple-deletions-per-
> transaction business. I do not think that this code will get exercised
> enough, either in the f
On Sun, Nov 27, 2016 at 8:26 PM, Tsunakawa, Takayuki
wrote:
> I see. autovacuum is certainly almost unpredictable, at least for those who
> are not aware of its existence and tuning. Recently, one of our customers
> faced the inability to perform INSERTs because of xid wraparound.
> Their work
On Mon, Nov 28, 2016 at 11:46 AM, Tom Lane wrote:
> Michael Paquier writes:
>> In order to reproduce the failure I have just inserted a manual
>> pg_usleep before looping through the list of orphan_oids, and after
>> dropping manually from another session a couple of orphaned temporary
>> tables
On Mon, Nov 28, 2016 at 8:11 AM, Thomas Munro
wrote:
> When a new participant arrives here, if it finds that we're still in
> the INIT phase, then it enters an election to see if it can build the
> bitmap; one lucky participant wins and does that, while any other
> participants twiddle their thumb
On Sat, Nov 26, 2016 at 8:57 AM, Tom Lane wrote:
> Could you show us a test case that provokes the warning you see?
Nothing to worry about IMO. Looking at the patch, there is no
pg_class_relation declared, so this would not even compile...
--
Michael
--
Sent via pgsql-hackers mailing list (pg
Michael Paquier writes:
> In order to reproduce the failure I have just inserted a manual
> pg_usleep before looping through the list of orphan_oids, and after
> dropping manually from another session a couple of orphaned temporary
> tables I was able to see the failure. Attached is a proposal of
On Sun, Nov 27, 2016 at 3:34 PM, Dilip Kumar wrote:
> On Sun, Nov 27, 2016 at 3:15 AM, Robert Haas wrote:
>> I think the Barrier stuff has a process for choosing one worker to
>> conduct a particular phase. So it seems like if the Barrier API is
>> well-designed, you should be able to use it to
On Mon, Nov 28, 2016 at 11:33 AM, Tom Lane wrote:
> I pushed a patch to deal with this. I ended up simplifying the previous
> commit considerably by getting rid of the commit-multiple-deletions-per-
> transaction business. I do not think that this code will get exercised
> enough, either in the
Magnus Hagander writes:
> Ok, we now have it. https://postgr.es/m/messageid will redirect to that
> messageid in the main archives.
I pushed a patch using this new convention:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=dafa0848da11260e9510c699e7060171336cb550
While the UR
On Mon, Nov 28, 2016 at 10:02 AM, Robert Haas wrote:
> On Sun, Nov 27, 2016 at 5:45 PM, Tom Lane wrote:
>> So the problem seems to be confirmed to exist, but be of low probability
>> and low consequences, in back branches. I think we only need to fix it in
>> HEAD. The lock acquisition and stat
Robert Haas writes:
> Thanks for digging into this. I failed to notice while reviewing that
> the way we were printing the message had changed a bit in the new
> code, and I just totally overlooked the existing locking hazards.
> Oops.
I pushed a patch to deal with this. I ended up simplifying
From: Robert Haas [mailto:robertmh...@gmail.com]
> On Thu, Nov 24, 2016 at 2:32 AM, Tsunakawa, Takayuki
> wrote:
> > IMHO, overall, there should be pros and cons of the current approach and
> the new UNDo one (like Oracle?), depending on the workload. Under
> update-heavy workload, the UNDO metho
On Sun, Nov 27, 2016 at 5:45 PM, Tom Lane wrote:
> So the problem seems to be confirmed to exist, but be of low probability
> and low consequences, in back branches. I think we only need to fix it in
> HEAD. The lock acquisition and status recheck that I proposed before
> should be sufficient.
On Sun, 27 Nov 2016 21:54:46 +0100
Gilles Darold wrote:
> Again, patches patch_pg_current_logfile-v14.diff.doc_linux_default-v2
> have not been included because I don't see any reason to talk
> especially about systemd. If you talk about systemd you must talk
> about other stderr handler by all s
On Sat, Nov 26, 2016 at 10:49 PM, Amit Kapila wrote:
> On Fri, Nov 25, 2016 at 11:23 PM, Bruce Momjian wrote:
>> On Thu, Nov 24, 2016 at 12:23:28PM -0500, Robert Haas wrote:
>>> I agree up to a point. I think we need to design our own system as
>>> well as we can, not just copy what others have
On 27/11/16 23:42, Erik Rijkers wrote:
> On 2016-11-27 19:57, Petr Jelinek wrote:
>> On 22/11/16 18:42, Erik Rijkers wrote:
>>> On 2016-11-20 19:02, Petr Jelinek wrote:
>>>
0001-Add-support-for-TE...cation-slots-v8.patch.gz (~8 KB)
0002-Refactor-libpqwalreceiver-v8.patch.gz (~9 KB)
0
I wrote:
> Buildfarm member skink failed a couple days ago:
> http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2016-11-25%2017%3A50%3A01
Ah ... I can reproduce this with moderate reliability (one failure every
10 or so iterations of the regression tests) by inserting a delay just
be
On 2016-11-27 19:57, Petr Jelinek wrote:
On 22/11/16 18:42, Erik Rijkers wrote:
On 2016-11-20 19:02, Petr Jelinek wrote:
0001-Add-support-for-TE...cation-slots-v8.patch.gz (~8 KB)
0002-Refactor-libpqwalreceiver-v8.patch.gz (~9 KB)
0003-Add-PUBLICATION-catalogs-and-DDL-v8.patch.gz (~30 KB)
0004
On 2016-11-27 22:21:49 +0100, Petr Jelinek wrote:
> On 27/11/16 21:47, Andres Freund wrote:
> > Hi,
> >
> >>> +typedef struct SlabBlockData *SlabBlock; /* forward reference */
> >>> +typedef struct SlabChunkData *SlabChunk;
> >>>
> >>> Can we please not continue hiding pointers behind type
On Tue, Nov 22, 2016 at 08:59:09AM -0200, Matheus de Oliveira wrote:
> Hi all,
>
> I noticed that we have no option to set default privileges for newly
> created schemas, other than calling GRANT explicitly. At work I use ALTER
> DEFAULT PRIVILEGE (ADP) command extensively, as the developers are
>
On 27/11/16 21:47, Andres Freund wrote:
> Hi,
>
>>> +typedef struct SlabBlockData *SlabBlock; /* forward reference */
>>> +typedef struct SlabChunkData *SlabChunk;
>>>
>>> Can we please not continue hiding pointers behind typedefs? It's a bad
>>> pattern, and that it's fairly widely used
Hi,
I did look at the code a bit. The first 6 patches seem reasonable.
I don't understand why some patches are separate tbh (like 7-10, or 11).
About the 0009:
> diff --git a/contrib/pg_visibility/pg_visibility.c
> b/contrib/pg_visibility/pg_visibility.c
> index 9985e3e..4fa3ad4 100644
> --- a/c
Hi Karl,
I've attached the v15 of the patch that applies your changes/fixes and
remove the call to strtok().
I've not applied patch patch_pg_current_logfile-v14.diff.backoff to
prevent constant call of logfile_writename() on a busy system (errno =
ENFILE | EMFILE). I think this can be done quite
Hi,
> > +typedef struct SlabBlockData *SlabBlock; /* forward reference */
> > +typedef struct SlabChunkData *SlabChunk;
> >
> > Can we please not continue hiding pointers behind typedefs? It's a bad
> > pattern, and that it's fairly widely used isn't a good excuse to
> > introduce furthe
On Sun, Nov 27, 2016 at 09:12:47AM -0600, Jim Nasby wrote:
> On 11/27/16 12:16 AM, Michael Paquier wrote:
> > date: Thu, 2 Jul 2015 17:24:36 -0400
> > Make numeric form of PG version number readily available in Makefiles.
>
> If you don't want to wait for that,
I wonder whether a back-patch to 9.
Paul Ramsey writes:
> On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane wrote:
>> Why doesn't hs_fdw.h have a collation?
> I think I'm missing something, I cannot find a file like that anywhere.
I was referring to the variable shown in your EXPLAIN.
> With respect to this particular example, is this a
On 27 November 2016 at 11:29, Tom Lane wrote:
> Dave Cramer writes:
> > We are proposing changing the JDBC version from
> > 9.4. to 42.x.x
>
> > We have two issues we are trying to address here.
>
> > 1) we do not want to be tied to the server release schedule. This has
> been
> > somewhat a
On Sun, Nov 27, 2016 at 9:31 AM, Tom Lane wrote:
> Paul Ramsey writes:
> > On Fri, Nov 25, 2016 at 11:30 AM, Paul Ramsey >
> > wrote:
> >> I've been trying to figure out an issue with operators not being pushed
> >> down for user defined types, in this case "hstore". TL;DR:
> >>
> >> hstore=# e
Thank you for answers.
2016-11-19 21:28 GMT+03:00 Michael Paquier :
> On Thu, Nov 17, 2016 at 1:17 PM, Alvaro Herrera
> wrote:
>> It's a bug. You're right that we need to handle the object class
>> somewhere. Perhaps I failed to realize that tsconfigs could get
>> altered.
>
> It seems to me th
On 22/11/16 18:42, Erik Rijkers wrote:
> On 2016-11-20 19:02, Petr Jelinek wrote:
>
>> 0001-Add-support-for-TE...cation-slots-v8.patch.gz (~8 KB)
>> 0002-Refactor-libpqwalreceiver-v8.patch.gz (~9 KB)
>> 0003-Add-PUBLICATION-catalogs-and-DDL-v8.patch.gz (~30 KB)
>> 0004-Add-SUBSCRIPTION-catalog-and
Buildfarm member skink failed a couple days ago:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2016-11-25%2017%3A50%3A01
I believe the interesting parts of the log are
2016-11-25 18:29:03.285 UTC [583882e7.2a45:1] LOG: autovacuum: dropping orphan
temp table "(null)"."(null)" i
On 11/27/2016 07:25 PM, Petr Jelinek wrote:
On 15/11/16 01:44, Tomas Vondra wrote:
Attached is v6 of the patch series, fixing most of the points:
* common bits (valgrind/randomization/wipe) moved to memdebug.h/c
Instead of introducing a new header file, I've added the prototypes to
memdebug.h
On 15/11/16 01:44, Tomas Vondra wrote:
> Attached is v6 of the patch series, fixing most of the points:
>
> * common bits (valgrind/randomization/wipe) moved to memdebug.h/c
>
> Instead of introducing a new header file, I've added the prototypes to
> memdebug.h (which was already used for the val
Paul Ramsey writes:
> On Fri, Nov 25, 2016 at 11:30 AM, Paul Ramsey
> wrote:
>> I've been trying to figure out an issue with operators not being pushed
>> down for user defined types, in this case "hstore". TL;DR:
>>
>> hstore=# explain (verbose) select * from hs_fdw where h -> 'a' = '1';
>> QUE
On Sun, Nov 27, 2016 at 03:16:37PM +0900, Michael Paquier wrote:
> On Sun, Nov 27, 2016 at 9:16 AM, David Fetter wrote:
> > While updating some extensions, I noticed that pg_config --version
> > produces output that's...maybe not quite as useful as it might be, at
> > least to a machine, so I'd li
>From looking at other databases' docs, it seems like the behavior of
various JSON-related operators / functions are described partially in terms
of a "json path expression":
* In Oracle, "JSON_TABLE", "JSON_exists_column", "JSON_value_column": [1]
* In MySQL: [2]
* In DB2: [3]
* In MS SQL Server:
Dave Cramer writes:
> We are proposing changing the JDBC version from
> 9.4. to 42.x.x
> We have two issues we are trying to address here.
> 1) we do not want to be tied to the server release schedule. This has been
> somewhat addressed already but has left us with the second issue.
> 2) Av
Jim Nasby writes:
> I suspect this is unrelated, but I've run into another oddity with
> extension dependency: if an extension creates any temporary objects the
> extension will install and function correctly... until the backend that
> created the extension quits. This is VERY confusing if you
On 11/26/16 10:25 AM, Tom Lane wrote:
It suddenly struck me that the problem being complained of in bug #14434
is that dependency.c's findDependentObjects() is handling extension
dependencies incorrectly.
I suspect this is unrelated, but I've run into another oddity with
extension dependency:
Jim Nasby writes:
> On 11/27/16 2:01 AM, Amos Bird wrote:
>>
>>> I was thinking about introducing a new GUC, named something like
>>> default_index_tablespace, which would need to have at least these
>>> behaviors:
>>
>> Should we also consider the chidren tables as mentioned by Corey?
>
> Wouldn
On 11/27/16 2:01 AM, Amos Bird wrote:
I was thinking about introducing a new GUC, named something like
default_index_tablespace, which would need to have at least these
behaviors:
Should we also consider the chidren tables as mentioned by Corey?
Wouldn't point #2 handle that?
2. index tab
On 11/27/16 12:16 AM, Michael Paquier wrote:
date: Thu, 2 Jul 2015 17:24:36 -0400
Make numeric form of PG version number readily available in Makefiles.
If you don't want to wait for that, you can use [1] in shell or Make to
accomplish something similar. Looks like there is a dotted MAJORVERSI
We are proposing changing the JDBC version from
9.4. to 42.x.x
We have two issues we are trying to address here.
1) we do not want to be tied to the server release schedule. This has been
somewhat addressed already but has left us with the second issue.
2) Avoid confusion as to which version
On Mon, Nov 21, 2016 at 11:04 AM, Magnus Hagander
wrote:
> On Sun, Nov 20, 2016 at 11:02 PM, Andrew Dunstan
> wrote:
>
>>
>>
>> On 11/20/2016 11:34 AM, Magnus Hagander wrote:
>>
>>>
>>>
>>>
>>> I'm prepared to go along with this if there's general agreement.
>>> However, maybe we should
On Sun, Nov 27, 2016 at 1:16 AM, Tom Lane wrote:
> If we just did points 1 and 2 then a bool GUC would suffice. I'm
> not sure how to handle all three cases cleanly. We could define
> default_index_tablespace as empty to get point 1 or a tablespace
> name to get point 3, but that leaves us havin
On 26 Nov. 2016 23:40, "Robert Haas" wrote:
>
> On Wed, Nov 23, 2016 at 8:37 AM, Craig Ringer
wrote:
> >>> The last checkpoint's oldestXid, and ShmemVariableCache's oldestXid,
> >>> are already held down by ProcArray's catalog_xmin. But that doesn't
> >>> mean we haven't removed newer tuples from
> I was thinking about introducing a new GUC, named something like
> default_index_tablespace, which would need to have at least these
> behaviors:
Should we also consider the chidren tables as mentioned by Corey?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make ch
61 matches
Mail list logo
