OK. I'm not sure which idia is the best. So I wait for comments in
community:)
Hmmm. Maybe you can do what Tom voted for, he is the committer:-)
--
Fabien.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/m
On 4 March 2014 01:07, Andres Freund wrote:
> On 2014-03-03 19:15:27 -0500, Tom Lane wrote:
>> Noah Misch writes:
>> > Just to be clear, that list is not a commentary on the particular patch at
>> > hand. Those are merely the kinds of regressions to look for in a patch
>> > affecting this area o
(2014/03/04 17:28), Fabien COELHO wrote:
OK. I'm not sure which idia is the best. So I wait for comments in community:)
Hmmm. Maybe you can do what Tom voted for, he is the committer:-)
Yeah, but he might change his mind by our disscuttion. So I wait untill tomorrow,
and if nothing to comment,
Hi Oleg,
On Mon, Mar 3, 2014 at 7:17 AM, Oleg Bartunov wrote:
> you can always look at our development repository:
I think I found a bug:
[local]/postgres=# \d+ bar
Table "public.bar"
Column | Type | Modifiers | Storage | Stats target | Description
+---+-
>
> Good points.
>
> In most cases, DDL is applied manually after careful thought, so
> people seldom dump at the same time they upgrade the database. This is
> especially true for pg_dump since it captures the logical definition
> of tables. So most people will be happy with the default locking, b
On 4 March 2014 04:18, Amit Kapila wrote:
> On Mon, Mar 3, 2014 at 3:38 PM, Andres Freund wrote:
>> On 2014-02-28 20:55:20 +0530, Amit Kapila wrote:
>>> On Thu, Feb 27, 2014 at 4:14 PM, Christian Kruse
>>> > Well, as I already stated: we don't. I copied the behavior we use in
>>> > CHECK constrai
On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote:
> You're reasoning from a false premise: it's *not* necessarily an error.
When wouldn't it be an error? Can you give a real-life example of when
it would be a good idea to use the same name of an input parameter as
a declared variable?
Isn't this
Thanks, looks like a bug.
On Tue, Mar 4, 2014 at 12:38 PM, Peter Geoghegan wrote:
> Hi Oleg,
>
> On Mon, Mar 3, 2014 at 7:17 AM, Oleg Bartunov wrote:
>> you can always look at our development repository:
>
> I think I found a bug:
>
> [local]/postgres=# \d+ bar
> Table "
On 4 March 2014 08:39, Atri Sharma wrote:
>
>>
>> Good points.
>>
>> In most cases, DDL is applied manually after careful thought, so
>> people seldom dump at the same time they upgrade the database. This is
>> especially true for pg_dump since it captures the logical definition
>> of tables. So m
Hi all,
I think this patch is completely forgotten, and feel very unfortunate:(
Min, max, and stdev is basic statistics in general monitoring tools,
So I'd like to push it.
(2014/02/12 15:45), KONDO Mitsumasa wrote:
(2014/01/29 17:31), Rajeev rastogi wrote:
No Issue, you can share me the test
On Tue, Mar 4, 2014 at 1:30 AM, Oleg Bartunov wrote:
> Thanks, looks like a bug.
I guess this is down to the continued definition of gin_hstore_ops as
an opclass with text storage?:
+ CREATE OPERATOR CLASS gin_hstore_ops
+ DEFAULT FOR TYPE hstore USING gin
+ AS
+ OPERATOR7 @>
> > If its not the case, the user should be more careful about when he is
> > scheduling backups to so that they dont conflict with DDL changes.
>
> That is most certainly the wise choice.
>
> > I am not too comfortable with exposing the locking type to the user. That
> > may be just me though.
>
>
Hello, I examined the your patch and it seemed reasonable, but I
have one question about this patch.
You made ec_relids differ to the union of all ec members'
em_relids. Is it right?
At Mon, 03 Mar 2014 14:05:10 -0500, Tom Lane wrote
> Noah Misch writes:
> > If you are convinced that a sepa
Dear Developers,
Please help with the following problem. I am running PostgreSQL 9.2.3 on SUN
Solaris 9. This is 64 bit system with 32G swap and 16G RAM. I use same
configuration file as on Linux or SUN Solaris 10, where everything is ok. I am
unable to set shared buffer 5G, the maximum possible
I guess this is down to the continued definition of gin_hstore_ops as
an opclass with text storage?:
No, type of this storage describes type of keys. For gin_hstore_ops each key and
each value will be stored as a text value. The root of problem is a JavaScript
or/and our numeric type. In JavaScr
select '{"a": 25}'::json->>'a' = '{"a": 25.0}'::json->>'a';
?column?
--
f
Although for development version of hstore (not a current version)
# select 'a=> 25'::hstore = 'a=> 25.0'::hstore;
?column?
--
t
That is because compareJsonbValue compares numeric values with a help
On Tue, Mar 4, 2014 at 2:07 AM, Teodor Sigaev wrote:
> No, type of this storage describes type of keys. For gin_hstore_ops each key
> and each value will be stored as a text value. The root of problem is a
> JavaScript or/and our numeric type. In JavaScript (which was a base for json
> type) you n
On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev wrote:
> That is because compareJsonbValue compares numeric values with a help of
> numeric_cmp() instead of comparing text representation. This inconsistent
> will be fixed.
Cool.
--
Peter Geoghegan
--
Sent via pgsql-hackers mailing list (pgsql
On Tue, Mar 4, 2014 at 2:18 AM, Peter Geoghegan wrote:
> On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev wrote:
>> That is because compareJsonbValue compares numeric values with a help of
>> numeric_cmp() instead of comparing text representation. This inconsistent
>> will be fixed.
>
> Cool.
Perha
On 03/04/2014 11:59 AM, Yuri Levinsky wrote:
Dear Developers,
Please help with the following problem. I am running PostgreSQL 9.2.3 on SUN Solaris 9.
This is 64 bit system with 32G swap and 16G RAM. I use same configuration file as on
Linux or SUN Solaris 10, where everything is ok. I am unable
I tried try.mongodb.com
> 25 == 25.0
true
On Tue, Mar 4, 2014 at 2:18 PM, Peter Geoghegan wrote:
> On Tue, Mar 4, 2014 at 2:18 AM, Teodor Sigaev wrote:
>> That is because compareJsonbValue compares numeric values with a help of
>> numeric_cmp() instead of comparing text representation. This inc
On 03/03/2014 04:57 PM, Andres Freund wrote:
On 2014-03-03 16:27:05 +0200, Heikki Linnakangas wrote:
Attached is a rewritten version, which does the prefix/suffix tests directly
in heapam.c, and adds the prefix/suffix lengths directly as fields in the
WAL record. If you could take one more look
Do we have function to trim right zeros in numeric?
--
Teodor Sigaev E-mail: teo...@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes t
Hi,
On 03/03/14 21:03, Heikki Linnakangas wrote:
> I spotted this in section "17.4.1 Shared Memory and Semaphores":
>
> >Linux
> >
> >The default maximum segment size is 32 MB, and the default maximum total
> > size is 2097152 pages. A page is almost always 4096 bytes except in unusual
> >
Heikki,
I changed postgresql.conf to decrease those parameters but no change:
GMT54000FATAL: requested shared memory size overflows size_t
> My kernel is:
> set semsys:seminfo_semmap=64
> set semsys:seminfo_semmni=4096
> set semsys:seminfo_semmns=4096
> set semsys:seminfo_semmnu=4096
> set sems
On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev wrote:
> Do we have function to trim right zeros in numeric?
I'm not sure why you ask. I hope it isn't because you want to fix this
bug by making text comparisons in place of numeric comparisons work by
fixing the exact problem I reported, because th
On Tue, Mar 4, 2014 at 2:18 PM, Simon Riggs wrote:
> On 4 March 2014 04:18, Amit Kapila wrote:
>> I know that patch truncates the values if they are greater than certain
>> length (30), but the point is why it is not sufficient to have tuple location
>> (and primary key if available) which unique
On 2014-03-04 12:43:48 +0200, Heikki Linnakangas wrote:
> >>This ought to be tested with the new logical decoding stuff as it modified
> >>the WAL update record format which the logical decoding stuff also relies,
> >>but I don't know anything about that.
> >
> >Hm, I think all it needs to do disab
On 4 March 2014 09:31, Simon Riggs wrote:
> On 4 March 2014 08:39, Atri Sharma wrote:
>>
>>>
>>> Good points.
>>>
>>> In most cases, DDL is applied manually after careful thought, so
>>> people seldom dump at the same time they upgrade the database. This is
>>> especially true for pg_dump since i
On Mon, Mar 3, 2014 at 7:57 PM, Heikki Linnakangas
wrote:
> On 02/16/2014 01:51 PM, Amit Kapila wrote:
>>
>> On Wed, Feb 5, 2014 at 5:29 PM, Heikki Linnakangas
>> wrote:
>
> Thanks. I have to agree with Robert though that using the pglz encoding when
> we're just checking for a common prefix/suf
On Tue, Mar 4, 2014 at 6:57 AM, Simon Riggs wrote:
> The main impact I see is that this would block VACUUM while pg_dump runs.
>
> But then, while pg_dump runs VACUUM is ineffective anyway so perhaps
> that is no bad thing.
Well, a vacuum that's already running when pg_dump starts up may be
doing
2014-03-04 8:55 GMT+01:00 Pavel Stehule :
>
>
>
> 2014-03-03 18:18 GMT+01:00 Alvaro Herrera :
>
> Pavel Stehule escribió:
>> > This patch has redesigned implementation --if-exists for pg_dumpall.
>> Now it
>> > is not propagated to pg_dump, but used on pg_dumpall level.
>>
>> Seems sane, thanks.
>
On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev wrote:
Do we have function to trim right zeros in numeric?
Fixed, pushed to github
(https://github.com/feodor/postgres/tree/jsonb_and_hstore). Now it used
hash_numeric to index numeric value. As I can see, it provides needed trim and
doesn't de
I'd really like to see us find a way to apply some version of this
> patch. I was in favor of the concept 3 years ago when we did this the
> first time, and I've subsequently done quite a bit of work (viz., MVCC
> catalog snapshots) to eliminate the main objection that was raised at
> that time.
On 04/03/14 02:36, Craig Ringer wrote:
On 02/25/2014 01:28 AM, Dean Rasheed wrote:
On 13 February 2014 04:12, Craig Ringer wrote:
It's crashing while pulling up the query over "emp" (hl7.employee) and
"part" (hl7.participation).
Given the simplicity of what the row-security code its self is d
On 02/14/2014 01:13 PM, Andres Freund wrote:
There's a small issue in abfd192b, namely one of the error cases wasn't
changed when WalSndLoop was changed to be able to return.
I don't think this is likely to have any grave consequences, we'll
likely error out soon afterwards again.
Patch attache
On Tue, Mar 4, 2014 at 6:48 AM, Teodor Sigaev wrote:
>> On Tue, Mar 4, 2014 at 2:44 AM, Teodor Sigaev wrote:
>>>
>>> Do we have function to trim right zeros in numeric?
>
>
> Fixed, pushed to github
> (https://github.com/feodor/postgres/tree/jsonb_and_hstore). Now it used
> hash_numeric to index
On 4 March 2014 12:18, Robert Haas wrote:
> On Tue, Mar 4, 2014 at 6:57 AM, Simon Riggs wrote:
>> The main impact I see is that this would block VACUUM while pg_dump runs.
>>
>> But then, while pg_dump runs VACUUM is ineffective anyway so perhaps
>> that is no bad thing.
>
> Well, a vacuum that's
On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost wrote:
>> As I mentioned
>> up-thread, I'd really like to see FDW join push-down, FDW aggregate
>> push-down, parallel query execution, and parallel remote-FDW execution
>> and I don't see this CustomScan approach as the right answer to any of
>> those
* Kouhei Kaigai (kai...@ak.jp.nec.com) wrote:
> Do you think it makes sense if my submission was only interface portion
> without working example?
No, we're pretty strongly against putting in interfaces which don't have
working examples in contrib- for one thing, we want to know when we
break it.
On Tue, Mar 4, 2014 at 7:39 PM, Robert Haas wrote:
> On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost wrote:
> >> As I mentioned
> >> up-thread, I'd really like to see FDW join push-down, FDW aggregate
> >> push-down, parallel query execution, and parallel remote-FDW execution
> >> and I don't see
* Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> During EXPLAIN, ExecInitNode() is called. If ExecInitNode() fires queries
> to foreign servers, those would be fired while EXPLAINing a query as well.
> We want to avoid that. Instead, we can run EXPLAIN on that query at foreign
> server.
2014-03-04 23:09 GMT+09:00 Robert Haas :
> On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost wrote:
>>> As I mentioned
>>> up-thread, I'd really like to see FDW join push-down, FDW aggregate
>>> push-down, parallel query execution, and parallel remote-FDW execution
>>> and I don't see this CustomScan
* Robert Haas (robertmh...@gmail.com) wrote:
> More generally, I think this discussion is focusing on the wrong set
> of issues. The threshold issue for this patch is whether there is a
> set of hook points that enable a workable custom-scan functionality,
> and whether KaiGai has correctly identi
Kyotaro HORIGUCHI writes:
> Hello, I examined the your patch and it seemed reasonable, but I
> have one question about this patch.
> You made ec_relids differ to the union of all ec members'
> em_relids. Is it right?
ec_relids has never included child relids.
regards, to
On Tue, Mar 4, 2014 at 6:05 AM, Yuri Levinsky wrote:
> I changed postgresql.conf to decrease those parameters but no change:
> GMT54000FATAL: requested shared memory size overflows size_t
I think this means you are running on a 32-bit operating system, or at
least on a 32-bit build. That means
On Mon, Mar 3, 2014 at 12:08 PM, Stephen Frost wrote:
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
>> wrote:
>> > Is the TODO item "make an unlogged table logged" [1] a good GSoC project?
>>
>> I'm pretty sure we found some problems in
On 04/03/14 02:36, Craig Ringer wrote:
On 02/25/2014 01:28 AM, Dean Rasheed wrote:
On 13 February 2014 04:12, Craig Ringer wrote:
It's crashing while pulling up the query over "emp" (hl7.employee) and
"part" (hl7.participation).
Given the simplicity of what the row-security code its self is d
* Atri Sharma (atri.j...@gmail.com) wrote:
> If its not the case, the user should be more careful about when he is
> scheduling backups to so that they dont conflict with DDL changes.
I'm not following this as closely as I'd like to, but I wanted to voice
my opinion that this is just not acceptabl
Stephen Frost writes:
> * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
>> During EXPLAIN, ExecInitNode() is called. If ExecInitNode() fires queries
>> to foreign servers, those would be fired while EXPLAINing a query as well.
>> We want to avoid that. Instead, we can run EXPLAIN on that
On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
> On Mon, Mar 3, 2014 at 12:08 PM, Stephen Frost wrote:
> > * Robert Haas (robertmh...@gmail.com) wrote:
> >> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
> >> wrote:
> >> > Is the TODO item "make an unlogged table logged" [1] a good GS
Robert,
Please advise me: I just downloaded the source and compiled it. Sun Spark
Solaris 9 is always 64 bit, I verified it with sys admin. He may run 32 bit
applications as well. Have I use some special option during compilation to
verify that compiled PostgreSQL is actually 64 bit app?
Since
2014-03-04 23:10 GMT+09:00 Stephen Frost :
>> The "cache_scan" module that I and Haribabu are discussing in another
>> thread also might be a good demonstration for custom-scan interface,
>> however, its code scale is a bit larger than ctidscan.
>
> That does sound interesting though I'm curious ab
Joel Jacobson writes:
> On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote:
>> You're reasoning from a false premise: it's *not* necessarily an error.
> Isn't this almost exactly the same situation as we had in 9.0?
> "PL/pgSQL now throws an error if a variable name conflicts with a
> column name u
On Sun, Mar 02, 2014 at 05:38:38PM -0500, Noah Misch wrote:
> Concerning the immediate fix for non-Windows systems, does any modern system
> ignore modes of Unix domain sockets? It appears to be a long-fixed problem:
>
> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-1402
> http://unix.
huh. what it is the standard for equivalence? I guess we'd be
following javascript ===, right?
(http://dorey.github.io/JavaScript-Equality-Table/).
right.
But in your link I don't understand array (and object) equality rules. Hstore
(and jsonb) compare function believes that arrays are equal
On Tue, Mar 4, 2014 at 3:31 AM, Andres Freund
wrote:
>
> On 2014-03-04 01:10:50 -0300, Fabrízio de Royes Mello wrote:
> > Today I do something like that:
> >
> > 1) create unlogged table tmp_foo ...
> > 2) populate 'tmp_foo' table (ETL scripts or whatever)
> > 3) start transaction
> > 4) lock tabl
On Mon, Mar 03, 2014 at 08:15:41PM -0500, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Mar 03, 2014 at 01:29:00AM -0500, Tom Lane wrote:
> >> What I was envisioning was that we'd be relying on the permissions of the
> >> containing directory to keep out bad guys. Permissions on the socket
> >
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > * Ashutosh Bapat (ashutosh.ba...@enterprisedb.com) wrote:
> >> During EXPLAIN, ExecInitNode() is called. If ExecInitNode() fires queries
> >> to foreign servers, those would be fired while EXPLAINing a query as well.
> >> We want t
Stephen Frost escribió:
> * Atri Sharma (atri.j...@gmail.com) wrote:
> > If its not the case, the user should be more careful about when he is
> > scheduling backups to so that they dont conflict with DDL changes.
>
> I'm not following this as closely as I'd like to, but I wanted to voice
> my opi
Hello,
RFE: Consider that you want to run pg_upgrade via some script with some
default '-o' option. But then you also want to give the script's user a
chance to specify the old-server's options according user's needs.
Then something like the following is not possible:
$ cat script
...
pg_
On Tue, Mar 4, 2014 at 8:19 PM, Stephen Frost wrote:
> * Atri Sharma (atri.j...@gmail.com) wrote:
> > If its not the case, the user should be more careful about when he is
> > scheduling backups to so that they dont conflict with DDL changes.
>
> I'm not following this as closely as I'd like to,
On Tue, Mar 4, 2014 at 11:50 AM, Andres Freund
wrote:
>
> On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
> > On Mon, Mar 3, 2014 at 12:08 PM, Stephen Frost
wrote:
> > > * Robert Haas (robertmh...@gmail.com) wrote:
> > >> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
> > >> wrote:
>
On Mon, Mar 3, 2014 at 7:52 AM, Robert Haas wrote:
> But all that having been said, a deadline is a deadline, so if anyone
> wishes to declare this untimely please speak up.
Hearing only crickets, committed.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Comp
On Tue, Mar 4, 2014 at 4:06 PM, Tom Lane wrote:
> Joel Jacobson writes:
>> On Tue, Mar 4, 2014 at 12:55 AM, Tom Lane wrote:
>>> You're reasoning from a false premise: it's *not* necessarily an error.
>
>> Isn't this almost exactly the same situation as we had in 9.0?
>> "PL/pgSQL now throws an e
On Tue, Mar 4, 2014 at 10:17 AM, Alvaro Herrera
wrote:
> One possible idea would be to create a new lock level which conflicts
> with DDL changes but not with regular operation including dumps; so it
> wouldn't self-conflict but it would conflict with ShareUpdateExclusive.
> pg_dump would acquire
Alvaro Herrera writes:
> One concern is schema changes that make a dump unrestorable, for
> instance if there's a foreign key relationship between tables A and B,
Yeah. Ideally, what pg_dump would produce would be a consistent snapshot
of the database state as of its transaction snapshot time.
On Tue, Mar 4, 2014 at 9:53 AM, Yuri Levinsky wrote:
> Robert,
> Please advise me: I just downloaded the source and compiled it. Sun Spark
> Solaris 9 is always 64 bit, I verified it with sys admin. He may run 32 bit
> applications as well. Have I use some special option during compilation to
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Yeah. Ideally, what pg_dump would produce would be a consistent snapshot
> of the database state as of its transaction snapshot time. We have always
> had that guarantee so far as user data was concerned, but it's been shaky
> (and getting worse) so far as
Robert Haas writes:
> I think this is all too late for 9.4, though.
I agree with the feeling that a meaningful fix for pg_dump isn't going
to get done for 9.4. So that leaves us with the alternatives of
(1) put off the lock-strength-reduction patch for another year;
(2) push it anyway and accept
Stephen Frost writes:
> I don't have too much of an issue with the above, but I would like to
> have us figure out a solution to the deadlock problem with parallel
> pg_dump. The issue arises when pg_dump gets an AccessShareLock and then
> another process attempts to acquire an AccessExclusiveLoc
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I don't have too much of an issue with the above, but I would like to
> > have us figure out a solution to the deadlock problem with parallel
> > pg_dump. The issue arises when pg_dump gets an AccessShareLock and then
> > another
Tom Lane escribió:
> I'd like to have lock strength reduction as much as anybody, but it
> can't come at the price of reduction of reliability.
Can we have at least a cut-down version of it? If we can just reduce
the lock level required for ALTER TABLE / VALIDATE, that would be an
enormous impro
Hi all,
I had doubts regarding behavior of CheckRequiredParameterValues() function.
I could not start standby server which is created by pg_basebackup
with following scenario.
1. Start the master server with 'wal_level = archve' , 'hot_standby =
on' and other settings of replication.
2. Create th
On Tue, Mar 4, 2014 at 10:20 PM, Stephen Frost wrote:
> * Tom Lane (t...@sss.pgh.pa.us) wrote:
> > Stephen Frost writes:
> > > I don't have too much of an issue with the above, but I would like to
> > > have us figure out a solution to the deadlock problem with parallel
> > > pg_dump. The issue
On 03/03/2014 09:06 PM, Peter Geoghegan wrote:
> On Mon, Mar 3, 2014 at 9:05 PM, Andrew Dunstan wrote:
>> What you're not welcome to do, from my POV, is move jsonb into the hstore
>> extension. I strenuously object to any such plan.
>
> We both know that that isn't really the point of contention
Pavel Stehule escribió:
> Hello
>
> updated version - a precheck is very simple, and I what I tested it is
> enough
Okay, thanks. I pushed it after some more editorialization. I don't
think I broke anything, but please have a look.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund wrote:
> On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
>> On Mon, Mar 3, 2014 at 12:08 PM, Stephen Frost wrote:
>> > * Robert Haas (robertmh...@gmail.com) wrote:
>> >> On Mon, Mar 3, 2014 at 11:28 AM, Fabrízio de Royes Mello
>> >> wrote:
>> >> > I
On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
> Robert Haas writes: > I think this is all too
> late for 9.4, though.
>
> I agree with the feeling that a meaningful fix for pg_dump isn't going
> to get done for 9.4. So that leaves us with the alternatives of (1)
> put off the lock-strength-reduc
On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
> On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund wrote:
> > On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
> > Can't that be solved by just creating the permanent relation in a new
> > relfilenode? That's equivalent to a rewrite, yes, but we need t
Kyotaro HORIGUCHI wrote:
> Hi, I saw this patch has been moved into "committed patches" but
> only the first part (0001_..) for the core is committed as of
> 32001ab but the rest for extension side seem not to have been
> committed.
>
> Would you mind taking a look on that, Álvaro?
Yep, pushed.
2014-03-04 19:12 GMT+01:00 Alvaro Herrera :
> Pavel Stehule escribió:
> > Hello
> >
> > updated version - a precheck is very simple, and I what I tested it is
> > enough
>
> Okay, thanks. I pushed it after some more editorialization. I don't
> think I broke anything, but please have a look.
>
I
On 03/04/2014 11:23 AM, Joel Jacobson wrote:
I understand that from a technical perspective, the mandatory
BEGIN...END you always need in a PL/pgSQL function, is a new block,
and the variables declared are perhaps technically in a new block, at
a deeper level than the IN/OUT variables. But I wo
Pavel Stehule escribió:
> 2014-03-04 19:12 GMT+01:00 Alvaro Herrera :
>
> > Pavel Stehule escribió:
> > > Hello
> > >
> > > updated version - a precheck is very simple, and I what I tested it is
> > > enough
> >
> > Okay, thanks. I pushed it after some more editorialization. I don't
> > think I
* Robert Haas (robertmh...@gmail.com) wrote:
> On Mon, Mar 3, 2014 at 5:15 PM, Stephen Frost wrote:
> > In accordance with the above, what I'd like to see with this patch is
> > removal of the postgres_fdw changes and any changes which were for that
> > support. In addition, I'd like to understan
I apologize for not having paid much attention to this thread so far.
It kept getting stuck on my "to look at later" queue. Anyway, I've
taken a preliminary look at the v7 patch now.
While the patch seems roughly along the lines of what we talked about
last PGCon, I share Stephen's unease about a
On 4 March 2014 16:27, Tom Lane wrote:
> Alvaro Herrera writes:
>> One concern is schema changes that make a dump unrestorable, for
>> instance if there's a foreign key relationship between tables A and B,
>
> Yeah. Ideally, what pg_dump would produce would be a consistent snapshot
> of the data
On March 4, 2014 8:39:55 PM CET, Simon Riggs wrote:
>On 4 March 2014 16:27, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> One concern is schema changes that make a dump unrestorable, for
>>> instance if there's a foreign key relationship between tables A and
>B,
>>
>> Yeah. Ideally, what pg_dum
On Tue, Mar 4, 2014 at 3:29 PM, Andres Freund
wrote:
>
> On 2014-03-04 12:54:02 -0500, Robert Haas wrote:
> > On Tue, Mar 4, 2014 at 9:50 AM, Andres Freund
wrote:
> > > On 2014-03-04 09:47:08 -0500, Robert Haas wrote:
> > > Can't that be solved by just creating the permanent relation in a new
> >
2014-03-04 20:20 GMT+01:00 Alvaro Herrera :
> Pavel Stehule escribió:
> > 2014-03-04 19:12 GMT+01:00 Alvaro Herrera :
> >
> > > Pavel Stehule escribió:
> > > > Hello
> > > >
> > > > updated version - a precheck is very simple, and I what I tested it
> is
> > > > enough
> > >
> > > Okay, thanks. I
Andres Freund writes:
> On 2014-03-04 11:40:10 -0500, Tom Lane wrote:
>> I don't care for (2). I'd like to have lock strength reduction as
>> much as anybody, but it can't come at the price of reduction of
>> reliability.
> I am sorry, but I think this is vastly overstating the scope of the
> pg
On 3 March 2014 23:00, Florian Pflug wrote:
>> * In show_windowagg_info(), this calculation looks suspicious to me:
>>
>>double tperrow = winaggstate->aggfwdtrans /
>>(inst->nloops * inst->ntuples);
>>
>> If the node is executed multiple times, aggfwdtrans will be reset in
>> e
Hi all,
Is the TODO item "CREATE SCHEMA ... LIKE ..." [1] a good GSoC project?
Regards
[1] http://wiki.postgresql.org/wiki/Todo
--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedi
On Tue, Mar 4, 2014 at 8:04 PM, Andrew Dunstan wrote:
> Lots of code quite correctly relies on this,
> including some I have written.
I really cannot see when it would be a good coding practise to do so,
there must be something I don't understand, I would greatly appreciate
if you can give a real
On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost wrote:
> Alright- so do you feel that the simple ctidscan use-case is a
> sufficient justification and example of how this can be generally
> useful that we should be adding these hooks to core..? I'm willing to
> work through the patch and clean it u
* Robert Haas (robertmh...@gmail.com) wrote:
> On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost wrote:
> > Alright- so do you feel that the simple ctidscan use-case is a
> > sufficient justification and example of how this can be generally
> > useful that we should be adding these hooks to core..? I
On Tue, Mar 4, 2014 at 2:39 PM, Simon Riggs wrote:
> On 4 March 2014 16:27, Tom Lane wrote:
>> Alvaro Herrera writes:
>>> One concern is schema changes that make a dump unrestorable, for
>>> instance if there's a foreign key relationship between tables A and B,
>>
>> Yeah. Ideally, what pg_dump
On 03/04/2014 03:40 PM, Joel Jacobson wrote:
On Tue, Mar 4, 2014 at 8:04 PM, Andrew Dunstan wrote:
Lots of code quite correctly relies on this,
including some I have written.
I really cannot see when it would be a good coding practise to do so,
there must be something I don't understand, I wo
2014-03-05 5:52 GMT+09:00 Stephen Frost :
> * Robert Haas (robertmh...@gmail.com) wrote:
>> On Tue, Mar 4, 2014 at 2:34 PM, Stephen Frost wrote:
>> > Alright- so do you feel that the simple ctidscan use-case is a
>> > sufficient justification and example of how this can be generally
>> > useful th
Robert Haas writes:
> On Tue, Mar 4, 2014 at 2:39 PM, Simon Riggs wrote:
>> Your earlier claim that the dump is inconsistent just isn't accurate.
>> We now have MVCC catalogs, so any dump is going to see a perfectly
>> consistent set of data plus DDL. OK the catalogs may change AFTER the
>> snaps
1 - 100 of 115 matches
Mail list logo
