Could somebody explain me what's going on?
That seems entirely unrelated to what you changed, and curculio's next
run failed even more bizarrely:
commands/explain.o: could not read symbols: File format not recognized
collect2: ld returned 1 exit status
As that is my animal I will take a loo
Hi,
Today at the developer meeting -
https://wiki.postgresql.org/wiki/PgCon_2016_Developer_Meeting - there
was some talk of sharing corporate roadmaps. Postgres Pro put their
roadmap up at https://wiki.postgresql.org/wiki/Postgres_Professional_roadmap
and I have now done the same thing for the da
On 2016/05/18 2:22, Tom Lane wrote:
> Amit Langote writes:
>> On 2016/05/16 22:12, Ildar Musin wrote:
>>> Could you please tell is
>>> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE
>>> query?
>
>> Hmm, I think invalidation would not occur mid-query since it would have
On Tue, May 17, 2016 at 3:33 PM, Peter Geoghegan wrote:
> Fundamentally, since temporary_files_size enforcement simply
> piggy-backs on low-level fd.c file management, without any
> consideration of what the temp files contain, it'll be hard to be sure
> that parallel workers will not have issues.
On Tue, May 17, 2016 at 1:53 PM, Amit Kapila wrote:
> What kind of special treatment are you expecting for temporary_files_size,
> also why do you think it is required? Currently neither we build hash in
> parallel nor there is any form of parallel sort work.
I expect only that temporary_files_s
On Wed, May 18, 2016 at 6:00 AM, Manuel Kniep wrote:
> I realized that inserts into foreign tables are only done row by row.
> Consider copying data from one local table to a foreign table with
>
> INSERT INTO foreign_table(a,b,c) SELECT a,b,c FROM local_table;
>
> When the foreign server is for
Teodor Sigaev writes:
> Seems, this patch isn't liked by curculio [1] buildfarm member, but I'm
> confused
> with diagnostics:
> 2016-05-17 21:43:19.489 CEST [573b7457.547c:3] LOG: statement: CREATE
> EXTENSION
> bloom;
> 2016-05-17 21:43:19.501 CEST [573b7457.547c:4] ERROR: syntax error in
On 18/05/16 09:34, Vik Fearing wrote:
On 17/05/16 21:32, Alvaro Herrera wrote:
Is SCAN_ALL really the best we can do here? The business of having an
underscore in an option name has no precedent (other than
CURRENT_DATABASE and the like).
ALTER DATABASE has options for ALLOW_CONNECTIONS, CONNE
On Tue, May 17, 2016 at 2:02 PM, Tom Lane wrote:
> Jeff Janes writes:
>> I'm getting seg faults on contrib/bloom when updating a tuple which
>> was found via a bloom index.
>
> I pushed a patch that should fix this, but without having tried to
> reproduce the problem locally; so possibly I guesse
On 17/05/16 21:32, Alvaro Herrera wrote:
> Is SCAN_ALL really the best we can do here? The business of having an
> underscore in an option name has no precedent (other than
> CURRENT_DATABASE and the like).
ALTER DATABASE has options for ALLOW_CONNECTIONS, CONNECTION_LIMIT, and
IS_TEMPLATE.
> Ho
On Tue, May 17, 2016 at 4:34 PM, Joshua D. Drake wrote:
> On 05/17/2016 12:32 PM, Alvaro Herrera wrote:
>
>> Syntaxes are;
>> VACUUM (SCAN_ALL) table_name;
>> VACUUM (SCAN_ALL); -- for all tables on database
>>
>> Is SCAN_ALL really the best we can do here? The business of having an
>> und
>
> Would something like this be valid?
>
> OFFSET { start_literal | ( start_expression ) } { ROW | ROWS }
> FETCH { FIRST | NEXT} [ count_literal | ( count_expression ) ] { ROW |
> ROWS } ONLY
>
> Leaving the mandatory parentheses detail to the description, while
> adequate, seems insufficient -
Jeff Janes writes:
> I'm getting seg faults on contrib/bloom when updating a tuple which
> was found via a bloom index.
I pushed a patch that should fix this, but without having tried to
reproduce the problem locally; so possibly I guessed wrong as to
what is causing it. Please test.
Hi,
I realized that inserts into foreign tables are only done row by row.
Consider copying data from one local table to a foreign table with
INSERT INTO foreign_table(a,b,c) SELECT a,b,c FROM local_table;
When the foreign server is for example in another datacenter with long latency,
this as an
On Wed, May 18, 2016 at 12:55 AM, Peter Geoghegan wrote:
>
> temp_file_limit "specifies the maximum amount of disk space that a
> session can use for temporary files, such as sort and hash temporary
> files", according to the documentation. That's not true when parallel
> query is in use, since th
On 05/17/2016 12:32 PM, Alvaro Herrera wrote:
Syntaxes are;
VACUUM (SCAN_ALL) table_name;
VACUUM (SCAN_ALL); -- for all tables on database
Is SCAN_ALL really the best we can do here? The business of having an
underscore in an option name has no precedent (other than
CURRENT_DATABASE and
On Tue, May 17, 2016 at 3:32 PM, Alvaro Herrera
wrote:
> Masahiko Sawada wrote:
>> On Mon, May 16, 2016 at 10:49 AM, Robert Haas wrote:
>
>> > We should support scan_all only with the new-style options syntax for
>> > VACUUM; that is, vacuum (scan_all) rename. That doesn't require
>> > making sc
Allocate all page images at once in generic wal interface
That reduces number of allocation.
Per gripe from Michael Paquier and Tom Lane suggestion.
Branch
--
master
Details
---
http://git.postgresql.org/pg/commitdiff/7c979c95a3700d0bd34c2831f49a9260d505b0f9
Modified Files
---
Masahiko Sawada wrote:
> On Mon, May 16, 2016 at 10:49 AM, Robert Haas wrote:
> > We should support scan_all only with the new-style options syntax for
> > VACUUM; that is, vacuum (scan_all) rename. That doesn't require
> > making scan_all a keyword, which is good: this is a minor feature, and
>
temp_file_limit "specifies the maximum amount of disk space that a
session can use for temporary files, such as sort and hash temporary
files", according to the documentation. That's not true when parallel
query is in use, since the global variable temporary_files_size
receives no special treatment
On Mon, May 16, 2016 at 10:49 AM, Robert Haas wrote:
> On Tue, May 10, 2016 at 10:40 PM, Masahiko Sawada
> wrote:
>> Or second way I came up with is having tool to remove particular _vm
>> file safely, which is executed via SQL or client tool like
>> pg_resetxlog.
>>
>> Attached updated VACUUM S
Jeff Janes writes:
> I'm getting seg faults on contrib/bloom when updating a tuple which
> was found via a bloom index.
> It does not happen on every update, but it does happen within a few
> seconds of run time, so it is readily reproducible. The test harness
> is a bit of a mess, I'll try to cl
On Tue, May 17, 2016 at 12:15 PM, Shay Rojansky wrote:
> Apologies, as usual I didn't read the docs carefully enough.
>
> On Tue, May 17, 2016 at 7:13 PM, Tom Lane wrote:
>
>> Shay Rojansky writes:
>> > A user of mine just raised a strange issue... While it is possible to
>> use a
>> > paramete
Hi
With regard to previous conversations:
http://www.postgresql.org/message-id/flat/CA+q6zcV8qvGcDXurwwgUbwACV86Th7G80pnubg42e-p9gsSf=g...@mail.gmail.com#CA+q6zcV8qvGcDXurwwgUbwACV86Th7G80pnubg42e-p9gsSf=g...@mail.gmail.com
http://www.postgresql.org/message-id/flat/ca+q6zcx3mdxgcgdthzuyswh-apyhh
I'm getting seg faults on contrib/bloom when updating a tuple which
was found via a bloom index.
It does not happen on every update, but it does happen within a few
seconds of run time, so it is readily reproducible. The test harness
is a bit of a mess, I'll try to clean it up and post it if no o
Amit Langote writes:
> On 2016/05/16 22:12, Ildar Musin wrote:
>> Could you please tell is
>> it possible that relcache invalidation occurs during SELECT/UPDATE/DELETE
>> query?
> Hmm, I think invalidation would not occur mid-query since it would have
> acquired a lock on the table.
This is inco
On Tue, May 10, 2016 at 02:06:19PM -0400, Tom Lane wrote:
> Sooner or later we are going to need to go to 8-byte TOAST object
> identifiers. Maybe we should think about doing that sooner not
> later rather than trying to invent some anti-wraparound solution
> here.
Yay! Is there any lift in sepa
Michael Paquier writes:
> On Tue, May 17, 2016 at 4:40 AM, Piotr Stefaniak
> wrote:
> -toc_bytes = offsetof(shm_toc, toc_entry) +nentry * sizeof(shm_toc_entry)
> +toc_bytes = offsetof(shm_toc, toc_entry) + nentry * sizeof(shm_toc_entry)
> + allocated_bytes;
> I don't recall the
On 17 May 2016 at 10:37, David Steele wrote:
> On 5/17/16 10:51 AM, David Fetter wrote:
>
>> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
>>> On 14 May 2016 at 02:49, Tom Lane wrote:
* This year's major release will be 9.6.0, with minor updates 9.6.1,
9.6.2, etc. It's
Apologies, as usual I didn't read the docs carefully enough.
On Tue, May 17, 2016 at 7:13 PM, Tom Lane wrote:
> Shay Rojansky writes:
> > A user of mine just raised a strange issue... While it is possible to
> use a
> > parameter in a LIMIT clause, PostgreSQL does not seem to allow using one
>
Shay Rojansky writes:
> A user of mine just raised a strange issue... While it is possible to use a
> parameter in a LIMIT clause, PostgreSQL does not seem to allow using one in
> a FETCH NEXT clause. In other words, while the following works:
> SELECT 1 LIMIT $1;
> The following generates a synta
Sorry for the pgTAP off-topicness here, hackers. Please feel free to ignore.
On May 17, 2016, at 8:10 AM, Jim Nasby wrote:
> Speaking specifically to is(), what I'd find most useful is if it at least
> hinted that there might be some type shenanigans going on, because I've run
> across somethi
On May 17, 2016, at 7:58 AM, Jim Nasby wrote:
> Probably in an attempt to bypass parse overhead on ingestion.
>
> Possibly because JSONB silently eats duplicated keys while JSON doesn't
> (though in that case even casting to JSONB is probably not what you want).
It’s also when you’d want text
On 5/17/16 10:51 AM, David Fetter wrote:
> On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
>> On 14 May 2016 at 02:49, Tom Lane wrote:
>>> * This year's major release will be 9.6.0, with minor updates 9.6.1,
>>> 9.6.2, etc. It's too late to do otherwise for this release cycle.
>>>
Teodor Sigaev writes:
>> Instead of allocating this memory unconditionally for each buffer,
>> wouldn't it be better to set all the page pointers to NULL in
>> GenericXLogStart and allocate memory only once a buffer is registered
>> in GenericXLogRegisterBuffer when finding a free slot? This patch
A user of mine just raised a strange issue... While it is possible to use a
parameter in a LIMIT clause, PostgreSQL does not seem to allow using one in
a FETCH NEXT clause. In other words, while the following works:
SELECT 1 LIMIT $1;
The following generates a syntax error:
SELECT 1 FETCH NEXT $
On Mon, May 16, 2016 at 6:08 AM, Amit Langote wrote:
> Hi,
>
> Attached patch adds missing "is" in a sentence in backup.sgml.
>
Applied, thanks!
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
On 5/11/16 7:05 PM, David E. Wheeler wrote:
On May 11, 2016, at 10:34 AM, Kevin Grittner wrote:
I'm not clear enough on your intended usage to know whether these
operators are a good fit, but they are sitting there waiting to be
used if they do fit.
Huh. I haven’t had any problems with IS DI
On 5/12/16 4:25 PM, David E. Wheeler wrote:
On May 12, 2016, at 12:02 PM, Tom Lane wrote:
Andrew mentions in the extension you pointed to that providing a default
comparison operator would enable people to do UNION, DISTINCT, etc on JSON
columns without thinking about it. I'm not convinced th
On Tue, May 17, 2016 at 01:45:09PM +0800, Craig Ringer wrote:
> On 14 May 2016 at 02:49, Tom Lane wrote:
> > * This year's major release will be 9.6.0, with minor updates 9.6.1,
> > 9.6.2, etc. It's too late to do otherwise for this release cycle.
> >
> > * Next year's major release will be 10.0,
On 5/10/16 4:12 PM, Andres Freund wrote:
The catalog representation (as in pg_class.reltoastrelid) isn't entirely
clear to me. One way would be to invert pg_class.reltoastrelid's
meaning and have the toast table point to the table it stores values
for. That'd also open the potential of having on
In the contrib/intarray benchmarking script bench.pl, the -e option to print
the plan via EXPLAIN is using the DBI do() method which discards output
resulting in nothing being printed. Judging by the usage help (“show explain”)
I assume the intention is to print the plan to STDOUT when invoked (wh
Hi Ildar,
On 2016/05/16 22:12, Ildar Musin wrote:
> Hi Amit,
>
> I'm running some experiments based on your infrastructure trying to
> optimize SELECT queries. At some point I need to get PartitionDesc for
> relation and to do it I'm using RelationGetPartitionDesc() function.
> Problem is that t
43 matches
Mail list logo