On Sat, Nov 8, 2014 at 8:56 AM, Alvaro Herrera
wrote:
>
> I just pushed this, after some more minor tweaks. Thanks, and please do
> continue testing!
>
>
Here's another small fix for some unused variable warnings. Unfortunately
this Microsoft compiler that I'm using does not know about
__attribu
Hi Tom,
>If you don't need that, why are you insistent on extracting the
>information from a plan tree?
I need to resolve expressions and apply rewrite rules before I reverse the
query plan to a query.
>It seems far simpler to me to make use of ruleutils.c to reverse-list
>the original parsetree.
On Sat, Nov 8, 2014 at 5:55 AM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Fri, Nov 7, 2014 at 2:31 AM, Alvaro Herrera
>> wrote:
>
>> > I thought the consensus was that the SQL-callable function declarations
>> > should remain in builtins.h -- mainly so that quote.h does not need to
>>
In my Windows development environment, the tablespace regression test fails
approximately half the time. Buildfarm member frogmouth failed in the same
manner at least once:
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=frogmouth&dt=2014-05-21%2014%3A30%3A01
Here is a briefer command sequ
On Wed, Nov 5, 2014 at 6:36 AM, Peter Eisentraut wrote:
> While we're talking about removing old things, is there any use left for
> pg_standby?
+1 for this autumn cleanup.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
ht
Andrew Dunstan writes:
> On 11/07/2014 04:59 PM, Tom Lane wrote:
>> I think this is probably a variant of bug #11210, in which the problem is
>> that tupledescs bubbled up from inheritance children never get column
>> names assigned to them. I've been speculating about ways to fix that
>> but I'v
Tom Lane wrote:
> David Rowley writes:
> > I'm having problems getting this to compile on MSVC. Attached is a patch
> > which fixes the problem.
>
> The committed code is completely broken on compilers that don't accept
> varargs macros, and this patch will not make them happier.
I tried to make
On Thu, Nov 6, 2014 at 5:46 PM, Peter Eisentraut wrote:
> I think it's fine to log a message in the server log if the pg_hba.conf
> file needs reloading. But the client shouldn't know about this at all.
I agree.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL
On Tue, Nov 4, 2014 at 11:45 AM, Tom Lane wrote:
> I wrote:
>> However: at no point in this sequence did we flush the original catalog
>> blocks out of shared buffers. Therefore, a read of the database's
>> pg_class or pg_type at this point is likely to find the previous states of
>> those pages
On Fri, Nov 7, 2014 at 10:45 AM, Alvaro Herrera
wrote:
> Michael Paquier wrote:
>
>> Here are more thoughts among those lines looking at the current state of
>> the patch 4 that introduces the infrastructure of the whole feature. This
>> would make possible in-memory manipulation of jsonb containe
On Thu, Nov 6, 2014 at 8:03 PM, Jim Nasby wrote:
> The problem right now is there's no way to actually obtain evidence that
> this is (or isn't) something to worry about, because we just silently skip
> pages. If we had any kind of tracking on this we could stop guessing. :(
I could see logging i
David Rowley writes:
> I'm having problems getting this to compile on MSVC. Attached is a patch
> which fixes the problem.
The committed code is completely broken on compilers that don't accept
varargs macros, and this patch will not make them happier.
Probably what needs to happen is to put ext
You should add this patch here, so it doesn't get forgotten:
https://commitfest.postgresql.org/action/commitfest_view/open
On Fri, Nov 7, 2014 at 2:19 PM, Michael Banck wrote:
> 1. Should this log when the duration is exceeded (like log_lock_waits),
> or on commit? I guess the latter, cause log_
On Fri, Nov 7, 2014 at 7:26 PM, Petr Jelinek wrote:
>> My main problem is actually not with having tuple per-seqAM, but more
>> with the fact that Heikki does not want to have last_value as compulsory
>> column/parameter. How is the new AM then supposed to know where to pick
>> up and if it even c
On Fri, Nov 7, 2014 at 7:07 PM, Petr Jelinek wrote:
> The list of what is useful might be long,
That's FUD. It might also be short.
> but we can't have everything there
> as there are space constraints, and LSN is another 8 bytes and I still want
> to have some bytes for storing the "origin" or
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 tests by creating a
> symlink from the short-name tempdir that
Josh Berkus wrote:
> On 11/07/2014 04:43 PM, Alvaro Herrera wrote:
> > This says that the live multixact range goes from 123 million to 162
> > million; roughly 40 million values. (The default value for
> > vacuum_multixact_freeze_table_age is 150 million, which is what
> > determines how many val
On 11/07/2014 04:43 PM, Alvaro Herrera wrote:
> This says that the live multixact range goes from 123 million to 162
> million; roughly 40 million values. (The default value for
> vacuum_multixact_freeze_table_age is 150 million, which is what
> determines how many values are kept.)
>
> You gist.
Josh Berkus wrote:
> So, just did a quick survey of our managed services customers. 4 out of
> 6 have pg_multixact bloat. Basically it looks like this:
>
> User1 (the one above): 1.1GB
> User2: 64K
> User3: 929MB
> User4: 1.3GB
> User5: 301MB
> User6: 48K
>
> Nobody (out of 6 more) running a v
On 08/11/14 00:57, Petr Jelinek wrote:
On 08/11/14 00:45, Robert Haas wrote:
On Nov 5, 2014, at 5:43 PM, Petr Jelinek wrote:
I don't see how to make that work with ALTER SEQUENCE USING to be
honest and I do care quite a lot about that use-case (I think the
ability to convert the "local" sequen
On 11/05/2014 11:15 AM, Josh Berkus wrote:
> On 11/05/2014 10:40 AM, Jim Nasby wrote:
>> Can you post the contents of pg_multixact/members/?
>
> Well, not as of last week, obviously.
>
> https://gist.github.com/jberkus/d05db3629e8c898664c4
>
> I haven't pasted all the filenames, because, well, l
On 08/11/14 00:35, Robert Haas wrote:
On Nov 5, 2014, at 7:31 PM, Steve Singer wrote:
On 11/05/2014 05:43 PM, Andres Freund wrote:
On 2014-11-05 17:17:05 -0500, Steve Singer wrote:
Imo that's essentially a different feature. What you essentially would
need here is a 'commit sequence number' - b
On 11/07/2014 04:59 PM, Tom Lane wrote:
Andrew Dunstan writes:
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Could this be a bug in lookup_rowtype_tupdesc()?
I think this is probably a variant o
On 08/11/14 00:45, Robert Haas wrote:
On Nov 5, 2014, at 5:43 PM, Petr Jelinek wrote:
I don't see how to make that work with ALTER SEQUENCE USING to be honest and I do care
quite a lot about that use-case (I think the ability to convert the "local"
sequences to 3rd party ones and back is very
On Nov 5, 2014, at 5:43 PM, Petr Jelinek wrote:
> I don't see how to make that work with ALTER SEQUENCE USING to be honest and
> I do care quite a lot about that use-case (I think the ability to convert the
> "local" sequences to 3rd party ones and back is very important).
What specific problem
On Nov 4, 2014, at 4:20 PM, Peter Eisentraut wrote:
> On 11/3/14 5:17 PM, Petr Jelinek wrote:
>>> Please don't name anything "committs". That looks like a misspelling of
>>> something.
>>>
>>> There is nothing wrong with
>>>
>>> pg_get_transaction_commit_timestamp()
>>>
>>> If you want to redu
On Sat, Nov 8, 2014 at 8:56 AM, Alvaro Herrera
wrote:
>
> I just pushed this, after some more minor tweaks. Thanks, and please do
> continue testing!
>
>
I'm having problems getting this to compile on MSVC. Attached is a patch
which fixes the problem.
There also seems to be a bit of a problem w
> On Nov 5, 2014, at 7:31 PM, Steve Singer wrote:
>> On 11/05/2014 05:43 PM, Andres Freund wrote:
>> On 2014-11-05 17:17:05 -0500, Steve Singer wrote:
>> Imo that's essentially a different feature. What you essentially would
>> need here is a 'commit sequence number' - but no timestamps. And
>> pr
> On Mon, Oct 27, 2014 at 2:35 AM, Kouhei Kaigai wrote:
> >> FYI, patch v12 part 2 no longer applies cleanly.
> >>
> > Thanks. I rebased the patch set according to the latest master branch.
> > The attached v13 can be applied to the master.
>
> I've committed parts 1 and 2 of this, without the do
On Mon, Oct 27, 2014 at 2:35 AM, Kouhei Kaigai wrote:
>> FYI, patch v12 part 2 no longer applies cleanly.
>>
> Thanks. I rebased the patch set according to the latest master branch.
> The attached v13 can be applied to the master.
I've committed parts 1 and 2 of this, without the documentation, a
On Saturday, November 8, 2014, Tom Lane wrote:
>
> I'm confused too. The original example seemed to imagine that details
> of a query (not the function, but the calling query) would be stored in
> the catalogs, which is completely nuts.
>
> pg_proc already has provisions to remember the names of
On 11/07/2014 01:30 PM, Robert Haas wrote:
> On Fri, Nov 7, 2014 at 4:00 PM, Josh Berkus wrote:
>> In order for this to work, the archive would need to stop before
>> recovery_target_time.
>
> Yeah, good point. I didn't think of the case where you've rewound the
> master but not the archive. Th
Andrew Dunstan writes:
> On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
>> row_to_json() yields empty strings for json keys if the data is
>> fulfilled by an index only scan.
> Could this be a bug in lookup_rowtype_tupdesc()?
I think this is probably a variant of bug #11210, in which the problem
On Fri, Nov 7, 2014 at 4:42 PM, Alvaro Herrera wrote:
> Robert Haas wrote:
>> I personally think that's getting our priorities backwards, but
>> there's clearly a spectrum in terms of how much people care about the
>> cost of partial compiles, and I'm clearly all the way on one end of
>> it. I do
Robert Haas wrote:
> I personally think that's getting our priorities backwards, but
> there's clearly a spectrum in terms of how much people care about the
> cost of partial compiles, and I'm clearly all the way on one end of
> it. I don't like having to think hard about where a function
> proto
Robert Haas writes:
> On Fri, Nov 7, 2014 at 11:31 AM, Atri Sharma wrote:
>> Can I store relattnos or something? I need to get the stored att in planner
>> and build pathkeys from it.
> I still can't really follow. The columns returned by an SRF can't
> change after the function is created, so
I did \o /tmp/tst, then
\dS
create table "eh | oh" ();
\dS
and then filtered the output file to HTML. The CREATE TABLE tag ended
up in the same line as the title of the following table. I think
there's a newline is missing somewhere.
The good news is that the | in the table name was processed
On Fri, Nov 7, 2014 at 3:55 PM, Alvaro Herrera wrote:
> Michael Paquier wrote:
>> On Fri, Nov 7, 2014 at 2:31 AM, Alvaro Herrera
>> wrote:
>
>> > I thought the consensus was that the SQL-callable function declarations
>> > should remain in builtins.h -- mainly so that quote.h does not need to
>>
On Fri, Nov 7, 2014 at 4:00 PM, Josh Berkus wrote:
> On 11/07/2014 12:02 PM, Robert Haas wrote:
>> Several people then suggested that you could accomplish your
>> originally stated goal - namely "restore a master *and replica* to a
>> point in time before Bad Stuff happened, and then have a workin
On Fri, Nov 7, 2014 at 12:52 PM, Robert Haas wrote:
> Committed with some copy-editing based on Andreas's comments.
Thank you both.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpr
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Kevin Grittner wrote:
>> I think most people have always assumed that
>> BEGIN starts the transaction and that is the point at
>> which the snapshot is obtained.
> But there is so much evidence to the contrary. Not only does the
> *name* of t
On 11/07/2014 12:02 PM, Robert Haas wrote:
> Several people then suggested that you could accomplish your
> originally stated goal - namely "restore a master *and replica* to a
> point in time before Bad Stuff happened, and then have a working
> master-replica pair" - by just connecting the new sta
On Mon, Oct 6, 2014 at 3:09 AM, Heikki Linnakangas
wrote:
> On 07/18/2014 10:47 AM, Michael Paquier wrote:
>>
>> On Fri, Jul 18, 2014 at 3:54 AM, Peter Geoghegan wrote:
>>>
>>> I am not opposed to moving the contrib code into core in the manner
>>> that you oppose. I don't feel strongly either wa
Michael Paquier wrote:
> On Fri, Nov 7, 2014 at 2:31 AM, Alvaro Herrera
> wrote:
> > I thought the consensus was that the SQL-callable function declarations
> > should remain in builtins.h -- mainly so that quote.h does not need to
> > include fmgr.h.
> Moving everything to quote.h is done in-li
On Wed, Nov 5, 2014 at 8:30 PM, Peter Geoghegan wrote:
> Thanks for the review.
Committed with some copy-editing based on Andreas's comments.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postg
On Wed, Nov 5, 2014 at 7:17 PM, Álvaro Hernández Tortosa
wrote:
>>> Given a transaction started with "BEGIN (REPEATABLE READ |
>>> SERIALIZABLE)", if a concurrent session commits some data before *any*
>>> query
>>> within the first transaction, that committed data is seen by the
>>> tra
On Thu, Nov 6, 2014 at 9:17 PM, Amit Langote
wrote:
> I mentioned upthread about the possibility of resurrecting Itagaki-san's
> patch [1] to try to make things work in this direction. I would be willing to
> spend time on this. I see useful reviews of the patch by Robert [2], Simon
> [3] at
On Fri, Nov 7, 2014 at 11:31 AM, Atri Sharma wrote:
> Let me give an example:
>
> Consider an user defined SRF (or an inbuilt one (generate_series)). I am
> working on a path keys tracking project (more details on it in a separate
> email). I am interested in one of the columns of the result of th
On 11/07/2014 11:17 AM, Andrew Dunstan wrote:
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl;
On Fri, Nov 7, 2014 at 1:40 PM, Josh Berkus wrote:
> Is the current interaction of recovery_target_time and standby_mode
> (that is, that recovery_target_time causes standby_mode to be ignorned)
> the correct behavior?
I think this summary of the behavior is probably not correct in
detail. For e
On Fri, Nov 7, 2014 at 1:35 PM, Josh Berkus wrote:
> On 11/07/2014 08:12 AM, Robert Haas wrote:
>> On Wed, Nov 5, 2014 at 9:15 PM, Josh Berkus wrote:
>>> What I'm pointing out is that you can't actually do that. You think you
>>> can, but you can't.
>>
>> I do think that. You haven't explained
I just pushed this, after some more minor tweaks. Thanks, and please do
continue testing!
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On 2014-11-07 17:54:32 +0100, Petr Jelinek wrote:
> On 06/11/14 08:50, Andres Freund wrote:
> >On 2014-11-05 19:31:52 -0500, Steve Singer wrote:
> >>It also doesn't allow you to load two extensions at once on a system.
> >>You wouldn't be able to have both the 'steve_commit_order' extension
> >>and
On 7.11.2014 13:19, Katharina Büchse wrote:
> On 06.11.2014 11:56, Tomas Vondra wrote:
>> Dne 6 Listopad 2014, 11:15, Katharina Büchse napsal(a):
>>>
>>> because correlations might occur only in parts of the data. In this case
>>> a histogram based on a sample of the whole table might not get the p
Hi,
Am Montag, den 27.10.2014, 19:29 + schrieb Thom Brown:
> On 27 October 2014 19:21, Josh Berkus wrote:
> > I just realized that there is one thing we can't log currently:
> > transactions which last more than #ms. This is valuable diagnostic
> > information when looking for issues like ca
While we're talking about removing old things, is there any use left for
pg_standby?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
All,
The point of this thread was to determine:
Is the current interaction of recovery_target_time and standby_mode
(that is, that recovery_target_time causes standby_mode to be ignorned)
the correct behavior?
If Yes, then we have a tech bug and a doc bug:
Tech Bug: if the user sets both recover
On 11/07/2014 08:12 AM, Robert Haas wrote:
> On Wed, Nov 5, 2014 at 9:15 PM, Josh Berkus wrote:
>> What I'm pointing out is that you can't actually do that. You think you
>> can, but you can't.
>
> I do think that. You haven't explained why I'm wrong; just asserted
> than I am. Which doesn't r
On 10/28/2014 09:49 AM, Andrew Dunstan wrote:
On 10/27/2014 05:57 PM, Alvaro Herrera wrote:
Anyway this whole business of searching through the CASTSOURCETARGET
syscache seems like it could be refactored. If I'm counting correctly,
that block now appears four times (three in this patch, once
On 06/11/14 01:31, Steve Singer wrote:
On 11/05/2014 05:43 PM, Andres Freund wrote:
Is this patch supposed to:
A) Add commit timestamp tracking but nothing more
B) Add infrastructure to store commit timestamps and provide a facility
for storing additional bits of data extensions might want to
On 06/11/14 08:50, Andres Freund wrote:
On 2014-11-05 19:31:52 -0500, Steve Singer wrote:
It also doesn't allow you to load two extensions at once on a system.
You wouldn't be able to have both the 'steve_commit_order' extension
and BDR installed at the same time. I don't think this patch does
On 06/11/14 11:22, Craig Ringer wrote:
On 11/05/2014 05:01 AM, Petr Jelinek wrote:
I guess I could port BDR sequences to this if it would help (once we
have bit more solid agreement that the proposed API at least
theoretically seems ok so that I don't have to rewrite it 10 times if at
all possib
On Fri, Nov 7, 2014 at 7:15 PM, Robert Haas wrote:
> On Wed, Nov 5, 2014 at 8:24 AM, Atri Sharma wrote:
> > I am working on something that requires representing a SRF return column
> in
> > pg_proc and being able to retrieve it, retrieve the name of the column
> and
> > make a ColumnRef node fro
On 11/07/2014 10:51 AM, Ross Reedstrom wrote:
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl;
count
---
426
(1 row)
testjson=# SELEC
On Wed, Nov 5, 2014 at 9:15 PM, Josh Berkus wrote:
> What I'm pointing out is that you can't actually do that. You think you
> can, but you can't.
I do think that. You haven't explained why I'm wrong; just asserted
than I am. Which doesn't really get us anywhere.
However, if you do happen to
On Wed, Nov 5, 2014 at 6:19 PM, Andres Freund wrote:
> * In benchmarks it becomes apparent that the dynamic element width makes
> some macros like CHashTableGetNode() and
> CHashTableGetGarbageByBucket() quite expensive. At least gcc on x86
> can't figure how to build an efficient expression
This is a serious bug in 9.3.5 and 9.4 beta3:
row_to_json() yields empty strings for json keys if the data is
fulfilled by an index only scan.
Example:
testjson=# select count(*) from document_acl;
count
---
426
(1 row)
testjson=# SELECT row_to_json(combined_rows) FROM (
SELECT uuid, u
Craig Ringer wrote:
> On 11/05/2014 05:01 AM, Petr Jelinek wrote:
> > I guess I could port BDR sequences to this if it would help (once we
> > have bit more solid agreement that the proposed API at least
> > theoretically seems ok so that I don't have to rewrite it 10 times if at
> > all possible).
Michael Paquier wrote:
> Here are more thoughts among those lines looking at the current state of
> the patch 4 that introduces the infrastructure of the whole feature. This
> would make possible in-memory manipulation of jsonb containers without
> relying on a 3rd-part set of APIs like what this
On Wed, Nov 5, 2014 at 8:24 AM, Atri Sharma wrote:
> I am working on something that requires representing a SRF return column in
> pg_proc and being able to retrieve it, retrieve the name of the column and
> make a ColumnRef node from it.
>
> The catch here are aliases:
>
> SELECT generate_series(
Greg Stark wrote:
> I agree bloat isn't really a threat, but what about the relfrozenxid?
> If we skip even one page we don't get to advance it and retrying could
> eliminate those skipped pages and allow us to avoid a vacuum freeze
> which can be really painful. Of course that only works if you c
On Thu, Nov 6, 2014 at 5:13 PM, Tom Lane wrote:
> Jim Nasby writes:
>> On 11/5/14, 7:38 PM, Robert Haas wrote:
>>> I don't understand why you went to all the trouble of building a
>>> versioning system for extensions if you're not going to use it.
>
>> I was about to dismiss this comment since I
Hi,
On 2014-11-07 22:08:33 +0900, Michael Paquier wrote:
> After looking at a patch of this commit fest using
> rd_rel->relpersistence, I got a look at how many times this expression
> was being used directly in the backend code and wondered if it would
> not be useful to add a dedicated macro in
Hi all,
After looking at a patch of this commit fest using
rd_rel->relpersistence, I got a look at how many times this expression
was being used directly in the backend code and wondered if it would
not be useful to add a dedicated macro in rel.h to get the persistence
of a relation like in the pa
On Fri, Oct 31, 2014 at 5:46 PM, wrote:
>> > We seem to be going in circles. You suggested having two options,
>> > --feedback, and --fsync, which is almost exactly what Furuya posted
>> > originally. I objected to that, because I think that user interface
>> is
>> > too complicated. Instead, I s
Simon Riggs writes:
> It would be more useful to work on the applications of this
>
> 1. INSERT into a table
> * Action start time
> * Schema
> * Tablename
> * Number of blocks in table
> which would then allow you to do these things run an assessment report
> showing which tables would be rew
Ahoj ;-)
On 06.11.2014 11:56, Tomas Vondra wrote:
Hi,
Dne 6 Listopad 2014, 11:15, Katharina Büchse napsal(a):
Hi,
I'm a phd-student at the university of Jena, Thüringen, Germany, in the
field of data bases, more accurate query optimization.
I want to implement a system in PostgreSQL that dete
(2014/11/07 14:57), Kyotaro HORIGUCHI wrote:
Here are separated patches.
fdw-chk.patch - CHECK constraints on foreign tables
fdw-inh.patch - table inheritance with foreign tables
The latter has been created on top of [1].
[1]
http://www.postgresql.org/message-id/540da168.3040...@lab.ntt.co
On 11/07/2014 08:15 AM, Simon Riggs wrote:
How about we set lock level on each Foreign Key like this
[USING LOCK [lock level]]
level is one of
KEY - [FOR KEY SHARE] - default
ROW - [FOR SHARE]
TABLE SHARE - [ ]
TABLE EXCLUSIVE - [FOR TABLE EXCLUSIVE]
I like the idea and thinks it solves the
Hi Furuya-san,
(2014/11/07 16:54), furu...@pm.nttdata.co.jp wrote:
>> (2014/08/28 18:00), Etsuro Fujita wrote:
>>> (2014/08/22 11:51), Noah Misch wrote:
Today's ANALYZE VERBOSE messaging for former inheritance parents
(tables with relhassubclass = true but no pg_inherits.inhparent
l
80 matches
Mail list logo
