On Mon, 2013-03-04 at 08:35 +0100, Pavel Stehule wrote:
> in this use case I am think so some regression test is important - It
> should not be mine, but missing more explicit regression test is
> reason, why this bug was not detected some years.
I've added the tests.
--
Sent via pgsql-hacker
Kevin Grittner wrote:
> Andrew Dunstan wrote:
>> On 03/11/2013 12:30 PM, Fujii Masao wrote:
>>> Andrew Dunstan wrote:
The problem is that pg_dump is sending an empty query in
versions less than 9.3, and choking on that. Suggested fix
attached - there's really no reason to be doin
I'm writing my own /Group by/ operator (non-hashed implementation) and I'm
currently looking on a good data structure to store the result groups. There
are two requirement in my mind: the table need to be efficiently expanded
and the tuples within each group need to be sorted.
I carefully examined
Thanks Alvaro!
The thought of psql_help purely because it was the easiest at that time.
Since I've just begun my understanding of the code is barely negligible.
I began working on SEQUENCE related tests thereafter and hopefully would
move to more complicated tests in time. Peter's link is obvious
On Thu, Mar 14, 2013 at 1:51 AM, Jim Nasby wrote:
> On 3/12/13 9:10 AM, Ants Aasma wrote:
>> I have a feeling this is an increasingly widespread pattern with a
>> proliferation of mobile devices that need syncing.
>
> If you're doing that with timestamps you're asking for a slew of problems,
> not
On 2/13/13 10:06 PM, Vlad Arkhipov wrote:
- I don't need to deal with update conflicts, because I use
clock_timestamp() instead of current_timestamp.
You can still come across a conflict even with clock_timestamp(). What if
clocks go back during the time synchronization? Even if you have
Thom Brown writes:
> How about:
> CREATE FOREIGN TABLE tablename (id int DEFAULT PASSTHROUGH) SERVER pg_server;
> That way it will pass DEFAULT through to the remote table as it's
> defined on the table. Users can then explicitly insert values, or
> select the default, which will configured to
On 3/12/13 9:10 AM, Ants Aasma wrote:
I have a feeling this is an increasingly widespread pattern with a
proliferation of mobile devices that need syncing.
If you're doing that with timestamps you're asking for a slew of problems, not
all of which can be solved by just adding some random amoun
On 3/7/13 9:31 PM, Bruce Momjian wrote:
1 storage
2 storage controller
3 file system
4 RAM
5 CPU
I would add 2.5 in there: storage interconnect. iSCSI, FC, what-have-you.
Obviously not everyone has that.
My guess is that storage checksums only cover la
Tom Lane wrote:
> diff --git a/src/backend/rewrite/rewriteDefine.c
> b/src/backend/rewrite/rewriteDefine.c
> index
> a1a9808e5d94959218b415ed34c46579c478c177..896326615753f2344b466eb180080174ddeda31d
> 100644
> *** a/src/backend/rewrite/rewriteDefine.c
> --- b/src/backend/rewrite/rewriteDefine.c
Joe Conway writes:
> I think it should dump the user data portion, especially since that
> matches what pg_dump would do if you did not specify the table or schema.
+1
If you don't have time slots to fix that by then, I will have a look at
fixing that while in beta.
Regards,
--
Dimitri Fontain
On 03/13/2013 12:40 PM, David E. Wheeler wrote:
On Mar 13, 2013, at 5:17 AM, Robert Haas wrote:
What I think is tricky here is that there's more than one way to
conceptualize what the JSON data type really is. Is it a key-value
store of sorts, or just a way to store text values that meet cert
Josh Berkus writes:
> Tom,
>
>> If you're proposing changing the contents of the default prompt, I think
>> that has very little chance of passing. A new option for something to
>> add into a custom prompt might get accepted. I'm not sure that that
>> approach would do much for the scenario yo
On Wed, Mar 13, 2013 at 11:10 PM, Heikki Linnakangas <
hlinnakan...@vmware.com> wrote:
> On 01.03.2013 16:22, Alexander Korotkov wrote:
>
>> On Tue, Mar 12, 2013 at 8:03 PM, Heikki Linnakangas> vmware.com
>>
>>> wrote:
>>>
>>
>> So, after some hacking, I ended up with this version. I find it mor
2013-03-13 13:45 keltezéssel, Andres Freund írta:
On 2013-03-13 09:09:24 +0100, Boszormenyi Zoltan wrote:
2013-03-13 07:42 keltezéssel, Craig Ringer írta:
On 03/12/2013 06:27 AM, Craig Ringer wrote:
Think also about the case where someone wants to change multiple
values together and having jus
On 13 March 2013 19:04, Tom Lane wrote:
> Albe Laurenz writes:
>>> Yeah, I'm drifting towards the position that we should just define the
>>> defaults as being whatever they are locally, rather than trying to be
>>> cute about supporting remotely-executed defaults.
>
>> That was my first thought
On 03/13/2013 03:07 PM, Robert Haas wrote:
>> Is this intentional, or oversight, or missing feature?
>
> Hmm. It doesn't seem right to me. It seems like it should either
> dump everything, or dump just the user data portion, when the name
> matches. Not entirely sure which - probably the latter
On Fri, Mar 8, 2013 at 5:07 PM, Joe Conway wrote:
> (reposting" apparently I used a verboten word the first
> time around . Sorry for any duplicates)
>
> The -t and -n options of pg_dump do not dump anything from an extension
> configuration table, whereas normal pg_dump will dump the user data.
Andrew Dunstan wrote:
> On 03/11/2013 12:30 PM, Fujii Masao wrote:
>> Andrew Dunstan wrote:
>>> On 03/11/2013 10:43 AM, Andrew Dunstan wrote:
I noticed this morning that I am still getting failures on
9.0, 9.1 and 9.2 which cause my cross-version upgrade testing
to fail for git ti
Erikjan Rijkers wrote:
> With 9.3devel, I can't seem to join a matview to a view; surely
> that should be allowed?
Yes.
> Here is an example:
I expect to add a regression test based on that, once the bug is
fixed.
Thanks!
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterp
On 01.03.2013 16:22, Alexander Korotkov wrote:
On Tue, Mar 12, 2013 at 8:03 PM, Heikki Linnakangas
wrote:
So, after some hacking, I ended up with this version. I find it more
readable, I hope I didn't miss anything. This seems to produce results that
are close, but not identical, to the origin
Albe Laurenz writes:
>> Yeah, I'm drifting towards the position that we should just define the
>> defaults as being whatever they are locally, rather than trying to be
>> cute about supporting remotely-executed defaults.
> That was my first thought on the topic, to have a solution that
> is simpl
On Mar 13, 2013, at 10:59 AM, Andrew Dunstan wrote:
>> And my first cut at it won’t descend into sub-objects.
>
>
> The you wouldn't be doing it right. The whole thing about a recursive descent
> parser is that it's, well, recursive.
Right, but it would serve my immediate needs. I have a colu
On 03/13/2013 01:50 PM, David E. Wheeler wrote:
On Mar 13, 2013, at 10:45 AM, Andrew Dunstan wrote:
If someone wants functions to enforce a stricter validity check (e.g. via a
check constraint on a domain), or to convert json to a canonical version which
strips out prior keys of the same na
On Mar 13, 2013, at 10:45 AM, Andrew Dunstan wrote:
> If someone wants functions to enforce a stricter validity check (e.g. via a
> check constraint on a domain), or to convert json to a canonical version
> which strips out prior keys of the same name and their associated values,
> then these
On 03/13/2013 12:51 PM, Gavin Flower wrote:
On 14/03/13 02:02, Andrew Dunstan wrote:
On 03/13/2013 08:17 AM, Robert Haas wrote:
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan
wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last insta
Jeff,
> However, I'm willing to be convinced to exclude temp tables again.
>
Those reasons sound persuasive. Let's leave them in for 9.3.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Peter Eisentraut writes:
> At run time, this will sort itself out, because all the required modules
> will be loaded. The problem is when you create the "glue" extension and
> haven't invoked any code from any of the dependent extension in the
> session. Abstractly, the possible solutions are ei
On 14/03/13 02:02, Andrew Dunstan wrote:
On 03/13/2013 08:17 AM, Robert Haas wrote:
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan
wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last instance of a
key wins
and is actually stored
2.
On Mar 13, 2013, at 5:17 AM, Robert Haas wrote:
> What I think is tricky here is that there's more than one way to
> conceptualize what the JSON data type really is. Is it a key-value
> store of sorts, or just a way to store text values that meet certain
> minimalist syntactic criteria? I had i
Merlin Moncure writes:
> As long as lock as held between ctid examination and row modification
> you are ok. didn't read the patch, just pointing that out (history is
> full of client side drivers that did not do this properly).
> I also might have missed some of the finer contextual points of t
On Wed, Mar 13, 2013 at 10:15 AM, Tom Lane wrote:
> Andres Freund writes:
>> Perhaps pgsql-fdw should make sure the update was performed *without*
>> following the ctid chain to a new valid tuple?
>
> I did think about these issues before committing the patch ;-)
>
> The basic theory in PG's exis
Andres Freund writes:
> Perhaps pgsql-fdw should make sure the update was performed *without*
> following the ctid chain to a new valid tuple?
I did think about these issues before committing the patch ;-)
The basic theory in PG's existing design is to postpone locking rows as
long as possible;
We're seeing similar behaviour on several of our FreeBSD servers too.
It doesn't look like open files, or filesystem snapshots. Rebooting
does reset it, but restarting PG makes no difference.
We've got an assortment of different versions of both FreeBSD and
PostgreSQL, some of which are demonstrat
On 2013-03-13 09:51:59 -0500, Merlin Moncure wrote:
> On Wed, Mar 13, 2013 at 9:30 AM, Tom Lane wrote:
> > Merlin Moncure writes:
> >> On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane wrote:
> >>> Yeah, I considered that. I thought seriously about proposing that we
> >>> forget magic row identifiers a
Merlin Moncure writes:
> I just find it odd that rowid concept is used at all without strong
> guarantee that the record you are referencing is the one you are
> supposed to be referencing. Basically I'm saying PKEY semantics are
> the correct ones and that ctid is ok to use iff they match the pk
On Wed, Mar 13, 2013 at 9:30 AM, Tom Lane wrote:
> Merlin Moncure writes:
>> On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane wrote:
>>> Yeah, I considered that. I thought seriously about proposing that we
>>> forget magic row identifiers altogether, and instead make postgres_fdw
>>> require a remote
On 2013-03-13 18:52:48 +0530, Amit Kapila wrote:
> On Wednesday, March 13, 2013 6:44 PM Andres Freund wrote:
> > On 2013-03-13 18:38:12 +0530, Amit Kapila wrote:
> > > On Wednesday, March 13, 2013 6:10 PM Andres Freund wrote:
> > > > On 2013-03-12 10:46:53 +0530, Amit Kapila wrote:
> > > > > Do you
Merlin Moncure writes:
> On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane wrote:
>> Yeah, I considered that. I thought seriously about proposing that we
>> forget magic row identifiers altogether, and instead make postgres_fdw
>> require a remote primary key for a foreign table to be updatable.
> IMO,
Robert Haas writes:
> On Wed, Mar 6, 2013 at 12:06 PM, Tom Lane wrote:
>> On the other hand, I don't have a problem with decreeing that
>> non-Postgres FDWs need to use PK row identification in the first
>> release; which would be the consequence if we don't do anything about
>> allowing new syst
On Wed, Mar 6, 2013 at 11:06 AM, Tom Lane wrote:
> Shigeru Hanada writes:
>> I'm not sure whether postgres_fdw should support, but updatable views
>> have no system column including ctid. So, we need magic identifier,
>> perhaps it would be set of primary key value(s), to support updating
>> rem
On Wednesday, March 13, 2013 6:44 PM Andres Freund wrote:
> On 2013-03-13 18:38:12 +0530, Amit Kapila wrote:
> > On Wednesday, March 13, 2013 6:10 PM Andres Freund wrote:
> > > On 2013-03-12 10:46:53 +0530, Amit Kapila wrote:
> > > > Do you mean to say that because some variables can only be set
>
On 2013-03-13 18:38:12 +0530, Amit Kapila wrote:
> On Wednesday, March 13, 2013 6:10 PM Andres Freund wrote:
> > On 2013-03-12 10:46:53 +0530, Amit Kapila wrote:
> > > Do you mean to say that because some variables can only be set after
> > restart
> > > can lead to
> > > inconsistency, or is it be
On 2013-03-13 20:48:57 +0800, Craig Ringer wrote:
> On 03/13/2013 08:17 PM, Robert Haas wrote:
> > I think Andrew and I had envisioned this as basically a text data type
> > that enforces some syntax checking on its input, hence the current
> > design. But I'm not sure that's the ONLY sensible des
On Wednesday, March 13, 2013 6:10 PM Andres Freund wrote:
> On 2013-03-12 10:46:53 +0530, Amit Kapila wrote:
> > Do you mean to say that because some variables can only be set after
> restart
> > can lead to
> > inconsistency, or is it because of asynchronous nature of
> pg_reload_conf()?
>
> As l
On 03/13/2013 08:17 AM, Robert Haas wrote:
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan wrote:
So my order of preference for the options would be:
1. Have the JSON type collapse objects so the last instance of a key wins
and is actually stored
2. Throw an error when a JSON type has duplica
On 03/13/2013 08:17 PM, Robert Haas wrote:
> I think Andrew and I had envisioned this as basically a text data type
> that enforces some syntax checking on its input, hence the current
> design. But I'm not sure that's the ONLY sensible design.
We're probably stuck with it at this point, but it ma
On 2013-03-13 09:09:24 +0100, Boszormenyi Zoltan wrote:
> 2013-03-13 07:42 keltezéssel, Craig Ringer írta:
> >On 03/12/2013 06:27 AM, Craig Ringer wrote:
> Think also about the case where someone wants to change multiple
> values together and having just some set and not others would be
> >
On 2013-03-12 10:46:53 +0530, Amit Kapila wrote:
> Do you mean to say that because some variables can only be set after restart
> can lead to
> inconsistency, or is it because of asynchronous nature of pg_reload_conf()?
As long as SET PERSISTENT cannot be executed inside a transaction - or
only t
On Wed, Mar 6, 2013 at 12:06 PM, Tom Lane wrote:
> On the other hand, I don't have a problem with decreeing that
> non-Postgres FDWs need to use PK row identification in the first
> release; which would be the consequence if we don't do anything about
> allowing new system columns in 9.3. We will
On Fri, Mar 8, 2013 at 4:42 PM, Andrew Dunstan wrote:
>> So my order of preference for the options would be:
>>
>> 1. Have the JSON type collapse objects so the last instance of a key wins
>> and is actually stored
>>
>> 2. Throw an error when a JSON type has duplicate keys
>>
>> 3. Have the acces
Thanks Laurenz.
Would correct these (and readup) before submitting next patch.
--
Robins
Tharakan
On 13 March 2013 13:49, Albe Laurenz wrote:
> robins wrote:
> > Attached is a small patch to test corner cases related to Sequences
> (basically aimed at increasing
> > code-coverage of sequence.
2013-03-13 09:09 keltezéssel, Boszormenyi Zoltan írta:
2013-03-13 07:42 keltezéssel, Craig Ringer írta:
On 03/12/2013 06:27 AM, Craig Ringer wrote:
Think also about the case where someone wants to change multiple
values together and having just some set and not others would be
inconsistent.
Ye
On 2 March 2013 18:47, Heikki Linnakangas wrote:
>> Uh ... no. I haven't looked into why the flex tables are so large,
>> but this theory is just wrong. See ScanKeywordLookup().
>
>
> Interestingly, the yy_transition array generated by flex used to be much
> smaller:
>
> 8.3: 22072 elements
> 8
robins wrote:
> Attached is a small patch to test corner cases related to Sequences
> (basically aimed at increasing
> code-coverage of sequence.sql in regression tests).
>
> Look forward to any and all feedback.
Looks ok except that the patch is backwards
(all added lines start with "-"). I fo
2013-03-13 07:42 keltezéssel, Craig Ringer írta:
On 03/12/2013 06:27 AM, Craig Ringer wrote:
Think also about the case where someone wants to change multiple
values together and having just some set and not others would be
inconsistent.
Yeah, that's a killer. The reload would need to be schedul
Tom Lane wrote:
> Yeah, I'm drifting towards the position that we should just define the
> defaults as being whatever they are locally, rather than trying to be
> cute about supporting remotely-executed defaults. It looks to me like
> if we try to do the latter, we're going to have pitfalls and we
On Mar 13, 2013 3:04 AM, "Tom Lane" wrote:
>
> Palle Girgensohn writes:
> > ... I got lots of space freed
> > up, but it seems that after that the disk usage grows linearly (it seems
> > to leave many inodes unreferenced).
>
> Hm. We've seen issues in the past with PG processes failing to close
58 matches
Mail list logo
