Hello
Six years ago we did discuss about global temporary tables - persistent
schema, ephemeral data.
http://postgresql.nabble.com/idea-global-temp-tables-td2007217.html
I am thinking so some reasons why implement this feature are valid:
* we can get some performance benefit against current tem
2015-02-02 11:15 GMT+01:00 Pavel Stehule :
> Hello
>
> Six years ago we did discuss about global temporary tables - persistent
> schema, ephemeral data.
>
> http://postgresql.nabble.com/idea-global-temp-tables-td2007217.html
>
> I am thinking so some reasons why implement this feature are valid:
>
> Some was changed from 2009:
>
> * We have updatable CTE
>
> * We have unlogged tables
>
> Opened questions:
>
> 1. Name and conformance with standard of this feature - because we doesn't
> support modules, a mapping ANSI -> PG should not be trivial
>
> 2. Implementation
>
> I see three possible w
2015-02-02 11:51 GMT+01:00 Atri Sharma :
>
> Some was changed from 2009:
>>
>> * We have updatable CTE
>>
>> * We have unlogged tables
>>
>> Opened questions:
>>
>> 1. Name and conformance with standard of this feature - because we
>> doesn't support modules, a mapping ANSI -> PG should not be tri
Hi,
On 2015-02-02 11:15:22 +0100, Pavel Stehule wrote:
> Six years ago we did discuss about global temporary tables - persistent
> schema, ephemeral data.
>
> http://postgresql.nabble.com/idea-global-temp-tables-td2007217.html
>
> I am thinking so some reasons why implement this feature are vali
2015-02-02 12:04 GMT+01:00 Andres Freund :
> Hi,
>
> On 2015-02-02 11:15:22 +0100, Pavel Stehule wrote:
> > Six years ago we did discuss about global temporary tables - persistent
> > schema, ephemeral data.
> >
> > http://postgresql.nabble.com/idea-global-temp-tables-td2007217.html
> >
> > I am t
Hi all,
Attached patch adds VERBOSE option to REINDEX commands.
The another maintaining commands(VACUUM FULL, CLUSTER) has VERBOSE option,
but REINDEX has not been had it.
Examples is following,
- REINDEX TABLE
[postgres][5432](1)=# REINDEX TABLE VERBOSE hoge;
INFO: index "hoge_idx" was reindex
On 2015-02-02 12:24:44 +0100, Pavel Stehule wrote:
> 2015-02-02 12:04 GMT+01:00 Andres Freund :
> > > 2.b - using unlogged tables for holding statistics, relfilenode, and all
> > > necessary data
> >
> > I can't follow why that'd achieve anything?
> >
>
> 1. Main catalogue will be stable.
> 2. The
On Mon, Feb 2, 2015 at 8:31 PM, Sawada Masahiko wrote:
> Attached patch adds VERBOSE option to REINDEX commands.
> Please give me feedbacks.
This could provide useful feedback to users. Now, I think that it may
be better to provide the keyword VERBOSE before the type of object
reindexed as REINDEX
>
>
> > 1. Main catalogue will be stable.
> > 2. There is not necessary to implement new storage and it can helps with
> > transaction support.
>
> The amount of complexity that'd be involved to store catalog data in a
> separate relation around the caches and accesses would be significant. I
> don
On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane wrote:
> I think it's time we changed the policy of including all release notes
> back to the beginning in Appendix E. I seem to recall we debated this
> once before, and decided that we liked having all that project history
> visible. But Release 6.0 is
On Sat, Jan 31, 2015 at 8:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> I understand Andrew to be saying that if you take a 6-character string
>> and convert it to a JSON string and then back to text, you will
>> *usually* get back the same 6 characters you started with ... unless
>> the first
2015-02-02 13:15 GMT+01:00 Andres Freund :
> On 2015-02-02 12:24:44 +0100, Pavel Stehule wrote:
> > 2015-02-02 12:04 GMT+01:00 Andres Freund :
> > > > 2.b - using unlogged tables for holding statistics, relfilenode, and
> all
> > > > necessary data
> > >
> > > I can't follow why that'd achieve any
2015-02-02 13:36 GMT+01:00 Atri Sharma :
>
>> > 1. Main catalogue will be stable.
>> > 2. There is not necessary to implement new storage and it can helps with
>> > transaction support.
>>
>> The amount of complexity that'd be involved to store catalog data in a
>> separate relation around the cac
On Fri, Jan 30, 2015 at 3:58 AM, Heikki Linnakangas
wrote:
>> During my tests, I did not observe the significance of
>> min_recycle_wal_size
>> parameter yet. Ofcourse, i had sufficient disk space for pg_xlog.
>>
>> I would like to understand more about "min_recycle_wal_size" parameter. In
>> theo
On Tue, Jan 20, 2015 at 4:01 AM, Fabien COELHO wrote:
>> I had a look at this patch. This patch adds some text below a table
>> of functions. Immediately above that table, there is this existing
>> language:
>>
>> The functions working with double precision data are mostly
>> implemented on
On Fri, Oct 24, 2014 at 8:51 PM, Jim Nasby wrote:
> The comment for the BackgroundWorkerSlot structure tripped me up reviewing
> Robert's background worker patch; it made it clear that you need to use a
> memory barrier before setting in_use, but normally you'd never need to worry
> about that bec
On Mon, Feb 2, 2015 at 9:21 PM, Michael Paquier
wrote:
> On Mon, Feb 2, 2015 at 8:31 PM, Sawada Masahiko wrote:
>> Attached patch adds VERBOSE option to REINDEX commands.
>> Please give me feedbacks.
> This could provide useful feedback to users.
Thanks.
> Now, I think that it may
> be better t
On Fri, Nov 7, 2014 at 9:03 PM, Peter Eisentraut wrote:
> On 11/4/14 3:52 PM, Peter Eisentraut wrote:
>> Here are patches to address that. First, it reports errors when
>> attempting to create a tar header that would truncate file or symlink
>> names. Second, it works around the problem in the t
On Mon, Feb 2, 2015 at 6:34 PM, Pavel Stehule
wrote:
>
>
> 2015-02-02 13:36 GMT+01:00 Atri Sharma :
>
>>
>>> > 1. Main catalogue will be stable.
>>> > 2. There is not necessary to implement new storage and it can helps
>>> with
>>> > transaction support.
>>>
>>> The amount of complexity that'd be
On Fri, Jan 23, 2015 at 4:17 PM, Brar Piening wrote:
> Am 23.01.2015 um 09:17 schrieb Abhijit Menon-Sen:
>> At 2014-06-03 22:30:50 -0400, pete...@gmx.net wrote:
>>> I'm not sure whether the following coding actually detects any errors:
>>>
>>> Solution.pm:
>>>
>>> open(P, "cl /? 2>&1 |") || d
On Mon, Feb 2, 2015 at 9:57 PM, Robert Haas wrote:
> On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane wrote:
>> I propose that we go over to a policy of keeping in HEAD only release
>> notes for actively maintained branches, and that each back branch should
>> retain notes only for branches that were ac
On 2014-11-12 16:11:58 -0500, Robert Haas wrote:
> On Wed, Nov 12, 2014 at 4:10 PM, Robert Haas wrote:
> > On Thu, Nov 6, 2014 at 9:50 AM, Peter Eisentraut wrote:
> >> If REINDEX cannot work without an exclusive lock, we should invent some
> >> other qualifier, like WITH FEWER LOCKS.
> >
> > What
Hi,
On 2015-02-02 08:36:41 -0500, Robert Haas wrote:
> Also, I'd like to propose that we set the default value of
> max_checkpoint_segments/checkpoint_wal_size to something at least an
> order of magnitude larger than the current default setting.
+1
I think we need to increase checkpoint_timeout
On 30 January 2015 at 21:58, Peter Geoghegan wrote:
> On Fri, Jan 30, 2015 at 6:59 AM, Geoff Winkless wrote:
>> I suppose there's no reason why we couldn't use a no-op ON CONFLICT
>> UPDATE anyway
>
> Right. IGNORE isn't really all that compelling for that reason. Note
> that this will still lock
On Sun, Feb 1, 2015 at 9:14 PM, Noah Misch wrote:
> On Sun, Feb 01, 2015 at 10:50:24AM -0500, Tom Lane wrote:
> > Peter Eisentraut writes:
> > > At least writing `pg_config --sysconfdir` indicates that it's in an
> > > installation-specific location, whereas hardcoding /etc will create
> > > con
Robert Haas writes:
> On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane wrote:
>> I propose that we go over to a policy of keeping in HEAD only release
>> notes for actively maintained branches, and that each back branch should
>> retain notes only for branches that were actively maintained when it split
On Mon, Feb 2, 2015 at 3:44 PM, Tom Lane wrote:
> Robert Haas writes:
> > On Sun, Feb 1, 2015 at 11:10 PM, Tom Lane wrote:
> >> I propose that we go over to a policy of keeping in HEAD only release
> >> notes for actively maintained branches, and that each back branch should
> >> retain notes o
Hi,
I've, for a while, pondered whether we couldn't find a easier way than
CSN to make snapshots cheaper as GetSnapshotData() very frequently is
one of the top profile entries. Especially on bigger servers, where the
pretty much guaranteed cachemisses are quite visibile.
My idea is based on the o
Sawada Masahiko writes:
> On Mon, Feb 2, 2015 at 9:21 PM, Michael Paquier
> wrote:
>> Now, I think that it may
>> be better to provide the keyword VERBOSE before the type of object
>> reindexed as REINDEX [ VERBOSE ] object.
> Actually, my first WIP version of patch added VERBOSE word at before
Magnus Hagander writes:
> Yeah, the PDF size is definitely someting to consider in this context. And
> the limits.
> But if we can find some good way to "archive" or preserve them *outside the
> main docs* that should solve this problem, no? We could keep them in SGML
> even, but make sure they a
On Mon, Feb 2, 2015 at 10:43 AM, Tom Lane wrote:
> Magnus Hagander writes:
>> Yeah, the PDF size is definitely someting to consider in this context. And
>> the limits.
>
>> But if we can find some good way to "archive" or preserve them *outside the
>> main docs* that should solve this problem, no
On 2 February 2015 at 14:32, Geoff Winkless wrote:
> Mmmf. So I would have to make sure that my source tuples were unique
> before doing the INSERT (otherwise the first ON CONFLICT UPDATE for a
> tuple would block any other)? That's potentially very slow :(
Replying to my own message, because it
On 01/18/2015 04:48 AM, Peter Geoghegan wrote:
I think that the fundamental, unfixable race condition here is the
disconnect between index tuple insertion and checking for would-be
exclusion violations that exclusion constraints naturally have here,
that unique indexes naturally don't have [1] (n
On 01/30/2015 01:38 AM, Peter Geoghegan wrote:
I have not addressed the recently described problems with exclusion
constraints. I hope we can do so shortly. Simply removing IGNORE
support until such time as we straighten that all out (9.6?) seems
like the simplest solution. No need to block the p
On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
wrote:
> I noticed that when updating security barrier views on foreign tables,
> we fail to give FOR UPDATE to selection queries issued at ForeignScan.
> Here is an example.
>
> postgres=# create foreign table base_ftbl (person text, visibility text)
On 01/03/2015 10:42 PM, Peter Geoghegan wrote:
On Sat, Jan 3, 2015 at 2:41 AM, Heikki Linnakangas
wrote:
A-ha, I see. And this can happen without INSERT ON CONFLICT, too? In that
case, one of the transactions is bound to error and roll back anyway, but
you get a deadlock error instead of the co
On 01/31/2015 12:25 AM, Jim Nasby wrote:
[snip]
It's a bit more complex than that. First, toast isn't limited to
bytea; it holds for ALL varlena fields in a table that are allowed to
store externally. Second, the limit is actually per-table: every table
gets it's own toast table, and each toas
The attached patch adds a LINE: ... hint when schemaname.typename
results in a schema which does not exist. I came across this when a
missing comma in a SELECT list resulted in an error without a location
in a query a few thousand lines long.
Before:
(postgres@[local]:5432 14:41:25) [postgres]> s
On 02/02/2015 07:54 AM, Robert Haas wrote:
>> I could live with keeping the ancient-branch release note SGML files
>> > around in HEAD --- I'd hoped to reduce the size of tarballs a bit, but the
>> > savings by that measure would only be a few percent (at present anyway).
>> > What's more important
Josh Berkus writes:
> On 02/02/2015 07:54 AM, Robert Haas wrote:
>> The last 5 branches only takes us back to 9.0, which isn't very far.
>> I would want to have at least the 8.x branches in the SGML build, and
>> maybe the 7.x branches as well. I would be happy to drop anything
>> pre-7.x from th
On 1/30/15, Jim Nasby wrote:
> On 1/30/15 11:54 AM, Roger Pack wrote:
On 1/29/15, Roger Pack wrote:
> Hello. I see on this page a mention of basically a 4B row limit for
> tables that have BLOB's
Oops I meant for BYTEA or TEXT columns, but it's possible the
reasoning
On 2/2/15, José Luis Tallón wrote:
> On 01/31/2015 12:25 AM, Jim Nasby wrote:
>> [snip]
>> It's a bit more complex than that. First, toast isn't limited to
>> bytea; it holds for ALL varlena fields in a table that are allowed to
>> store externally. Second, the limit is actually per-table: every t
On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
> The existing release notes are not conveniently searchable, for sure;
> they're not in a single file, and they don't show up on a single page
> on the Web, and I've never seen a PDF-searching tool that didn't suck.
> So I'm bemused by Robert's insi
On Sat, Jan 31, 2015 at 8:28 AM, Marco Nenciarini
wrote:
> Il 30/01/15 03:54, Michael Paquier ha scritto:
>> On Fri, Jan 30, 2015 at 2:49 AM, Tom Lane wrote:
>>> There is at least one other bug in that function now that I look at it:
>>> in event of a readdir() failure, it neglects to execute clo
On 1/27/15 4:08 AM, Abhijit Menon-Sen wrote:
> Anyway, I think it's reasonably clear now that pgaudit is unlikely to
> make it into 9.5 in any form, so I'll find something else to do.
That's unfortunate. I've been following this thread for a while with
some interest (and anticipation).
The role
* Robert Haas (robertmh...@gmail.com) wrote:
> On Fri, Jan 30, 2015 at 5:20 AM, Etsuro Fujita
> wrote:
> > I noticed that when updating security barrier views on foreign tables,
> > we fail to give FOR UPDATE to selection queries issued at ForeignScan.
> > Here is an example.
[...]
> > postgres=#
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Robert Haas wrote:
> but there are times when it's easier to find out what release
> introduced a feature by looking at the release notes, and it's
> certainly more useful if you want to send a link to someone who
> is not git-aware illustrat
Roger Pack writes:
> On 2/2/15, José Luis Tallón wrote:
>> So yes, using one sequence per TOAST table should help.
>> Combined with the new SequenceAMs / sequence implementation being
>> proposed (specifically: one file for all sequences in a certain
>> tablespace) this should scale much better
On Sat, Jan 31, 2015 at 6:47 PM, Marco Nenciarini
wrote:
> Il 31/01/15 17:22, Erik Rijkers ha scritto:
>> On Sat, January 31, 2015 15:14, Marco Nenciarini wrote:
>>
>>> 0001-public-parse_filename_for_nontemp_relation.patch
>>> 0002-copydir-LSN-v2.patch
>>> 0003-File-based-incremental-backup-v8.pat
On 02/02/2015 09:38 PM, Robert Haas wrote:
Well, maybe I'm the only one who is doing this and it's not worth
worrying about it just for me. But I do it, all the same.
I do the later quite often: link people to old release notes. For me it
would be fine to remove them from tar balls as long as
Robert Haas writes:
> On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
>> So I'm bemused by Robert's insistence that he wants that format to support
>> searches. As I said, I find it far more convenient to search the output
>> of "git log" and/or src/tools/git_changelog --- I keep text files of t
On February 2, 2015 9:38:43 PM CET, Robert Haas wrote:
>On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
>> The existing release notes are not conveniently searchable, for sure;
>> they're not in a single file, and they don't show up on a single page
>> on the Web, and I've never seen a PDF-search
On Mon, Feb 2, 2015 at 10:06 PM, Robert Haas wrote:
> On Sat, Jan 31, 2015 at 6:47 PM, Marco Nenciarini
> wrote:
> > Il 31/01/15 17:22, Erik Rijkers ha scritto:
> >> On Sat, January 31, 2015 15:14, Marco Nenciarini wrote:
> >>
> >>> 0001-public-parse_filename_for_nontemp_relation.patch
> >>> 000
On 02/02/2015 09:36 PM, Roger Pack wrote:
On 2/2/15, José Luis Tallón wrote:
On 01/31/2015 12:25 AM, Jim Nasby wrote:
[snip]
It's a bit more complex than that. First, toast isn't limited to
bytea; it holds for ALL varlena fields in a table that are allowed to
store externally. Second, the limi
On 02/02/2015 07:54 AM, Robert Haas wrote:
The last 5 branches only takes us back to 9.0, which isn't very far.
I would want to have at least the 8.x branches in the SGML build, and
maybe the 7.x branches as well. I would be happy to drop anything
pre-7.x from the docs build and just let the p
On 2/1/15 11:10 PM, Tom Lane wrote:
> I think it's time we changed the policy of including all release notes
> back to the beginning in Appendix E.
I share the sentiment that the release notes *seem* too big, but the
subsequent discussion shows that it's not clear why that's really a
problem. Exa
On Mon, Feb 2, 2015 at 6:40 PM, Peter Eisentraut-2 [via PostgreSQL] <
ml-node+s1045698n5836471...@n5.nabble.com> wrote:
> On 2/1/15 11:10 PM, Tom Lane wrote:
> > I think it's time we changed the policy of including all release notes
> > back to the beginning in Appendix E.
>
> I share the sentimen
On 02/02/2015 05:39 PM, Peter Eisentraut wrote:
> On 2/1/15 11:10 PM, Tom Lane wrote:
>> I think it's time we changed the policy of including all release notes
>> back to the beginning in Appendix E.
>
> I share the sentiment that the release notes *seem* too big, but the
> subsequent discussion s
On 2/2/15 7:49 AM, Robert Haas wrote:
On Fri, Oct 24, 2014 at 8:51 PM, Jim Nasby wrote:
The comment for the BackgroundWorkerSlot structure tripped me up reviewing
Robert's background worker patch; it made it clear that you need to use a
memory barrier before setting in_use, but normally you'd n
On 2/2/15 3:50 PM, José Luis Tallón wrote:
Hmm 2^32 times aprox. 2kB (as per usual heuristics, ~4 rows per heap
page) is 8796093022208 (~9e13) bytes
... which results in 8192 1GB segments :O
Looks like partitioning might be needed much sooner than that (if only
for index efficiency reasons)
On Mon, Feb 02, 2015 at 4:48 AM, Heikki Linnakangas
wrote:
>> I think that the fundamental, unfixable race condition here is the
>> disconnect between index tuple insertion and checking for would-be
>> exclusion violations that exclusion constraints naturally have here,
>> that unique indexes natu
On 2/2/15 3:10 PM, Andres Freund wrote:
On February 2, 2015 9:38:43 PM CET, Robert Haas wrote:
On Mon, Feb 2, 2015 at 3:11 PM, Tom Lane wrote:
The existing release notes are not conveniently searchable, for sure;
they're not in a single file, and they don't show up on a single page
on the Web
Hi all,
Per $subject, I noticed that a markup was missing in the description
of the option --synchronous.
Patch is attached.
Regards,
--
Michael
diff --git a/doc/src/sgml/ref/pg_receivexlog.sgml b/doc/src/sgml/ref/pg_receivexlog.sgml
index be321b5..9405f0f 100644
--- a/doc/src/sgml/ref/pg_receive
On Sat, Jan 31, 2015 at 5:34 AM, Andres Freund wrote:
> On 2015-01-29 11:01:51 -0500, Robert Haas wrote:
>> On Wed, Jan 28, 2015 at 2:41 AM, Michael Paquier
>> wrote:
>> > Andres Freund wrote:
>> >> I think this isn't particularly pretty, but it seems to be working well
>> >> enough, and changing
Josh Berkus writes:
> On 02/02/2015 05:39 PM, Peter Eisentraut wrote:
>> I share the sentiment that the release notes *seem* too big, but the
>> subsequent discussion shows that it's not clear why that's really a
>> problem. Exactly what problem are we trying to fix?
> At a rough count of lines,
On Wed, Dec 24, 2014 at 12:42 AM, Alvaro Herrera
wrote:
>> Although that might be taking this thread rather far off-topic.
> Not really sure about that, because the only outstanding objection to
> this discussion is what happens in the startup stage if you specify -f.
> Right now vacuum is attempt
Where are we on this patch? No new version has been provided and there
have been comments provided by Heikki here
(5491e547.4040...@vmware.com) and by Alexei here
(87ppbqz00h@commandprompt.com).
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
Hi Fujita-san,
I agree that it's a problem, and it looks more severe when there are
multiple children
postgres=# create table parent (a int check (a < 0) no inherit);
CREATE TABLE
postgres=# create table child1 (a int check (a >= 0));
CREATE TABLE
postgres=# create table child2 (a int check (a >= 0
Hi all,
In exactly 3 places of the ECPG driver (for numeric, for interval and
for date), we do something as follows:
/* Allocation of mallocedval */
if (!(mallocedval = ecpg_strdup("array [", lineno)))
return false;
for (element = 0; element < var->arrsize; element++)
{
int
On 02/03/2015 05:59 AM, Michael Paquier wrote:
Hi all,
Per $subject, I noticed that a markup was missing in the description
of the option --synchronous.
+Issue sync commands as soon as there is WAL data which has
+not been flushed yet. Also status packets are sent back to the
Hi all,
In ecpg_add_mem of memory.c, we use ecpg_alloc but there is actually
no NULL-pointer check. If an OOM shows up exactly at this point, this
is likely to cause a crash. Attached patch adds some extra processing
to ecpg_add_mem to check if the allocation fails, and to fail properly
if an OOM
In relation to the talk and discussions at FOSDEM regarding
helping data recovery, I searched the archives for the
old thread after I performed my last recovery; for reference:
http://www.postgresql.org/message-id/20101019201223.ga15...@cuci.nl
I haven't checked yet if the proposed space there is
Hi Fujita-san,
I am having some minor problems running this repro
On Thu, Jan 15, 2015 at 12:45 PM, Etsuro Fujita wrote:
> Here is an example using postgres_fdw.
>
> [Terminal 1]
> postgres=# create table t (a int, b int);
> CREATE TABLE
> postgres=# insert into t values (1, 1);
> INSERT 0 1
>
On 02/02/2015 03:39 AM, Michael Paquier wrote:
In metaphone() we do the following:
/* return an empty string if we receive one */
if (!(str_i_len > 0))
PG_RETURN_TEXT_P(cstring_to_text(""));
if (str_i_len > MAX_METAPHONE_STRLEN)
erepor
On 02/02/2015 06:03 AM, Amit Langote wrote:
Attached does the following:
-* stmt->relation->relpersistence if the select namespace is temporary.
+* stmt->relation->relpersistence if the selected namespace is temporary.
Fixed, thanks.
- Heikki
--
Sent via pgsql-hackers mailing list (pgsql-h
On 03-02-2015 PM 04:49, Heikki Linnakangas wrote:
>
> Fixed, thanks.
Thanks!
Amit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
77 matches
Mail list logo
