Hello,
> 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, Á
Hello, I haven't look closer on their relationship.
> > 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 reli
Hi all
One of the remaining issues with row security is how to pass plan
invalidation information generated in the rewriter back into the planner.
With row security, it's necessary to set a field in PlannerGlobal,
tracking the user ID of the user the query was planned for if row
security was appl
On Wed, Mar 5, 2014 at 2:09 AM, Sawada Masahiko wrote:
>
> xlog.c:6177
> if (ControlFile->wal_level < WAL_LEVEL_HOT_STANDBY)
> ereport(ERROR,
> (errmsg("hot standby is not possible because wal_level was not
>
> So we have to start and stop standby server with changed
> wal_leve
On 03/04/2014 09:41 PM, Yeb Havinga wrote:
> On 04/03/14 02:36, Craig Ringer wrote:
>>
>> I've pushed an update to the branch with the fix for varno handling.
>> Thanks. It's tagged rls-9.4-upd-sb-views-v8 .
>>
>> I've almost run out of time to spend on row security for this
>> commitfest, unfortun
On Wed, Mar 5, 2014 at 4:09 AM, Sawada Masahiko wrote:
> 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'
On Sat, Mar 1, 2014 at 01:35:45PM -0500, Noah Misch wrote:
> Having that said, I can appreciate the value of tightening the socket mode for
> a bit of *extra* safety:
>
> --- a/src/test/regress/pg_regress.c
> +++ b/src/test/regress/pg_regress.c
> @@ -2299,4 +2299,5 @@ regression_main(int argc, ch
Andres Freund writes:
> On 2014-03-04 16:37:48 -0500, Tom Lane wrote:
>> However, it seems possible that we could have a mode in which a read-only
>> session did all its catalog fetches according to the transaction snapshot.
>> That would get us to a situation where the backend-internal lookups th
Greg Stark writes:
> On Tue, Mar 4, 2014 at 8:08 PM, Tom Lane wrote:
>> CREATE INDEX CONCURRENTLY, otoh, already did break pg_dump,
>> and we had to hack things to fix it; see commit
>> 683abc73dff549e94555d4020dae8d02f32ed78b.
> Well pg_dump was only broken in that there was a new catalog state
On 03/03/2014 06:48 AM, Michael Paquier wrote:
On Mon, Mar 3, 2014 at 1:13 PM, Andrew Dunstan wrote:
That difference actually made the file_fdw regression results plain
wrong,
in my view, in that they expected a quoted empty string to be turned to
null
even when the null string was something e
On 2014-03-04 16:37:48 -0500, Tom Lane wrote:
> However, it seems possible that we could have a mode in which a read-only
> session did all its catalog fetches according to the transaction snapshot.
> That would get us to a situation where the backend-internal lookups that
> ruleutils relies on wou
On Tue, Mar 4, 2014 at 8:08 PM, Tom Lane wrote:
> CREATE INDEX CONCURRENTLY, otoh, already did break pg_dump,
> and we had to hack things to fix it; see commit
> 683abc73dff549e94555d4020dae8d02f32ed78b.
Well pg_dump was only broken in that there was a new catalog state to
deal with. But the comm
On 2014-03-04 14:29:31 -0800, Josh Berkus wrote:
> On 03/04/2014 11:43 AM, Andres Freund wrote:
> > On March 4, 2014 8:39:55 PM CET, Simon Riggs wrote:
> >> I was going to add an option to increase lock level, but I can't see
> >> why you'd want it even. The dumps are consistent...
> >
> > Mvcc s
On 03/04/2014 11:43 AM, Andres Freund wrote:
> On March 4, 2014 8:39:55 PM CET, Simon Riggs wrote:
>> I was going to add an option to increase lock level, but I can't see
>> why you'd want it even. The dumps are consistent...
>
> Mvcc scans only guarantee that individual scans are consistent, not
On Wed, Jan 29, 2014 at 2:53 AM, KONDO Mitsumasa
wrote:
> Attached is latest patch.
> I change little bit at PinBuffer() in bufmgr.c. It will evict target clean
> file cache in OS more exactly.
>
> - if (!(buf->flags & BM_FADVED) && !(buf->flags & BM_JUST_DIRTIED))
> + if (!(buf->flags & BM_DIRTY)
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
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
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
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
* 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: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
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
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 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
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 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
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 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
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
* 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
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
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
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
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.
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
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
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 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
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
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
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
* 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
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
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
* 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
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
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 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
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 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 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 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,
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_
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
* 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
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
> >
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
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 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.
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
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
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
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
* 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 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 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 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
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
* 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
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
* 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.
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
* 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 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
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 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 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 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
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 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
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 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
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 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 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 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 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
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
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
> >
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
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
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/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
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 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
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
1 - 100 of 115 matches
Mail list logo
